Sorry for the delay in responding -- I haven't been able to keep up with the volume lately -- and I'm amazed at how well you do.
On Jul 6, 12:47 pm, Dianne Hackborn <[email protected]> wrote: > On Mon, Jul 5, 2010 at 11:56 PM, Bob Kerns <[email protected]> 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. I believe it was in 1.6 that I did my testing -- on a Nexus One. I very carefully verified not only that the objects were different, but that they came from different classloaders. It may be just that the change was after that point. Careful verification would be good. However there are still all those devices out there running 1.5. Though one is final and one is not... > > 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(). The benefit would be less confusion -- and I believe fewer people using getApplicationContext() just because it says 'Context' and the parameter they need is typed and named 'Context". > > * 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. Poorly stated on my part. I mean they shouldn't be making assumptions about what other applications may or may not live in the same application. Certainly, it's central that the different components of an app generally live in the same process. > > * 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. Yes, things were super broken. I haven't tried to reproduce it in 2.0 -- but so long as older devices are out there, I claim we still have to regard it as unusable, especially since it's also redundant. > > * It's not well-defined just WHICH application will be the "single > > global Application object of the current process". > > It is today. Well, no. I think what you're trying to say is that it's well-defined what object getApplicationContext() returns. Which would be true, if the documentation were updated to match. > > * 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. Or you could just have one method -- let's call it "getApplication()", have it return Context, and override it on Activity to return an Application. > > > 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. Entirely good. > > 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. That you experienced the bug gives me more confidence that it's fixed now. ... > Yeah the documentation should be updated. If I stop bugging you, will that save you enough time? You're pretty good at explaining things... :=) -- 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
