iOS componentization exploration: creation of private libraries

iOS componentization is basically based on cocoapods. How to use cocoapods to create your own component library is the most important factor in realizing componentization. The following will fully present the specific process of making a private library through gif pictures. Ready? Let's get started together~

1: Create an index library for private libraries

Creating an index library for a private library is a bit confusing, so let's look at it separately:

1. Private library: refers to where we actually place the component code.
2. Index library: The place where spec files are stored, used to index the location of the code.

For example, the index library is like a pointer, and the private library is like an object. The pointer stores the address of the object, and the object can be found through the address!

2: Add the created index library to the local cocoapods repository

1.cocoapods local warehouse path

 $ ~/.cocoapods/repos

2. Add your own remote index library locally

 $ pod repo add QinzRepo https://gitee.com/Qinz_323/QinzRepo.git

The above is to simply place the index library we created ourselves in the warehouse managed by cocoapods. By default, there is only one master warehouse, and the local indexes of SDWebImage, AFNetWoking, etc. that we commonly use are in this warehouse. Now we create our own warehouse through Code Cloud, so we need to create our own index warehouse, which only stores the index files of each component, not the code!

Three: Create a template

Command to create a template

 $ pod lib create QinzTool

This command will automatically create a template project, which contains the index file we need in the spec format. Next, we can use this template file to make our own components.

Four: Put our own components into the specified directory

Put the component into the specified file.gif

In the template file, you will see a Development pods folder, which represents the local component library. Here we put the Tool file (that is, the component we made ourselves) in the specified folder and then introduce it into the project. So far, our local third-party component has been made. Now we can run pod install in the terminal to see the effect! Of course, we will definitely not be limited to the local, and the next step is how to make an online component library!

5. Upload the prepared components to Code Cloud

1. Execute the following three commands to upload the template file

 $ cd /Users/Qinz/Desktop/QinzTool/QinzTool
 $ git remote add origin https://gitee.com/Qinz_323/Tool.git
 $ git push -u origin master

Here you will find that I have created a new project, which is different from the index library project I created before. This is where we actually put the encapsulated code. Here we choose to import an existing project. After clicking Create, some command prompts will be generated. We find the three commands at the bottom and upload the local template to the warehouse! See the figure below:

2. Upload the component code. In the previous step, only the template file was uploaded.

 $ git add .
 $ git commit -m 'initialize'  
 $ git push -u origin master

-m 'initialization' is the submitted note information, which can be filled in according to your needs. At the same time, you can go to the website to check the changes in the warehouse at any time! See the figure below:

6. Change the template file related information

We open the Xcode project, find the file with the .podspec suffix, change s.summary, which is the brief description displayed in pod search, s.version is the version number, the default is 0.1.0, no need to modify it, and then mainly modify the address in s.homepage and s.source to create the address of the component warehouse for us!

7: Verify the spec file

 $ pod lib lint --private  
 If a warning appears, you can
 s.homepage = 'https://gitee.com/Qinz_323/Tool'  
 Change to
 s.homepage = 'https://gitee.com/Qinz_323'  

Here we verify our spec file to see if it meets the requirements! If an error is reported here, it means that there is a problem with your configuration of the spec file!

8: Make a branch for the version

 The 0.1.0 version number here should be consistent with the spec file
 $ git tag 0.1.0
 $ git push --tags  

The branching step is very important. It directly determines whether the following steps can continue. When we have a version update, we need to change the version number. The default here is 0.1.0. It must be consistent with the s.version number we saw in Xcode before!

9. Establish association

Create association.gif

 $ pod repo push QinzRepo QinzTool.podspec

Through this step, we have synchronized the remote and local index libraries. At this point, the private library has been created!

10: Use your own private library

When we want to use the private library we created, we need to reference the index warehouse address we created in the first step, that is, the pointer warehouse address, as shown above!