Android and Google GWT
Now I have an integration decision with AndCooper Android Java Application ANT based build tool. With the webview web code suport in the build tool my diea was at some point to swtitch to Goolge GWT compiler support and keep the non GWT web tooling support there for those who wil not use Google GWT. The key question is do I make a separate project just for GWT and feed it in or a new set of directories and ANt script code to support GWT JS generation in the main Android project.
Seems to me that is should be part of the overall Android Project structure and plus if I were say secretly working on a an Android application using Motorola CLiQ-Motorola Blur APIs and the Google Maps APIs it would seem that the Google GWT tooling would be an ideal component in that development work-flow.
Build Numbers in Android Applications
When working with new innovative technologies you often have to take apart old tools and gleu them back in new ways to deal with new issues. If you have worked in JavaMe(j2ME) before you might have used something like JReleaseInfo to adjust and collate different manifest items to add to the manifest before you jar’d it such as the build number. However, in the Adnroid Java Application development world the manifest is no longer an *.Mf file but an XML file and thus the version number we have to change upon calling an ANT task such as build number is in that file.
I came up with:
<!-- Set build number -->
<condition property="build.number.property.set">
<available file="build.number"/>
</condition>
<if>
<equals arg1="${build.number.property.set}" arg2="false"/>
<then>
<!-- We know build.number will set to 1 at <buildnumber/> call
-->
<buildnumber/>
</then>
<else>
<!-- Set var build.number.initial to build.number-1 -->
<if>
<equals arg1="${build.number}" arg2="1"/>
<then>
<!-- do not change AndrodManifest -->
</then>
<else>
<!--- okay do our repalce thing on AndoridManifest.xml -->
<property name="android.version.code" value="android:versionCode="/>
<property name="android.version.name" value="android:versionName="/>
<replaceregexp file="androidManifest.xml"
match="android:versionCode=(.*)"
replace='${android.version.code}"${build.number}"'/>
<replaceregexp file="AndroidManifest.xml"
match="android:versionName=(.*)"
repalce='${android.version.name}"${build.number}.00"'/>
<buildnmuber/>
</else>
</if>
</else>
</if>
The way I came up with is:
1. check to see if build.number file exists, rember the build.number property is incremented from zero to 1 on first <buildnumber/> ant task call.
2. if false than cal <buildnumber/> task
3 if true than check to see if build.number is 1 and if so do not change AndroidManifest.xml and if not change to relfect new build number.
AndCooper and Hudson Integration

- Image via Wikipedia
First, thanks to my blog comment posters. Yes, I can see why the desire to run AndCooper in Hudson Continuous Integration Server as its easy to set up and get started. While we do not have Hudson plugins for JSLint, Jdepend, Classycle, JCSC, DocCheck, and etc I can set up AndCooper specific items so we should be able to be able to run AndCooper right in Hudson almost right at the first AndCooper project releases.
For example, if I do a separate hudson-project-docs sub-directory and put html forms of all reports in there than you can do post-build project links with relative urls to those documents and thus stil have them in some form of dashboard like. Than as hudson plugins appear make a new andcooper-hudson-build.xml script that accounts for that set of features. That way we can use Hudson CI server right away. Which means I have to write a project sample config.xml for Hudson CI server integration.
AndCooper Reports Refactoring
I am in the final phases of refactoring the reports look for AndCooper and the 0.1 release of AndCooper should be shortly. Looks like this before the final adjustments such as company logo, reports.css, and etc:

Plus, the reports should have a similar look to them to guide the developer as easy to read analysis reports. For example, adding summary explanations to some reports telling the viewer how to use the report.
I have choose to use a Continuous Integration Server as the platform to allow me to extend it beyond the first few versions to enable the easy on-the-fly-analysis. Basically, two modes. One mode allows the AndCoooper tool to run as a JavaBuilder in your IDE. The other mode allows you to run AndCooper in the Hudson Continuous Integration Server.
AndCooper Build Tool Details

- Image via CrunchBase
While I adjust the code reportts to display information in the Android Application Development Context such as Classycle:

I better explain how AndCooper fits into things. AndCooper, although it can be used as a mini-continuous integration server, is not a CI server itself. Its just a build tool with a lot of features for the Android Application Development Process. If your CI server can use ANT than you should at ome point be able to integrate AndCooper with the CI server you use.
AndCooper ReportWriter Code
I am now on the Report Writer code portion of AndCooper development. On one hand I could easily state that it should be in groovy and a separate project. The problem is that fragments it in certain ways that I do not like.
If I choose to embedd the groovy code in the ANT script than I can re-use the code in the Android Mobile Build Continuous Integration Server project and everything is right there ready to test rather than run ant scripts from multiple projects. Which means I should set every report to xml and have that as an undelrying requriement that each code analysis/metric tool has to output reports in xml form so that I can transofrm that into an Android Developemnt specialized structure and format.
What is a Mini-Continuous Integration Server for Android

- Image via CrunchBase
When I started developing AndCooper I certainly did not intend to build a continuous integration server. But, along the way it seemed that Android Application development might need one. Not in the sense that it attempts to solve all problems but problems that are specific to Android Application Development.
What does a mini-continuous integration server look like? Its very small in Ant build script size and made to act as a Java Builder within modern IDE tools to get that incrmental set of builds as the developer is coding and thus generate code analysis reports as the develpoer is developing code. The analysis is specifically adjusted to pertain to Android developer challgnes, for example a new set of PMD rules beyond the PMD provided ruleset for Android, such as a rule checking for services leaks in code.
On the ease of code analaysis report use and etc, a web dash board to view reports and eventually BiRT functionalities to query analysis data. The mini-continuous integration server for Android application development looks different in that there is no server really deploy just drop it in yoru project folder and point the IDE JavaBuilder to use the build script, its just that simple.
As I finish version 0.1 over the weekend I am wondering how AndCooper will be received by Google, OHA members such as Motorola and etc as having a mini-continuous integration server for Android application development is kind of a new concept. And having support for javascript analysis for webview Android applications is a even neweer concept. Its a trail that no-one has trail-blazed before.
Android SDK detection
So how do we detect the Android SDK version so that the AndCoooper build tool can be used if the SDK is updated? Goolge/OHA through the SDK provide us with a ANT target property located in default.properties that is generated by the SDK. Normally, ANT does not support conidiotnal logic to hook into this but if you use a differnet optional task library such as ANTXtras you can integrate with this target property to determine not only the SDK version by adjust the classpaths for the tools and apis such as:
<!-- SDK Version setup -->
<emit message="target: ${target}">
<domatch property="target">
<equals value="android-6">
<property name="android.sdk.version" value="android-3.0">
</property>
<equals value="android-5">
<property name="android.sdk.version" value="android-2.5">
</property>
<equals value="android-4">
<property name="android.sdk.version" value="android-2.0">
</property>
<equals value="android-3">
<property name="android.sdk.version" value="android-1.5">
</property>
<equals value="android-2">
<property name="android.sdk.version" value="android-1.1">
</property>
<!-- 1.0 is no longer supported in SDKs and thus not needed -->
</equals>
<emit message="android.sdk.version: ${android.sdk.version}">
<!-- Set aidl framework location based on android.sdk.version value -->
<property name="android.aild" value="${sdk.location}/platforms/${android.sdk.version}/framework.aidl">
<property name="android.jar" value="${sdk.location}/platforms/${android.sdk.version}/android.jar">
<domatch property="mapapi">
<equals value="yes">
<domatch property="oem">
<equals value="no">
<path id="sdk.apis.classpath">
<pathelement path="${sdk.location}/platforms/${android.sdk.version}/android.jar">
<pathelement path="${sdk.location}/add-ons/google_apis-3/lib/maps.jar">
</pathelement>
<property name="android.target.classpath" value="sdk.apis.classpath">
</property>
<equals value="yes">
<path id="sdk.apis.classpath">
<pathelement path="${sdk.location}/platforms/${android.sdk.version}/android.jar">
<pathelement path="${sdk.location}/add-ons/google_apis-3/lib/maps.jar">
<pathelement path="${sdk.location}/add-ons/${oem-vend-add-name}/${oem-vend-add-jarname}.jar">
</pathelement>
<property name="android.target.classpath" value="sdk.apis.classpath">
</property>
</pathelement>
</pathelement>
<equals value="no">
<domatch property="oem">
<equals value="no">
<path id="sdk.apis.classpath">
<pathelement path="${sdk.location}/platforms/${android.sdk.version}/android.jar">
</pathelement>
<property name="android.target.classpath" value="sdk.apis.classpath">
</property>
<equals value="yes">
<path id="sdk.apis.classpath">
<pathelement path="${sdk.location}/platforms/${android.sdk.version/android.jar">
<pathelement path="${sdk.location}/add-ons/${oem-vend-add-name}/${oem-vend-add-jarname}.jar">
</pathelement>
<property name="android.target.classpath" value="sdk.apis.classpath">
</property>
</pathelement>
</path>
</equals>
<emit message="android.target.classpath set to:${android.target.classpath}">
<property name="sdk-location" value="${sdk.location}">
I also included some alpha code to integrate with OEM add-ons.
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=4422b9d8-248a-42e3-9ca1-f42071010af8)
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=af0d10cb-295f-41b7-8221-bf63ee7de2b5)
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=967d9596-6f9f-4a4c-ae07-2ba9ced4bb76)
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=761c3d36-6ad8-40f9-b50a-20216b1c550f)
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=309e34b6-17cd-404a-bd9c-8c40e0c3cec5)
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=4f3bccc1-0f47-4dae-abf9-c9a1d5173a76)
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=a653116b-3863-41cf-bc22-2c0bf6cf2716)
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=f37e32dc-1a2f-420c-8d24-7df1d987c449)


