All posts by Bob
In all of our apps, whether they are web-apps or iOS apps, we make extensive use of different frameworks. These help us to save time by abstracting out stuff that’s needed in a lot of different projects.
But these frameworks grow together with our projects, so copying these into several projects can become tedious and managing different versions would make things too complicated.
Ruby has Bundler to solve this problem. Just create a gemfile that lists every “gem” you use, Bundler will install these gems and keep track of the versions in the “Gemfile.lock”.
Now there is a similar system for Cocoa, called Cocoapods.
Cocoapods runs on macruby, so installing it using RVM is a breeze:
Then simply setup cocoapods like this:
And now we’re ready to start using Cocoapods.
Adding Cocoapods to a project
Using Cocoapods in a new project is quite similar to using Bundler in a rails project. We start by adding a Podfile which could look like this:
The platform can either be
Note that, just like with Bundler, you can specify a git repository, and even a commit or tag to reference your dependency. This makes it a lot easier to fix versions and avoid breaking the project when updating the dependencies.
The dependencies referencing a git repository must contain a “.podspec” file. When no repository is specified, Cocoapods looks for the podspec in it’s own spec-repository. There’s already a bunch of frameworks that are available, and more are sure to follow.
Now we can enable Cocoapods for our project by running
pod install for the first time.
This will clone the git repositories of the pods specified in a new “Pods” directory in your project root. Just like Bundler it will create a “Podfile.lock” which holds the references to the current version of the pods and its dependecies. Together with a new workspace we can use to open our project in XCode. There we will see that there are actually two projects added to the workspace.
One containing your regular project, and one containing the pods, this makes it easier to view the source code of these pods while working.
When building your project your pods will be built into “libPods.a” before building the project itself.
Now you’re good to go. When adding new pods or updating existing ones in your podfile just run
pod install again to update your “Podfile.lock” and adding or updating the Pods.
When multiple build configurations are needed, we also need to add these in the “Pods.xcodeproj”.
You should also set “Skip Install” to yes in your build target in order to create archives for different build types.
thanks Verbeeckx for figuring these last two out
Creating your own Cocoapods
To be able to add our own frameworks into our own projects easily, we had to add a “.podspec” to the repos. These podspecs look very similar to the gemspecs in Ruby.
In this podspec we set the source, where Cocoapods can find the repository to clone. We specify where the required classes can be found within the repository. We can also set several dependencies, specifying the tags that should be used.
Note that adding a dependency like this, it needs to be present in the spec repository of Cocoapods. When the correct tag or framework isn’t present in the repo yet, we can add it ourselves in the Podfile of the project we are using the framework in. In the case of Tin, we had to add “AFNetworking” separately in the Podfile because the highest available version from Cocoapods was 0.7.0.
I suspect Cocoapods will gain a lot in popularity in the future, because it makes adding dependencies to projects much easier. As it gains in popularity, more frameworks will become available.
I suggest you get over to the Cocoapods github and give it a try.
One of the projects I’m working on requires me to read a lot of data from multiple d2r servers using SPARQL. Because the data on these servers can sometimes be similar the data has to be filtered before it is made available to a Rails app that will be displaying the data.
I didn’t want to litter the database of the Rails app with this duplicate data (because it will feed a d2r server in the future), and fetching 10 rows of the server already took some seconds. So fetching all of the data from multiple servers would take quite a long time.
So I needed a place to store this temporary data separately where it wouldn’t bother the data of the Rails app, and be available for filtering when all of the data was fetched. A separate schema for each of the servers would do the job.
Here’s how it goes
I didn’t load the entire Rails environment for this; this way AR doesn’t automatically load the database connection parameters and we can easily adjust them ourself:
Creating the schema wasn’t that difficult, executing some SQL on the connection did the trick…
After that we have to alter the connection so AR does all future operations on the newly created schema.
If you do intend to use the entire Rails environment, be sure to do this before the classes are loaded, so they inherit the
correct connection. If not you could unload the classes using
But in this case I was loading the classes manually, and fetching the data from different servers in different processes. That way the loaded model classes couldn’t interfere with each other.
With all the fetching processes finished, the data is ready to be filtered and loaded into the database of the Rails app, and be the source database for another D2R server.
Sign up for our newsletter
Who’s got the mic?
Architecture & Design
Koen Van Der Auwera
Bob Van Landuyt
Nathan de Witte