Activity lifecycle, saving to a database, and remembering row IDs

by Jesse McGrew » Thu, 05 Mar 2009 01:32:44 GMT

Sponsored Links
 I'm writing a simple app based on on the NotePad V3 example. In my
activity to edit a record, I have these methods:

    protected void onSaveInstanceState(Bundle outState) {
        if (mRowId != null)
                outState.putLong(MyDbAdapter.KEY_ROWID, mRowId);

    protected void onPause() {

saveState() is defined pretty much as it is in the example: if mRowId
is set, it updates the existing database row, otherwise it creates a
new row and sets mRowId to point to it.

The problem I'm having is that when I change the screen orientation
during this activity, I get duplicate rows. A row is inserted when I
flip the screen, then another row is inserted when I leave the

Presumably, onSaveInstanceState() is being called first when the
activity is destroyed for the configuration change. Since there's no
row ID yet, it doesn't store a row ID in the bundle. Then onPause() is
called, which creates a new row, but it's too late to save the row ID
for next time. When the activity is recreated in the new orientation,
the bundle has no row ID, so the activity thinks it's creating a new
record instead of editing the one it just saved.

What's the recommended fix here? Should I persist to the database in
onSaveInstanceState() as well as onPause()? Or is there some way for
onPause() to store the row ID where the activity can find it later
after being recreated?



Activity lifecycle, saving to a database, and remembering row IDs

by Jesse McGrew » Thu, 05 Mar 2009 13:05:56 GMT


FWIW, I ended up making it save the row in either onSaveInstanceState
() or onPause(), whichever one runs first.

I also looked at the notepad app in the SDK samples, which uses a
content provider. The way that one works is it creates the row as soon
as you start editing a note, and then deletes the row if you leave
without entering anything. I decided not to use that approach - I only
want valid rows in the database.


Sponsored Links

Other Threads

1. further doubt in layout and activity

Again I am confused a little. If I can show a different layout calling
setContentLayout, please anybody can give me an example of a
compelling situation where my app would need more than one activity ?



2. Droid or android 2.0 performance issues?

I had been waiting to make the switch from the iphone to android until
both some nice hardware was released and it had been out for a while
for the initial usability issues to be resolved. The Droid is what
made me take the plunge but I am *constantly* frustrated by what seems
to be surprisingly sub-par performance for the most basic UI

I started looking into the SDK and worked on a few apps in order to
resolve some issues i was having, but even the most basic example apps
in the sdk aren't nearly as fast as I would expect them to be on a
new, relatively high-end device.

For example, something as simple as the sample 'home' app that comes
with the sdk can't even open the 'all programs' list smoothly. This
may seem trivial, but it is very telling if a basic application
written by programmers experienced in the SDK performs poorly on a
{*filter*} device.

There are a slew of problems that bother me and i am reaching out for
any expert insight as to whether or not they are Droid specific, or
general to android 2.0 that may be addressed with future updates. My
primary frustrations:

Delay between swiping gestures/clicks and visual response.
Scrolling is choppy in almost all cases, from lists, to home, to browser pages.
Scrolls are frequently registered as clicks.
Occasionally clicks register as powerful downward scrolls, so a click
on a large list will throw me near the bottom of the list as if the
Droid is consciously mocking me.

I could go on for pages, but as I write them all down I think the bulk
of my issues stem from the general feeling of sluggishness on the
Droid. Usability can be enhanced by other applications and by
workarounds, but poor performance at an OS or device level doesn't
seem easily fixable.

I can't imagine it is inherent to the Droid because the specs seem
perfectly decent for a hand held device. Could it be the screen
resolution be requiring more processing power than the Droid can
provide? Does the road forward look promising?

"Works fine for me" is not a useful response, so please use restraint
when hovering over the 'Send' button. This is not device-specific, the
same problems occur on the 5 other droids i've compared against in my
company. Some people are OK with it, which is fine by me, but arguing
that opinion is not helpful.



3. deleting then recreating a MapView in the same MapActivity fails

4. Widget multiple sizes

5. R wont generate

6. Upgrade problems with HTC hero type phones

7. Publish IBinder interface of native service with system manager