Basics of using Cocoapods in iOS app development
CocoaPods is a very powerful tool that has a must have status for any iOS Developer. With it, we can easily, quickly and simply connect a variety of tasty tools, utilities and libraries that make life easier for us when developing applications. But every tool must be able to use and CocoaPods is no exception.
Under the cat information that will allow you to start mastering this tool (based on what is stated in the documentation and personal experience). And so, dear reader, put aside the microscope, enough already to nail the nails and continue to read.
Podfile is just that magic specification, which shows all the dependencies necessary for our project. Podfile always creates an implicit target (target), named by default, which links it to the first target (target) of the project. This file should be named just Podfile and be in the same folder as the .xcodepoj file.
To begin with, it is very important to indicate for which platform and which version it is being developed. This is done like this:
')
In this example, we indicate that we are developing an application for iOS version not lower than 8.0
Next, we can hide all warnings from xCode that relate to the link libraries:
If you want to use plug-in libraries for several target'ov (for example for tests), for this you can use the command link_with :
In this example, we include libraries not only for the target of our application, but also for tests. But you need to be extremely careful with this command : this command connects all libraries to two target'am, and sometimes this can lead to errors in the work, for example, not all API methods that are familiar to us will work for Application Extension (the same extension Today Extension) .
A more reliable way is to manually set the target for which certain libraries will be connected:
With the help of such a Podfile, we have defined those libraries that will be used for both the widget and the application (shared_pods). And they outlined which ones should be connected for which target.
The next moment is also very important. Most often, in addition to the library name, we also indicate the version number that we want to use. We do it like this:
So we do this at a minimum because such recommendations are usually given to us in response to the query pod search . And on the one hand, this is correct, but on the other hand, nuances are possible.
How to avoid unnecessary loss of nerve cells? Otherwise, specify the version! There are many opportunities for this.
Thus, we indicate exactly which version we need:
In addition, we can use logical operators, which are not necessary to explain in detail: '> 4.1.4' or '> = 4.1.4' or '<4.1.4' or '<= 4.1.4'.
More need to talk about the operator '~>'. With it, we can specify the version that we need, but at the same time get the necessary bugfixes for it. For example, like this, '~> 0.1.2', we indicate that we want to use the library version from 0.1.2 to 0.2, but not including version 0.2. Or by specifying '~> 0.1' we indicate that we plan to use all versions from 0.1 to 1.0, but not including version 1.0.
In addition, we can specify the repository resource from which we will load the library:
But this is not all. By specifying a resource, we can still indicate the branch we need,
tag
or even a specific commit
Sometimes it happens that after installing a particular library, you need to open a particular project file that was generated by Cocoapods and add / remove / change some parameter there so that everything works correctly.
The first thing that comes to mind in such a situation: do everything as it should and write in the wiki on gitlab. It seems everything is okay. BUT! It is also necessary to write about this to the whole team in Skype ... and send the mailing list! And I will definitely link to the wiki ...
Made by And now everyone has forgotten about it. How to be? Use post_install !
In the example above, after installing all the necessary libraries, we loop through all the target'y of the project automatically created by cocoapods, find the right one among them, and then go through the settings of this target'and find the right one and add it to the build settings. In a specific example, for AFNetworking we set the parameter that allows using this library in the Application Extensions. And no more notes on the wiki. Totally! Well done!
Under the cat information that will allow you to start mastering this tool (based on what is stated in the documentation and personal experience). And so, dear reader, put aside the microscope, enough already to nail the nails and continue to read.
Podfile
Podfile is just that magic specification, which shows all the dependencies necessary for our project. Podfile always creates an implicit target (target), named by default, which links it to the first target (target) of the project. This file should be named just Podfile and be in the same folder as the .xcodepoj file.
To begin with, it is very important to indicate for which platform and which version it is being developed. This is done like this:
')
platform :ios, '8.0' In this example, we indicate that we are developing an application for iOS version not lower than 8.0
Next, we can hide all warnings from xCode that relate to the link libraries:
inhibit_all_warnings! Project target
If you want to use plug-in libraries for several target'ov (for example for tests), for this you can use the command link_with :
platform :ios, '6.0' link_with 'MyApp', 'MyApp Tests' pod 'AFNetworking', '~> 2.0' pod 'Objection', '0.9' In this example, we include libraries not only for the target of our application, but also for tests. But you need to be extremely careful with this command : this command connects all libraries to two target'am, and sometimes this can lead to errors in the work, for example, not all API methods that are familiar to us will work for Application Extension (the same extension Today Extension) .
A more reliable way is to manually set the target for which certain libraries will be connected:
def shared_pods pod 'AFNetworking' pod 'INTULocationManager' end target 'myapp' do shared_pods pod 'Reachability', '~> 3.1.1' pod 'sqlite3', '~> 3.8.4.3' end target 'mywidget' do shared_pods end With the help of such a Podfile, we have defined those libraries that will be used for both the widget and the application (shared_pods). And they outlined which ones should be connected for which target.
Library version
The next moment is also very important. Most often, in addition to the library name, we also indicate the version number that we want to use. We do it like this:
pod 'WebViewJavascriptBridge', '~> 4.1.4' So we do this at a minimum because such recommendations are usually given to us in response to the query pod search . And on the one hand, this is correct, but on the other hand, nuances are possible.
A small example.
You have connected a certain library (indicating the version as in the example above) and are actively using it, then for some time suspended the work on the project, and returned only after n time. And you decided to resume work with the pod update command, which will pull up new versions of the used libraries. We start the project and can face the fact that the library developer has added new methods, and those that you use have already been declared as deprecated or deleted altogether, or have accepted a merge request from another programmer, having checked it not very carefully, but he made a critical error and now everything crashes.
How to avoid unnecessary loss of nerve cells? Otherwise, specify the version! There are many opportunities for this.
Thus, we indicate exactly which version we need:
'WebViewJavascriptBridge', '4.1.4' In addition, we can use logical operators, which are not necessary to explain in detail: '> 4.1.4' or '> = 4.1.4' or '<4.1.4' or '<= 4.1.4'.
More need to talk about the operator '~>'. With it, we can specify the version that we need, but at the same time get the necessary bugfixes for it. For example, like this, '~> 0.1.2', we indicate that we want to use the library version from 0.1.2 to 0.2, but not including version 0.2. Or by specifying '~> 0.1' we indicate that we plan to use all versions from 0.1 to 1.0, but not including version 1.0.
In addition, we can specify the repository resource from which we will load the library:
pod 'CRToast', :git => 'https://github.com/akhatmullin/CRToast.git' But this is not all. By specifying a resource, we can still indicate the branch we need,
pod 'CRToast', :git => 'https://github.com/akhatmullin/CRToast.git', :branch => 'dev' tag
pod 'CRToast', :git => 'https://github.com/akhatmullin/CRToast.git', :tag => '0.7.0' or even a specific commit
pod 'CRToast', :git => 'https://github.com/akhatmullin/CRToast.git', :commit => '082f8310af' Automate maximum or post_install
Sometimes it happens that after installing a particular library, you need to open a particular project file that was generated by Cocoapods and add / remove / change some parameter there so that everything works correctly.
The first thing that comes to mind in such a situation: do everything as it should and write in the wiki on gitlab. It seems everything is okay. BUT! It is also necessary to write about this to the whole team in Skype ... and send the mailing list! And I will definitely link to the wiki ...
Made by And now everyone has forgotten about it. How to be? Use post_install !
post_install do |add_app_extension_macro| add_app_extension_macro.project.targets.each do |target| if target.name.include?("Pods-widget") target.build_configurations.each do |config| config.build_settings['GCC_PREPROCESSOR_DEFINITIONS'] ||= ['$(inherited)', 'AF_APP_EXTENSIONS=1'] end end end end In the example above, after installing all the necessary libraries, we loop through all the target'y of the project automatically created by cocoapods, find the right one among them, and then go through the settings of this target'and find the right one and add it to the build settings. In a specific example, for AFNetworking we set the parameter that allows using this library in the Application Extensions. And no more notes on the wiki. Totally! Well done!
Source: https://habr.com/ru/post/261711/
All Articles