Your singleton's lifetime is that of the process (via its class loader), but a process can be reused, right? That is, can't the same process may be reused for subsequent instances of an application?
On Sep 17, 9:28 am, Dianne Hackborn <[email protected]> wrote: > 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%2Bunsubs > > [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
