Yes it can. But will it? It probably will after some hours are invested in tracking memory leaks. And the caller still would not know unless it is documented or there is access to the source code.
It is clearly not the best choice for the singleton API design. On Dec 20, 2011 10:03 AM, "Kostya Vasilyev" <[email protected]> wrote: > Um... Singleton.getInstance(Context) can call getApplicationContext on > the Context that's passed in, without requiring the caller to do that. > > 20 декабря 2011 г. 21:57 пользователь Y2i <[email protected]> написал: > >> No, Diane is saying that you can say > >> Singleton.getInstance(context.getApplication()) to pass the > >> Application reference to the singleton and it will be used to > >> initialize the singleton if not already. > > > > No, Diane was clearly saying Singleton.getInstance(context) to pass > context > > (not the application) reference to the singleton (and it will be used to > > initialize the singleton if not initialized already). And passing > context > > of random activities to initialize a singleton will result in the > problems > > described earlier. > > > > Consistently > calling Singleton.getInstance(context.getApplicationContext()) > > or Singleton.getInstance(context.getApplication()) will avoid memory > leaks > > and dead context problems, but the signature of > > the Singleton.getInstance(Context) does not ensure that the method will > > always be called with the application context as the parameter, which is > not > > the best choice from API design perspective. > > > > Having a method Singleton.getInstance(Application) instead > > of Singleton.getInstance(Context) will ensure that no activity context > will > > be used to initialize the Singleton object. But from API design > perspective > > this method signature is not the best one because the actual parameter > will > > only be used once and ignored all other times. Using new > > NormalObject(Application) instead of Singleton.getInstance(Application) > is a > > cleaner API. > > > >> > >> Specifically, the case for me where Application.onCreate() is > >> > >> necessary is initializing singletons in this way. I have a lot of non- > >> Android java code that hide the details of being run inside or outside > >> of Android, and singletons are no exception. If running in Android, I > >> want a version of my singleton to use a context. If not Android, a > >> version with no context (something else). I need the > >> Application.onCreate() entry point to establish this configuration for > >> me or be forced to put that line of init code into every component's > >> onCreate, which is horrible. > > > > This is exactly what I meant when I said "Application.onCreate() would be > > the best place to initialize singletons that require a context" > > > > -- > > 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 > > -- > 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 -- 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
