Should I use a singleton class or preferences to store the data that is shared in the program. For example, say the user can enable or disable location tracking. The state of tracking has to be stored and shared with the SERVICE that handles the location changes. In such case, should I use a singleton class or preferences to persist the choice for a background SERVICE ? Please also relevant supporting points to your choice.
The purpose of SharedPreference is exactly store preference settings and status values.
Singleton restricts the instantiation of a class to one object, that is a different matter.
If you want to avoid the lost of data when the application is closed, if you don't use Preferences you have to create manually a method to store and load your data on a file, so SharedPreference is the best choice, if you want to share an object only during the program execution you can use singleton to restrict its instantiation, however if the value to store is a String or a primitive using Preference also in this case has no side effects but is a bit dirty programming choice.
Singleton - Saves Data in variables and get deleted when Application is Destroyed.
Shared Prefs - Save Data outside of your Application so u can later use even application is destoryed.
SharedPreferences, Service, and Singletons are substantially different. None of them can be used INSTEAD of the other one. If at ANY situation you though you can use one instead of the other, you can be sure you did not understand their application very well.
As one example difference, SharePrefs are saved in the disc so they are persistent, while Singletons are not.
Related
I am building my first Android app. I need to add a specific set of headers to each web api call and want them to persist even when the app closes. I implemented them in shared preferences but now I need to drag around a context for every call, which seems like a bad way to do things. I would like to set the values on initialization of the app. Have them usable by the WebAPIHelper object without much trouble, and when the values change, save them. I am using Room so I could save them there.
Is it standard practice to use LiveData or extend the application object to have access to the values for use within an object such as my WebAPIHelper, or is there another, better way? Is it best to persist these values in a database or SharedPreferences?
UPDATE
I have seen some examples of extending the application object like here and here. I would want to get the values from sharedpreferences onCreate and save them to sharedpreferences by calling a setXXX, but I haven't gotten that to work.
Also I was concerned about this statement I found in an article:
"Storing data in the Application object is error-prone and can crash your app. Prefer storing your global data on disk if it is really needed later or explicitly pass to your activity in the intent’s extras."
The implication of this would mean that I would need to pass the header values to the WebAPIHelper object all the time. I am passing the context object everywhere now so I guess it's 6 of one vs 1/2 dozen of the other.
The other way to do this might be to extend the AndroidViewModel class in a BaseViewModel, add the properties there from SharedPreferences so they are available through all ViewModels in the app. Has anybody done it this way?
I need to pass an ArrayList across activities and make it persistent.
From a popular SO post i found the solution. But still I cannot understand why SharedPreference from API 11 takes a Set
SharedPredferences.getStringSet but not a so common ArrayList directly.
What are the logic reasons, ex. as to avoid duplicates using a Set for instance?
If you only need to persist simple flags and your application runs in a single process SharedPreferences is probably enough for you. It is a good default option.
There are two reasons why you might not want to use SharedPreferences:
Performance: Your data is complex or there is a lot of it
Multiple processes accessing the data: You have widgets or remote
services that run in their own processes and require synchronized
data
You should can use Bundle to share list to another activities. If it is a globally used stuff keep it in your Database(Sqlite)
With reference of this, Concept behind SharedPreference is build a user interface for your app settings. you can only add key-value type of data in shared preference.
In my Android application there are some Boolean variables which I want to access anywhere in the app, by declaring them as public static boolean I can access anywhere but when keeping my app long time in background or if the user clears the memory(by clean master app) then my static variables get reset and again if the user goes to the app from stack then there will be an issue since all my variables got reset to default values.
Instead I am planning to store those boolean vars to Sharedprefs, everytime when I want I will access them from sharedprefs. Everytime reading from sahredprefs is the best way or not?does it effect any performance if I had large number of booleans? Can anyone suggest me what would be the best way of handling this situation.
SharedPreferences is the way to go.
Variables saved to SharedPreferences are saved in an xml file. I never had problems in terms of performance when it comes to large set of preferences. I think you should be fine.
SharedPreferences are in fact an XML, they are fast for few values and you can load/save them on the OnPause/OnResume events on the Application class.
If you need to store large amount of data consider using JSON or even better an ORM like SugarORM (greenDAO is good too).
I am working with an android app and am looking for a way to establish some global preferences that will be later accessible to all all activities/classes in my app. This is similar to what i know some people end up using the AppDelegate in objective c programming. The answers i have seen on the net suggest that i either extend from Application or save the data to SharedPreferences. I would like to know if there is a way to combine the two approches so that in my app, i can keep calling properties of a Preferences object (such as Preferences.getName()) and also persist the data to SharedPreferences so that, in case Android decides to restart my application and i loose all the data in my Preferences object, i can still get it back from SharedPreferences and repopulate the Preferences object. Can anyone please let me know how this can be done and if it is viable?
See my answer at https://stackoverflow.com/a/13673178/338479
In short, I create a "singleton" class to hold my preferences, and the data persists as long as the application stays in memory. If the application is killed by the system, the singleton class silently reloads it later.
It's also possible to do this by extending Application class, but conventional wisdom holds that there's no real advantage to doing it this way.
Ddms tells that, when I recall my class called in the past, it performs an onCreate() instead of onResume() that I expected...
I noticed that values that I stored in variables of my class in this case are lost and are null.
I presume that Android decide to do so to free memory resources (isn't it?).
I know that I could use Sharedpreferences to store data in a persistent way and then retrieve... But this is a really dirty way, in my opinion.
So, my question: how to have variables' values preserved also after an onDestroy() (I think?) that Android decided automatically?
Android will terminate your process at any time when you have no visible activities. For example, the user might go into Settings and terminate your app.
Static data members (my interpretation of your "variables of my class" description) are only meant to be caches, at best. They are no substitute for a persistent data model, whether you use a database, an XML file, a JSON file, or whatever.
So, if you want "variables' values preserved", save them someplace persistent.
You might find this page on data storage helpful. If your data is primitive, SharedPreferences are the recommended route. (Why do you think they are dirty?) If you need to store an object, you can use internal storage, as documented on that page.
http://developer.android.com/reference/android/app/Activity.html#onSaveInstanceState(android.os.Bundle)
If you don't like SharedPreferences, then you might want to look into Content Providers Even though Content Providers share data across applications, they also provide functionality for you to store persistent data in SQLlite and files that are available only to your app. In this case data stored in this fashion will be available even after closing and restarting your app.
You can save dynamic state by passing name:value pairs or serializable objects using the Android Architecture and the methods onSaveInstanceState and onRetainNonConfigurationState. You can persist state as explained in the other answers by writing to prefs and doing database writes.
I've been using custom Application class to store data over application life line.
How to declare global variables in Android?