Android Programming Experiences with Sparql Droid
As I release my 3rd Alpha-version of Sparql Droid I thought I’d document a few lessons learned and open items as I work with the Android environment. Some of my constraints are based on targeting smart phones rather than tablets, but the lessons learned around development environments, screen layouts, and memory management are valuable.
I’ll start on the development side. I use Eclipse and the android development plugin is very helpful. It greatly streamlines the development process. Principally, it automates the generation of the resources from the source files. These resources, such as screen layouts and menus, require a conversion step after being edited. The automation, though, comes at a price.
Taking a step back, Android doesn’t use an Oracle-compliant JVM. Instead it uses the Dalvik VM. This difference creates two major ramifications: 1) not all the standard packages are available; and 2) any compiled Java code has to go through a step to “align” it for Dalvik. This alignment process is required for class files you create and for any third-party classes (such as those found in external JAR files). Going back to item 1, if an external JAR file you use needs a package that isn’t part of Dalvik, you’ll need to recreate it.
The alignment process works pretty fast for small projects. My first application was a game that used no external libraries. The time required to compile and align was indistinguishable from typical compile time. However, with Sparql Droid, which uses several large third-party libraries, the alignment time is significant – on the order of a full minute.
That delay doesn’t sound so bad, unless you consider the Build Automatically feature in Eclipse. This is a feature that you want to turn off when doing Android development that includes third-party libraries of any significance. Turning off that feature simply adds an extra step to the editing process, a manual build, and slightly reduces the convenience of the environment.
With my first Android project, I was able to edit a resource file and immediately jump back to my Java code and have the resource be recognized. Now I have to manually do a build (waiting a minute or so) after editing a resource file before it is recognized on the code side. Hopefully the plug-in will be improved to cache the aligned libraries, saving that time when the libraries aren’t being changed.
Another lesson learned for me relates to GUI interaction, specifically updating the GUI. In Sparql Droid I am using threads so that processing of ontologies or execution of SPARQL queries does not interfere with UI interaction. I immediately hit the Android design principle that only the thread that created a view can update the view.
Attempting to interact with a UI component from another context (thread) leads to a CalledFromWrongThreadException being thrown. The correct way to have an asynchronous update to the UI is using a Handler instance that is created as part of the view and therefore runs under that view’s thread. Once I setup a handler and used events to communicate updates, I was able to create threads and manage asynchronous GUI updates without any issues.
A major frustration point for me was an Ant 1.7 compatibility issue. I hadn’t bothered upgrading to Ant 1.8 and for my first Android application I had no issues with the release target that the Android environment provides. However, the reason it worked was that I was not using any third-party JAR files.
There is an incompatibility with the Android development environment’s dynamic inclusion of JARs in the default libs folder. The real issue is that the Android setup doesn’t complain about Ant 1.7. According to this bug report that shortcoming will be resolved in the next Android development tools release (perhaps it has already).
Unfortunately the build failure is silent (since the build classpath includes the JARs, only the Dalvik alignment process doesn’t) and the symptom is, obviously, a ClassNotFoundException when you run the released application. Focusing on that error led me down the wrong path for a while since I though the issue might be an incompatibility with a class being aligned – even though it was working in the emulator. I eventually unzipped the APK file and saw that the JARs were not there. Given that fact, Google quickly led me to a report about the Ant 1.7 and Android tools problem.
Of course a major constraint when programming for the phone is memory. When I programmed for my Vic 20 (with a whopping 3.5 K of user memory) I prided myself on what I could squeeze into the system. I’m back to pursuing that line of design.
For me, the most interesting aspect of dealing with constrained memory is reacting to OutOfMemoryException situations. I’m experimenting with detecting these and changing the operation of the program. In many cases the out of memory condition isn’t fatal and can be handled (at least with the functionality I’m working with currently).
For example, a common place for me to exhaust memory is when resizing images that have been downloaded. In my initial design, I downloaded the image and held onto the original, returning a resized copy to my view. My first memory-sensitive fix was to resize the image and only keep the smaller version.
However, depending on the number of images being downloaded this can still overwhelm the available heap. I have been experimenting with catching the out of memory condition and abandoning the image. This seems to work fine in the emulator. Next I’ll be trying to save the image to local storage as a last ditch effort to not losing it.
I have also been learning a bit about image manipulation. There are API calls that seem to imply they will support resizing an image in a general fashion but they don’t seem to actually alter the image. Specifically, I tried creating a Canvas with my desired dimensions and calling the Image class’ draw() method, keeping the returned Image instance. However that image had the same dimensions as the original.
To actually resize an image, I ended up having to create a Bitmap instance from the Image and use the createBitmap() method, passing in the desired dimensions. It isn’t clear to me from the API documentation why my original approach doesn’t work.
One other design consideration that I’m still fussing with is laying out sets of query results. When pulling data that is best represented in groups we often use tables. Each row is a member of the group and each column is one attribute of the group. However, on the small UI of a phone that design almost always guarantees horizontal scrolling. Also, if the columns require varying amounts of vertical space then the table looks odd when the taller columns aren’t visible.
When I first released Sparql Droid I had the SPARQL results reported in a table. I didn’t mind the horizontal scrolling and for simple result sets the tables weren’t too wide and my columns had similar amounts of data in them so no rows were taller than others. Once I opened up my queries to a broader set of endpoints and added images that all changed.
Using the HorizontalLayout becomes problematic; it implies an infinitely wide canvas. The side effect I encountered was that large text fields simply ended up as one long line rather than wrapping. Add to that the fact that images occupy varying vertical space, and the table ended up looking very odd.
I removed the use of a horizontal layout and instead now group results with a horizontal divider label row. I like this visualization better for most situations. Though I think for small sets of attributes that have short values, a horizontal layout makes more sense. This is another place, like dealing with memory constraints, where I’ll probably want the program to make a dynamic decision. In this case, deciding on a horizontal or vertical record layout.
All told, these are the Android programming events that have been of the most interest, and in some cases frustration, for me over the past few weeks. I’m looking forward to adding more features to Sparql Droid while learning more about the Android environment.
I’d appreciate your feedback whether about programming in general, semantic technology or the Sparql Droid application.
Tags: Java, linkedin, ontology, programming, semantic web