50

I know similar question to this one has been asked a numerous times, and surfing through SO I partially found an answer, but not complete, and android docs don't really help. Obviously I know how they work and have used shared preferences many times before, but I am wondering at what point ( how many ) is too much, I've read people had ~ 100KBS stored without any problem. Long story short -- Did someone actually had problems with too many data stored in shared preferences and what was problem, does data get deleted or?

** this is only a question out of curiosity, I already have my large values stored in SQL DB, just wondered what would be and if there would be any problems if someone for some reason stored everything in shared preferences

Marko Niciforovic
  • 3,561
  • 2
  • 21
  • 28
  • I know what are they used for and when, I just wonder what problems can they cause if used too many. – Marko Niciforovic Mar 25 '13 at 14:49
  • 1
    SharedPreferences are mostly used to store some primitive data types, and I don't think there's a limit. If you really want to know you have to look for "Android application maximum stored data amount", I doubt you'll find an answer around SharedPreferences – Droidman Mar 25 '13 at 14:53
  • thanks Maver1ck, ill search on Android application maximum stored data amount – Marko Niciforovic Mar 25 '13 at 14:57
  • just extending my commend a little: as soon as you use SharedPreferences and find your app using Settings - Apps, you will see that "data" section is not zero anymore. That's why I believe that data used by SharedPreferences is generalized as "application data" and if there is a limit - it equals the maximum amount of data an application is allowed to store – Droidman Mar 25 '13 at 15:02

3 Answers3

62

Since SharedPreferences are stored in an XML file, and therefore lacks the strong transaction support of SQLite, I would not recommend storing "100KBS" in SharedPreferences.

That being said, the lowest size limit that I am aware of will be your amount of free heap space, as SharedPreferences reads that entire XML file's contents into memory.

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • 9
    Good to know about the heap size. However, I don't think i've ever got the xml files to be so large. wonder why they are xml in the first place and not binary files (or json). – android developer Mar 25 '13 at 15:33
  • 1
    Hey #CommonsWare ! You mean storing string of size around 100kb is not a good idea ? – Muhammad Adil Jul 16 '15 at 06:45
  • 1
    @CommonsWare what should be the ideal size approx of Shared Preferences, that would be OKAY for smooth functioning of Android App ? – Gaurav Arora Mar 27 '18 at 10:52
  • 2
    @GauravArora: Personally, I would try to keep it small: a few KB or so. – CommonsWare Mar 27 '18 at 10:53
  • Thanks. I think a data less than 10kb would be okay. Am I right ? – Gaurav Arora Mar 27 '18 at 13:12
  • 1
    @GauravArora: I have never had a `SharedPreferences` that large, so I cannot comment, sorry. – CommonsWare Mar 27 '18 at 13:37
  • 5
    For the sake of posterity can we get our Kb/KB/KBs/Kbps correct! Try always using caps for data like KB(kilobyte) and KBs(for its plural). While Kb and kb for data speed, annexed with "ps". So speed is denoted kbps/Kbps(Kilo bits per sec). So, just "kb" for data is misleading. And KBS would sound like one of those internet Ads trying to yell its high speeds! Oh and 8bits = 1 Byte and 1024Bytes = 1KB(not kb).Cheers! – Yo Apps Oct 21 '18 at 09:32
17

There is a limitations of SharedPreference data. In my case it throw a Memory Exception when SharedPreference data cross 1428.51-kb.

So its better to use SQLite database when you required huge data to store.

Mani
  • 3,394
  • 3
  • 30
  • 36
16

From reading your question I would think that you should not be using SharedPreferences, because (a) they are intended for storing much smaller amounts of data (hence the use of XML), and (b) there are many simple alternatives.

The only thing 'special' about SharedPreferences is the integration with the Preferences Activity for showing your preferences to the user, and that is probably not applicable in your case based on the amount you plan to store. (Oh, also the SharePreferences handles concurrency issues for you.)

You could use Java's serialization to store Preference class(s) in binary files. These would be dramatically smaller then comparable PreferenceFile and can easily be passed through GZIPInputStream to make it smaller (or CipherInputStream) to encrypt it. I have found this alternate to be a powerful, simple, and cross-platform way to store app data where the power of SQLite is not needed.

(Sorry this isn't a direct answer.)

Tom
  • 17,103
  • 8
  • 67
  • 75