Monday, June 21, 2010

[android-developers] Re: Avoid non-static inner classes in an activity?

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