Screaming Penguin

Another useful Android programming tip is to either allow users to selectively backup any database your application uses, or just do it for them in the background (at some interval).

Why is this important? Well, if the user gets a new phone (for whatever reason, lost it, upgraded, chucked it out the window before going kayaking) one of the first things they will do is hit the Android Market again and try to re-download the applications they had (the Market saves this info and makes it easy, well, generally, there are a few quirks, but that is beyond the scope here). Also, they might just want to uninstall your app at some point and later come back to it on an existing phone. Without a database backup they might re-acquire your application but they will be pissed (rightly so) if all the data is missing.

Some applications handle this very well (notably Evan Charlton's Mileage, which is a great app BTW, has always upgraded for me flawlessly -- I don't know if it uses a similar method to what I advocate here or not, but it works very well however it does it), and others don't (Google Listen, I am looking at you ;)).

To that end in this article we are going to modify the AndroidExamples application we have worked on before here at TotSP to include a new Activity that allows users to backup the database. This is really just to demonstrate a few ways to do this rather than an exhaustive example, but it should get you started if you are interested in this area.

Our new version of AndroidExamples (complete code via the link) will have a Menu on the Main activity that lets users go to a new ManageData activity -- as seen in the screen shot below:

Programming on Android is pretty easy. At least it is at first, then the subtleties creep in -- like maintaining state, long running tasks, managing orientation changes, and so on. When you get to that stuff programming Android gets, well, not hard, but let's say more complicated.

The Android APIs are generally very nice, and there are ways to deal with just about any situation, it's just that they aren't always obvious. In this tutorial we will expand on the last one we worked on which covered SQLite and using a database. Here we are going to fill out more details, including adding an android.app.Application object to create expensive objects and maintain state, adding a few more data operations, and putting said data operations onto a background Thread using AsyncTask (plus demonstrating saving instance state when the screen orientation is changed, and restoring same).

The complete application, which is intended to be very simple, will look like the screen shot below:

Because I often have to revisit this stuff myself, I thought I would write a quick reference tutorial on creating and using a database with an Android application. This isn't terribly well covered in the Android docs, and though many ContentProvider tutorials exist (such as the Unlocking Android code for chapter 5, and the NotePad tutorial included with the SDK), and these help a lot with general database concepts, they are really more complicated than what a basic application needs - a database to store and retrieve stuff.

I will walk through the code and tools for an oversimplified example here, with the ultimate goal of inserting and retrieving some data from an database in an Android app, and then examining the database using a shell and the sqlite3 command line tool. The entire code for this example is available here: http://totsp.com/svn/repo/AndroidExamples/trunk/.

NOTE This code was updated for part 2, and part 3 of this series, so it no longer exactly matches this example -- it's still a working sample app, it just now does a bit more than the original.

First, to get this rolling, we need to create an Android application that HAS a database. We could use any built in application that has a database just to explore it, such as com.android.alarmclock), but we are going to create one here for completeness. After it's setup, the interface for our application will look like the screen shot shown below:

A few months back our team at the office decided to buckle down and create an automated repeatable build for a new Eclipse RCP app we are working on - because it's the right thing to do. What follows is most of an article I wrote back then, and never got around to publishing here. This article isn't polished but if I don't hit submit right now, it will never see the light of day again - and I think it *might* help someone somewhere sometime even in less than perfect form, so here goes.

(I updated the CODE and README for this project today - 01.07.2009, haven't really written a proper article yet, but README is better, and tested setup on multiple platforms, win32 and lin32. Check out the screen shot, Windows! Trying to make it nice for the people, since a few of you asked, even as much as I loathe said OS ;).)

My life with PDE Build

Fortunately, Eclipse comes with a lot of support for automating builds in terms of the PDE (Plug-In Development Environment) project which includes an Ant based set of Eclipse Plug-In build tools. Even though Eclipse provides this, we normally use Maven for our builds, so we set out to find a way to use Maven to manage Eclipse PDE. Hence the saga began . . .

I answer questions on the Android developers mailing list (http://groups.google.com/group/android-developers) from time to time. Often when doing so I point people to the code examples at the Unlocking Android gCode site.

Just to repeat it, so that maybe more people will realize it's there, all the code for UAD is at the site: http://code.google.com/p/unlocking-android/.

You can browse it by chapter and go right to the examples. It was written for Android 1.1, but all the examples still run fine on 1.5 and 1.6 (I haven't tried them in 2.0 yet, but plan to).