In this quick post, I’d like to show you how to patch your current stable SDK (e.g. 7.2.0.GA) with features and bug fixes that have not been released yet. A good example for this is the foreground-service support that will be available in Titanium
SDK 7.3.0 in a few months. There was a lot of bounce regarding this feature on TiSlack and its related JIRA ticket TIMOB-16066).
As we all know, upgrading to a new major version of the SDK (read more about “patch”, “minor” and “major” terminlogy here) can be HARD. So, how would you apply this feature to your current SDK? The answer is Cherry Picking, a Git command that picks the sweet cherries (aka commits) from a different branch and applies it to your current branch. If you are new to Git, commits and branching, I recommend reading through the Git Basics before going into the wild.
Requirements
For this tutorial, I used Git Tower, my personal favorite for managing Git repositories. The same procedure can also be done via the Git CLI or other clients.
In addition, I expect that you already cloned the appcelerator/titanium_mobile repository from GitHub. If you have issues cloning the SDK, I recommend reading through the GitHub Guides.
Getting Serious
Ready? Let’s get serious!
1. Locate the pull request that you want to use locally. Either via searching through JIRA or GitHub. In this case, we use this pull request by our Android engineer Josh!
2. Open the Tower app on your Mac or PC and add a new remote. This is used to get all branches from Josh’s fork and apply selected ones to our own version of the SDK.
3. Enter the Git-URL of the remote you want to add. In this case, it is “https://hansemannn@github.com/jquick-axway/titanium_mobile.git” which follows the easy scheme of:
https://YOUR_USERNAME@github.com/REMOTE_USERNAME/titanium_mobile.git
4. Next, go to the titanium_mobile upstream remote, so the official version of titanium_mobile by @appcelerator and select the SDK that you want to base your custom SDK from – for example, 6_3_X will use the 6.3.0.GA as the base, 7_2_X the 7.2.0.GA. Give your branch a notable name like 6_3_X-ForegroundServices and save it.
5. After that, select the remote of Josh (jquick-axway) and search for the branch that added the particular feature. You can
locate the name by looking into the pull request page on GitHub:
hansemannn merged 4 commits into appcelerator:master from jquick-axway:TIMOB-16066 15 days ago
6. After you have located it, use the search on the top-right of Tower and search the commits you want to apply. In this case,
you only need the main commit, `[TIMOB-16066] Android: Added “foreground” service support.` You can easily
find it by searching the JIRA ticket number. Once you find it, right click on the commits you want to apply and
select “Cherry pick
7. In this example, we are applying a commit from one major to another (7.x -> 6.x), which can likely result in a possible
merge conflict, which is a case where a file was changed from two different sources at the same time. In that case, you need
to decide which version to use by manually resolving all issues inside the diff. We are not deep-diving into this topic as
part of this tutorial, but you can read more in this article.
8. Finally, you are ready to compile, package and install your new SDK. Luckily, our tooling will do the whole thing for you! So, all you need to do is run a couple commands and our build script will take care of everything. Here we go:
cd titanium_mobile/build # change to the Titanium SDK
npm install # install required Node.js dependencies
node scons.js cleanbuild # compile, package and install the SDK
If everything runs through, the SDK will be installed to your SDK home, e.g. `~/Library/Application Support/Titanium/mobilesdk/osx/`. If there is an error, the Terminal will let you know what’s wrong, e.g. a NDK-mismatch.
That’s it! You are ready to go. You have learned that using cherry picking can be a powerful way of applying changes
to the SDK early. But remember that using a master/non-GA version of the SDK does not always guarantee
the full quality cycle that stable versions of the SDK go through. So, you should test any changes properly
before submitting your app to the App Store again.
Code strong!
Follow us on social