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
Android Development wrote:
The docs
here: http://developer.android.com/reference/android/app/Application.html say
that, if the application needs to maintain global state, it should do it
here.
On the other hand, Ms. Hackborn has indicated that she thinks the
Application object is not that
I think it's more accurate to say *you may choose* to maintain global state
by extending Application.
It's my preferred approach, though it's important to to instantiate global
state lazily wherever it's sensible to do so.
I describe my default approach here:
Thanks for the replies.
The data is hidden from the human user and is totally consumed by the
application. Its a small file..some 4-5 attributes only. I am also somewhat
inclined towards using a static singleton option.
On Fri, Sep 11, 2009 at 8:43 PM, Tom Gibara m...@tomgibara.com wrote:
On Fri, Sep 11, 2009 at 8:10 AM, Mark Murphy mmur...@commonsware.comwrote:
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
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
6 matches
Mail list logo
