views:

465

answers:

2

We're designing an Android app that has several activities which are working in a wizard like way - user should pass from the activity #1 to activity #5 to get to the final activity (#6).

Since we know an activity can be suddenly terminated by OS on low memory we used Application class as a static storage for keeping the data the user inputs on "wizard" activities and other data our app needs for the whole session.

Unfortunately we've discovered this approach fails - looks like the Application class instance is also can be killed by OS (this was specifically discovered on Android 1.6 versus 1.5). Are our expectations wrong on this approach (we think Application class instance always lives for the whole app session)?

So the question is - what is the best practices on Android to keep data between activities deathes/restarts for the whole application session?

A: 

Hi,
If the data that user inputs and you need to store is just a set of primitives, you could simply use SharedPreferences as persistent storage.
Regards!

Ramps
+4  A: 

We're designing an Android app that has several activities which are working in a wizard like way - user should pass from the activity #1 to activity #5 to get to the final activity (#6).

Are you sure you should be implementing them as separate activities? Why not a single activity, using ViewFlipper or something to move between the wizard states?

Are our expectations wrong on this approach (we think Application class instance always lives for the whole app session)?

The Application class instance does always live for the whole app session, AFAIK. Once all your activities are destroyed, though, the Application will be destroyed as well.

So the question is - what is the best practices on Android to keep data between activities deathes/restarts for the whole application session?

  1. Use a Service -- if this gets kicked out of RAM, just start over from scratch
  2. Use a database
  3. Use a file

Or, best: don't use multiple activities in this case. A wizard is a single logical thing; treat it as such and make it be a single activity. Persist your state via onSaveInstanceState(), and you're set.

CommonsWare
I really like this answer. It may be cleaner to implement this as one activity, however you do have to consider situations such the Back button which won't take you to the previous "screen" by default.Yes just assume your process (and therefore the framework objects within it such as Application) can be killed at any time. Using a Service may help, but that may just simply delay the inevitable.This FAQ may be useful:http://developer.android.com/guide/appendix/faq/framework.html#3
James

related questions