You should read the documentation for getApplicationContext(), and not simply believe what the name says.
It does NOT, repeat, NOT, return your application. Well, it might, but it might not. "Return the context of the single, global Application object of the current process. This generally should only be used if you need a Context whose lifecycle is separate from the current context, that is tied to the lifetime of the process rather than the current component." Read that carefully. I didn't, first time. The application object it returns may not even be associated with your current .apk -- it can be some other .apk with code running in the same process. It does NOT necessarily return the same as Activity.getApplication(). Activity.getApplication() can be useful. I claim Context.getApplicationContext() should absolutely NEVER be called by developers using the SDK. We simply do not have sufficient control over what it returns. It may work today -- and then later, when you introduce another .apk with the same signature and process name, suddenly stop working -- some of the time. This literally happened to me, which is why I'm clear on the point. The object it returns may even have been loaded with a different classloader -- you won't even be able to cast to get access. The page you linked needs to be fixed! Just as various demos needed to be fixed for the same flaw. On Jun 19, 6:04 pm, Nathan <[email protected]> wrote: > On Jun 19, 5:45 pm, Mark Murphy <[email protected]> wrote: > > > Well, as I wrote: > > > "A number of GUI-related things fail outright if you use > > getApplicationContext() instead of an Activity, for example." > > > Off the top of my head, I can't name any specific methods. Resources > > don't map right, IIRC, and you can't use one for opening a Dialog. It > > seems like any time I suggest somebody replace getApplicationContext() > > with "this" in a StackOverflow answer, it fixes their problem. > > Frankly, I just avoid getApplicationContext() completely unless I am > > specifically looking for the Application object. > > > Also, FWIW, Ms. Hackborn has voiced her concerns about Application as > > a Context in the past. > > Advice from Google Developers isn't exactly consistent on this point, > then. > > From this page: > > http://developer.android.com/intl/de/resources/articles/avoiding-memo... > " The second solution is to use the Application context. This context > will live as long as your application is alive and does not depend on > the activities life cycle. If you plan on keeping long-lived objects > that need a context, remember the application object. You can obtain > it easily by calling Context.getApplicationContext() or > Activity.getApplication()." > > Romain and Ms. Hackborn should probably talk. First, we should use an > application context to avoid storing the Activity context. Second, we > should use an Activity context because an application context plain > won't work. > > Perhaps these aren't in conflict. If you have to store a context > beyond the life of an Activity (something to be avoided when > possible), you are stuck with the application context and whatever > limitations it has. > > I don't know what Google Analytics does with the context; I'd guess > they use the file system for temp storage. I don't if I'm allowed to > reverse engineer the jar to find out, because the terms and conditions > page is down. > > Nathan -- 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
