Ignition 0.1 Is Here

Today it’s “Fun Friday” (10% time) at Qype, so we thought this would be a good opportunity to release the first version of our ignition library for Android!

What’s ignition? In short, it’s a rewrite of Droid-Fu. What is Droid-Fu? It was an attempt to create a utility library for Android that makes your life easier by creating add-ons and wrappers for the Android framework classes that are just a little friendler to use. Our approach with Droid-Fu was to pull all the helper code and boilerplate we wrote for our Qype app into a reusable library, but we did a poor job at maintaining it. We didn’t have proper release and issue management in place and since I was short of spare time (not least due to my work on Android in Practice), it just never happened. We soon had many issues filed, but it was virtually impossible for us to backtrack through all the snapshot versions to find out which one it was actually affecting.

Moreover, we did mistakes with Droid-Fu’s API design, and we wanted to have a chance of fixing these without horribly breaking all the apps that used it. Yes, we could have done a “Droid-Fu 2.0” (even though there never even was a 1.0) or a “Droid-Fu NG”, but I felt the least intrusive way would be to start out fresh as morning dew.

The fruit of this labor is ignition, and I believe we improved things a lot. First, here’s what ignition has to offer in the first place:

Cross-cutting stuff

  • helper classes for dealing with Intents, dialogs, device screens, etc.
  • an improved version of AsyncTask (IgnitedAsyncTask) which makes it a lot easier to deal with the following things:
    • task life-cycle: there are onStart, onComplete, onSuccess, and onError callbacks
    • yes, your task may now raise exceptions while running
    • all callbacks are guaranteed to be passed a valid Context object, so that you can immediately update the UI (those must be bound and unbound using connect/disconnect to avoid memory leaks!)
    • re-use task logic from pre- and post-execute handlers by being able to bind to different callables that execute the actual job logic
  • EndlessListAdapter can be used to implement lists that fetch more content when reaching the bottom of the list

Dealing with remote images

  • RemoteImageView is a drop-in replacement for ImageView which can download its image resource from the Web and show a progress spinner in the mean time
  • if you’re showing a whole bunch of these, you can use RemoteImageGalleryAdapter which will feed RemoteImageViews into an Android gallery widget
  • both are backed by RemoteImageLoader, which can be used independently to download images drawable into ImageViews asynchronously. We use this to download thumbnail images for list elements in ListViews on the fly.
  • all this in turn is backed by ImageCache, a 2-level cache which is able to cache to both internal storage and SD card, therefore minimizing network traffic when dealing with lots of data (as is the case with images)

Dealing with HTTP requests and network failures

  • speaking of caching, you can not only cache image data, but also HTTP responses using HttpResponseCache
  • better yet, IgnitedHttp is an abstraction of Android’s Apache HttpClient that exposes a simple DSL to build and send HTTP requests, like so:
    • new IgnitedHttp().get(“http://example.com”).expecting(200, 404).retries(3).withTimeout(5000).send();
  • it integrates with the response cache by setting a single flag
  • it will enable GZip uncompression of response data with a single flag
  • it will register a BroadcastReceiver which listens for changes in network configuration and automatically update e.g. proxy settings for you (this can be a major source of error in your app for users who must go through carrier proxies on 3G and then fail over from or to Wi-Fi)
  • it has a more robust request-retry logic than the standard HttpClient does

Dealing with location

Stefano has build a fantastic new way of dealing with location on Android. It takes all the cruft out of your Activities and hides it in a single annotation you drop onto an Activity. It will then automagically inject location fixes into a prepared field, using the power of AspectJ. Read more about it on his blog.

What’s different to Droid-Fu?

Except for the location module, all of this has existed in Droid-Fu. As I mentioned before, the motivation behind iginition was not to build a new library, but re-launch what worked well for us in a more maintainable and less intrusive way. Here’s what changed:

  • The project is now split into multiple modules, so you can decide which ones you’d like to link. This makes the whole thing less monolithic, and for instance doesn’t force the Maps dependency on you if you do not want to use the location stuff
  • The project is less intrusive. You do not have to inherit from BetterApplication, BetterActivity or BetterService anymore (these classes have been removed). This was done as to make ignition integrate seamlessly with other libraries like Roboguice. We felt that ignition was not supposed to be a framework: it should be an all-opt-in solution.
  • The API has received a major cleanup. Things have been renamed, restructured, and generally made more consistent.

Where can I get more information?

It’s all on GitHub right now, but here are some quick links to useful stuff:

Thanks again for everyone who contributed issue report and fixes! We promise we’ll do more regular updates with this library.