The getApplicationContext() should return return the same Application object as getApplication()... however, they do go through slightly different code-paths (the Activity has its Application handed to it during initialization, while the base Context implementation needs to retrieve it for its package), so there could have been differences in behavior at times. We should probably have a CTS test for this.
The main limitation of using an Application context is that it can not do direct UI. Activity represents the application's direct interaction with the user, so knows how to associate a Dialog or other UI element you make with the correct Z ordering in the window manager. The Application object in contrast lives separate from the app's UI flow, so can't properly display its own UI. That said, you can use it to display a toast (which briefly overlays on top of all UI) and of course a notification. Also the resources you get from Application should be as fine as those from Activity. The main thing to watch out for (and this also applies to Activity) is that if a configuration change happens while the application doesn't have an activity displayed, then the resources won't be updated. They will only be updated when the user next returns to the app. This is done so that if you for example rotate while in one app, we don't have to rebuild the resources in every other app when you return to it even if by that point the orientation is back to its previous state. On Mon, Jun 21, 2010 at 10:46 AM, Bob Kerns <[email protected]> wrote: > My claim is that it is always incorrect but will usually work. (A bad > combination!) I've raised the issue many times, and nobody, from > Google or otherwise, has come up with an example of when it is correct > to use it. (Unless I missed it, which is possible, but I think the > reason is simply there is no reason!) > > If the Application is really the context you want, then > getApplication() will get the right one. But the other problem is > that people often are confused about what context they want, and > usually the Activity is it. So a much more common source of bugs than > using the wrong way to get to the Application context is using the > Application context when the Activity context is required. > > On Jun 20, 7:11 pm, Streets Of Boston <[email protected]> wrote: > > I hope some Google engineers can way in when and when not to use > > getApplicationContext(). > > > > I use it all the time for getting a context that isn't tied to an > > activity life-cycle, which - as i am now learning - may be incorrect. > > > > On Jun 20, 9:06 pm, Bob Kerns <[email protected]> wrote: > > > > > > > > > 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- Hide quoted text - > > > > > - Show quoted text - > > -- > 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
