SharedPreferences reads old values

I use SharedPreferences to write and then read values ​​in different actions in my application. It used to work fine, but lately it seems like if it wasn’t destroyed. I mean, I am writing a value, but then another action is still reading the old value. Sometimes this works correctly. Any idea?

EDIT: This is a sample code:

First from the stream:

SharedPreferences prefs = getSharedPreferences("MyPrefs", Context.MODE_PRIVATE); SharedPreferences.Editor editor = prefs.edit(); editor.putInt("ComandToDo", value); editor.commit(); ... some code later: alarmmanager.set(AlarmManager.RTC_WAKEUP, Miliseconds, sender); 

In the alarm receiver:

 SharedPreferences prefs = contexto.getSharedPreferences("MyPrefs", Context.MODE_PRIVATE); int value = prefs.getInt("ComandToDo", -1); 

And here the problem arises because the β€œvalue” is not the value recorded in the stream.

+7
source share
4 answers
  • General information about SharedPreferences files is documented so that it doesn’t work through processes, http://developer.android.com/reference/android/content/SharedPreferences.html , "Note: this class does not currently support using multiple processes. It will added later. "

  • This answer recommends encapsulating the data in the content provider, and the discussion also discusses some other parameters, including general SQLite: https://stackoverflow.com/a/216722/ ...

  • You also have plain old files in the file system. We used them in several projects with blocking without any problems. Maybe for you.

+2
source

Here is what I met and what I did to fix it.

I triggered an alarm from Activity and Broadcast-Receiver from this alarm. I updated the Shared-Preferences that were read every time the application was launched.

After the alarm was started, whenever the application started, it received old values ​​that were set only from this activity. There were no changes from the broadcast receiver.

The trick here is to set general preferences as MODE_MULTI_PROCESS

Usually we use MODE_PRIVATE, but do the following:

 SharedPreferences prefs = this.getSharedPreferences("Preferences", MODE_MULTI_PROCESS); 

Note. After changing the mode in the code, it is recommended to clear the application data in order to avoid debugging problems.

EDIT: MODE_MULTI_PROCESS needs at least API 11

Before API 11, a workaround I can come up with is to create a database with 2 columns KEY and VALUE. Access to it is possible from other modules.

+4
source

You write the settings file "MyPrefs" and then try to read the file "PerfilDeSonidoPreferencias". Please read / write from the same settings file.

0
source

Just use IntentService instead of BroadcastReceiver. This works for me.

ServiceClass:

 public class ServiceClass extends IntentService { public NotificationPopupService(String name) { super(name); } public NotificationPopupService(){ super("YOU_DEFAULT_NAME"); } @Override protected void onHandleIntent(Intent intent) { SharedPreferences sp = PreferenceManager.getDefaultSharedPreferences(getApplicationContext()); do magic... } } 

In the AndroidManifest.xml file in the application tag:

 <service android:name="ServiceClass"/> 

Create an alarm:

 intent = new Intent(context, ServiceClass.class); pendingIntent = PendingIntent.getService(context, 0, intent, PendingIntent.FLAG_UPDATE_CURRENT); // magic after 2 seconds after the creation of alarm alarmManager.set(AlarmManager.RTC_WAKEUP, System.currentTimeMillis() + 2000, pendingIntent); 
0
source

All Articles