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.