Working With An Evolving Android SDK

Image by netzkobold via Flickr

Finishing up hacks and testing those with AndCooper 0.1 The problem with the Android SDK is it  is evolving so we have things that change form release to release and so I have had to ot hacks to get around those changing items such as the value of the target value in default.properties changing syntax and etc.

The whole idea here is that say Google and OHA pulbish a new relase of Android SDk called 2.0 on Firday.  Than I should as a developer be able to take the AndCooper Build Toool and with no changes or avery few adjustments be able to build projects right-away using the AndCooper tool. I as an Android Developer should not hav to wait for the p;roject lead of AndCooper to adjust and ix things, it should alrady work with the new SDK release.

It is a very different approach than say an OEM, say Motorola,  would take on building an Android Application Development ANT-based build tool as my target audience is both beginning Android  Developers and Advanced Andorid Application Developers. It is importna ot get this right as we will see Four SDK releases per year. Through today I expect to be posting some videos of final AndCooper 0.1 testing to apologize for the delays in the 0.1 release.

Advertisement

Emma Builds for AndCooper

Image via CrunchBase

Emma Builds of the present SDK and the bleeding edge SDK will be downloadable today from the AndCoper project page by end of today. Because they are only for my distro an article with instructions so that you can build one for your distro will be posted under my profile at the Google Knol site.

For those on Ubuntu 9.0.4 that cannot wait, my change to Qemu, sockets.c, line 32 is:

#  define __USE_GNU 
#  include <netdb.h>

The define must be before the include netdb.h. It was either that or the change makefile for qemu trick outlined here. At this point I am not real sure which might be more correct as I have not touched C in years. if I had to choose, the change above since it somewhat less obtrusive in some aspects rather than the makefile change.

AndCooper Instructions

I am finalizing the AndCooper Instructions:

and testing for the 0.1 alpha release and thus the release will be over the weekend. It is not the experts in ANY that I am worried about. Its making it use-able for those who are not experts in Apache ANT.

Its the little details such as an set of instructions, having an image an music set of sub-folders in the assets folder that have double use both in Android WebView application development and regular Android Application development.

WebView Obfuscation Magic

This is what the obfuscation prepaation ANT script code looks like:

<property name="assets-css-obfuscated" value="${assets-folder}/css-obfuscated"></property>
<property name="assets-js-obfuscated" value="${assets-folder}/js-obfuscated"></property>
<property name="assets-js-libs-compressed" value="${assets-folder}/js-libs-compressed"></property>
<property name="project-assets-css-libs" value="${basedir}/project-assets/css-libs"></property>
<property name="project-assets-js-libs-compressed" value="${basedir}/project-assets/js-libs-compressed"></property>
<property name="project-assets-temp-concat" value="${basedir}/project-assets/temp-concat"></property>
 <!--  The assumption is that during testing/dev we want the non obfuscated js/css files to 
 be real but the obfuscated oen sot be empty and reverse that for the 
 production/release. Thus prep step prepares an obfuscated empty file
 concat of the js-libs and the css files.  we assume
 that we plaqce js-libs-compressed libs in the folder
 -->
 <!-- Concat js-libs-compressed into one js-libs-3rdparty file-->
 <concat destfile="${project-assets-temp-concat}/js-compressed-3rdparty.js" force="no">
 <fileset dir="${project-assets-js-libs-compressed}" includes="**/*.js"></fileset>
 </concat>
 <!-- Move js lib file to assets -->
 <copy file="${project-assets-temp-concat}/js-compressed-3rdparty.js" todir="${assets-js-libs-compressed}"></copy>
 <!-- Produce an empty css-obfuscated file and a js-obfuscated file only empty for testing/dev -->
<property name="css-obfuscated-file-name" value="css-obfuscated-file-name.css"></property>
<property name="js-obfuscated-file-name" value="js-obfuscated-file-name.js"></property>
 <concat destfile="${project-assets-temp-concat}/${css-obfuscated-file-name}" force="no">
 <fileset dir="${project-assets-temp-concat}" includes="${css-obfuscated-file-name}"></fileset>
 </concat>
 <copy file="${project-assets-temp-concat}/${css-obfuscated-file-name}" todir="${assets-css-obfuscated}"></copy>
 <concat destfile="${project-assets-temp-concat}/${js-obfuscated-file-name}" force="no">
 <fileset dir="${project-assets-temp-concat}" includes="${js-obfuscated-file-name}"></fileset>
 </concat>
 <copy file="${project-assets-temp-concat}/${js-obfuscated-file-name}" todir="${assets-js-obfuscated}"></copy>
 <delete includeemptydirs="true">
 <fileset dir="${project-assets-temp-concat}"></fileset>
 </delete>

Than during the release.produciton target before the apkbuilder task you make empty css-not-obfuscated.css and js-not-obfuscate.js files and thus your import wil always be:

import css-non-obfuscated.css

import css-bofuscated.css

import js-non-obfuscate.js

import js-0obfuscated.js

import js-compressed-3rdparty.js

Notice that you will always have the import js 3rdparty compressed lib.  Because if you import an empty css or js file nothing happens it will always work right for both testing and production release because of the switching of which one is the empty file. Is not that a cool trick? And you never have to go through the html and change the damn imports every time.  Sure I could have threw together an ANT build script like everyone else but I thought it might be valuable to actually have an Android Build script that supports WebVuiew application development.

Is this trick used in the PhoneGap or QuickConnect or Rhomobile build scripts? Suprisingly, no in fact. This is the quality that needs  to go into a WebView application development book. However, I can not develop the book unless I have side Android App Development contracts. Now, some more details to finish than AndCooper Build Tool 0.1 release.

WebView Magic in Android

Image by netzkobold via Flickr

Part of the difficulty in using WebView has to do with the build, test, release process. Let me explain. You are importing or linking the importing of css and js to different locations depending upon whether you are testing or producing files for release. Obviously importing both the non shrinked version along with the shrinked version could also cause problems.

But. what if your importing both non-obfuscated and obfuscated to do this:

Testing:

non-obfuscated

-real css file

-real js file

obfuscated

-concat dummy empty css file

-concat dummy js empty file

Than, now here is the magic for the production release you reverse it in that the operational files are the obfuscated ones with the other original files being concated to empty files, importing a concated empty files does nothing(perfect!). Now, all that extra changing of imports and copying files and etc eliminated! Why? Because the step to change the concated empty files from non-obfuscated to obfuscated occurs during the lines right before the apkbuilder ANT task in the release.produciton target.  Than always name the css-library as css-library.css and the js libraries as the concat file of js-library.js. It will look weird that you have a pair of imports for css and js but hey no more other extra steps, who cares what it looks like when it saves some steps!

Now here is what I do not understand. The amount of time saved in the development process in developing Mobile RIAs that deploy on Android is significant when usin gthis new AndCooper build process tool so why the ‘long-face’ among several Android parties to the point of me not even answering Android employment inquires because of the non-listening about these important areas? Should I have to hide from Android Employment inqiuries if I am creating such time saving development tools?

Okay, sorry for the rant. The non OHA members have been extremely helpful and the comments have been used in making AndCooper better. And let us not forget all the helpful and overworked  Google Engineers who answered by questions this spring about SDK tools as the AndCooper project idea was being formed. The upcoming videos tonight are another reports video and possibly a video showing the tiddlywiki document system in AndCooper.

The whole reason why I built Android applications including those using WebView bare for several months was to understand what part of that process had to  change to make it accessible to more developers  both in saving time within that development process and etc. My model of how things should not be, was the PhoneGap mess. that is nothing against the contributors to PheonGap but no-one is really acting as architect and it shows up in the way the phoneGap is organized and how that impacts development time of those who are new to Mobile RIA development and those that are not.

Webview-Code Obfuscation-Minifization

Those of you using WebView fully as a mobile RIA or as a way to embed application help html files you have probably been searching for a way to obfuscate and shrink the files. Not just js, but also css as well. You can drive the YUI-compressor library through the javaFlight ant task. It is the last bit I needed integrated into the AndCooper Android Application Build tool.

AndCooper Reports Video

While I finish up the other reports, a video showing most of the AndCooper code analysis reports:

You will notice not only we get UML diagrams within javadocs  but also some jdepend diagrams.

AndCooper 0.1 Progress

Just tracking down some final errors so that I can release the first alpha 0.1 version of the AndCooper Android Application Build Tool. Screenshots of one of the code analysis reports:

I will dress-up the reports later. 0.1 release should be shortly.