Archive for January, 2012

ContrarianView, DeviceID

A new coding article is up called, Contrarian View, DeviceID And it even has sample code, but no pizza..sorry. In android development we often want to compute a deviceID to use in debugging not only from developers but also from end users and this article explains the choices and suggest a more correct choice.

Twitter Bootstrap 2.0 WIP

if anyone wants to see what Twitter Bootstrap 2.0 WIP looks like being used, try:

I just redesigned it over the weekend, still some minor tweaks to go but I am happy with it.

Agile Android Dev in Anger

Some of you saw my AndrodCMWrench project go up yesterday, including a project dos site for the project. Do you realize that was just few hours to generate the website and complete ant script tool?

One of the problems every firm faces is that its the perceived notion that obtaining an android developer at premium prices means a slow development cycle. Google and OHA was kind enough already to make a choice of Java for Android Application Development which serves to somewhat halve the development time when com pared to a non-VM language such as Objective-C.Should we not take it rest of the way?

Imagine this,a complex android application getting down to its core features and a fast prototype in a week to two week period.  So, what are the areas left to improve/

Libraries can be heavily used to reduce development time. Not just one the application side as you can create jars that are used on the Android Instrumented Test Project side. It is also the tool-integration side.

If you look at source of my gh-pages branch of AndoirCMWrench you will notice that I did not use Github’s Jekyll. Why? Because I do not have an IDE Jekyll plugin so go with something that I have a plugin for. In the Android Application Development context since I have a nice plugin to make shortcuts of my ant targets, I can develop a nice tool that fires off execution of the MonkeyRunner scripts to run not only TDD/BDD unit tests but also regression testing right from the IDE.

This is what agile is, analyzing  your development work-flow to get better feedback and in shorter time periods to improve the stability and quality of what is produced.

There is a clown of a-Chicago firm(cough 4tegroup, cough quite spamming me folks) that thinks knowing how to write a Continuous Integration build script is agile, the only problem with that is that no-one in android development writes continuous integration scripts due to the differences between CI plugins and what we need to inject in certain ant stuff on how the android sdk tools operate. We tend to write a full ant build scrip  that integrates with the android sdk tools and our code metrics and than just have the CI server be pointed to run that instead.

So do not be that clown-of-Chicago firm be curious about your developer work-flow, the libraries you use, the tools you use,etc. And if you do not have time and want to borrow my tools and libraries, than just make sure that you follow my github account.

Okay, a small agile tool. Instead of counting on Google ot get the ant scripts right with every SDK release, just use your IDE and its android plugin and this small ant script(AndroidCMWrench) to run the the code metrics and javadocs after your IDE does an incremental build.

Shh, if you actually clone the project and look at the gh-pages branch you will have a nice simple example of how to use twitter boootstrap in your project docs.

In my quest for Agile with a vengeance I have been not only examining what to add to my instrumented testing tool box but also what other things in my developer workflow to change to squeeze every ounce of development time saving so as to be fast in two areas, prototyping and android app production. Why?

Because we know that Google will continue to put no-one in charge of developer acceptance testing the ant scripts provided with the sdk during each sdk release. For those that do not know, if you execute the targets in the Google supplied ant scripts from the android sdk you find the show stopping errors in the build.xml that will prevent you from using it un-modified, which means non-one at Google bothered to even test the item before any sdk release.

That is my former profession creeping in, I use to train corporate end users on computer software,which meant I had to develop the courseware. That involved inventing some techniques to ensure that the courseware was always right. That involved just taking the specific piece of software and attempting to use it in the exact way described in the courseware. Its not hard andnow its sort of a habit I cannot shake.

So we know we cannot count on Google to ever field test the ant scripts provided with the android sdk before each sdk release. Sure we could modify the sdk ant-scripts each time and than copy them into every project we have to build and than customize that to include our code reporting stuff. But, there is a better way. The IDE that we often use already does incremental builds.

Thus, if we only need to run code metrics after the build we can than move on to saving time both in the fast prototyping and app production cases of our development workflow as the Eclipse IDE has this neat feature where you can check under runs as ant build on the build tab build the project before running the ant script. So the projects i ened up with thus far are:



and AndroidCodeMetericsSetup to see where the Eclipse IDE stores the pmd, checkstyle, and classycle settings/reports. Unfortunately, each code metric plugin in Eclispe stores its reports or generates its reports indifferent formats and locations and so thus I had to come up with the plan to develop an ant script that runs after the project build and generates the javdocs and the codemetrics reports.

Now, its on to the next step in that I create a new project that combines AndroidDoclavaSetup with an ant script that executes the generation of javadocs using Doclava and the code metrics reports that is designed to be executed by the IDE that has a-run-after build setting in their run-as-ant-build feature. Than to polish that I will come up with a python script that you can put on path that will move those assets from abase-template folder to the newly created android application project.

Thus, what I end up with is that I can immediately be productive upon each new sdk release as I am not DEPENDENT ON GOOGLE’S OWN FUCKUPS in the SDK PROVIDED ANT SCRIPTS.

Agile Android Small steps

I found a neat library to allow me to use log4j over slf4j on android. But how about going a little further?

If I query the android.util.Config.DEBUG I can configure the android logging log4j library to set log4j to use either a logcat appender supplied by the library or a file appender to output to the sdcard, see the gist.
This allows me to support two use cases, one where I am debugging using locat and the other one when we need a log report from an end user as it non debug mode sets file appender as the log output.

AndroidMock(EasyMock) Mockito

I will be updating a personal build copy of androidmock to android 4.0.x as from my reading I only need to change the sdkversion file and add some libs(yes at by github account). However, I did find this neat Android support thread at Mockito it appears that with Google’s help are getting a patch to Mockito to support android. Dexmaker fills the asm cglib role.

That would also mean due to the devmaker project we might finally get groovy on Android and some other neat stuff.

Use robotiun in your Android Instrumented application testing? Do  you know there are some useful robotium extensions?

First, the warning. These are often tied to specific versions of robotium. That means you have some choices on how to update them to the current version of robotium. For me, because I do not use maven, I am porting them slightly to use ant/IDE to do the builds and update the robotium code to the current version of robotium.  You choice will depend on what benefits you want. Okay, enough wanrings..onward.

The first up is robotium.ultra by Enric Geijo and is a blackbox testing setup to test across applications. Its integrated with the May 2011 version of robotium.

Next up is reomte-robotium which allows using multiple emulators and device instances s to run tests. Its integrated with the Summer 2011 version of robotium. In other words you can split up the groups of tests per emulator instance to save test time.

And the last one but not the least important one, LessPainfull-local which is a way to execute Cucumber tests using robotium and its integrated with version 2.5. Yes it does use the current android sdk ant setup for ADT16.


Have you seen that dreaded aapt error? if you have an older machine and only 4 gig ram and run Linux you will see this error when Eclipse attempts to fork to do the aapt process. Some solutions have you mess with certain process flags or swap, but my solution is easier and no side-effects.  Just switch from using Chrome to the Mozilla browser.  Several tabs open only takes up 200 megs or less memory and do not add any other 3rd party plug-ins to the install.

I am putting up a BDD example while I finish my customized build scripts. It will be setup so that if you are using eclipse IDE you should be able to fully set it up with the exception of Cucumber without waiting for a build script. The main project(BDDAndroid) will contain an apectj setup and the dependency injection setup. The instrumented test project(BDDAndroidTest) will contain the setup for robotium/android-mock, dependency injection and fest-assertions and hamcest.

I will be adding the LunarLander example to use for testing thus if you follow the commit sequence of both projects you have the general sequence to get fast BDD and prototype iterations. For those new to Eclipse 3.7 and github, you should be creating your projects outside the workspace, ie home/yourname/git/github and than check the store git in project folder so that you do not get an extra project folder when remote pushing to github on a project you have created.  As I progress I will be adding hooks in my customized build script to trigger monkeyrunner to run the tests so as we can get the screenshots and regression testing.

Because I will be committing the customized build script to the same projects from first commit you will be able to see how to customize your own build-script.