On Mon, Jul 5, 2010 at 11:56 PM, Bob Kerns <r...@acm.org> wrote: > Actually, they CAN return different Application objects, and are > actually documented to do so, if you read it carefully. >
Well I wrote the functions and looked at the code to double-check, and as intended they return the Application singleton associated with that component's package. Note that in some early versions of the platform there could not be multiple Application objects in a process, so if you had multiple .apks loaded in the same process then you would always get the Application of the first. That has been fixed since at least 1.5. And anyway, if we are just talking about a single .apk running in a process, this is all extremely simple and there is one and only one Application object there. > 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). > I don't think there is any benefit to removing it. Like I said, it would be good to have a CTS test to ensure that these days it returns the same thing as getApplication(). > getApplicationContext() returns "the context of the single, global > Application object of the current process." There are several problems > with this: > The documentation has not been updated since the fix was done to deal with multiple .apks in a process. > * Programmers shouldn't be writing their programs around what process > their activities and applications live in > Er... of course they should. We very carefully define what process things will run in, and allow developers to explicitly modify that behavior. Forcing people to not be able to make assumptions about the process they are running in would make developing applications incredibly difficult for no good reason. > * 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). > Yes if you have multiple .apks in a process, there are interesting interactions. These days you should be getting the Application/Context for your own .apk. Things are super broken if you don't -- for example any attempt to access your own resources with it will fail. > * It's not well-defined just WHICH application will be the "single > global Application object of the current process". > It is today. > * 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. > This is mostly a case of layering. Context lives in the content package, so doesn't know anything about Application. However it is useful to have a clear way to get the Application object, so there is a method on Activity to do so. > 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. > We really just don't want this to happen. > 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. > Yes sharing a process should be a rare thing, though we do this not infrequently in the platform. One of the reasons this bug got fixed is because on the initial lower-end devices launcher and contacts share a process, and started running into bugs because of the mix of the Application object. > 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. > Yeah the documentation should be updated. -- Dianne Hackborn Android framework engineer hack...@android.com 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 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
