This summer I added some features to Nurse AMIE, an Android app proposed, developed, and tested by Dr. Kathryn Schmitz at the Penn State Cancer Institute.
In the last post about this app, I talked to you about the technical execution of the form. We discussed the user interface design decisions that went into the weekly survey form, and why they mattered. In this post, I’ll talk about persisting the weekly survey information to the local database on the device.
When we submit the weekly survey responses for each patient, we need to save those results somewhere. We do this in two ways:
- We upload the responses to a server with a custom API post request.
- We save the responses to a local database on the device.
Databases on Android
Android apps allow us to store information in a sqlite database inside the app’s sandbox. We can integrate with this database from scratch, but in order to do so, we need to:
- Maintain a single instance of a SQLiteDBOpenHelper
- Write a lot of our own SQL commands
- Ensure that we’re opening and closing access to the database properly
- Update our schema version and manually manage what happens upon upgrading the database
Even if we get it all right, we still run into snafus. Experimenting with our schema means either constantly incrementing the schema version or constantly un-installing and re-installing the app on an emulator. And even if we wanted to separate the logic for different tables into different classes, we’re tethered to the need to keep a single SQLiteDBOpenHelper as our database access point.
So implementing from scratch is doable but, at times, frustrating. Luckily, there are libraries to make that process a little easier. On Nurse AMIE, we use a library called GreenDAO. The “DAO” in this case stands for “data access object.”
How we use GreenDAO
We start with a class to represent our WeeklySurvey and we give it the @Entity annotation:
GreenDAO is a third-party dependency, so it doesn’t have any special access in the Android framework to avoid the rigamarole we’d go through to manage a database manually. So it operates by generating all that code for us. Each time we build or make the project, GreenDAO checks for new entities. It then generates a bunch of code: constructors for the entities, data access objects for the entities, et cetera. We don’t commit those to version control.
Next, we instantiate a session at the application level to access our database. We set up an attribute for it here:
and instantiate it in the onCreate() method of the same class:
We can access this session from anywhere in the app. For the weekly survey in particular, we do that in the WeeklySurveyFragment:
When the patient taps the “submit” button on their weekly survey, we:
- Get ahold of the WeeklySurvey data access object from the application’s DAO session
- Instantiate a WeeklySurvey (the @Entity class we created above)
- Set its attribute for the current date.
Then we:
- Set all the other attributes—that is, the survey responses (I have a hashmap to keep track of these)
- Check that all the attributes are there (isFormValid)
- Send the survey results to the API, and finally
- Insert the new WeeklySurvey record into the database!
We don’t happen to read these results from the database anywhere in the app, but if we wanted to, greenDAO enables us to do such a thing with a queryBuilder like so”
I didn’t happen to choose GreenDAO for this project—several other pieces of data throughout the app were persisted to a local database with it when I rolled on—but it felt refreshing to not have to deal with the peculiarities of the manual approach, and the code generation that runs automatically with each build makes this relatively low-hassle.
If you liked this piece, you might also like:
The first post on the Nurse AMIE Android app about the role of empathy in mobile apps for care management
The second post on the Nurse AMIE Android app about implementing the survey view itself
Maybe you’d like to watch some live coding? I do a fair amount of mobile development live 🙂