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.
Related
I want to save some small data structures (~1kB total), as well as the user's preferences, while my app is closed. The settings are modified only in my PreferenceActivity, but the data structures are modified in pretty much every activity. I've extended Application and made all the data structures and preferences static. I've then tried saving to SharedPreferences in my application class's onTerminate() and loading it again in onCreate(). However, onTerminate()'s documentation states that "It will never be called on a production Android device, where processes are removed by simply killing them".
Answers to this question suggest saving to SharedPreferences in the onStop() method of each activity modifying their data. Will this guarantee that the data is saved in all cases? Is there a way to avoid the waste of saving every time the user transitions between activities (or should I even care)?
I would honestly just save in the onPause() of each activity as is recommended by Android (i.e. when you write an email notice how the draft is saved when the app pauses, such as if the screen turns off). Unless you notice that it is causing lags/delays, it probably won't matter too much.
If you do notice lags with this "autosave" method, then you should probably have some sort of "Save" functionality implemented in each activity, which could, for example, entail using a ProgressDialog / AsyncTask combination.
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.
I want to save application state to be able to restore it after another launch. Is is it better to use method onSaveInstanceState and save it to Bundle or to use SharedPreferences?
Thanks
It depends on your intention. Using the onSaveInstanceState() is only a reasonable solution if you want to ensure saving the state during configurations changes and other restarting events. In case you aim for a true saving of the application's state beyond the lifecycle of the application, you should consider using either the SharedPreferences or maybe even employ a database.
I may not have the same development chops as some of the other posters here (I've been seriously developing apps since July 2012), but I've found a solution that integrates SharedPreferences as well as the onSaveInstanceState().
My App has a splash screen activity that reads values from SharedPreferences and assigns them to the appropriate variables. Additionally, each Activity I make has its own onSaveInstanceState() method, and I commit all of the data I need to save to SharedPreferences there, in each and every Activity. Since onSaveInstanceState() is run before an App or Activity closes normally, it should back up data values under all normal circumstances.
It may not be the most code-efficient solution, especially in larger Apps with many Activities, but as far as my tests go it protects your app from data loss 99% of the time.
If a more experienced developer would like to chime in and confirm or deny this, I'm sure it'll enrich the question and answer.
I am sure onSaveInstanceState() is the better option.
Here it is already given a better explanation: Saving Android Activity state using Save Instance State
I have a widget and I want to save its state when it's being clicked.
Currently I'm saving the state with SharedPreferences.
This works but it is relatively slow to commit updates to the preferences.
Are there any better solutions?
Thanks.
I have a widget and I want to save its state when it's being clicked.
If by "widget" you mean "widget", this makes no sense. At most, a widget should be communicating with its hosting activity. The activity can save its state at appropriate times using appropriate means.
If by "widget" you mean "app widget", this makes more sense.
Currently I'm saving the state with SharedPreferences.
This works but it is relatively slow to commit updates to the preferences.
Are there any better solutions?
All writes to flash are slow, by flash's nature. Where possible, committing SharedPreferences should be done in the background. On Android 2.3 and higher, you have a new apply() method that does that automatically.
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().