Mobile Gurus

[mobilerockstars]

Locating XCode6 instruments templates

By de_poon

With the help of my colleagues, I am trying to request the author of calabash to fix (via Pull Request) an issue of run_loop repo with XCode6.

Apparently the issue lies with the output of

xcrun instruments -s templates

when XCode6SDK is set at "/Applications/Xcode.app/Contents/Developer the output is:

Known Templates: "Activity Monitor" "Allocations" "Automation" "Blank" "Cocoa Layout" "Core Animation" "Core Data" "Counters" "Dispatch" "Energy Diagnostics" "File Activity" "GPU Driver" "Leaks" "Multicore" "Network" "OpenGL ES Analysis" "Sudden Termination" "System Trace" "System Usage" "Time Profiler" "UI Recorder" "Zombies"

However if your SDK is at a different location, eg "/Applications/Xcode6.app", the output becomes

"/Applications/Xcode6.app/Contents/Applications/Instruments.app/Contents/PlugIns/AutomationInstrument.xrplugin/Contents/Resources/Automation.tracetemplate" "/Applications/Xcode6.app/Contents/Applications/Instruments.app/Contents/PlugIns/OpenGLESAnalyzerInstrument.xrplugin/Contents/Resources/OpenGL ES Analysis.tracetemplate" "/Applications/Xcode6.app/Contents/Applications/Instruments.app/Contents/PlugIns/XRMobileDeviceDiscoveryPlugIn.xrplugin/Contents/Resources/Energy Diagnostics.tracetemplate" "/Applications/Xcode6.app/Contents/Applications/Instruments.app/Contents/PlugIns/XRMobileDeviceDiscoveryPlugIn.xrplugin/Contents/Resources/GPU Driver.tracetemplate" "/Applications/Xcode6.app/Contents/Applications/Instruments.app/Contents/PlugIns/XRMobileDeviceDiscoveryPlugIn.xrplugin/Contents/Resources/templates/Core Animation.tracetemplate" "/Applications/Xcode6.app/Contents/Applications/Instruments.app/Contents/PlugIns/XRMobileDeviceDiscoveryPlugIn.xrplugin/Contents/Resources/templates/System Usage.tracetemplate" "/Applications/Xcode6.app/Contents/Applications/Instruments.app/Contents/Resources/templates/Activity Monitor.tracetemplate" "/Applications/Xcode6.app/Contents/Applications/Instruments.app/Contents/Resources/templates/Allocations.tracetemplate" "/Applications/Xcode6.app/Contents/Applications/Instruments.app/Contents/Resources/templates/Blank.tracetemplate" "/Applications/Xcode6.app/Contents/Applications/Instruments.app/Contents/Resources/templates/Counters.tracetemplate" "/Applications/Xcode6.app/Contents/Applications/Instruments.app/Contents/Resources/templates/Leaks.tracetemplate" "/Applications/Xcode6.app/Contents/Applications/Instruments.app/Contents/Resources/templates/Network.tracetemplate" "/Applications/Xcode6.app/Contents/Applications/Instruments.app/Contents/Resources/templates/System Trace.tracetemplate" "/Applications/Xcode6.app/Contents/Applications/Instruments.app/Contents/Resources/templates/Time Profiler.tracetemplate" "/Applications/Xcode6.app/Contents/Developer/Platforms/MacOSX.platform/Developer/Library/Instruments/PlugIns/CoreData/Core Data.tracetemplate" "/Applications/Xcode6.app/Contents/Developer/Platforms/MacOSX.platform/Developer/Library/Instruments/PlugIns/templates/Cocoa Layout.tracetemplate" "/Applications/Xcode6.app/Contents/Developer/Platforms/MacOSX.platform/Developer/Library/Instruments/PlugIns/templates/Dispatch.tracetemplate" "/Applications/Xcode6.app/Contents/Developer/Platforms/MacOSX.platform/Developer/Library/Instruments/PlugIns/templates/File Activity.tracetemplate" "/Applications/Xcode6.app/Contents/Developer/Platforms/MacOSX.platform/Developer/Library/Instruments/PlugIns/templates/Multicore.tracetemplate" "/Applications/Xcode6.app/Contents/Developer/Platforms/MacOSX.platform/Developer/Library/Instruments/PlugIns/templates/Sudden Termination.tracetemplate" "/Applications/Xcode6.app/Contents/Developer/Platforms/MacOSX.platform/Developer/Library/Instruments/PlugIns/templates/UI Recorder.tracetemplate" "/Applications/Xcode6.app/Contents/Developer/Platforms/MacOSX.platform/Developer/Library/Instruments/PlugIns/templates/Zombies.tracetemplate"

The difference in output affects how run_loop interprets and parses it.

If you need a quick fix for v.1.0.2

/Users/xxxXXXXxxx/.rvm/gems/ruby-2.0.0-p353/gems/run_loop-1.0.2/lib/run_loop

lib/run_loop/core.rb 560: not name == 'Automation'

change to

lib/run_loop/core.rb 560: not name =~ /\/Automation/

[mobilerockstars]

iOS Versioning with agvtool

When search around how to update version number of an iOS project, most of the result is about how to update the info.plist file using scripts.

Actually, apple provides a command line tool called agvtool to update the version numbers for us. It's simple and gets the task done.

The thing is, before you know it, it may not be obvious about how to start. So here are the steps.

Steps

Setup Xcode project to use apple's scheme for versioning In project build settings, set Versioning System to "Apple Generic" Set Current Project Version to the current build version of the project.

In command line, check the current build version of the project:  agvtool what-version

Set the build version number based on what we got in step 2 and what need to set for next build version. agvtool new-version -all new_version_number

Check the current marketing version of the project:  agvtool what-marketing-version

Set the new marketing version of the project based on what we got in step 4 and what we need for next marketing version.  agvtool  new-marketing-version new_marketing_version_number

If you want to increase the version number to the next highest integral value, use agvtool bump -all instead.

References

OS X Man Page for agvtool

Setting iPhone Application Build Versions

Technical Q&A QA1827:Automating Version and Build Numbers Using agvtool

[mobilerockstar]

Java unit testing in Android

by hidroh

Having spent 1.5 years working on PHP projects with very high test coverage and frequent test runs, it strikes me with great surprise that to achieve the same thing in Android is not as straightforward.

One of the best advantages of having unit tests is that you can get instant feedback on your changes, whether your code does what it’s supposed to do, or if it breaks existing behaviour. In an ideal environment, it should take only a few seconds to verify your changes. Sometimes it’s too fast that people argue that as disadvantages.

Surprisingly, it is not the case for Android, which was not designed with unit testing in mind. You would need an emulator or a real device to run your tests! Say what? Every test run now adds at least 30 seconds of overhead. Goodbye, all the best TDD!

Of course there are alternative ways to make Android tests run faster, but what if I only need to test my Java logic that has nothing to do with Android? Why do I need a device to test that logic? Sure, one can extract all pure Java code into a library so he can test them, but with product managers chasing after you, it’s not always the best choice. But worry no more, with a little bit of customization to Gradle build system for Android, that dream of TDD your Android projects is getting closer.

What you will need

Gradle 1.11 with Android plugin 0.9.0 and Jacoco plugin. Java plugin for Gradle supports unit testing out of the box. Applying Java plugin will give you a test task that you can use to run all the tests. Jacoco plugin complements that by generating code coverage report, without any special setup. It just works!

To do the same thing with Android, you will need to apply Java plugin together with Android plugin. But you will soon realize that it’s not possible, they are not compatible. So that leave you with only option of making a test task by yourself. Luckily, it is not that difficult:

Run Java unit tests with Gradle

First, you need to tell Gradle where you put your test code. Define a sourceSet, here we call it unitTest.

sourceSets { unitTest { java.srcDirs = ['test'] resources.srcDirs = ['test'] } }

Then you need to tell Gradle what you need to compile your sourceSet. Ideally test compilation should be separate from production compilation. Here we add a custom configuration called unitTestCompile, which extends from compile, since you obviously need to compile your code to test it! The inclusion of junit is compulsory, while other libraries are needed if you use some Android interfaces, mock classes or parameterize your tests.

configurations { unitTestCompile { extendsFrom compile } } dependencies { compile project(':your-project') compile project(':your-project-dependencies') unitTestCompile 'junit:junit:4+' unitTestCompile 'com.google.android:android:4.1.1.4' unitTestCompile 'org.mockito:mockito-core:1.9.5+' unitTestCompile 'pl.pragmatists:JUnitParams:1.0.2+' }

With everything compiled and ready to run, let’s create our own Gradle’s test task. Here the trick is to extends the Test class that is readily available in Gradle API, which executes JUnit tests. We call our extended task 'unitTest'. It depends on assemble to make sure that it will run after we have rebuilt everything.

def debugClassesDir = "${buildDir}/classes/debug" task unitTest(type: Test, dependsOn: assemble) { testClassesDir = sourceSets.unitTest.output.classesDir sourceSets.unitTest.compileClasspath += files(debugClassesDir) sourceSets.unitTest.runtimeClasspath += files(debugClassesDir) project.configurations .collectMany { it.allDependencies } .findAll { it instanceof ProjectDependency } .each { dependenciesBuildDir = "${it.dependencyProject.project.buildDir}/classes/debug" sourceSets.unitTest.compileClasspath += files(dependenciesBuildDir) sourceSets.unitTest.runtimeClasspath += files(dependenciesBuildDir) } classpath = sourceSets.unitTest.runtimeClasspath }

When this task is executed, it will need to know where to look for the compiled .class files. The rest of the task code serves this purpose. It instructs Gradle to look for current project’s build folder plus all dependencies’ build folders. Take note of the first line of task body. It’s needed to tell Test class where its code has been compiled into, even though you don’t see testClassesDir used anywhere else.

Switch to your console and type `gradle :your-project:unitTest`. Depends on test results, it will pass or fail your build!

Generate code coverage report with Gradle

Now it’s important to be able to run tests, but you would have no idea if you manage to cover every execution path without a code coverage report. Luckily, unlike Java plugin, Jacoco plugin works with Android. All you need to do is add the plugin, tell your Test task where to generate jacoco execution data, and customize jacoco to generate a nice HTML report for you.

apply plugin: "jacoco" task unitTest(type: Test, dependsOn: assemble) { ... jacoco { append = false destinationFile = file("${buildDir}/jacoco/jacocoUnitTest.exec") } } task jacocoTestReport(type: JacocoReport, dependsOn: unitTest) { reports { xml.enabled false csv.enabled false html.destination "${buildDir}/jacocoHtml" } classDirectories = fileTree(dir: debugClassesDir) sourceDirectories = files(android.sourceSets.main.java.srcDirs) executionData = files(unitTest.jacoco.destinationFile) }

With everything in place now, you can make unit test a required step of your build (which you should), by having it run while Gradle checks for compilation errors.

check.dependsOn unitTest

Have fun unit testing!

[mobilerockstars]

Configuration file to scale iOS Mobile Apps

by de_poon In our team of mobile rockstar engineers, we often ask ourselves this question: How can we scale our ios mobile apps? Lets take a hypothetical situation. Your CEO is very pleased with the first delivery of the company's mobile app. The other country managers come along and want you to build the same app but adjusted for their individual countries. Assuming they want a separate downloadable app, the general requirements are 1. I want some features taken from the main app 2. I do not want some features from the main app 3. I want some features to be modified from my custom app. Sounds familiar? The way to go about is to create a non-binary configuration file that allows us to specifcy what we want in the app.

The most important principle is that no recompilation is needed when we scale our apps. In our team we've chosen to go with PList file as it is easy for developers to create one out of the box in XCode. Here's the steps 1. Create a PList from XCode

2. Set up your features in a .plist

3. Add the plist file into your main bundle. 4. Use the following codes to read the contents of the plist as a NSDictionary

5. In your app features, read the contents off the NSDictionary to determine how your feature should behave. Eg. - Should this feature be turned on? - How should I order by menu items on the side menu? - Should I enable specific UI Animations at a particular screen? To create additional scalable apps, simply create a new project - import your lib.a binaries - import your resource bundle files - add in your configuration plist ... package and deploy your app!!! Considerations 1. Adding your plist directly into your main app bundle is not a secure way to do (So you think you can start working on it? Gotcha...). It is possible for someone to extract the plist from your app and this exposes all sensitive information such as api end points, security tokens, etc. Dont worry, an upcoming post will address this issue. 2. You might want to create your own configurations file manager to generate your plist on the fly. 3. PList is probably not the best way to encapsulate application configuration. You may want to explore other formats. Feel free to buzz us your thoughts on this

[mobilerockstars]

Using context in Android testing

by hidroh

If you are keen on doing TDD with Android, you may have stumbled upon the dreaded java.lang.RuntimeException: Stub! when you try to test drive your code with different contexts as input. For us, most of the time we use context is to get some resources out of it, either string, bool, raw, you name it. These resources may change execution behavior, and thus we are required to test with different resources to cover all cases.

Soon you learn that it is not straightforward to get the default Android's Context out of the way, even with MockContext. That is one of the reasons why we see test frameworks such as Robolectric (or mock framework such as Mockito, PowerMock) getting popular. While it is convenient to let Robolectric build an activity for you and use it as the context, or mock up your own context using Mockito, there is a more structured way of making Context work for you in testing.

The reason why you can't get Context out of your way in the first place is because it is a class, and you need to construct a specific instance to use it in testing, and it is just impossible to construct a real one! But what if it's an interface? Then you can pass the interface around, and have a mock implementation of that interface to be used in testing instead of the real one?

With that in mind, we come up with the solution of having a ContextWrapper, which serves exact same purpose as Android's Context, delegating all tasks to Android's Context, and implements an interface, says IContext, that we will pass around instead of Android's Context object. This IContext at a glance will look very much like what Android's Context offers, and you can add in more as you go along with your project.

Below is a simplified example of how we implement this pattern. Now at least you can test AppUtils' method without worrying about how to construct a Context!

public interface IContext { boolean getBoolean(int resId) throws Resources.NotFoundException; } public final class ContextWrapper implements IContext { private Context mContext; public ContextWrapper(Context context) { mContext = context; } @Override public boolean getBoolean(int resId) throws NotFoundException { return mContext.getResources().getBoolean(resId); } } public MyActivity extends Activity { private IContext mContext; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); mContext = new ContextWrapper(this); } ... private boolean checkIsEnabled() { return AppUtils.isFeatureEnabled(mContext); } } public AppUtils { public static boolean isFeatureEnabled(IContext context) { try { return context.getBoolean(R.bool.is_feature_enabled); } catch (NotFoundException e) { return false; } } }

[mobilerockstars]

Android: How to add fragments on callbacks

by hidroh

If you happen to use Fragments and Loaders a lot, you would probably stumble upon this exception before:

java.lang.IllegalStateException: Can not perform this action after onSaveInstanceState at android.support.v4.app.FragmentManagerImpl.checkStateLoss(FragmentManager.java:1343) at android.support.v4.app.FragmentManagerImpl.enqueueAction(FragmentManager.java:1361) at android.support.v4.app.BackStackRecord.commitInternal(BackStackRecord.java:595) at android.support.v4.app.BackStackRecord.commit(BackStackRecord.java:574)...

A very detailed explanation can be found here, and it has been made clear enough on various StackOverflow threads that it is not safe to commit your fragment transactions on callbacks, as there are good chances that your hosted activity may have been sent to background. Another nasty fact is that this exception only happens on some very specific scenarios, so you may have missed it totally during development phase.

But what if it happens quite often that you need to wait for some data to be loaded until you can render your view, and each view is complicated enough to deserve its own lifecycle as in a Fragment. How can you commit fragment transactions on loader's callbacks, without triggering the exception above?

Here is an example showing how we make it happen:

Let's say our activity implements LoaderCallbacks interface as follows:

public class YourActivity extends Activity implements LoaderManager.LoaderCallbacks<Cursor> { private static int LOADER_ID = 1; // ... }

And our interface implementation is as follows:

@Override public Loader<Cursor> onCreateLoader(int id, Bundle args) { // ... } @Override public void onLoadFinished(Loader<Cursor> loader, Cursor data) { if (!data.moveToFirst()) { return; } if (loader.getId() == LOADER_ID) { // ... // process cursor data and store to loadContent // ... // instantiate and add fragment to render view based on loadContent addFragment(loadContent); } } @Override public void onLoaderReset(Loader<Cursor> loader) { // ... } private void addFragment(Parcelable loadContent) { final FragmentManager fm = getSupportFragmentManager(); final FragmentTransaction transaction = fm.beginTransaction(); // ... // instantiate fragment with loadContent // ... transaction.replace(viewId, fragment); transaction.commit(); }

The problem with this piece of code is that addFragment may only be called when YourActivity has been paused, at which state IllegalStateException will be thrown.

We need a way to call addFragment only when the activity is in resumed state, which means after onResume() is called:

@Override public void onResume() { super.onResume(); mIsResumed = true; // only load data once if (!mLoaded) { getSupportLoaderManager().restartLoader(LOADER_ID, null, this); } } @Override public void onPause() { super.onPause(); mIsResumed = false; } @Override public void onLoadFinished(Loader<Cursor> loader, Cursor data) { if (!data.moveToFirst()) { return; } if (loader.getId() == LOADER_ID) { mLoaded = true; // ... // process cursor data and store to loadContent // ... if (mIsResumed) { addFragment(loadContent); } } }

If onLoadFinished returns when your activity is on resumed state, everything works as before.

If onLoadFinished returns after your activity has been paused, we prevent fragment transactions from committing, and retry once the activity is resumed again. Some considerations may need to be taken if you don't want to reload data every time your activity is active.