There is already a pod for that.
Hello again, today i’m going to talk a bit about dependency management. The most popular tools that can do it for you, how to use them, some tricks and also some cool dependencies that you can use in your projects to avoid implementing complex features from scratch.
I interpret dependencies as sub-projects, projects inside your project. A fragment or a module from another project to supply some feature for you ready-to-cook. The most famous tools that can do this ‘integration’ for us, instead of copy-pasting code are CocoaPods and Carthage (when it comes to iOS development) both support Objective-C and Swift projects and both are open-source projects on Github. I’ll be focusing here today on CocoaPods since is the one i’ve most used. It doesn’t mean Carthage is harder to use or it’s not so good. CocoaPods IMHO is more popular so i never saw my self on a position that i couldn’t use it and i had to use Carthage instead.
It's terminal time
When you become a developer, like it or not, you will have to learn some unix commands. Whether in source-control (Git/SVN) or dependency management, sooner or later you will have to face it, and just so you know: these things are better controlled via terminal (i've got this from my former boss). To kick off, you should install your CocoaPods gem (Ruby)
$ sudo gem install cocoapods
Done that, navigate to your project folder e.g: i've created a project called Example on the desktop folder so it would be something like this:
$ cd Desktop/Example
Just to make sure you are in the project folder, you can use the command ls (list files) to show you which files are in the folder, and than you should see Example.xcodeproject
Now you have to initialise a podfile for that project, and you do that using:
$ pod init
A podfile is a plain text file in which will be the names and versions of the pods you have attached to your Example project. After you initialised, again just to make sure you can use the command ls to list the files in the folder and guess what: the podfile should be appearing now for you. Use this command to open your podfile, insert and also remove pods from your project:
$ open podfile
OK, this last command has nothing to do with CocoaPods, you should already know that you can open files via terminal using the ‘open’ command. Anyway, if you didn’t knew, look for: ls, ls -a, open, cat, cd, cd .., cp and mv. These are the most basic unix commands and with this you should be able to do enough at least for now.
When you open your podfile, you'll probably see that there was nothing on it, i mean… you probably saw a couple of lines with ‘#’ symbol on the beggining which means that the compiler will ignore that line. So for now, your podfile has something written there but no pod inside it. To add a pod, you just simply have to add:
target ‘Example’ do
This top and bottom line were already there, so you only had to add the pod ‘Firebase’ line into it. Firebase is… ok, we’ll come to that later, but the point here is that any pod is added to your podfile like this.
After you added this line and hit command+s to save the .txt file, you just have to go back to the terminal and hit:
$ pod install
This last command will generate a new project file to you with .xcworkspace extension. So in our Example project it will be generating a new project called Example.xcworkspace and this will be the project that you should use from now on.
Now that we are using the Example.xcworkspace instead, and our example pod named Firebase is added to the project, we can simply use the classes from this sub-project by importing the classes like if we were doing it with a framework like:
You can have as many pods as you want in the same project, and for this you just have to open the podfile, add a new line with a new pod ‘SomePod’. Than, run “pod install” again. Now i’m going to talk about some tricks/tips that took me some time to learn the importance and the use of it.
Using specific versions of a pod — why bother?
Well, depending on how critical is your app you really should consider specifying the version of the pod you're using because unless you have unit tests implemented, if for some reason the pod owner releases a new version and this new version has some new issue that takes you to a bug in your project — you're done. You're going to lose some precious time to conclude where is the problem and ain't nobody got time fo dat.
To specify the version of the pod you want to install you should just do a simple changing on the pod line at the podfile, instead of just "pod PodName" you're going to use:
pod 'Firebase', '~>1.0.0'
Using Swift developed pods
Some pods are also developed in Swift, but that doesn't mean you can't bridge between the projects, it's perfectly normal to use Swift pods in Obj-C projects and vice-versa. To use Swift pods into your podfile, just remove the '#' signal from the line that says: use_frameworks! This will un-comment this line and from now on when you run pod install or pod update it will consider that there is a swift pod there.
When i was at the university, i did a cool app that with face detection and recognition. This app used the OpenCV pod, which is really big. Much more than the size available for free github accounts, so my way out of it was: only push the podfile to the remote repository, not the other files that you can see using:
$ ls -a
This last command will show you not only regular files but also hidden files, or files that have . at the beginning of it's name. This trick will save you a lot of space on your remote repo and every time someone has to pull down your project, they just have to run pod install, because the podfile is already set with all the pod names.
Sometimes, when running pod install you may have some trouble like:
-bash: pod: command not found
The way i've fixed is described right here. You will have to do something like this:
$ mkdir -p $HOME/Software/ruby
$ export GEM_HOME=$HOME/Software/ruby
$ gem install cocoapods
1 gem installed
$ export PATH=$PATH:$HOME/Software/ruby/bin
Notice that every line that starts with dollar sign, means that it's an input from the user.
It worth to mention that at the moment you use a project from somebody else inside your project, not only the good things come with it, but also the security breaches might also come, which is a big concern when it comes to a really serious project. The best option is to download the project, check the algorithm, how does it work, re-implement it on your own project adapting to your needs and that's it. Ofc that if we are talking about an app that shows you a static png on the screen like that one with the diamond you don't have to worry about that.
Some good stuff to use in your projects:
I could list literally dozens of really cool pods here but it really depends on what does your app do or plans to do. Instead of just guessing it i will show the biggest/nicest pod library i've seen on Github, it's called: awesome-ios. On this link you will find not only really nice pods but also articles and books to read about iOS development and many other topics that i'm pretty sure you will be interested.
Ok, i promised. Here are some cool pods that i've used and i always think like: "I think i can use this again here or there…"
DCAnimationKit - A collection of animations for iOS. Simple, just add water animations.github.com
NVActivityIndicatorView - Collection of awesome loading animationsgithub.com
SwipeableTabBarController - UITabBarController with swipe interaction between its tabs.github.com
SWTableViewCell - An easy-to-use UITableViewCell subclass that implements a swippable content view which exposes…github.com
All of these pods are on the awesome-ios github .readme and there are many many others really cool, even better than this ones depending on what are you looking for.
That's it, i hope you enjoyed reading it and next time i will try to keep it shorter. In the next article i will talk about push notifications, how to send custom payloads, how to handle them on background and some other topics of it. Thank you for your time and don't hesitate to comment what do you think about this lecture down here.