I know this topic has been discussed before on Stack Overflow. But there are still some things that are not clear when I read previous posts about it. So here they are:
I know that we use shared preference for small datasets and sqlite for large data manipulation, so if we just want to save a username and password should we use shared preferences?
Won't shared preferences be lost when user uninstalls the app? For example I download an app called abc and save my username and password. Then I uninstall this app from one phone and try to access it from other phone using the same username and password. Will this be saved using shared preferences or the data be lost?
What are the main reason we use one over the other beside large and small datasets?
You can think of the difference between shared preferences and an SQLite database in terms of data size but that isn't entirely accurate. A better way to think of it is in terms of the structure of the data you want to store.
Shared preferences can only store key-value pairings whilst an SQLite database is much more flexible. So shared preferences are particularly useful for storing user preferences, e.g. should the app display notifications etc. Whilst an SQLite database is useful for just about anything.
Both data sources are local but something you should be aware of is the ability to backup your application data to cloud storage that is linked to the user's Google account. This makes it much easier for your users to change devices and for their applications to easily transfer to the new device. For more info take a look here.
In the situation you described about you will lose the user name and password in both situations. The data is stored on the phone, when you uninstall the application, the data that some with it will also be lost. The user will have to re-enter this information.
You can save the user name and pass in either the shared Preferences or a DB, that is personal preference. Just make sure you lock either down, i.e. don't share the DB or Shared Preferences that you keep this information in.
As for the difference... shared Preferences should hold well... shared Preferences... here is an example:
If I create an option to change the background color, I will store all available options in a DB that can be loaded into a adapter view for the user to choose from. But I will store the color that they have selected in the Shared Preferences. This way when the application load I can get the Shared Preference value of the background color that should be used.
SharedPreferences is used for just that, storing user preferences shared application-wide. You can use it, for example, to store a user's username, or perhaps some options he or she has configured in your app in which you want to remember.
SQLite is a relational database. It's used to store your application's data, not preferences or configuration information.
Both are stored locally on the device.
1.SharedPreferences stores only Boolean, int, float, long, String five kinds of simple data types, such as can not be conditional query. So, whether SharedPreferences data storage operation is how simple it can only be a supplement of storage, but can not completely replace other data such as the SQLite database is stored.
2.SharedPreferences based on the XML file to store key-value key used to store configuration information(mainly user preference for your application).
3.Sharedprefrece just like cookies in web which store some basic information at client side.
both store their data locally, so uninstalling the app will delete both. other than that, SharedPreferences is easier to program, and you're right about the data amounts.
In general, shared preferences should be used if you want to allow your user to directly manipulate certain data fields. Shared preferences are basically user preferences; if you would like the user to reconfigure the app to behave in different ways, you should expose that functionality as a shared preference. On the other hand, the SQLite database should be used if you want to limit the visibility of the data to just the application, if you want a stronger guarantee that the data be persistent, and if you want the application to behave independently of what is stored in the database. Of course, you can use both in one application.
Shared preferences and the database are part of local data that the application stores. If you uninstall the application, both of the data stores will be removed.
Related
Suppose i made an app which uses shared preferences,
will the data stored with shared preferences be deleted when user clears app storage?
if yes then what is alternative to store/retrieve important data faster which will not get erased by user?
i tried firebase-database, but it is lagging the speed/performance i require.
will the data stored with shared preferences be deleted when user clears app storage?
Yes.
what is alternative to store/retrieve important data faster which will not get erased by user?
Store it on a server.
i tried firebase-database, but it is lagging the speed/performance i require.
Then store it on a faster server, I guess. Or, use a local file as a cache, with the server acting as a backup location, should you need to restore the data at a later point.
In the official site of Android, for getPreference() method, it is said that :
Retrieve a SharedPreferences object for accessing preferences that are
private to this activity.
And here(How do I get the SharedPreferences from a PreferenceActivity in Android?) it is said that :
These preferences can only be used within the particular activity and
can not be used by other components of the application.
However, in url http://skillgun.com/android/basics/interview-questions-and-answers/paper/25 5th question,
it is said that it is not guaranteed to be protected as it will be
stored with the name of Activity.
I am confused whether other components of an application(such as activity,service etc.) can access the shared preference created by getPreference() method. is a shared preference created by calling getPreference() method accessible only for an activity for all circumstances?
Basically if you use shared preferences you will be able to read and write the preference from any part of your app. But other apps will not be able to access this information.
The statement regarding not being protected refers to the fact that rooted users (and apps) can read this files from the phone internal storage. So avoid at any cost saving sensitive user information in Shared Preferences. Ex. Dont store userNames, Passwords, personal details, etc.
Use shared preferences for simple things you wish to store Ex. If developing a contacts app you can store whether the user likes to read his contacts firstName LastName or LastName FirstName.
This kind of data is very short and not compromising.
If you require to store sensitive information always encrypt the data first.
As you see on app like facebook, twitter, etc you have list of content in home page. if you close the app then open it again, you still have those content without load again from server.
currently i use this code to save all value in my app
SPref.setPref(getActivity(), Config.USER_ID, lb.userId);
SPref.setPref(getActivity(), Config.USER_NAME, lb.name);
SPref.setPref(getActivity(), Config.USER_EMAIL, lb.email);
its just save a string or a an int value not a list. i used saving data at local device with sqlite and a file for my other project. in this case in my new project, i want to make sure which way is better for saving list value.
by the way, i use SharedPreferences because someone told me its faster.
shared preference
is only to store KEY , VALUE pair, So you can store here small amount of data like username , some flags etc.
To store your normal contents like here you want to store list.
Use SQLite for this is the list will not frequently going to changed, or it will going to modify then use Cache.
Please follow this links for better understanding
https://developer.android.com/guide/topics/data/data-storage.html
https://developer.android.com/reference/android/util/LruCache.html
Shared Preferences certainly are very fast, but those aren't meant to be stored with a huge data set, As the name suggest those are meant to store the preference data of the app in a key value pair for example
setting the sound on/off
setting the logged in status
setting the day/night theme for the app.
In the above example whenever user changes a setting you can just store it in SP, and use it next time to make any decisions
For Larger data set, you have to use SQL lite
https://developer.android.com/training/basics/data-storage/databases.html
Or Realm DB(Third party library)
https://realm.io/
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'm creating an app that will need, at the most, probably 16 account's basic information. This includes several items per account such as name, password, and some basic settings. This information will be used periodically throughout the app to access information on the web, and display it to the user as needed. I will probably also be storing other information, per account, in a SQL file so it can be searched, categorized and displayed when requestedd.
I am going to use a Pref Fragment to add/edit each of these account's main information for simplicity (they are all identical in format, just different values) but as I started reading on the differences between shared preferences and SQL, there are alot of pros and cons for using each.
Where would the best place be to store this basic information?
Is this information, including passwords more secure in one vs the other from outside prying eyes?
Some people say that shared preferences can sometimes get corrupted... is that something I need to worry about?
I've never had problems with corrupted shared prefs. If you're only ever going to have around 16 account entries, I think shared prefs would be fine (and easier to implement than a Sqllite db). If you do use shared prefs, just make sure to hash or otherwise avoid saving passwords in plain text. Pref files, although normally restricted (if you specify MODE_PRIVATE) still can be accessed when a phone is rooted.