A little other perspective:
First, there is no need to use Application except in cases where you need a
global Context. I generally prefer to have shared resources simply placed
in singletons in my process, which anyone can directly access:
public class SharedStuff {
private static final Object sLock = new Object();
private static final SharedStuff sInstance;
public static SharedStuff getInstance() {
synchronized (sLock) {
if (sInstance == null) sInstance = new SharedStuff();
return sInstance;
}
}
}
Then anyone can access this wherever they want. I think this is much
cleaner and more modular than trying to hang stuff off application, as it
avoids having one central place where I need to enumerate the global
resources for the entire code in the application (including shared
libraries).
If your global data needs to do stuff with the context (such as register
receivers), just pass it a Context and let it pull the Application Context
out:
public static SharedStuff getInstance(Context caller) {
synchronized (sLock) {
if (sInstance == null) {
sInstance = new SharedStuff(caller.getApplicationContext());
}
return sInstance;
}
}
If it will be doing active stuff while your app is running that you want it
to stop when not running, have methods each activity calls when it
resumes/pauses or starts/stop to keep track of how many active clients it
has.
As for ContentProvider, they are only *needed* for sharing your data with
others *outside* of your app. If you are not doing that, there is no need
to use one. Often it can be convenient to have one for data that is only
used within the app when it is for example going to be presented with a list
view, since the framework has lots of facilities to help work with content
providers. But if it's not convenient... don't use it. And at any rate,
they are almost always used with a SQLite database, so if you don't have a
database I just wouldn't consider one at all.
On Fri, Sep 17, 2010 at 8:41 AM, Jason <[email protected]> wrote:
> ok great. Sounds like the ticket.
>
> Thanks for your help.
>
> On Sep 18, 1:39 am, Bret Foreman <[email protected]> wrote:
> > By the way, the Android-centric name for the pattern you want is
> > "Content Provider". You can search the documentation for that phrase.
> > SQLite is an example of a content provider where you normally create
> > an Adapter that wraps around the raw SQLite API to present an
> > application-specific API to the rest of your code. Content providers
> > are where any substantial persistent state is supposed to reside. Then
> > you just instantiate the adapter in your onCreate and access the state
> > you need.
>
> --
> 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]<android-developers%[email protected]>
> For more options, visit this group at
> http://groups.google.com/group/android-developers?hl=en
>
--
Dianne Hackborn
Android framework engineer
[email protected]
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 [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
