Actually, they CAN return different Application objects, and are actually documented to do so, if you read it carefully.
I don't think it's exactly a bug that they do -- but I do think the platform would be improved by removing getApplicationContext() from the public API somehow. Perhaps by deprecating it, changing all the valid internal uses to something internal, and making it return what getApplication() returns (thereby fixing bugs). getApplicationContext() returns "the context of the single, global Application object of the current process." There are several problems with this: * Programmers shouldn't be writing their programs around what process their activities and applications live in * They won't have useful access to it anyway (when it's from a different .apk, it's also from a different classloader, so you can't cast it to anything). * It's not well-defined just WHICH application will be the "single global Application object of the current process". * It's confusing having two calls which APPEAR to do the same thing. I believe the presence of the name "context" in the name here is responsible for a lot people using it when they should be using the Activity. It's like a road sign showing a shorter route, that happens to lead to a bridge that's out. It's worth noting that, in the case where getApplicationContext() returns a different Application, you don't even want to access the resources. If it's not your application, they'll be the wrong ones -- and you have no definition of which application it will be. It's fortunate that applications rarely share a process, and never without sharing a name and signing key. Calling the wrong one will very rarely hurt you. I'd like to highlight your statement: "while the base Context implementation needs to retrieve it for its package". That's NOT what it's documented to do, and that's NOT the behavior I last observed. The last I checked, it did NOT retrieve it based on the current package. If that has changed, then the documentation needs to catch up, and you're probably half-way toward my proposed solution (deprecation + behavior change). In that case, you'd just need to document the change (i.e. change the document), and deprecate. On Jul 5, 12:01 pm, Dianne Hackborn <hack...@android.com> wrote: > 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. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
