As I mentioned in an
earlier article, one of the goals for the Android port of Hecl is to make it as easy as it is to create Java ME applications:
- Write the script.
- Wrap it up and send it to the phone.
No "compiling" (well, none that's obvious or explicitly asked of the user, at least, as we'll see) or fiddling with build files or writing new Java classes or any of that.
We're still not there yet 100%, but I did managed to hack together a system that, from an original
Hecl.apk, creates a new application that can be installed on the emulator. This is tricky, because Android looks at the uniqueness of the package and class utilized for the application, meaning you can't just rename
Hecl.apk to
Foo.apk and install it as a separate app. The emulator will overwrite your old copy of Hecl.
Here's what we go through to make this work. Be forewarned - big, ugly hacks that are not for the faint of heart follow. The command line isn't exactly beautiful either, but it beats all the individual steps that it replaces, as we'll see.
java -jar /home/davidw/workshop/hecl/jars/AndroidBuilder.jar -android \
/opt/android-sdk_m5-rc15_linux-x86/ -class Example -label "Hecl Example" \
-package my.example -permissions ACCESS_LOCATION,ACCESS_GPS
- The first thing that needs to be done is to replace the
AndroidManifest.xml that is contained within our "template" application, that resides in Hecl.apk, a copy of which is contained within the AndroidBuilder jar file. Since the compiled version of the xml file is a binary format that hasn't been reverse engineered or documented yet, the best way to do this was to simply:
- Write out a new
AndroidManifest.xml in our temporary work directory that uses our provided package name, label and class.
- Using the
aapt command in the SDK, create a new, empty apk file, specifying the newly created xml file as the manifest file to use.
- Now we can extract the compiled version of the xml file, for later use.
- At this point, we extract a version of
Hecl.jar contained within AndroidBuilder.jar to the temp directory.
- Now we need to generate some Java classes that correspond to the new package and class names that we've passed to AndroidBuilder. Ideally, I would have done this with some tools to write the byte code out directly, since the classes are so simple: all they do is subclass the
Hecl and SubHecl classes so that methods fall through to those.
- But instead, I just write out the .java code and compile it.
- The two new classes get stashed inside the copy of
Hecl.jar that we're working with.
- We now use the
dx command to compile the entire jar into the classes.dex file that Android uses.
- Since
Hecl.apk is just a zip file, we can replace the AndroidManifest.xml file and classes.dex file with the new files we have created.
- At this point, we rename the whole works, and move it out of the temporary working directory to the current directory.
Phew! That's a lot of ugly work. It's obvious that a lot of this should and could be handled in a less "brute force" way, but for now it gets the job done. The only thing left to do is replace the Hecl script, which is very easy:
zip -r Example.apk res/raw/script.hcl
This makes it possible to whip out new Android Hecl scripts without carrying around a lot of project infrastructure - all you really need is
AndroidBuilder.jar and your script.
Naturally, all of this is very much a work in progress, so it may not work as advertised, and, given the mess that we go through, bugs are likely as well. Do report them if you find any, and have fun! In the future, it will be necessary to make it so that it's possible to add resources to the apk file with zip, and have them be available to Hecl applications, which was actually the focus of the previous article.
Bubulle asked about whether anyone has computed the number of bugs open (and by inference close) and I've just found a link from the DD statistics pages: 
Ubuntu package translation storage in Launchpad used to annoy me, primarily because the synchronization workflow between Launchpad and upstream was unclear. My questions have been 
Christian, 
I finished reading the 
The 
I think that Matt Hartley is spot on on his 
PGAPack is rather nice and fairly small library for 'parallel' optimisation
via generic algorithms using the MPI message passing protocol. PGAPack 1.0
was written by David Levine while doing graduate work during the mid-1990s at
Before my 
Quite a lot people are unhappy with how the package descriptions are translated. Different teams handle it differently, but the approach the German "team" chose is quite unfriendly from a quality point of view: The 
