English | 简体中文 | 繁體中文 | Русский язык | Français | Español | Português | Deutsch | 日本語 | 한국어 | Italiano | بالعربية
After learning to use others' Pods dependency libraries, you must be eager to create your own dependency libraries. Today, let's unveil the mystery of the Pods dependency library creation process. The entire creation process takes my implementation of a view named WZMarqueeView for scrolling text effects as an example, and the steps are as follows:
Firstly, create your own GitHub repository
CocoaPods are hosted on GitHub (the official link is:https://github.com/CocoaPods), and all Pods dependency libraries also depend on GitHub, so the first step we need to do is to create our own GitHub repository. The repository creation interface is as shown below:
The numbered items in the figure above total6The corresponding description is as follows:
1Repository name
Repository name, here write WZMarqueeView, which is required to be filled in;
2Description
Repository description information, optional;
3Repository publicality
Here you can only select Public, for one reason is that Private requires money, and the other is that Private others can't see and share it at all;
4Whether to create a default README file
A complete repository needs a README documentation, so it is recommended to check it. Of course, if you are not bothered, you can also manually create one later;
5Whether to add a .gitignore file
The .gitignore file records several types of files. For any file type included in this file, Git will not include it in version control. Whether to select it depends on personal needs;
6License type
All official repositories should have a license file, and Pods dependency libraries have stricter requirements for this file, which must be present. Therefore, it is best to have GitHub create one here, or you can create it yourself later. The license type I use is MIT.
After all the above items are filled in, click the Create repository button, and the successful creation interface is as shown below:
With this, the repository creation process is complete.
Secondly, clone the repository to the local machine
To facilitate the deletion of content in the repository, it is necessary to clone the repository to the local machine first. There are many ways to do this, and the recommended method is to use the command line:
$ git clone https://github.com/wangzz/WZMarqueeView.git
After the operation is completed, the corresponding files on GitHub will be copied to the local machine, with the directory structure as follows:
The .gitignore file in the repository on GitHub is a hidden file that starts with a dot, so only two are visible here.
All subsequent file additions, deletions, and modifications are made in this directory.
Step 3: Add the required files for creating Pods dependency library to the local git repository
Note: The following described files must be placed in the root directory of the git repository cloned in step two.
1with suffix .podspec file
This file is the description file of Pods dependency library, and each Pods dependency library must have and only have one description file. The file name should be consistent with the name of the dependency library we want to create, and the file name of my WZMarqueeView dependency library is WZMarqueeView.podspec.
1.1 Content of podspec file
The content of WZMarqueeView.podspec is as follows:
Pod::Spec.new do |s|
s.name = 'WZMarqueeView'
s.version = ''1.0.0"
s.summary = 'A marquee view used on iOS.'
s.description = <<-DESC
It is a marquee view used on iOS, which implement by Objective-C.
DESC
s.homepage = "https:"//github.com/wangzz/WZMarqueeView"
# s.screenshots = "www.example.com/screenshots_1", "www.example.com/screenshots_2"
s.license = 'MIT'
s.author = { "王中周" => "wzzvictory_tjsd@"163.com" }
s.source = { :git => "https:"//github.com/wangzz/WZMarqueeView.git", :tag => s.version.to_s }
# s.social_media_url = 'https:'//twitter.com/NAME''
s.platform = :ios, ''4.3'
# s.ios.deployment_target = ''5.0''
# s.osx.deployment_target = ''10.7'
s.requires_arc = true
s.source_files = 'WZMarqueeView'/*'
# s.resources = 'Assets'
# s.ios.exclude_files = 'Classes'/osx'
# s.osx.exclude_files = 'Classes'/ios'
# s.public_header_files = 'Classes'/**/*.h'
s.frameworks = 'Foundation', 'CoreGraphics', 'UIKit'
end
This file is a ruby file, and all entries in it are easy to understand.
Among them, there are several parameters that need to be explained:
① s.license
The license type used by Pods dependency library, everyone can fill in their own choice.
② s.source_files
Indicates the path of the source file, note that this path is relative to the podspec file.
③ s.frameworks
The frameworks needed, no need to add the .frameworks suffix.
1.2 How to create podspec file
There are two ways for everyone to create their own podspec file:
① Copy my podspec file and modify the corresponding parameters, it is recommended to use this method.
② Execute the following creation command:
$ pod spec create WZMarqueeView
It will also create a file named WZMarqueeView.podspec. However, when you open the created file, you will find that there is too much in it, and many of them are not needed.
2LICENSE file
CocoaPods strictly requires that all Pods dependency libraries must have a license file, otherwise the verification will not pass. There are many types of licenses, for details, please refer to the website tl;dr Legal. When creating a github repository, I have already selected the MIT type of license.
3main class file
The purpose of creating a Pods dependency library is to facilitate others' use of our achievements, such as the WZMarqueeView class that I want to share with everyone, which is naturally indispensable. I put the two files of this class in a folder named WZMarqueeView, and the corresponding directory structure is as shown in the figure:
It contains two files: WZMarqueeView.h and WZMarqueeView.m
4demo project
In order to quickly teach others how to use our Pods dependency library, it is usually necessary to provide a demo project. The demo project I created is placed in a folder named WZMarqueeViewDemo, which contains the files as shown in the following figure:
5README.md
should be familiar to everyone who uses GitHub, as it is an indispensable part of a successful GitHub repository. It uses markdown language and is used for detailed descriptions of the repository.
The above-mentioned5are the most basic files required to create Pods dependency libraries, among which1,2,3is necessary,4,5is optional but strongly recommended to create.
After adding these files, the directory of my local GitHub repository looks like the following figure:
IV. Commit the modified files to GitHub
After step three, many files have been added to the local git repository. Now, these files need to be submitted to the GitHub repository. The submission process is divided into the following steps:
1Pod verification
Execute the following command:
$ set the new version to 1.0.0 $ set the new tag to 1.0.0
These two commands are used to add a version number to pod and tag it. Then execute the pod verification command:
$ pod lib lint
If everything is normal, the following output will appear after executing this command:
-> WZMarqueeView (1.0.0) WZMarqueeView passed validation.
That's it, the pod verification is over.
It should be noted that when executing the pod verification command, any warning or error information printed will cause the verification to fail! If there is an exception in the verification, the printed information will be very detailed, and everyone can make modifications according to the corresponding prompts.
2Upload the modified content of the local git repository to the GitHub repository
Execute the following commands in order:
$ git add -A && git commit -m "Release 1.0.0." $ git tag '1.0.0' $ git push --tags $ git push origin master
The above commands all belong to the category of git, and will not be elaborated on here. If everything is normal, the content you just added should be visible on GitHub. As shown in the following figure:
V. Upload podspec file to the official CocoaPods repository
After the four steps mentioned above, you might think it's over, but unfortunately, it's not yet.
To make a Pods dependency library truly usable, one final step is required: uploading the podspec file we generated just now to the official CocoaPods Specs repository, which can be accessed at: https://github.com/CocoaPods/Specs
Opening this link will reveal that all the Pods dependency libraries we can use, as well as those that can be searched using the pod search command, upload their podspec files to this repository. That is to say, only after uploading our podspec file to this repository can it become a real Pods dependency library, and others can use it normally!
According to the rules of git, in order to add files to someone else's repository, you must first fork a copy of someone else's repository, make the corresponding modifications, and then push it to the original author of the repository. After the author reviews and passes it, it is merged into the original repository.
After understanding the process, it is natural to know what to do:
1Fork a copy of the CocoaPods official Specs repository
Enter into the official repository link mentioned earlier, click the fork button in the upper right corner of the screen, as shown in the following figure:
Then you will find that there will be an additional repository branch under your name. For example, my branch is:
2Clone the forked repository to the local
Execute the following command:
$ git clone https://github.com/wangzz/Specs.git
Note that everyone needs to replace the corresponding repository address with their own.
This repository is quite large, and patience is required.
3Add your own podspec file to the local Specs repository
After cloning the Specs repository to the local, it will be placed in a folder named Specs. The principle of saving podspec files in the Specs repository is:
>folder with the same name as the Pods dependency library--->version number folder with the same name--->podspec file
Following this principle, I need to create a folder named WZMarqueeView under the Specs folder, and then enter into the WZMarqueeView folder to create a folder named1In the .0.0 folder, and finally enter into1In the .0.0 folder, and copy the previously created WZMarqueeView.podspec file into it.
It is not difficult to understand that if there are any upgrades to the WZMarqueeView class in the future, you can create a folder with the corresponding version name under the WZMarqueeView folder to save the podspec file of the corresponding version.
After these operations, the directory hierarchy is as follows:
4Upload the modifications in the local Specs repository to the github repository
Execute the following command:
$ git add -A && git commit -m "Add WZMarqueeView podspec file" $ git push origin master
After a successful operation, you can see the newly uploaded file in your forked Specs repository on github.
5Pull the modifications made to your forked Specs to the official CocoaPods Specs repository
Enter into your forked Specs repository, and you will see a green button in the upper left corner of the screen:
After clicking this button, you will see the interface as shown in the following figure:
Click the green Create Pull Request button in the figure to pull the modifications we made to the forked Specs to the official Specs repository of CocoaPods.
After this step, the remaining work is only to wait, waiting for the maintenance staff of CocoaPods to review and merge the modifications we pulled onto the official Specs repository. This process usually takes about a day's waiting time. If there is any message, such as the review is not approved, or the review is approved, CocoaPods official will send an email notification.
Once the review is approved, we can see the folder we uploaded in the official Specs repository.
6, Check Review Progress
Of course, we can also check the review progress, open this link:https://github.com/CocoaPods/Specs/pulls, here you can see all the pull requests of the Specs repository, as shown in the following figure:
The red circle indicates the pull request I just pulled, and you can see the corresponding review progress by clicking into it.
Part Six: Check Our Own Created Pods Dependency Library
After receiving the approval email from the official CocoaPods, you may be eager to execute the pod search command on your computer to see if you can search for the Pods dependency library you created. However, you will definitely be disappointed, because you still need to execute a command to use the search command on our local computer to search for our dependency library:
$ pod setup
In the first article of my CocoaPods tutorial series: An Overview of CocoaPods----The last part of the advanced tutorial has introduced this command, which will update all Pods dependency libraries to the local machine. After executing this command, go ahead and execute:
$ pod search WZMarqueeView
The corresponding introduction information will be displayed!
After all that has been said, the creation process of the entire Pods dependency library is truly over! Are you successful, my friends??? If you encounter any problems, please leave a message.
Part Seven: Reference Documents