Thank you very much for the reply! After reading what Fadden said
weeks ago, I happily converted my static inner handler classes to non-
static ones.
Just recently, I was browsing the source code of Handler and came
across this bit of internal Android debugging:
/*
* Set this flag to tr
I wrote that debugging code because of a couple of memory leaks I
found in the Android codebase. Like you said, a Message has a
reference to the Handler which, when it's inner and non-static, has a
reference to the outer this (an Activity for instance.) If the Message
lives in the queue for a long
On Mar 9, 7:17 pm, Greg Krimer wrote:
> I have been finding it convenient to extend Handler in many of my
> activities to handle messages specific to the activity. The handler
> sublass is an inner class of the activity and needs to access its
> state. I am wondering if there is any performance d
The problem is with a non-static inner class is that you don't 'see' the
implicit reference to the outer instance (OuterClass.this). It is easy to
forget about this one and later realize what problems it causes.
Usually,
when the lifetime cycle of an inner class matches the lifecycle of the
ou
fadden wrote:
>
> Greg Krimer wrote:
> > I have been finding it convenient to extend Handler in many of my
> > activities to handle messages specific to the activity. The handler
> > sublass is an inner class of the activity and needs to access its
> > state. I am wondering if there is any per
Note that there is now an Android Lint check for non-static inner classes
that extend Handler. See HandlerLeak:
http://tools.android.com/tips/lint-checks
I've implemented a Handler.Callback wrapper that wraps the Callback
(usually an inner class) in a WeakReference, and I construct the Handler
It's also pretty easy to remove outstanding messages in an activity or
fragment's end-of-lifecycle callbacks. Good idea anyway if those messages
are supposed to trigger UI changes -- you won't want them to arrive after
the activity/fragment has shut down.
-- K
2012/7/20 joebowbeer
> Note that t
But what about a Handler.Callback interface which can be passed to the
Handler's constructor. According to the source code it is stored in the
Handler class as a strong reference, so if the Message lives in the queue
for a long time, the callback will not be gc'ed. And the callback may be an
Ac
2012/7/17 Lew
>
> Use what makes the most sense *in the code* to express the logic.
> In your case this sounds like using inner classes instead of
> static nested classes.
>
> The rule of thumb is that inner classes are for when the inner
> instance needs access to the outer instance's state, whi
Kostya Vasilyev wrote:
> Lew wrote:
>
>>
>> Use what makes the most sense *in the code* to express the logic.
>> In your case this sounds like using inner classes instead of
>> static nested classes.
>>
>> The rule of thumb is that inner classes are for when the inner
>> instance needs access to
10 matches
Mail list logo