In the case I am using it, I would be happy with an activity context
*if* Google Analytics would not hold on to it, causing a huge memory
leak and subsequent crashes.
Nathan
On Jun 21, 10:46 am, Bob Kerns <r...@acm.org> 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 <flyingdutc...@gmail.com> 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 <r...@acm.org> 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 <critter...@crittermap.com> wrote:
>
> > > > On Jun 19, 5:45 pm, Mark Murphy <mmur...@commonsware.com> 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 android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
No comments:
Post a Comment