I am searching for the maximum Android SharedPreferences key, value pairs but cannot find any good answer. Secondly, I want to ask that if I have a key what is its String value limit. How many character can put into it. If I need a choice for a value change frequently, should I use SQLite or SharedPreferences.
Please refer me some good resources.
Yours,
All shared prefs are stored in /data/data/[package name]/shared_prefs/[app name].xml, so i think there's no limit based on aechitecture.
I don't know practical limit but i think it's enough for you..
Check Shared Preference for your reference.
should I use SQLite or SharedPreferences.
It is far better to use SQLite if you need to store values that will changes periodically.
Also you can store more amount of data..
Following Android Developer reference it seems like key, value and node name have each a max value defined.
If you have to change many related key pairs, I'd recommend creating a simple SQLite database, but if you are using only a few pairs maybe SharedPreferences is not a bad and quick solution.
SharedPreferences are for quickly storing values like single strings, settings, flags, etc. The SQLite Database can do the same but is a little more heavy duty, think storing tables of information like customer data with multiple properties and being able to search (the Query in SQL).
So the answer is, "it depends" on what that "something" is you want to store? If it's a user setting then the SharedPreferences is quick and easy. If it's a set of records then the SQLite Database may make more sense.
As for the key size limit: I believe it is just the max size of a String. Also it is answered here: Shared Preferences - max length of a single value
The max key/value pairs limit: usingShared preferences these values are stored in .xml files as stated in the answer above, and you can have multiple .xml sharePreference files. The size limit I suppose is limited by the size of your app or the storage space available on the device using your app.
If your preference values change frequently, I would consider using local variables to keep track of current preference set, maybe a global singleton class. And save changes to disk before app is destroyed/closed. If you don't like this idea then try using SharedPreferences, but be sure to use the SharedPreferences.Editor.apply() instead of SharedPreferences.Editor.commit() to save preferences (apply saves to disk asynchronously, commit saves synchronously).
Related
In my android app I have about 100 places (maximum will be 200). I want to allow the user to mark each place as visited and store this selection.
So the user can mark/unmark that he already visited some places/cities.
Is it a good idea if I store the values as SharedPreference?
My code:
SharedPreferences sharedPref = getActivity().getPreferences(Context.MODE_PRIVATE);
SharedPreferences.Editor editor = sharedPref.edit();
editor.putString("London", "1");
editor.commit();
and next time when user marks another place then:
editor.putString("Paris", "1");
I am asking due to amount of possible places to be stored there, which will be maximum 200 in my case. I am usually using this kind of storage just to store some settings or so, but I think this is an easy way to store the values in my case too, I don't want to use database or anything similar for storage.
Whether this is a good idea or not depends on your requirements and expectations. If you store the data like this, it will work for sure, but, there will be some limitations:
It might be complicated to show a list of places to the user. If you store some other data to shared preferences you will need a way to distinguish places from other data. In this case you'll probably need to add a prefix to all your keys, such as "place_London", "place_Paris", etc.
You are relying on English key names so you might have issues with localization if you support other languages
It will be much harder to support versioning and scalability. E.g. if later you have an entity called "Place" and it has more information than just a name with a flag, then it will be much harder to keep it in shared preferences. E.g. if at some point you want to add a corresponding country name to all places, what do you do?
I think in this scenario you actually DO want to use database. It will pay off.
SharedPreferences is a key/value way to save data. I think it is not appropriate to save large amount of structured data as you have to define a key for each value you have.
Using SQLite might be a better option for your case.
You should switch to a more reliable way of storing data in storage instead of using SharedPreferences.
Sqlite is good option but if you don't like to write SQL Queries and want a solution where you want to store data in your storage, Realm is an amazing alternative.
Although before implementing please read more on the pros and cons of using realm. You can read more about Realm here :-
realm.io
Realm vs Room vs ObjectBox
I am new to Android. I am building a test application where I need to store a variable's value say, strength of the user. I want to increase or decrease this strength's value whenever user uses the app. And after user closes the app and reopens it on next day, he should find the same value of strength.
One way I can think of is to store a local db in phone and read/write each time into that, since there are hardly 3 to 4 such variables. So db is not a good option I guess.
Other one I thought was to use android.app.Application class but I am not able to get what I want from that. Can we actually do it using android.app.Application? Or then any other method for 3 to 4 variables.
You can use SharedPreferences to store your variable inside shared preferences. For example, set it like:
SharedPreferences sharedPreferences = context.getSharedPreferences("DATA",Context.MODE_PRIVATE);
sharedPreferences.edit().putString("STRENGTH",yourVar).apply();
Then get it out using:
SharedPreferences sharedPreferences = context.getSharedPreferences("DATA",Context.MODE_PRIVATE);
strength = sharedPreferences.getString("STRENGTH",null);
Use SharedPreferences. SharedPreference provides an easy mechanism to persist a value across the life of an app.
Write an XML file in the application directory that the application can read on startup.
Use application class when our app is open read last state and store your data in shared preference, and you are right db is not good choice.
Like you suggested, you can use an SQLite database to store a table regarding the users. Although, you might only have one variable, strength, associated with each user now but if there's potential for more associated values that you want to store regarding the user, I'll recommend using an SQLite database.
Another option you can use is SharedPreferences, it allows you to store key value pairs. So in your case, each strength value can correspond to a username.
If you haven't learned the different storage options for Android, I'll recommend you taking a look at this.
Hope this helps!
Can I use a column in table to check if user has logged in.
When user logs in I set value to 1. When he logs out I set to 0.I dont want to use SharedPreferences. Is using it like this inefficient.
I used sharedpreferences first. I set username in the sharedpreference along with other preferences and display username in the nav drawer. When I install the app in another device, I think even the sharedpreference file will be installed and I saw that in the new device the username is displayed in the from the sharedpreference file though that user doesn't exist in the table in that device's database
When user logs in I set value to 1. When he logs out I set to 0
Here, what will happen is when you set values to 0 or 1 you have to open and close database everytime and will be a hastle to maintain. you have to check it each time what flag is. while in SharedPreferences it will be globally accesible and easy to set flag.
I would suggest you to use SharedPreferences because
SharedPreferences is a key/value store where you can save a data under certain key. To read the data from the store you have to know the key of the data. This makes reading the data very easy. But as easy as it is to store a small amount of data as difficult it is to store and read large structured data as you need to define key for every single data, furthermore you cannot really search within the data except you have a certain concept for naming the keys.
To give an example, SharedPreferences are useful for storing user preferences, where there are just a handful of variables that need storing. SQLite on the other hand would be better for storing data where there is a large set of items, such as song titles in a music library which need to be searched through
Check SharedPreferences and SQLite.
Better to use Shared Preferences instead of using Database for such a small thing.
Refer this : http://www.androidhive.info/2012/08/android-session-management-using-shared-preferences/
I need to store some config predefined information in my Android app such as the list of the servers, logins and passwords. This information should be stored permanently and be editable. For some reason, I think SharedPreferences isn't what I'm looking for. Maybe using internal Android SQLite db would be better?
What do you think?
You can store predefined data in a .db file under R.raw and copy it to your app's working directory then use it with SQLite.
You can specify these setting values in program as variables and insert in sqlite on first launch of application, By this way you can edit these values later in sqlite, I hope this can help you.
I have generally found SharedPreferences to be more easier to implement (also demands less resources than any kind of database). In your case, in my opinion, you should go for SharedPrefences, by loading your required information on first launch through some predefined keys, example, URL + i, where i can be run from zero to the number of URLs. This can be then later retrieved and edited. You can save the initial values in arrays as suggested by others above.
I have to store some data (string) in my Android app and I'm a dilemma. What is better solution ? Use Set Collection and keep it at SharedPreferences or I should save data to File and when I need it I have to read data from file and put it for example on ArrayList.
Depends on the quantity & complexity of the data. There is no straight answer to your question.
General approach: If the data are not too sensitive, small in quantity and more frequently used then you should go with SharedPreferences.
If your data is quite large lets say few hundred KBs of String then you should go with File.
SharedPreferences ultimately stores data into a file. The advantage of using SharedPreferences is that, the data is stored as a key value pair and can be retrieved easily using a key.
It depends on what you want to store.
Use SharedPreferences when you want store simple, prmitive data. Keep in mind that SharedPreferences will be available only for your app, so anothers apps cannot get data from it.
Use File when you have more complex data. You have to take care about how file is available to others. If you put it in sdcard root directory for example it will be available for everyone. If you put it in app package it will behave like SharedPreferences.