Automatically increasing versionCode with Gradle

Continuous Integration means, above all, automatization. The user should not be in charge of the distribution or deployment process. Everything should be scripted!

While deploying new versions in Android, one of the common tasks is to increase the versionCode to identify a particular build. Using the new Gradle system, this can also be automatized.

In our defaultConfig, we will need to specify that the versionCode must be read from the newly added function:

Testing Asynchronous Tasks on Android

Recently, at Sixt we have been migrating our development environment from Eclipse to Android Studio. This has mean we have also moved to the new build system, Gradle, and applying TDD and CI to our software development process. This is not the place to discuss the benefits of applying CI to a software development plan, but to talk about a problem arising when testing tasks running on different threads than the UI in Android.

 

A test in Android is (broad definition) an extension of a JUnit Suitcase. They do include setUp() and tearDown() for initialization/closing the tests, and infers using reflection the different test methods (starting with JUnit 4 we can use annotations to specify the priority and execution of all the tests). A typical test structure will look like:

This is a very obvious instance: in a practical case we would like to test things such as HTTP requests, SQL storage, etc. In Sixt we follow a Manager/Model approach: each Model contains the representation of an Entity (a Car, a User…) and each Manager groups a set of functionality using different models (for example, our LoginManager might require of models Users to interact with them). Most our managers perform HTTP  requests intensively in order to retrieve data from our backend. As an example, we would perform the login of a user using the following code:

 

When it comes to apply this to our own test suitcase, we just make the process fail() when the result does not work as we were expecting. We can see why in the method onFailure() we call to fail().

However, even if I was using a wrong username the test was still passing. Wondering around, seems that the test executed the code sequentially, and did not wait until the result of the callbacks was back. This is certainly a bad approach, since a modern application do intense usage of asynchronous tasks and callback methods to retrieve data from a backend!. Tried applying the @UiThreadTest bust still didn’t work.

I found the following working method. I simply use CountDownLatch signal objects to implement the wait-notify (you can use synchronized(lock){… lock.notify();}, however this results in ugly code) mechanism. The previous code will look like follows:

Follow me on Twitter @eenriquelopez !

Stripping HTML characters from NSString

A simple quick & dirty solution to stripping HTML characters in a NSString:

(Source: http://stackoverflow.com/questions/277055/remove-html-tags-from-an-nsstring-on-the-iphone)

Breakpoint for Objective-C exceptions

You can add a breakpoint for Objective-C exceptions in Xcode like this:

Switch to the breakpoint navigator (Cmd+7), press the “+” button in the lower left and “Add symbolic breakpoint…”. Then put symbol “objc_exception_throw” in module “libobj.A.dylib” like this:

Screen Shot 2013-12-11 at 13.55.47

By default, Xcode will only break on [NSException raise], which then in turn calls objc_exception_throw.

You can move this breakpoint to “global” by right clicking it and “Move breakpoint to –> User”.

Xcode & Breakpoints

Just some things you might already know and some not:

The most common way of adding breakpoints in Xcode is to just enable them by clicking on the left side in the Code editor.

Screen Shot 2013-11-29 at 06.50.35

In the breakpoint navigator (Cmd+7) you can now see your breakpoint – and possibly more breakpoints you already added. If you click it again, you will disable it. To remove it, delete it from the navigator or drag & drop it away to trash it. So much for the obvious part.

Now there’s so much more you can do with breakpoints. First of all, breakpoints can be in different scopes:

  • Workspace
  • User (Global)
  • Project

Just right click it and select “Move Breakpoint to”. If you move it to “User”, it will show up in all your Xcode projects or workspaces you open with your current user.

The most common “User”-scope breakpoint is the symbolic breakpoint to objc_exception_throw in libobjc.A.dylib.

Now if you right-click again and click “Edit Breakpoint…”, you will start to scratch the surface of the world of breakpoints. You can execute scripts, debugger or shell commands, log messages or even play a sound (w00t!). Keep in mind, that whatever you do there will interrupt the execution of your application until whatever you selected here is finished. A typical debugger command you might want to execute is bt which will show a backtrace (call hierarchy) at the current position in code.

Next, another powerful feature is symbolic breakpoints. You can add symbolic breakpoints to object-specific symbols (-[UIViewController viewWillAppear]) or even just symbols (viewWillAppear). Just try it and you will suddenly get insight to a huge bunch of internal object classes you never heard of. The latter will break your execution each time any object receives the viewWillAppear message.

Next, watch points. In some situations you might wonder why some property or object value changes and you just don’t understand why. No problem, just add a watch point to that property! Just use any breakpoint to pause execution of you app and take a look at the Debug area.

Screen Shot 2013-11-29 at 07.09.29

Right-click any of the variables you see there and select Watch. From now on, every time the variable changes, your app will be interrupted. Keep in mind, that variables change when non-object types change (like an NSInteger increases) or object pointers change. For example, appending something to a NSMutableString does not change the object pointer, so the watchpoint will not fire. By default, watch points will fire on “write”, however you can also watch reads. Watchpoints will show up in the Breakpoint Navigator too.

Every time your app gets interrupted, you can also use the debug console (lldb by default) and write what we just did as a command there. This is much more powerful as you can do even more there. Just take some time and read the command documentation

If you are already familiar with gdb and want to know how you do the same with lldb there’s a nice GDB to LLDB command map.

Happy debugging!

Useful things when working with git

So you’re working with git and you think it’s the best thing that every happened to you? Same with me, however there are a few settings that make working with git even more fun! Here they are:

This will always assume you want to push you current branch to origin with the same name (like develop to origin/develop).

More or less the same thing, just in the other direction. When you pull, git will assume you want to fetch & merge the origin branch with the same name.

This will disable fast-forward when doing merges. This means, that even if there is no merge needed (because one of the parents is the common ancestor), there will still be a merge commit. This is useful to keep track of the branch history.

This will tell git to use style diff3 to solve conflicts. Compared to the default style, this will also add the common ancestor version in the conflicting file, showing not only the result in both branches, but also the state before the changes. This often helps to resolve conflicts easier.

This tells git to remember how you solved a conflict. When a conflict appears, git will check the conflict history database and uses the same solution if the conflict is the same. Very helpful if you have conflicts that appear again and again (like storyboard files or submodules).