Should I save my objects as parcels or store their variables individually?

Question

I wish to store several instances of a simple class as part of saving my apps state when the activity is not in focus.

public class Player
{
   int score1;
   int score2;
   int total;
}

I've been told parceling is the way to go. What advantages does this hold over saving the variables individually using the method below?

savedInstanceState.putInt(player.getScore1);

Edit: I will likely store up to 50 instances of each of these classes and eventually increase the number of variables in them to 12.

Serialization springs to mind but everywhere I turn I'm told it is a slow inefficient method of storage and even that the android documentation advises to avoid it.

score 0 · Answer 1 · answered Feb 25 '12 at 16:34

0

My first advice will be using SharedPreference instead of savedInstanceState. savedInstanceState Has its own pro's and con's. If app is closed by user interaction like Back or home button then savedInstanceState will not be called.It is called only when app is disturbed by android o.s. itself like you are using app and call occured and app goes in background. In sharedpreference u will have control in you hand writing your own logic the way you want.

answered Feb 25 '12 at 16:34

Pankaj

1,242
1
9
21

I thought when back or home are pressed the app remains open up until the OS opts to close it due to memory constraints at which point savedInstanceState is called? I thought savedInstanceState was used to save the instance state. It's a bit useless if it isn't called if we press back :s – Declan McKenna Feb 25 '12 at 16:53
It's the instance state of your app, not your activities. You save the state of your activities *inside* your activities. When your *app* is about to get killed off the callback happens to save stuff in a bundle. – Kristopher Micinski Feb 28 '12 at 15:57

score 0 · Answer 2 · answered Feb 25 '12 at 17:19

Whenever a activity is killed, either by system or use, onPause() method is always called. You can use SharedPreferences to store your values and, thus, can retrieve it when activity is again created.

According to your code, you can make changes like this:

public class Player extends Activity {

  private SharedPreferences mPrefs;
  int score1;
  int score2;
  int total;
  protected void onCreate(Bundle savedInstanceState) {
     super.onCreate(savedInstanceState);

     SharedPreferences mPrefs = getSharedPreferences();
     score1 = mPrefs.getInt(String key1, int defaultValue);
     score2 = mPrefs.getInt(String key2, int defaultValue);
     total = mPrefs.getInt(String key3, int defaultValue);
 }

  protected void onPause() {
     super.onPause();

     SharedPreferences.Editor ed = mPrefs.edit();
     ed.putInt(key1, score1);
     ed.putInt(key2, score2);
     ed.putInt(key3, total);
     ed.commit();
 }
}

String key is the name of the preference.

int defaultValue is the default value returned when nothing is stored. It is generally returned when the activity is first created

I will be creating several instances of this class. using key1/key2/key3 as names won't work will it? I will likely store up to 50 instances of each of these classes and eventually increase the number of variables in them to 12. Is using shared preferences and variables such as key599 ideal? Serialization springs to mind but everywhere I turn I'm told it is a slow inefficient method of storage and even that the android documentation advises to avoid it. — Declan McKenna, Feb 28 '12 at 15:43

score 0 · Accepted Answer · answered Mar 19 '12 at 21:09

I used the following method to store my players instances.

public Object onRetainNonConfigurationInstance() 
{
  if (table != null) // Check that the object exists
      return(table);
  return super.onRetainNonConfigurationInstance();
}

The table instance stored contains an array holding all my player instances. When reloading my app the table object was loaded within the onCreate method using this code:

if (getLastNonConfigurationInstance() != null)
    {
      table = (Table)getLastNonConfigurationInstance();
    }

*This method is depreciated yet none of my beta testers phones have had any issues with it.

*This only works when your app has been shutdown by your phones OS and not when closed manually. Many users will press the back button not knowing it closes the app whilst home minimizes. The article below has many good approaches for ways to circumvent this.

http://www.androiduipatterns.com/2011/03/back-button-behavior.html

Should I save my objects as parcels or store their variables individually?

3 Answers3