inaka

Latest blog entries

/
Erlang and Elixir Factory Lite B.A.

A brief introduction about what was the Erlang Factory Conference in Buenos Aires for some Inaka team members

Jul 07 2017 : Euen Lopez

/
The Art of Writing a Blogpost

The Art of Writing a Blogpost

Apr 11 2017 : Matias Vera

/
SpellingCI: No more spelling mistakes in your markdown flies!

Feb 14 2017 : Felipe Ripoll

/
Fast reverse geocoding with offline-geocoder

Do you need a blazing fast reverse geocoder? Enter offline-geocoder!

Jan 18 2017 : Roberto Romero

/
Using Jayme to connect to the new MongooseIM REST services

MongooseIM has RESTful services!! Here I show how you can use them in an iOS application.

Dec 13 2016 : Sergio Abraham

/
20 Questions, or Maybe a Few More

20 Questions, or Maybe a Few More

Nov 16 2016 : Stephanie Goldner

/
The Power of Meeting People

Because conferences and meetups are not just about the technical stuff.

Nov 01 2016 : Pablo Villar

/
Finding the right partner for your app build

Sharing some light on how it is to partner with us.

Oct 27 2016 : Inaka

/
Just Play my Sound

How to easily play a sound in Android

Oct 25 2016 : Giaquinta Emiliano

/
Opening our Guidelines to the World

We're publishing our work guidelines for the world to see.

Oct 13 2016 : Brujo Benavides

/
Using NIFs: the easy way

Using niffy to simplify working with NIFs on Erlang

Oct 05 2016 : Hernan Rivas Acosta

/
Function Naming In Swift 3

How to write clear function signatures, yet expressive, while following Swift 3 API design guidelines.

Sep 16 2016 : Pablo Villar

/
Jenkins automated tests for Rails

How to automatically trigger rails tests with a Jenkins job

Sep 14 2016 : Demian Sciessere

/
Erlang REST Server Stack

A description of our usual stack for building REST servers in Erlang

Sep 06 2016 : Brujo Benavides

/
Replacing JSON when talking to Erlang

Using Erlang's External Term Format

Aug 17 2016 : Hernan Rivas Acosta

/
Gadget + Lewis = Android Lint CI

Integrating our Android linter with Github's pull requests

Aug 04 2016 : Fernando Ramirez and Euen Lopez

/
Passwordless login with phoenix

Introducing how to implement passwordless login with phoenix framework

Jul 27 2016 : Thiago Borges

/
Beam Olympics

Our newest game to test your Beam Skills

Jul 14 2016 : Brujo Benavides

/
Otec

Three Open Source Projects, one App

Jun 28 2016 : Andrés Gerace

/
CredoCI

Running credo checks for elixir code on your github pull requests

Jun 16 2016 : Alejandro Mataloni

/
See all Inaka's blog posts >>

/
The Fork Workflow in iOS

A photo of Pablo Villar wrote this on September 19, 2014 under cocoapods, dependencies, fork, github, inaka, ios, pods, workflow .

The situation

Here is the thing: You found out a dependency that fits some requirements that you need in your project (well, let's say it almost fits) and in order to make it perfectly fit your requirements you need to make some modifications to some of the files of that dependency.

The question is, what's the way to do it? Is there a formal way?

This blog post covers exactly that topic: What's the best workflow to follow when you're in such a case.

A piece of advice

First of all, you need to make sure whether there is no option other than making modifications to files that came with the dependency project. Sometimes you can, for example, create a subclass some class of the dependency, add the things you need and that's it, you use your subclass instead of the original one. If that's possible, go ahead with that then, since you're going to save time.

Nevertheless, sometimes you do need to apply some sort of internal surgery to a class, and there's no choice other than modifying it. If you're handling your dependencies via CocoaPods, you know (or you should know) that you can't modify dependencies' files, because those changes will be discarded as soon as you run 'pod install' or 'pod update', or what's worse, you're going to get errors when trying to do that.

So, what to do...? Is there a way such that I'm able to have my own copy of that dependency's repository, make the modifications I want and tell CocoaPods to fetch from that repository instead of the original one?

The answer to that is YES, there IS a way. When you find yourself in this situation you're being summoned to FORK.

The workflow, in steps

1.

First step, go to the GitHub repo where your dependency is allocated and press the Fork button. You're going to be asked where do you want to fork it, meaning: where do you want to place the copy of the repo you're forking.

Fork button

2.

Once you've forked the repo, you're able to do all the nasty things you can imagine, because now you have your own copy to work on and you don't need to do anything to the original one. So, you can create your own branches, pull requests, commits to master... (Yes, that's what I meant with 'nasty' things). Just kidding, even though you should not commit directly to master, the point is that the copy now belongs to you, so, as the owner of the copy you're able to do whatever you need with it. What you're going to do here is to make those modifications that make the dependency fit your project's requirements.

3.

Now you need to tell CocoaPods that you're going to use your own copy of the repository and not the original one.

Well, good news here, there is a very easy way to do that which is quite straightforward.

Just modify your Podfile by replacing this line: pod 'SomeDependency', '~> 1.0'

with this one: pod 'SomeDependency', ':git => https://github.com/you/somedependency'

Where you're explicitly pasting the HTML address of your copy of the original repo.

Don't forget to run 'pod update' after that.

4.

Last, but not least, we have an optional step. Making this step depends on how general your modifications could be as to be considered to belong with the original repo.

If you've done some work that you think "this could be useful to several other people using the repo" then you might want to share it. If you're not such a sharer developer (you should be, bad boy!) there is another good reason for which you might want to incorporate your changes in the original repo: You will be able to get the latest updates of the dependency with your changes. Otherwise, if you just keep using your own copy, each time the owners of the dependency make version updates you will have to merge those updates in your custom copy in order to have the latest. That sounds like unnecessary work, doesn't it?

The normal workflow to incorporate your changes into the repository you've forked from is just to open up a Pull Request, comparing the original repo's latest master branch with yours.

Be descriptive! Developers might be afraid of what you're wanting to add if you haven't written down a good description of what you modified and why you did so.

Remember that once they have merged your changes into their original repo (if you were lucky and they liked your changes), you should get rid of your working copy and restore your podfile to make pods fetch back again to the original dependency repo.

That's it!

I understood all of that... But, why 'fork'?

The term fork comes from the fork with which you usually eat:

A fork

It's just meant to express that you (and other people) are branching away from an original branch, as the sharps of the fork do with its handle.

A photo of

Pablo Villar

iOS Developer