MobileBytes

Just another WordPress.com weblog

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.

Reblog this post [with Zemanta]

September 26, 2009 Posted by sharemefg | AndCooper, Android, Java, Mobile | , | No Comments Yet

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.

Reblog this post [with Zemanta]

September 23, 2009 Posted by sharemefg | Android, Java, Mobile | , , | No Comments Yet

AndCooper and Hudson Integration

Looking downriver from the Circle Line sightse...
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.

Reblog this post [with Zemanta]

June 18, 2009 Posted by sharemefg | AndCooper, Android, Java, Mobile | , , , | No Comments Yet

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:
andcooper5
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.

Reblog this post [with Zemanta]

June 18, 2009 Posted by sharemefg | AndCooper, Android, Mobile | , , | No Comments Yet

AndCooper Build Tool Details

Image representing Android as depicted in Crun...
Image via CrunchBase

While I adjust the code reportts to display information in the Android Application Development Context such as Classycle:
andcooper3

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.

Reblog this post [with Zemanta]

June 16, 2009 Posted by sharemefg | AndCooper, Android, Java, Mobile | , , , , , , , | 1 Comment

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.

Reblog this post [with Zemanta]

June 11, 2009 Posted by sharemefg | AndCooper, Android, Java, Mobile | , , , , , , , , | No Comments Yet

What is a Mini-Continuous Integration Server for Android

Image representing Android as depicted in Crun...
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.

Reblog this post [with Zemanta]

June 5, 2009 Posted by sharemefg | AndCooper, Android, Java, Mobile | , , , , , , , , | 3 Comments

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]

June 2, 2009 Posted by sharemefg | AndCooper, Android, Java, Mobile | , , , , , , , | 1 Comment