0

In my application, when the phone is held in portrait mode the filename can be retrieved.

When I rotate the phone, the same file is being used to get the preferences, but this particular preference comes back blank.

I checked the one function where I write to this preference but it isn't called when the phone is rotated.

So, what could be the cause of a change in the sharedpreferences by rotating the phone?

Here is the code that I use:

static String retrieveStoredFilename(Context context) {
    SharedPreferences myPrefs = context.getSharedPreferences(PREF_NAME,
            Context.MODE_PRIVATE);
    String s = myPrefs.getString(FILENAME, "");

    return TextUtils.isEmpty(s) ? (String) null : s;
}

Here is some more code in case it helps. This is from the fragment that is actually messed up by the rotation. In onResume filename is set to null after rotating, but from then on it is null, even when I rotate back.

@Override
public void onPause() {
    super.onPause();
    mIV.getBitmap().recycle();
    mIV.setImageResource(R.drawable.ic_action_search);
    if (myBitMap != null)
        myBitMap.recycle();
}

@Override
public void onResume() {
    super.onResume();
    filename = ControllerFragment.retrieveStoredFilename(getActivity());
    getBitmap(filename);
    mIV.invalidate();
    }

And the two constants are:

public static String FILENAME = "filename";
public static String PREF_NAME = "photobrowser";
James Black
  • 41,583
  • 10
  • 86
  • 166
  • Weird, that doesn't make sense. `SharedPreferences` basically saves / retrieves data to / from an XML file with whatever the preferences name is. Example if your `PREF_NAME` is `prefs` then it creates a file called `prefs.xml` the first time you use it and then looks for that same file with each subsequent use. Changing orientation obviously shouldn't have any effect on that unless it's done before changes have been committed by the `SharedPreferences.Editor`. – Squonk Nov 07 '12 at 03:10
  • I'm not clear on the issue. The method isn't called when you rotate or it is called but returns null for that key? – LuxuryMode Nov 07 '12 at 03:11
  • Is it possible that the value of FILENAME is getting lost? I'm sure that's not the case as it appears to be a constant. – Jason Hessley Nov 07 '12 at 03:18

2 Answers2

1

The only possibility that I see is that the value of FILENAME is not being persisted. It may be worth looking into the lifecycle of an Activity and Saving Activity state on Android.

Here is an exert from the android documentation about Configuration Changes.

Unless you specify otherwise, a configuration change (such as a change in screen orientation, language, input devices, etc) will cause your current activity to be destroyed, going through the normal activity lifecycle process of onPause(), onStop(), and onDestroy() as appropriate. If the activity had been in the foreground or visible to the user, once onDestroy() is called in that instance then a new instance of the activity will be created, with whatever savedInstanceState the previous instance had generated from onSaveInstanceState(Bundle).

Because of this your onResume() is never called after an orientation change. The activity goes through the entire lifecycle to onDestroy(). After the orientation change onCreate() is called as it is a new instance of your activity.

Community
  • 1
  • 1
Jason Hessley
  • 1,608
  • 10
  • 8
  • I'm not sure about this. Bearing in mind an `Activity` is destroyed and re-created as a result of configuration change (such as change of orientation), if `FILENAME` is valid for portrait then it should be valid for landscape. Your reasoning is possibly valid but I think the OP needs to post more code. – Squonk Nov 07 '12 at 03:44
  • @squonk I agree. But who am I to protest the question asking skills of a user with 22.1k RP. FILENAME in all caps makes me think its a constant. However if it is declared/assigned during execution then its value could be lost. We can't know without seeing more code. I admit I would have asked more questions and been more specific with a less qualified user. – Jason Hessley Nov 07 '12 at 03:53
  • FILENAME is a static attribute, which is why it is in all caps. If there are more questions, please ask, as this makes no sense to me. – James Black Nov 07 '12 at 11:14
  • Oh, I may end up using onSavedInstanceState, but that is a last resort, as I fear that there may be something going on that is wrong, and I may be hiding it by using it. – James Black Nov 07 '12 at 11:16
  • This is the exact situation that onSavedInstanceState is there for. I edited my answer with more specifics about why this is happening. It's not the sharedprefs that are not persisting it is your local variable filename. – Jason Hessley Nov 07 '12 at 14:31
  • @JasonHessley - I looked at the SharedPreferences hashmap and the filename preference is not there, instead of three preferences when it was in portrait mode, I see two in landscape. – James Black Nov 08 '12 at 02:10
  • After onCreate, onResume is called. I can see in the debugger that it gets called, but I will be going with using onSavedInstanceState. – James Black Nov 08 '12 at 02:11
1

Check the lifecycle of your application. What do yo do on onCreate(), onPause(), etc.? Maybe you are clearing that preference entry. As this says:

Unless you specify otherwise, a configuration change (such as a change in screen orientation, language, input devices, etc) will cause your current activity to be destroyed, going through the normal activity lifecycle process of onPause(), onStop(), and onDestroy() as appropriate. If the activity had been in the foreground or visible to the user, once onDestroy() is called in that instance then a new instance of the activity will be created, with whatever savedInstanceState the previous instance had generated from onSaveInstanceState(Bundle).

MigDus
  • 767
  • 5
  • 17
  • I have one function that writes to this preference and it doesn't get called. In my onPause I was writing the value at one point, but that didn't fix it, so I removed that. – James Black Nov 07 '12 at 11:13