[android-developers] Correct way to implement Activity onDestroy()?
I read http://android-developers.blogspot.tw/2009/01/avoiding-memory-leaks.html about avoiding memory leaks. I would like to know whether I should null out all member variables, such as TextView and Button in onDestroy()? Or, unregistering listener, unbinding service and etc.in onDestroy() are enough to prevent memory leak? -- 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
Re: [android-developers] Correct way to implement Activity onDestroy()?
Basically, as long as you aren't hanging static Activity references you should be fine. The main activity will be thrown away upon its destruction, at which point the Activity will be thrown away: along with its contents. Of course, if you're holding onto Views elsewhere that's bad (i.e., don't hold static refs). kris On Mon, Jan 14, 2013 at 1:42 AM, Greenhand wrote: > I read > http://android-developers.blogspot.tw/2009/01/avoiding-memory-leaks.html > about avoiding memory leaks. > I would like to know whether I should null out all member variables, such as > TextView and Button in onDestroy()? Or, unregistering listener, unbinding > service and etc.in onDestroy() are enough to prevent memory leak? > > -- > 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 -- 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
Re: [android-developers] Correct way to implement Activity onDestroy()?
Thank you. Another related question, in section "5. Implement a more intelligent AsyncTask dealing with screen orientation" of http://blog.doityourselfandroid.com/2010/11/14/handling-progress-dialogs-and-screen-orientation-changes/, it has private AsyncTaskComplex activity in ListFresher as a member variable. Shouldn't it be null out because it is not a static Activity references? Kristopher Micinski於 2013年1月14日星期一UTC+8下午4時24分53秒寫道： > Basically, as long as you aren't hanging static Activity references > you should be fine. The main activity will be thrown away upon its > destruction, at which point the Activity will be thrown away: along > with its contents. Of course, if you're holding onto Views elsewhere > that's bad (i.e., don't hold static refs). > > kris > > On Mon, Jan 14, 2013 at 1:42 AM, Greenhand > > > wrote: > > I read > > http://android-developers.blogspot.tw/2009/01/avoiding-memory-leaks.html > > about avoiding memory leaks. > > I would like to know whether I should null out all member variables, > such as > > TextView and Button in onDestroy()? Or, unregistering listener, > unbinding > > service and etc.in onDestroy() are enough to prevent memory leak? > > > > -- > > -- 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
Re: [android-developers] Correct way to implement Activity onDestroy()?
After spending considerable time looking at this issue, I strongly suggest
that you look into an Intent Service, for any long running task. Using
AsyncTasks is just fraught.
First of all, onDestroy is only called best effort. If you care about
getting it done, you can't do it in onDestroy. Further, as kris points
out, onDestroy is, often, called just as your *process* is about to be
destroyed. Worrying about allocation of memory in your process, just as it
is destroyed, is pretty pointless.
There are two issues you need to consider: making your program correct
according to Java ("If mutable state is referenced from more than one
thread, all references must take place holding a single lock" - B. Goetz,
paraphrased). You also have to be sure that the lifecycles of unmanaged
objects (e.g. AsyncTasks) don't interfere with the lifecycles of managed
objects (Activities).
Nulling out pointers and AsyncTasks that survive screen
reorientation (despite the fact that I proposed it myself, at one
point) are just Voodoo.
G. Blake Meike
Marakana
Programming Android 2ed is now in stores:
http://bit.ly/programmingandroid
On Monday, January 14, 2013 1:10:52 AM UTC-8, Greenhand wrote:
>
> Thank you.
> Another related question, in section "5. Implement a more intelligent
> AsyncTask dealing with screen orientation" of
> http://blog.doityourselfandroid.com/2010/11/14/handling-progress-dialogs-and-screen-orientation-changes/,
>
> it has private AsyncTaskComplex activity in ListFresher as a member
> variable. Shouldn't it be null out because it is not a static Activity
> references?
>
>
> Kristopher Micinski於 2013年1月14日星期一UTC+8下午4時24分53秒寫道：
>
>> Basically, as long as you aren't hanging static Activity references
>> you should be fine. The main activity will be thrown away upon its
>> destruction, at which point the Activity will be thrown away: along
>> with its contents. Of course, if you're holding onto Views elsewhere
>> that's bad (i.e., don't hold static refs).
>>
>> kris
>>
>> On Mon, Jan 14, 2013 at 1:42 AM, Greenhand wrote:
>> > I read
>> >
>> http://android-developers.blogspot.tw/2009/01/avoiding-memory-leaks.html
>> > about avoiding memory leaks.
>> > I would like to know whether I should null out all member variables,
>> such as
>> > TextView and Button in onDestroy()? Or, unregistering listener,
>> unbinding
>> > service and etc.in onDestroy() are enough to prevent memory leak?
>> >
>> > --
>>
>>
--
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
Re: [android-developers] Correct way to implement Activity onDestroy()?
While you say that Activities only die when the process is about to be
destroyed (or usually die), I have heard that this is not the case.
This is mostly hearsay from developers and people I work with saying
that memory leaks because of this were really a problem, but I'd have
to look into it with some examples (of layouts that really use memory,
I'm thinking galleries and nested views, etc..) before making any
definite calls.
Kris
On Mon, Jan 14, 2013 at 9:37 AM, G. Blake Meike wrote:
> After spending considerable time looking at this issue, I strongly suggest
> that you look into an Intent Service, for any long running task. Using
> AsyncTasks is just fraught.
>
> First of all, onDestroy is only called best effort. If you care about
> getting it done, you can't do it in onDestroy. Further, as kris points out,
> onDestroy is, often, called just as your *process* is about to be destroyed.
> Worrying about allocation of memory in your process, just as it is
> destroyed, is pretty pointless.
>
> There are two issues you need to consider: making your program correct
> according to Java ("If mutable state is referenced from more than one
> thread, all references must take place holding a single lock" - B. Goetz,
> paraphrased). You also have to be sure that the lifecycles of unmanaged
> objects (e.g. AsyncTasks) don't interfere with the lifecycles of managed
> objects (Activities).
>
> Nulling out pointers and AsyncTasks that survive screen reorientation
> (despite the fact that I proposed it myself, at one point) are just Voodoo.
>
> G. Blake Meike
> Marakana
>
> Programming Android 2ed is now in stores:
> http://bit.ly/programmingandroid
>
>
> On Monday, January 14, 2013 1:10:52 AM UTC-8, Greenhand wrote:
>>
>> Thank you.
>> Another related question, in section "5. Implement a more intelligent
>> AsyncTask dealing with screen orientation" of
>> http://blog.doityourselfandroid.com/2010/11/14/handling-progress-dialogs-and-screen-orientation-changes/,
>> it has private AsyncTaskComplex activity in ListFresher as a member
>> variable. Shouldn't it be null out because it is not a static Activity
>> references?
>>
>>
>> Kristopher Micinski於 2013年1月14日星期一UTC+8下午4時24分53秒寫道：
>>>
>>> Basically, as long as you aren't hanging static Activity references
>>> you should be fine. The main activity will be thrown away upon its
>>> destruction, at which point the Activity will be thrown away: along
>>> with its contents. Of course, if you're holding onto Views elsewhere
>>> that's bad (i.e., don't hold static refs).
>>>
>>> kris
>>>
>>> On Mon, Jan 14, 2013 at 1:42 AM, Greenhand wrote:
>>> > I read
>>> >
>>> > http://android-developers.blogspot.tw/2009/01/avoiding-memory-leaks.html
>>> > about avoiding memory leaks.
>>> > I would like to know whether I should null out all member variables,
>>> > such as
>>> > TextView and Button in onDestroy()? Or, unregistering listener,
>>> > unbinding
>>> > service and etc.in onDestroy() are enough to prevent memory leak?
>>> >
>>> > --
>>>
> --
> 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
--
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
Re: [android-developers] Correct way to implement Activity onDestroy()?
An Activity's onDestroy is called all the time (but not every time :)).
It is true that you can't *rely *on it being called, though.
E.g. the onDestroy is always called when you click the 'back' key or do
some other action (code-execution) that causes the Acitivity's 'finish()'
method to be called.
On Monday, January 14, 2013 11:55:10 AM UTC-5, Kristopher Micinski wrote:
>
> While you say that Activities only die when the process is about to be
> destroyed (or usually die), I have heard that this is not the case.
> This is mostly hearsay from developers and people I work with saying
> that memory leaks because of this were really a problem, but I'd have
> to look into it with some examples (of layouts that really use memory,
> I'm thinking galleries and nested views, etc..) before making any
> definite calls.
>
> Kris
>
> On Mon, Jan 14, 2013 at 9:37 AM, G. Blake Meike
> >
> wrote:
> > After spending considerable time looking at this issue, I strongly
> suggest
> > that you look into an Intent Service, for any long running task. Using
> > AsyncTasks is just fraught.
> >
> > First of all, onDestroy is only called best effort. If you care about
> > getting it done, you can't do it in onDestroy. Further, as kris points
> out,
> > onDestroy is, often, called just as your *process* is about to be
> destroyed.
> > Worrying about allocation of memory in your process, just as it is
> > destroyed, is pretty pointless.
> >
> > There are two issues you need to consider: making your program correct
> > according to Java ("If mutable state is referenced from more than one
> > thread, all references must take place holding a single lock" - B.
> Goetz,
> > paraphrased). You also have to be sure that the lifecycles of unmanaged
> > objects (e.g. AsyncTasks) don't interfere with the lifecycles of managed
> > objects (Activities).
> >
> > Nulling out pointers and AsyncTasks that survive screen reorientation
> > (despite the fact that I proposed it myself, at one point) are just
> Voodoo.
> >
> > G. Blake Meike
> > Marakana
> >
> > Programming Android 2ed is now in stores:
> > http://bit.ly/programmingandroid
> >
> >
> > On Monday, January 14, 2013 1:10:52 AM UTC-8, Greenhand wrote:
> >>
> >> Thank you.
> >> Another related question, in section "5. Implement a more intelligent
> >> AsyncTask dealing with screen orientation" of
> >>
> http://blog.doityourselfandroid.com/2010/11/14/handling-progress-dialogs-and-screen-orientation-changes/,
>
>
> >> it has private AsyncTaskComplex activity in ListFresher as a member
> >> variable. Shouldn't it be null out because it is not a static Activity
> >> references?
> >>
> >>
> >> Kristopher Micinski於 2013年1月14日星期一UTC+8下午4時24分53秒寫道：
> >>>
> >>> Basically, as long as you aren't hanging static Activity references
> >>> you should be fine. The main activity will be thrown away upon its
> >>> destruction, at which point the Activity will be thrown away: along
> >>> with its contents. Of course, if you're holding onto Views elsewhere
> >>> that's bad (i.e., don't hold static refs).
> >>>
> >>> kris
> >>>
> >>> On Mon, Jan 14, 2013 at 1:42 AM, Greenhand
> wrote:
> >>> > I read
> >>> >
> >>> >
> http://android-developers.blogspot.tw/2009/01/avoiding-memory-leaks.html
> >>> > about avoiding memory leaks.
> >>> > I would like to know whether I should null out all member variables,
> >>> > such as
> >>> > TextView and Button in onDestroy()? Or, unregistering listener,
> >>> > unbinding
> >>> > service and etc.in onDestroy() are enough to prevent memory leak?
> >>> >
> >>> > --
> >>>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Android Developers" group.
> > To post to this group, send email to
> > android-d...@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
>
--
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
Re: [android-developers] Correct way to implement Activity onDestroy()?
That's right, I'd heard of people getting leaks on apps that kept doing
configuration changes.
Kris
On Jan 14, 2013 6:21 PM, "Streets Of Boston"
wrote:
> An Activity's onDestroy is called all the time (but not every time :)).
>
> It is true that you can't *rely *on it being called, though.
>
> E.g. the onDestroy is always called when you click the 'back' key or do
> some other action (code-execution) that causes the Acitivity's 'finish()'
> method to be called.
>
> On Monday, January 14, 2013 11:55:10 AM UTC-5, Kristopher Micinski wrote:
>>
>> While you say that Activities only die when the process is about to be
>> destroyed (or usually die), I have heard that this is not the case.
>> This is mostly hearsay from developers and people I work with saying
>> that memory leaks because of this were really a problem, but I'd have
>> to look into it with some examples (of layouts that really use memory,
>> I'm thinking galleries and nested views, etc..) before making any
>> definite calls.
>>
>> Kris
>>
>> On Mon, Jan 14, 2013 at 9:37 AM, G. Blake Meike
>> wrote:
>> > After spending considerable time looking at this issue, I strongly
>> suggest
>> > that you look into an Intent Service, for any long running task. Using
>> > AsyncTasks is just fraught.
>> >
>> > First of all, onDestroy is only called best effort. If you care about
>> > getting it done, you can't do it in onDestroy. Further, as kris points
>> out,
>> > onDestroy is, often, called just as your *process* is about to be
>> destroyed.
>> > Worrying about allocation of memory in your process, just as it is
>> > destroyed, is pretty pointless.
>> >
>> > There are two issues you need to consider: making your program correct
>> > according to Java ("If mutable state is referenced from more than one
>> > thread, all references must take place holding a single lock" - B.
>> Goetz,
>> > paraphrased). You also have to be sure that the lifecycles of
>> unmanaged
>> > objects (e.g. AsyncTasks) don't interfere with the lifecycles of
>> managed
>> > objects (Activities).
>> >
>> > Nulling out pointers and AsyncTasks that survive screen reorientation
>> > (despite the fact that I proposed it myself, at one point) are just
>> Voodoo.
>> >
>> > G. Blake Meike
>> > Marakana
>> >
>> > Programming Android 2ed is now in stores:
>> > http://bit.ly/**programmingandroid
>> >
>> >
>> > On Monday, January 14, 2013 1:10:52 AM UTC-8, Greenhand wrote:
>> >>
>> >> Thank you.
>> >> Another related question, in section "5. Implement a more intelligent
>> >> AsyncTask dealing with screen orientation" of
>> >> http://blog.**doityourselfandroid.com/2010/**11/14/handling-progress-*
>> *dialogs-and-screen-**orientation-changes/
>> >>> > about avoiding memory leaks.
>> >>> > I would like to know whether I should null out all member
>> variables,
>> >>> > such as
>> >>> > TextView and Button in onDestroy()? Or, unregistering listener,
>> >>> > unbinding
>> >>> > service and etc.in onDestroy() are enough to prevent memory leak?
>> >>> >
>> >>> > --
>> >>>
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups "Android Developers" group.
>> > To post to this group, send email to android-d...@**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
>>
> --
> 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
--
You received this message because you are subscribed to the Google
Groups "Android Deve
Re: [android-developers] Correct way to implement Activity onDestroy()?
I considered IntentService before; however, I did not found a way to abort
IntentService like the AsyncTask#cancel() mechanism.
It is why I adapt to Asynctask and wonder about the memory leak issue.
If I try to null out the member variables and the activity reference in
AsyncTask in onPause(), is it safe? Or, I do not have to null out them
unless they are static.
I know that onPause() is guaranteed to be called before the Activity
becomes killable.
G. Blake Meike於 2013年1月14日星期一UTC+8下午11時37分16秒寫道：
> After spending considerable time looking at this issue, I strongly suggest
> that you look into an Intent Service, for any long running task. Using
> AsyncTasks is just fraught.
>
> First of all, onDestroy is only called best effort. If you care about
> getting it done, you can't do it in onDestroy. Further, as kris points
> out, onDestroy is, often, called just as your *process* is about to be
> destroyed. Worrying about allocation of memory in your process, just as it
> is destroyed, is pretty pointless.
>
> There are two issues you need to consider: making your program correct
> according to Java ("If mutable state is referenced from more than one
> thread, all references must take place holding a single lock" - B. Goetz,
> paraphrased). You also have to be sure that the lifecycles of unmanaged
> objects (e.g. AsyncTasks) don't interfere with the lifecycles of managed
> objects (Activities).
>
> Nulling out pointers and AsyncTasks that survive screen
> reorientation (despite the fact that I proposed it myself, at one
> point) are just Voodoo.
>
> G. Blake Meike
> Marakana
>
> Programming Android 2ed is now in stores:
> http://bit.ly/programmingandroid
>
>
> On Monday, January 14, 2013 1:10:52 AM UTC-8, Greenhand wrote:
>>
>> Thank you.
>> Another related question, in section "5. Implement a more intelligent
>> AsyncTask dealing with screen orientation" of
>> http://blog.doityourselfandroid.com/2010/11/14/handling-progress-dialogs-and-screen-orientation-changes/,
>>
>> it has private AsyncTaskComplex activity in ListFresher as a member
>> variable. Shouldn't it be null out because it is not a static Activity
>> references?
>>
>>
>> Kristopher Micinski於 2013年1月14日星期一UTC+8下午4時24分53秒寫道：
>>
>>> Basically, as long as you aren't hanging static Activity references
>>> you should be fine. The main activity will be thrown away upon its
>>> destruction, at which point the Activity will be thrown away: along
>>> with its contents. Of course, if you're holding onto Views elsewhere
>>> that's bad (i.e., don't hold static refs).
>>>
>>> kris
>>>
>>> On Mon, Jan 14, 2013 at 1:42 AM, Greenhand
>>> wrote:
>>> > I read
>>> >
>>> http://android-developers.blogspot.tw/2009/01/avoiding-memory-leaks.html
>>> > about avoiding memory leaks.
>>> > I would like to know whether I should null out all member variables,
>>> such as
>>> > TextView and Button in onDestroy()? Or, unregistering listener,
>>> unbinding
>>> > service and etc.in onDestroy() are enough to prevent memory leak?
>>> >
>>> > --
>>>
>>>
--
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
Re: [android-developers] Correct way to implement Activity onDestroy()?
On Monday, January 14, 2013 6:13:34 PM UTC-8, Greenhand wrote: > > I considered IntentService before; however, I did not found a way to abort > IntentService like the AsyncTask#cancel() mechanism. > That's an interesting point. Note, first of all, that wrapping a job in an AsyncTask doesn't actually make it cancelable. Unless the job will actually stop when interrupted or something, you can call cancel on the AsyncTask all day long, to no effect. What AsyncTask *does* provide, is a pointer to the task you want to cancel. I should think that would be pretty easy to do with an IntentService: There is only one job running at any time. Just interrupt the thread or flag the job. If I try to null out the member variables and the activity reference in > AsyncTask in onPause(), is it safe?. I do not have to null out them unless > they are static. If the AsyncTask holds a reference to an Activity, you'll leak the activity. That's true even if the reference is implicit (that is, if the AsyncTask is an inner class and *not* static). Making sure that the task has no pointers to the Activity, after onPause, is safe. On the other hand, it brings up the question of why the Task is still running, if there is nobody to whom to report a result... G. Blake Meike Marakana Programming Android 2ed is now in stores: http://bit.ly/programmingandroid -- 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
Re: [android-developers] Correct way to implement Activity onDestroy()?
Conciser holding a WeakReference to the Activity from the AsyncTask. On Tuesday, January 15, 2013 5:44:04 PM UTC, G. Blake Meike wrote: > > > > On Monday, January 14, 2013 6:13:34 PM UTC-8, Greenhand wrote: >> >> I considered IntentService before; however, I did not found a way to >> abort IntentService like the AsyncTask#cancel() mechanism. >> > > That's an interesting point. > > Note, first of all, that wrapping a job in an AsyncTask doesn't actually > make it cancelable. Unless the job will actually stop when interrupted or > something, you can call cancel on the AsyncTask all day long, to no effect. > > What AsyncTask *does* provide, is a pointer to the task you want to > cancel. I should think that would be pretty easy to do with an > IntentService: There is only one job running at any time. Just interrupt > the thread or flag the job. > > If I try to null out the member variables and the activity reference in >> AsyncTask in onPause(), is it safe?. I do not have to null out them unless >> they are static. > > > If the AsyncTask holds a reference to an Activity, you'll leak the > activity. That's true even if the reference is implicit (that is, if the > AsyncTask is an inner class and *not* static). Making sure that the task > has no pointers to the Activity, after onPause, is safe. On the other > hand, it brings up the question of why the Task is still running, if there > is nobody to whom to report a result... > > G. Blake Meike > Marakana > > Programming Android 2ed is now in stores: > http://bit.ly/programmingandroid > > -- 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
Re: [android-developers] Correct way to implement Activity onDestroy()?
Blake Meike wrote: > an inner class and *not* static). > > That's redundant. In Java, the definition of "inner class" is a non-static nested class. -- Lew -- 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
Re: [android-developers] Correct way to implement Activity onDestroy()?
A weak reference may not be collected by the time of onPostExecute, even though that activity instance may have been destroyed (orientation change, etc.). The task would then, presumably, attempt to deliver the results and update the UI of the old activity instance. Really, a better way is to set the task to null in the owning activity's onDestroy, and reset to the new one in onCreate in case it was an orientation change. It's easy to know if it is by carrying the currently running task over in the activity's onRetainNonConfigurationInstance. Of course if the app uses fragments, it easy enough to call setRetainInstance(true) on the fragment, avoiding both issues. -- K 2013/1/15 RichardC : > Conciser holding a WeakReference to the Activity from the AsyncTask. -- 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
Re: [android-developers] Correct way to implement Activity onDestroy()?
2013/1/15 G. Blake Meike : > I should think that would be pretty easy to do with an IntentService: There > is only one job running at any time. Just interrupt the thread or flag the > job. IntentService uses HandlerThread for its implementation. Even though there can be at most one task (intent) running on the handler thread, there may be multiple tasks (intents) in the handler thread's event queue. In theory, those would also need to be considered when canceling a task (intent). -- K -- 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
Re: [android-developers] Correct way to implement Activity onDestroy()?
No, it's not redundant. There is something in Java called a *static inner class*. It is basically a weird use of the word static. Please see this: http://docs.oracle.com/javase/tutorial/java/javaOO/nested.html *A nested class is a member of its enclosing class. Non-static nested classes (inner classes) have access to other members of the enclosing class, even if they are declared private. Static nested classes do not have access to other members of the enclosing class. As a member of the OuterClass, a nested class can be declared private, public, protected, or package private.* On Tuesday, January 15, 2013 1:23:23 PM UTC-6, Lew wrote: > > Blake Meike wrote: > >> an inner class and *not* static). >> >> That's redundant. In Java, the definition of "inner class" is a > non-static nested class. > > -- > Lew > > -- 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
Re: [android-developers] Correct way to implement Activity onDestroy()?
bob wrote: > No, it's not redundant. There is something in Java called a *static > inner class*. > No, there is not. >From the JLS: "The static keyword may modify the declaration of a member type C within the body of a non-inner class or interface T. Its effect is to declare that C is not an inner class. " and "An *inner class* is a nested class that is not explicitly or implicitly declared static." Note: the effect of 'static' is to declare that the nested class is *not* an inner class. > It is basically a weird use of the word static. > > Please see this: > > http://docs.oracle.com/javase/tutorial/java/javaOO/nested.html > This does not support your claim. It correctly describes an "inner class" as a "non-static nested class". The words "static" and "inner class" in Java are mutually exclusive. -- Lew -- 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
Re: [android-developers] Correct way to implement Activity onDestroy()?
On Tuesday, January 15, 2013 9:54:58 AM UTC-8, RichardC wrote: > > Conciser holding a WeakReference to the Activity from the AsyncTask. I would argue that this is a bad idea. If the AT is holding the reference so that it can report a result, then, if the reference is broken, the task will have spent battery computing a useless result. If you are willing to throw the result away, just cancel the task. G. Blake Meike Marakana Programming Android 2ed is now in stores: http://bit.ly/programmingandroid -- 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
Re: [android-developers] Correct way to implement Activity onDestroy()?
In my scenario, I have a task to run but I do not want it to block my UI thread. Therefore, I adopt AsyncTask. IntentService can run a task at a time on another Thread but I do not know how to cancel it as mentioned earlier. The problem I would like to deal with is that when user press back to destroy the activity, I would like to abort the task and make sure there is no memory leak. It is why I would like to cancel the task. I expect a safe way to abort my task and destory the activity without memory leak. If it can be done, there is no problem that there is nobody to report and the task is running. None of them should be alive when user press back. To let AsyncTask to reference an Activity safely, it seems performing clean-up in onPause() is the last chance to be safe. However, it is a little early in life cycles. Sometimes, the task should be abort only if the activity is destoryed. I have not tried the FragmentRetainInstance.java in API demos but It seems Fragment is the solution to my problem. Am I right? G. Blake Meike於 2013年1月16日星期三UTC+8上午1時44分04秒寫道： > ... > If the AsyncTask holds a reference to an Activity, you'll leak the > activity. That's true even if the reference is implicit (that is, if the > AsyncTask is an inner class and *not* static). Making sure that the task > has no pointers to the Activity, after onPause, is safe. On the other > hand, it brings up the question of why the Task is still running, if there > is nobody to whom to report a result... > > G. Blake Meike > Marakana > > Programming Android 2ed is now in stores: > http://bit.ly/programmingandroid > > -- 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
Re: [android-developers] Correct way to implement Activity onDestroy()?
If the task is actually cancellable -- that is, if it actually stops when you cancel it -- that should be sufficient. If you implement the AT's onCancelled method, make sure it doesn't use any stale references. G. Blake Meike Marakana Programming Android 2ed is now in stores: http://bit.ly/programmingandroid On Wednesday, January 16, 2013 4:35:53 AM UTC-8, Greenhand wrote: > > In my scenario, I have a task to run but I do not want it to block my UI > thread. Therefore, I adopt AsyncTask. IntentService can run a task at a > time on another Thread but I do not know how to cancel it as mentioned > earlier. > > The problem I would like to deal with is that when user press back to > destroy the activity, I would like to abort the task and make sure there is > no memory leak. It is why I would like to cancel the task. > I expect a safe way to abort my task and destory the activity without > memory leak. If it can be done, there is no problem that there is nobody to > report and the task is running. None of them should be alive when user > press back. To let AsyncTask to reference an Activity safely, it seems > performing clean-up in onPause() is the last chance to be safe. However, it > is a little early in life cycles. Sometimes, the task should be abort only > if the activity is destoryed. > > I have not tried the FragmentRetainInstance.java in API demos but It > seems Fragment is the solution to my problem. Am I right? > > G. Blake Meike於 2013年1月16日星期三UTC+8上午1時44分04秒寫道： > >> ... >> If the AsyncTask holds a reference to an Activity, you'll leak the >> activity. That's true even if the reference is implicit (that is, if the >> AsyncTask is an inner class and *not* static). Making sure that the task >> has no pointers to the Activity, after onPause, is safe. On the other >> hand, it brings up the question of why the Task is still running, if there >> is nobody to whom to report a result... >> >> G. Blake Meike >> Marakana >> >> Programming Android 2ed is now in stores: >> http://bit.ly/programmingandroid >> >> -- 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
