I store my application config data in preferences: http://developer.android.com/guide/topics/data/data-storage.html#pref And have a singleton class to read and write (aka wrap) them. That way it is also maintained even if the application is killed.
On Sep 11, 8:21 pm, Tom Gibara <m...@tomgibara.com> wrote: > I hesitate to raise a word against any of Dianne's advice (ever) - and it > clearly depends on the nature of your application. But what I find with my > code is that most of the global state I want to keep depends on a Context. > For example, anything that loads resources, or anything that needs to > generate user readable messages. > As a consequence I end up with a number of 'helper' classes that hold a > reference to a context so that they can do their work. I find that the > Application instance is the obvious context for these helpers. > > Furthermore, a specialization of the Application class seems the natural > place for application code to access these objects, since the Application > can instantiate them with itself (eagerly in onCreate or lazily behind > accessors). > > Tom > > 2009/9/11 Dianne Hackborn <hack...@android.com> > > > On Fri, Sep 11, 2009 at 8:10 AM, Mark Murphy <mmur...@commonsware.com>wrote: > > >> The four main options I have used are: > > >> 1. Custom application class, like you are proposing > > >> 2. Static data (e.g., singleton class instance holding your configuration) > > >> 3. A service > > >> 4. Shared preferences > > >> "Best" is somewhat subjective -- I certainly do not have a definitive > >> "always use X" recommendation. > > > There isn't a best, it's very much dependent on what semantics you want -- > > shared preferences will remain after the process is gone, a service's state > > is tied to the process but tells the system to try to keep the process > > around, and Application and static data are tied directly to the lifetime of > > the process and allow the system to remove them without guilt when the > > process isn't in active use. (So Application and static are redundant, and > > static data lets you better modularize your code instead of stuffing > > everything in to Application, which is why I recommend statics.) > > > -- > > Dianne Hackborn > > Android framework engineer > > hack...@android.com > > > Note: please don't send private questions to me, as I don't have time to > > provide private support, and so won't reply to such e-mails. All such > > questions should be posted on public forums, where I and others can see and > > answer them. > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
