Archive for January, 2012

Eclipse EGIT/Github Trick

Is not that extra project folder annoying? Yes, they changed egit again as you can no longer store the repo in the eclipse workspace. To get the .git metadata folder in the project folder root like github expects uncheck default location at project setup and add an extra folder above the project name. For example:


This will than allow you to store the .git metadata folder in the proper place as its not crating the repo in the workspace which is not allowed.

If you use OOP than this looks like your code:

and in Android it gets worse in the Activity and other classes with views boilerplate, etc mixed in. If we are willing to change our workflow, dev techniques, and toool integration we can have this:


Guess which is easier to analyze and maintain? Yes, its true you can get some development time savings by adopting to new tools like LessPainfull or other instrumented testing in the clouds android testing solutions. But, the amount of time savings is not that much because as your accuracy of test results increases so does its effective use which increases your dev time as you make sue of those results,ie you get a huge increase in QA quality for some inceases in devtime.

If you separate out the concerns rather than just inject them we should see a decrease in development time as code libraries are built up as some of the cost savings wil occur when you re-factor the libraries you are using to separate concerns. Iteration-wise it should allow any android developer to push out iterations of an android application faster than they have did such development work before by at least a2 to 1 factor.

Now, of course if you are a start-up you could get the android developer candidate that looks pretty on a resume for the HR department to gleam about or yo cold just maybe pay attention to technical and development debt and get the android developer that develops new techniques and processes and tools to solve both short-term and long-term problems.


Aspectj Android Examples

I should have known to look at my peers github profiles for this, duh. Matthias Kappler(kaeppler) has two android projects using aspectj in some very useful ways. The android  library is called Ignition and the example project is ignition-example. Word of caution he is using maven and gradle and the gradle-android plugin so ou may have to translate to using with ant.

You can cut out boilerplate, etc using aspectj annotations in certain ways see the IgnitionLocatioManager.aj example

xGherkin-Cucumber plugin

There is a new XGherkin Cucumber Eclipse plugin based on xtext. Update site link is in the readme.

I have figured out howto run cucumber-jvm and robotium, etc the same way as LessPain. I just, now, have to write the android application build.xml to enable it.

It is not the really the speed of the test execution that matters, like robolectric(pivotal) claims. Its can you speed up the test writing by making it easier to write the test code. I think that combination combined with more reliable tests in the realm of BDD instrumented will be enough to always choose robotium over robolectric.

Fest assertions for Android

This an alpha build of the two fest-assertions android jars that you need to use Fest assertions. Use at own risk but if you download and use please blog about it.  Fest-assertions-android and fest-util-android. Some github stuff will go up later maybe, Nic Strong is the project lead of the original project at github. I just did a quick build now so I could use it.


The other aspect of agile is that you go through an evaluation process of your workflow and development tool chain. As we all know the docs on the android emulator are oblique in some areas.

To properly use BDD instrumented testing we have to improve the speed of the emulator. This is specific to those of us who have older PCs, if you have a brand new PC and can get set in your BIOS(assuming you do not run windows) the KVM speedups than you can get the latest android-x86 images and load that in VitualBox as your emulator. For the rest of us its these things:

1. AVD Device Ram size 768MB

2. AVD Cache Partion Size 556MB

3   LCD set to 240

4. Check use snapshot

Now, when you launch an emulator that launcher configuration is stored as the default for next time that you launch that AVD. For phones set the scale to between .54 and .84. Obviously, you can probably leave tablets set at say .54. And of course you also want to turn off the boot animation so in your IDE assuming that it has startup options box you wil enter:

-no-boot-anim -scale .64

Now, that does not take care of all the speed problems as we have a single-threaded qemu emulating arm stuff and openGL, etc but it helps quite a  bit to get it to a more tolerable level when completing instrumented testing.

I have updated my proguard.cfg configuration file.  I have added stuff for using roboguice 2.0 and guice. Its not fully tested as of yet so use at your own risk. The general idea was I wanted to get to the point of sometime this next week being fully switched over to always using roboguice/guice and BDD instrumented testing and thus needed certain items configured a certain way to be able to do everything or close to everything form the IDE without a build file as I am still cleaning up the build.xml file that I will be using.

Android build.xml drinking game

Found some more errors in build.xml supplied by adt16 in the android sdk. What it boils down to is you need to move two xpath property declarations back to the ant root node so that they are initialized right, see the gist. So what is the drinking game for each sdk android tools release for every error in  the build file take drink of wine and eat some cheese. please Google/OHA start offering some credit/debit card cash bounties to this shit as I am getting tired of seeing them every time you change the build process. Or maybe field test the changes before releasing a new sdk version?

Some are still not confuse so lets cover this point again. In mobile we have a virtual machine meaning that we cannot predict the behavior of member variables that have been exposed. in other words its the underlying reason why we came up with interface patterns in Java. That is different from say ObjectiveC iOS programming. That is the uniqueness of developing on a computer language environment that happens o use a Virtual Machine.

So in performance constrained environments where we are relying less on interface patterns what testing do we have to do to verify behavior since we are not normally mapping it too well through our architecture design? Exactly, BDD or functional unit testing which directly implies instrumented testing because that is the only way to measure the behavior on such a test in the first place.

Developers who advocate TDD unit testing in a JVM in a VM computer language that is different from running the same application through BDD unit testing on an emulator or device are hiding a choice they are fostering on you to appear cool when inn actual reality they expose themselves to deficiency in understanding what a mobile VM does why certain architecture patterns arose within java. That is a very bad choice to foster on someone in name of speed to replace proficiency in java development in a mobile constrained environment.