I have a question. In my project I have some user preferences which are stored in the SQL database. There are about 200 records and the table has 3 columns. This records do not change, only if the user is changed and the data is downloaded again. I want to put them in SharedPreferences because it would be easier to manipulate the code. The way it is now, it's a bit difficult as I make the queries asynchronous. Now, my question is: Is the number of records to large for SharedPrefrences? Or it should be no problem to store them there?
Asked
Active
Viewed 4,471 times
2
-
200 records with each of them having 3 columns should not be a problem for shared preference. This should be good enough for you. – Anukool May 17 '13 at 09:41
-
go for shared preference.....its lighter and efficient than DB. – ASP May 17 '13 at 10:19
1 Answers
5
Shared Preferences:
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.
Shared Preferences is nothing but a simple table which has two columns. (key, value).
Shared Preference size 8192 characters according to this documentation: http://developer.android.com/reference/java/util/prefs/Preferences.html#MAX_VALUE_LENGTH
advantages:
- Fast retrieval
- Easy to understand and program
disadvantages
- Maintaining Keys are difficult if we store a lot of values.
- User can clear this at any time.
Database:
When we have a lot of values to store with complex structure, we are left with only one great solution, ie. DB.
advantages
- We can maintain structure of data.
- Android has nice and simple APIs to handle sqlite operations.
disadvantages
Operation is little bit slow comparing to shared preferences. user can clear this at any time.
Community
- 1
- 1
Ronak Mehta
- 5,971
- 5
- 42
- 69
-
what do you base youself onto to say operation is slower on a database compared to shared prefs ? – njzk2 May 17 '13 at 09:55
-
@njzk2 http://stackoverflow.com/a/9529787/1218762 , http://stackoverflow.com/a/6276936/1218762 – Ronak Mehta May 17 '13 at 10:00
-
i tend to disagree. both sources quoted don't quote any source themselves. sqlite has much more room for optimization (with indexes and such), and is by construction faster if you need to search data by value. – njzk2 May 17 '13 at 11:48
-
@njzk2 http://stackoverflow.com/questions/7966751/sqlite-or-shared-preferences , http://stackoverflow.com/questions/4909701/sqlite-or-sharedpreferences-for-persistent-data-storage , http://codeblow.com/questions/benefits-and-drawbacks-of-sqlite-and-shared-preferences/ now prove your self – Ronak Mehta May 17 '13 at 12:21
-
SharedPref has only 1 get action, which is to get a value if you know the key. It is o(1) and very fast once it is in memory, but if it is not, there is still xml parsing to be done. There is no search whatsoever, meaning a considerable amount of overhead if you need that. Sqlite has the same action, performed in o(1) as well using the primary key, and it has searches mechanism that varies between o(1) and much more, depending on your indexes and forms of queries. It also has windowed cursor mechanism, allowing the load all data in a cursor that is actually fetched on a need basis. – njzk2 May 17 '13 at 12:48
-
basically, i tend to agree that if you don't see the need for sqlite, use sharedpref as it is simpler to use, but i also think that in this case, there is no concern for performances, given the amount of data considered. – njzk2 May 17 '13 at 12:49
-
as a disadvantage to sqlite, i'd rather mention the complexity of setup (unless using a framework, but still) – njzk2 May 17 '13 at 12:57
-
let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/30127/discussion-between-rstar-and-njzk2) – Ronak Mehta May 17 '13 at 13:01
-
1`User can clear this at any time.` This also applies for sqlite because when user presses "clear data" button, the SQLite database is also removed. – Sharp Edge Aug 06 '16 at 21:17