The Android Learning Curve

I'm learning Android development the hard way by writing my own simple compiler for a Python-like language. Doing this means learning about compilers, the Dalvik virtual machine, the Java language, and both the Android and Java APIs. While doing these things, I'd like to be able to create a few programs that some might call “Apps”.

Unsteady Progress

In terms of creating programs, things have been quite steady for a while. Of course, there have been complex things like matching the behaviour of the compiler's understanding of Java-like templates to what Dalvik expects. Other smaller obstacles still manage to surprise, such as the way I managed to break how the Object class's methods were called by assuming that the methods of any class without a base class are called using the invoke-interface instruction. The Object class isn't an interface, so that wasn't going to work. It's surprising that I only discovered that problem now — still, it was easy to fix.

The latest problem was caused by my attempt to reduce the number of objects to represent temporary variables. Ideally, all objects representing temporary variables occupying the same position on the stack with the same type could be reused. The problem with implementing a caching or factory system for these was that objects to represent variables are created when the variable needs to be allocated and sometimes the variable is allocated before we know its type; this is particularly a problem with empty list and dictionary literals. Ultimately, I decided to allow variable objects to be allocated when needed, but discard redundant ones when they are stored in instruction objects. I made two attempts to solve this problem; the first involved putting the cache at the point of allocation, the second put it at the point where instructions are created.

What About The Apps?

I find it difficult to get going with creating programs because I'm used to writing in Python, and Serpentine is not Python. I'm learning the semantics of my own language (or dialect) while learning the APIs it relies on. The APIs vary between reasonably simple to over-engineered (or over-abstracted) to over-complicated. There are development guides to read, but the API documentation itself is severely lacking in many places. In fact, when choosing some links to show some of the stranger recommendations in the API documentation, I found that the latest set of class pages seem to have dropped almost everything but the inline constant/field/method documentation!

Add to this the problem that even the offline documentation wants to call home to android.com, google.com or even google-analytics.com and you're looking at a slow browsing experience unless you block Javascript for those sites. All for the sake of showing the “correct” fonts or having an API-version-sensitive class list. So, slow progress is made, where you feel that the simple things you manage to achieve are hard won.

One of the positive things is that things are made and run and tested. As with many of the embedded platform experiments I've done over the last few years, a lot of the programs I end up making involve graphics of some sort or other. Combined with the need to test things like loops and array handling, one of the obvious non-trivial test programs turned into a simple toy based on a game I wrote many years ago for the Acorn A3000. It's amusing to think that the 1+ GHz processor in my phone is now running a similar game to an 8 MHz ARM-based system from 1989. The original game wasn't all that much fun to play, and the fluid flow thing is a nice effect looking for some gameplay, but it might develop into something.

Other programs have been based around file formats I've written existing Python modules for reading: those for handling Janome Embroidery Format (JEF) and Unified Emulator Format (UEF) files. The code for both of these modules needed some work before the compiler would accept it, and I took the opportunity to read each of these formats a bit differently than I did in the corresponding Python modules, partly out of necessity. It certainly seems to be easier to do file format research with Python than it is in the Java universe.

Rounding Off

I almost accidentally gave this article the title “The Android Learning Curse”, which seems quite appropriate. It's something that it seems I'm stuck with for the time being. Still, when it seems there's so much still to do, it's important to look back and see how far you've come. I'll try to keep writing updates to show things that I've been working on.

This document is licensed under the Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International license.