Shulou(Shulou.com)06/02 Report--

This article mainly introduces "what are the tips for iOS YBImageBrowser components to rely on to avoid conflicts". In daily operations, I believe many people have doubts about what are the tips for iOS YBImageBrowser components to rely on to avoid conflicts. Xiaobian consulted all kinds of materials and sorted out simple and easy-to-use methods of operation. I hope it will be helpful for you to answer the questions of "what are the tips for iOS YBImageBrowser components to rely on to avoid conflicts?" Next, please follow the editor to study!

Cause of the problem

This article takes the YBImageBrowser component as an example.

YBImageBrowser relies on SDWebImage, and some dependency conflicts may arise when using CocoaPods to integrate into a project. Recently, the community has mentioned several Issues and saw a high level of attention in Insights-> Traffic-> Popular content, so they have to solve them.

Strict version restrictions

During the iteration of an open source component, it would be nice to ensure the downward compatibility of the upper interface. In order to optimize performance and control memory, YBImageBrowser does not directly use its top-level interface, but uses download module and cache module separately. The iterative upgrade of SDWebImage can easily lead to the incompatibility of the author's components, so it has always been such a dependency:

S.dependency 'SDWebImage',' ~ > 5.0.0'

The advantage of this is to limit the scope of the version small enough to reduce the risk of component code errors caused by changes in the SDWebImage interface. However, if SDWebImage is upgraded to 5.1.0, CocoaPods is considered a dependency conflict regardless of whether the relevant API changes or not.

Other components rely on different versions of SDWebImage

When two components depend on different versions of the same component, and the dependent versions do not intersect, for example:

A.dependency 'SDWebImage',' ~ > 4.0.0'B.dependency 'SDWebImage',' ~ > 5.0.0'

Then there will be dependency conflicts when An and B are integrated into the project at the same time.

Solution

It is very convenient to use CocoaPods integration projects, and for component users, they always want to be able to integrate easily in any scenario, and can enjoy the update and optimization of components in the future. Obviously, the problems mentioned above may affect the convenience of integration.

More ambiguous version restrictions

In many cases, a large version of the component will not change the API, and we can hope that the popular components in the community will be compatible with each other, so relaxing the dependent version restrictions can cover more versions in the future (see rules: podspec dependency [2]):

S.dependency 'SDWebImage',' > = 5.0.0'

Why not just remove the version restrictions?

Because YBImageBrowser 3.x is based on SDWebImage 5.0.0, the author can clearly not be compatible with versions prior to 5.0.0, so this restriction is "perfect" to cover all versions until the relevant API incompatibility occurs in future iterative versions of SDWebImage.

Violent programmes to avoid relying on conflict

When other components rely on different versions of SDWebImage, the rough solution is as follows:

Directly modify the SDWebImage version that other components depend on.

Import YBImageBrowser into the project manually and modify the code to suit the current version of SDWebImage.

Community friend a method mentioned in Issue: find the YBImageBrowser folder in the ~ / .cocoapods/repos directory and change the dependent version of the SDWebImage in the corresponding version of the podspec.json file.

Obviously, the above solutions are not very elegant, it is difficult to manually import the project to enjoy the update and optimization of the components, and modifying the local repo information will be reset due to the update of the repo list.

An elegant solution to avoid relying on conflict

The occurrence of dependency conflicts is a problem that must be solved, the version restrictions on which other components depend can be regarded as invariants, and the solution can be considered from the aspect of component production.

The goal is to not only meet the rapid integration of components for some users, but also ensure that some users can enjoy the update and optimization of components in the future on the premise of resolving dependency conflicts.

The answer is subspec, and the following is part of the YBImageBrowser.podspec code (full code [3]):

S.subspec "Core" do | core | core.source_files = "YBImageBrowser/**/*. {NOSD m}" core.dependency 'SDWebImage',' > = 5.0.0'ends.subspec "NOSD" do | core | core.source_files = "YBImageBrowser/**/*. {hjorm}" core.exclude_files = "YBImageBrowser/WebImageMediator/YBIBDefaultWebImageMediator. {hjorm}" end

As a result, users are free to choose whether or not to rely on SDWebImage, and the look and feel in Podfile is something like this:

/ / rely on SDWebImagepod 'YBImageBrowser'//, not on SDWebImagepod' YBImageBrowser/NOSD'

So how should you tell the difference between relying on SDWebImage and providing a default implementation in your YBImageBrowser code?

The first step is to design an abstract interface (which does not depend on SDWebImage):

@ protocol YBIBWebImageMediator / / Download methode, caching methode, and so on.@end

The second step is to define an attribute in YBImageBrowser.h that follows this interface:

/ / mediators related to the image download cache (assignment can be customized) @ property (nonatomic, strong) id webImageMediator

The third step is to implement a default intermediary (this class relies on SDWebImage):

@ interface YBIBDefaultWebImageMediator: NSObject @ end@implementation YBIBDefaultWebImageMediator// implements the protocol method @ end through SDWebImage's API

The fourth step is to import and initialize the default mediator through conditional compilation in the internal code:

# if _ _ has_include ("YBIBDefaultWebImageMediator.h") # import "YBIBDefaultWebImageMediator.h" # endif...#if _ _ has_include ("YBIBDefaultWebImageMediator.h") _ webImageMediator = [YBIBDefaultWebImageMediator new]; # endif

The fifth step can also be seen in YBImageBrowser.podspec that two files are excluded when not relying on SDWebImage integration: YBIBDefaultWebImageMediator. {h.m}.

As a result, the goal is achieved:

Quickly integrate in an integration way that relies on SDWebImage.

Use an integration approach that does not rely on SDWebImage to avoid dependency conflicts in various situations, but note that this situation requires the implementation of a protocol-compliant intermediary.

At this point, the study on "what are the tips for iOS YBImageBrowser component dependency to avoid conflicts" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.