Changes in AIRS: Storing in SQLite (and more)

As you know from previous posts, I’m heavily extending AIRS towards more functionality, better UI, better storage and more. It’s a difficult process since I’m learning as I’m implementing. Recently, I implemented the biggest change in AIRS since starting its development: local recordings are stored in SQLite now!

This not only increases security in terms of protecting the previously created text files from access by other apps or users. It also allows for easily extending the visualisations that have found entry in AIRS. All on-device visualisations are now ported to the database model and the synchronisation of local recordings is done by temporarily creating text files which are usually deleted after being transferred according to your choice (e.g., via Bluetooth to your laptop).

The changes, however, came with many teething problems. SQLite is unfortunately not as multi-threading capable as the documentation for it claims. My many parallel write accesses, for instance, led to frequent crashes after the changes, although the documentation claims that SQLite is thread-safe when used as a single connection object. Obviously, it is even worse when you use multiple connections to the database. All of this is now hopefully sorted with the most recent release since DB access is now channeled through a single DB object and any parallel access is read-only which is safe.

In addition, AIRS now also supports access to calendar and sent SMS information. This, obviously, required more permissions added to the already long list but it also enhances the recording features and gives you a greater ability to create useful applications based on the recordings (having had only received SMS before, for instance, rendered many of the SMS threads useless since the sent part was missing).

With the many changes, however, the often mentioned fragmentation of Android hit me badly. I’m now using more and more API calls that are not available in older versions, requiring more SDK checks in the software. Some API level dependencies are also not obvious and difficult to search for in the Internet. For instance, the access to calendar data changed from Gingerbread to Honeycomb and above, requiring two different calendar database access methods. Figuring this all out is difficult and often leads to crashes on devices affected by the SDK difference. The method of developing is, unfortunately, reactive. In other words, I need to rely on bug reports being filled in and sent by users of AIRS. While these reports nicely pinpoint problems in many cases, this is generally undesirable since it requires AIRS to crash on end users devices, which likely leads to frustration (and likely to de-installation of AIRS). That’s frustrating to me since that’s the last thing I want.

So I hope that anybody who reads this and uses AIRS sympathises with the difficulties to develop for such different models and SDK levels in Android. Bugs are not only caused by bad programming but often simply by issues that are difficult to test (and the emulator only helps little since many of the supported sensors in AIRS are unavailable in the emulator). So bear with me while I’m sorting things out!