Through my exploration of attempts of an all inclusive ANT build script for Android development I have come to a set of contrary conclusions. These conclusions while they run counter to the status quo do in fact indicate that some Enterprise and Web techniques can be re-used.
In a mobile system we often have to interface with the Mobile Device Application Environment to employ unit testing which strongly indicates that a centralized builder server is not an ideal option. It is not that we could not run unit tests in a desktop JVM, its that code coverage and mock tests we can do with the mobile framework offer more value as we cannot use class loader stuff in running unit tests of a mobile framework within the desktop JVM.
There are DSL java tools that are coming out that make unit testing easier for example Calculon, and the introduction blog post about it. But the android developer still needs to do unit testing on device or emulator.
And I had an event happen this week that caused me to once again focus on this. now, imagine you are a radio station marketing company. You probably only have o n mobile developer that is forced to develop on Blackberry, iPhone, and Android. So lead developer Ascott decides on the Android application to have SDK 1.5 as base to target 1.5, 1.6, 2.0.1, and 2.1.
If you have worked with mediaplayer through those OS versions and dealt with multiple screens you know what errors are going to pop up. Now remember shops like this typically do not invest in a whit4 box deviceanywhere testing solution as their marketing budget per client for non development stuff is often far bigger than the budget assigned to mobile application development.
Now what if we had a white-box solution that was easy to use say suing Groovy DSL that could some automatic tests on Android OS versions and device setups in a set of emulator instances. Than to get full re-use of our investment we use Groovy to make the android application build system more powerful and yet simple.
Because its groovy it already builds on the java knowledge and yet gives a DSL to leverage rather than ANT DSL. This reduction in developer use complexity and use at the single developer level than should translate into developers seeing it as benefiting their android development work flow. And the general idea is to have eclipse IDE execute this groovy/gradle build script as its incrementally compiling the project.
There is jvoegele’s android gradle plugin for gradle style android application build scripts but it forces the developer to manualy adjust the proejct each time its created because gradle prefers src/main/java rather than src. Because we are not using a gradle unit and coverage anyway stick with the Android ANT convention of src.
So the only part is breaking down the building the components of this Groovy/Gradle Android Application build system and using a sample Android Application build so that I am eating my own dog food. The sample android application will be an Atom/RSS reader. That should be complicated enough to cover unit testing, unit testing coverage, and white box testing implementations along with webkit webview stuff as well.
In the mean-time I am almost finished with an Android Programming knol detailing the ant build script I use. Thus, I should have that up shortly.