On Wed, Nov 19, 2008 at 10:39 AM, dar <[EMAIL PROTECTED]> wrote: > > Interesting, I noticed this line in the documentation just now, from > > http://code.google.com/android/reference/android/content/SharedPreferences.html > > "Note: currently this class does not support use across multiple > processes. This will be added later." > > So to me, this means that even though my application's activities run > in one process, somehow the users experiencing this data loss problem > may be seeing it because they have a separate process accessing the > SharedPreferences before the first process has committed them to > storage? This does not seem like the intended functionality of > SharedPreferences.
I'm not sure I follow your reasoning -- if you are saying that your application is all running in one process, why do you think the whole caveat about not supporting multiple processes even applies? > I'll buy that any changes before you call > SharedPreferences.Editor.commit() won't be seen by other processes, > but if process A commits, then process B loads them, shouldn't B see > A's commited information? Or is the functionality to be added is what > will make this scenario work correctly? For me, A and B are instances > of the same application. Each process needs to monitor for changes to the file, synchronize them, etc. There is actually some basic support for this, but I wouldn't rely on it, because there isn't really any file locking going on. If you really need to have simultaneous access from multiple processes, at this point a content provider or perhaps shared database is the way to go. > If this scenario doesn't work: A commits, and then B loads but doesn't > see A's changes until some undetermined time later, then I can't use > SharedPreferences either. Also, neither can anyone else for that > matter, because you'll never know if your information is in a usable > state. Why all of the hang-up about multiple processes? Are so many people actually writing apps that for some reason distribute their code across multiple processes? If so, why? This should be an unusual situation. Each process has a fair amount of overhead, so extra processes should be saved for just very special cases. -- Dianne Hackborn [EMAIL PROTECTED] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
