0

When a user logs in to an app I'm developing, the back-end sends back information about the user. I want to persist the information so it can be used in other activities and when there is no network access.

The two main persistence options I'm aware of for Android are SharedPrefereces and SQLite, and I'm trying to determine which would be more appropriate for my use case. There are three requirements:

  1. The data to store are mostly a small number of primitive data types or simple reference types, but an array or an object of a derived type may also need to be stored.
  2. Reading and writing the data should be as simple as possible.
  3. Data that is written must be available on any subsequent read.

Here is my attempt to compare SharedPreferences and SQLite along these dimensions. (Note that there are other questions on StackOverflow that ask for comparisons of SharedPreferences and SQLite -- "Pros and Cons of SQLite and Shared Preferences", "Saving data on Android : File Storage vs SQLite Database vs Shared Preferences" -- but the answers do not address all three dimensions.)

SharedPreferences

  1. Works most naturally with primitive and simple reference types, but GSON can be used to store data of any type.
  2. Data can be written and read from the UI thread.
  3. Due to a race condition, there is no guarantee that data written to SharedPreferences will be available on any subsequent read.

SQLite

  1. Can be used in a natural way to store structured data of any degree of complexity.
  2. Data should be written and read in a thread separate from the UI thread.
  3. Using a singleton DatabaseHelper guarantees that data written to the database will be available on any subsequent read.

If my assessment is correct, it looks like the SharedPreferences race condition means I have to use SQLite instead to satisfy the requirements even though doing so is more involved. But is my assessment correct?

Community
  • 1
  • 1
stevehs17
  • 1,466
  • 2
  • 14
  • 19

1 Answers1

0

You said :

a small number of primitive data types or simple reference types

Then definitely SharedPreferences is preferred. If you can image to have a lot of similar rows of data which are all unique rows then use SQLite. You have three requirements and none of them need to store big amount of similar, nevertheless unique, data.

On the other hand:

an array or an object of a derived type may also need to be stored.

i would suggest to store these data in private text files and with every app launch try to decode the data (if it exists).

Abbas Akhundov
  • 562
  • 6
  • 12
  • 1
    Thanks, Abbas. But the write latency of SharedPreferences would still be a problem (if I'm right about that). I've edited the question to emphasize that. – stevehs17 Feb 18 '16 at 20:23
  • @stevehs17 , when you want to write to *SharedPreferences* then you can use `Editor.apply();` instead of `Editor.commit()`. `Editor.apply();` methos is async and won't give you much trouble. – Abbas Akhundov Feb 18 '16 at 20:30
  • 1
    Abbas: Regardless of whether I use commit() or apply(), if I subsequently try to retrieve the value I saved, it's not clear to me that there's a guarantee that it would be available if I try to retrieve it too quickly. That's my concern. – stevehs17 Feb 18 '16 at 20:49
  • @stevehs17 If you use `commit()` then you don't have to worry about retrieving the data you have saved since it is not async method and *UI Thread* won't step forward until this method is finished. I'm sure it will work as you expect it to work. Just run a little test and you will see. – Abbas Akhundov Feb 18 '16 at 20:58
  • Thanks, Abbas. But if I have to wait for commit() to return, then I don't think I should be calling it from the UI thread. – stevehs17 Feb 18 '16 at 22:22