I tried to find an explanation about this issue but I couldn't find anything.
I have a remote service that is working in the background. This service reads some preferences from a SharedPreference.
The problem I have happens when I change a preference from a PreferenceActivity (the activity and the service belong to the same application and the same package). I change the preference and it is saved correctly, but as soon as the service reads that preference (the service never modifies the preferences, it only modifies some internal preferences that cannot be modified from the PreferenceActivity) the preference is 'resetted' and the service gets the resetted value.
This is happening with CheckBoxPreference. I don't know if this would happen with other kind of preferences as I don't have any of them.
After I change the preference I should restart the service? Or I need to 'refresh' the preferences in the service? Maybe this is a problem related with using HoloEverywhere?
To get the SharedPreference object I use the following code:
PreferenceManager.wrap(context, getSharedPreferencesName(context), Context.MODE_MULTI_PROCESS);
This code is specific for HoloEverywhere and it equals this:
context.getSharedPreferences(getSharedPreferencesName(context), Context.MODE_MULTI_PROCESS);
'getSharedPreferencesName()' just returns a string composed by "package.name_preferences".
Thank you.
I have a remote service that is working in the background.
Why did you make your service be remote?
I change the preference and it is saved correctly, but as soon as the service reads that preference (the service never modifies the preferences, it only modifies some internal preferences that cannot be modified from the PreferenceActivity) the preference is 'resetted' and the service gets the resetted value.
That's because you made your service remote. Simply remove the android:process attribute from your manifest, to have all your components run in the same process, and this problem will go away. Along the way, you will make the user happier, because you won't be consuming as much RAM and battery.
After I change the preference I should restart the service? Or I need to 'refresh' the preferences in the service?
If you truly have a legitimate reason for having a remote service -- and IMHO there's a greater chance that I will spontaneously regrow my hair -- you will need to restart the service's process, AFAIK. SharedPreferences are cached per process, and I don't know of a way to force Android to reload SharedPreferences from disk except by restarting the process.
Or, you could not have a remote service. The choice is yours.
Related
I know this issue has been discussed already (here for example), but It's still unclear to me whether it is, or not, safe to have a Preference activity that updates the SharedPreferences and background threads that read from it simultaneously ?
In my specific example, I have a PreferenceActivity and PreferenceFragments that the user interacts with to change the preferences, and a background Service that read and acts upon those prefs.
I don't want to leave it to luck, just want to make sure if I should be locking the SharedPreference object each time I read from it (because writing to it is done automatically through the PreferencesActivity).
Thanks!
As discussed in the post you linked. Unless you specifically tells Android in you manifest to run your service in another process it should be safe to write and read at the same time.
So it would probably be fine your case.
I would like to know does Android caches an application preference?
I have an activity running.
And then I go to Setting->Manage Application->find my application-> clear data.
But from my activity, the value of a preference in my application stays the same, despite I clear it thru the above step.
But then when I power off and then power on the phone, that seems to clear it.
My question is does android some how cache an application preference?
Thank you.
I presume you mean SharedPreferences by telling Application Preference..
Android clears the preference files when you do clear data..
The application data(the values read from the preference files before it was cleared) stays in the memory until the app is killed by the system, that might be the reason why you are seeing that the value of preference stays same..
Try Clear Data and Force Close.. That should give you what you are expecting..
I'd like to make my IntentService remember when it was called last time and how many times it was called so far. It doesn't matter if these values are reset when the phone is rebooted, but they must not be reset when the application process is killed.
Should I store these state variables in a SharedPreferences, or is there is a better and/or more lightweight way? I tried intent.getExtras(), but it seems that the values I put there are not remembered between calls.
For persistent storage like this, SharedPreferences is usually the way to go. And don't forget to do commit() after editing the preference.
My app uses SharedPreferences (with the help of a PreferenceActivity) to store all settings. But sometimes all settings are deleted and all values are set back to default. Mostly on Android 3.x tabs.
On normal smartphones there are no problems.
I have observed that all settings are deleted when the application process is killed by Android.
I noticed this because the notification icon is no longer displayed.
I also wonder why the process is killed on tablets and not on smartphones. On my smartphone the notification icon never disappears.
My app also has a service, the main process and the service both read and write settings to the SharedPreferences.
I've sometimes noticed that all settings are cleared once the service writes to the SharedPreferences. But it does not happen every time.
Any ideas?
I realize that the SharedPreferences should not be used by different processes, but it works on all smartphones without problems!
I found out the reason why the settings disappear:
If two processes write data to SharedPreferences, it can happen that all SharedPreferences are reset to default values.
In my case all settings are cleared when the service write the first data to SharedPreferences.
Now, the service provides only read access to the SharedPreferences. The settings that are accessed by both processes writing are stored in a database.
SharedPreferences usually work great and as you mentioned without any problem on smartphones. It should also work on tablets. However it would be best to use sqlite or backing your shared prefs on a server for each users id data loss is a problem.
I have had the same issue.
All values from shared preferences become default if one value occasionally written with key = null. This is possible when you creating new constants using Eclipse, which inits them with null by default, and then you forgot to go to the beginning of the class and change constant to some meaningful value.
If you continue using the app, read operation of shared preferences will return valid values.
But when context is changed(for example, when activity killed by android and recreated) all values from shared preferences will return default values(zeroes).
So check your shared preferences's keys!
I hope this answer will help someone.
I would like to know if it is possible to for some application other my own to change a preference value of my application. Also are the preferences been kept by android when the phone is turned off?
Is it safe to store some data(flags) on sharedpreferences in order to notify an activity for something?
When user clears the application data what exactly is erased, shared preferences data?
Is it preferred to use an internal private file to store secure data? Such as passwords?
Also I would like to be able to show a dialog when I detect a certain behavior, for this I have a monitoring service that has to notify the main activity about that. currently this is done through a callback method but I would like to maintain that state even if the application is killed or the phone reboots.
So I thought of setting a sharedpreference value (flag) and then on the oncreate method check if that flag exists. Also should I also check on the resume method?
Preferences (including SharedPreferences) are stored in files under your application's private data directory. No other application can read or write there, unless the phone has been rooted. This internal storage is flash-based and survives the phone being turned off... not much would work if it didn't. :)
As a general security principle you should never store a password. Secure systems store and compare password hashes, not the passwords themselves.
It's fine to store application state in preference data... personally I'd read it in onCreate() and thereafter write the value back to preferences either at the point it changes or in onPause().