[android-developers] Re: Activity Lifecycle question
Veritatis,
yes, it is working fine :-)
in fact, the only thing i changed was to include (override) the
onBackPressed() method as it was posted.
goBack() also remains as it was posted, calling finish() at the end,
after calling setResult(RESULT_OK, rit).
methods onPause, onStop, on destroy are not calling goBack anymore.
another solution that i tested (... bad idea ...) succesfullly, was to
eliminate any action once pressed the back button, which can be done
by just calling return in the onBackPressed() method.
if any one needs, i can post more detail of the source code.
thanks again, for all of you guys ...
On Aug 14, 12:29 am, Indicator Veritatis mej1...@yahoo.com wrote:
Test thoroughly before you say it works. I have to say this because
1) the solution you describe still has a bad feel to it and 2) you
TALK about calling finish(), but you don't show it in this latest
post. Are you calling it from goBack()? As the last thing it does?
On Aug 13, 8:21 pm, hectordu...@yahoo.com hectordu...@yahoo.com
wrote:
thank you guys,
finally it works by overriding the back button, calling goBack() and
also calling finish().
@Override
public void onBackPressed() {
goBack();
//return;
}//onBackPressed
hector
On Aug 13, 12:00 pm, TreKing treking...@gmail.com wrote:
On Sat, Aug 13, 2011 at 11:22 AM, hectordu...@yahoo.com
hectordu...@yahoo.com wrote:
i am trying to also do it form onPause(), onStop() , onDestroy . :-
Well there's your problem.
I don't know what will actually happen with you doing this, but that seems
wrong. Those methods are already called when the user has backed out, so
calling goBack() (and thus finish()) in them seem like it should be
blowing
your stack or ripping the time-space continuum.
Don't call goBack() in those functions. If you need to set some result
Intent data, do that, but don't call finish().
OR, override the back key (see the Android blog for info on this) to stop
the current automatic finish(), then call your goBack() method.
-
TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago
transit tracking app for Android-powered devices
--
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
[android-developers] Re: Activity Lifecycle question
i callled goBack() with sucess from a button:
mButton_thisSpinValue.setOnLongClickListener(new
View.OnLongClickListener() {
public boolean onLongClick(View v) {
Toast.makeText(HDART10Activity.this, GO BACK
...,
Toast.LENGTH_SHORT).show();
goBack();
return true;
}//onLongClick
}); //clickListener
i am trying to also do it form onPause(), onStop() , onDestroy . :-
(
@Override
public void onStop() {
super.onStop();
goBack();
}//onStop
thanks for help ..
On Aug 12, 11:05 pm, TreKing treking...@gmail.com wrote:
On Fri, Aug 12, 2011 at 5:36 PM, hectordu...@yahoo.com
hectordu...@yahoo.com wrote:
i wonder if somebody has an idea to deal with this issue; i tried to catch
the RESULT_CANCELED but nothing happens, the activity 1 is as follows:
How and where are you calling your goBack() method?
-
TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago
transit tracking app for Android-powered devices
--
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] Re: Activity Lifecycle question
On Sat, Aug 13, 2011 at 11:22 AM, hectordu...@yahoo.com hectordu...@yahoo.com wrote: i am trying to also do it form onPause(), onStop() , onDestroy . :- Well there's your problem. I don't know what will actually happen with you doing this, but that seems wrong. Those methods are already called when the user has backed out, so calling goBack() (and thus finish()) in them seem like it should be blowing your stack or ripping the time-space continuum. Don't call goBack() in those functions. If you need to set some result Intent data, do that, but don't call finish(). OR, override the back key (see the Android blog for info on this) to stop the current automatic finish(), then call your goBack() method. - TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago transit tracking app for Android-powered devices -- 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
[android-developers] Re: Activity Lifecycle question
thank you guys,
finally it works by overriding the back button, calling goBack() and
also calling finish().
@Override
public void onBackPressed() {
goBack();
//return;
}//onBackPressed
hector
On Aug 13, 12:00 pm, TreKing treking...@gmail.com wrote:
On Sat, Aug 13, 2011 at 11:22 AM, hectordu...@yahoo.com
hectordu...@yahoo.com wrote:
i am trying to also do it form onPause(), onStop() , onDestroy . :-
Well there's your problem.
I don't know what will actually happen with you doing this, but that seems
wrong. Those methods are already called when the user has backed out, so
calling goBack() (and thus finish()) in them seem like it should be blowing
your stack or ripping the time-space continuum.
Don't call goBack() in those functions. If you need to set some result
Intent data, do that, but don't call finish().
OR, override the back key (see the Android blog for info on this) to stop
the current automatic finish(), then call your goBack() method.
-
TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago
transit tracking app for Android-powered devices
--
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
[android-developers] Re: Activity Lifecycle question
Test thoroughly before you say it works. I have to say this because
1) the solution you describe still has a bad feel to it and 2) you
TALK about calling finish(), but you don't show it in this latest
post. Are you calling it from goBack()? As the last thing it does?
On Aug 13, 8:21 pm, hectordu...@yahoo.com hectordu...@yahoo.com
wrote:
thank you guys,
finally it works by overriding the back button, calling goBack() and
also calling finish().
@Override
public void onBackPressed() {
goBack();
//return;
}//onBackPressed
hector
On Aug 13, 12:00 pm, TreKing treking...@gmail.com wrote:
On Sat, Aug 13, 2011 at 11:22 AM, hectordu...@yahoo.com
hectordu...@yahoo.com wrote:
i am trying to also do it form onPause(), onStop() , onDestroy . :-
Well there's your problem.
I don't know what will actually happen with you doing this, but that seems
wrong. Those methods are already called when the user has backed out, so
calling goBack() (and thus finish()) in them seem like it should be blowing
your stack or ripping the time-space continuum.
Don't call goBack() in those functions. If you need to set some result
Intent data, do that, but don't call finish().
OR, override the back key (see the Android blog for info on this) to stop
the current automatic finish(), then call your goBack() method.
-
TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago
transit tracking app for Android-powered devices
--
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
[android-developers] Re: Activity Lifecycle question
have Activity 1 use
startActivityForResult() to start up Activity 2, with Activity 2
sending the result back via setResult(), followed by finish().
ok, thats exactly what the activities do; but the result back doesnt
work when the hardware keyboarb (back) is used.
What actvity 2 does is:
public void goBack(){
rit = new Intent();
rit.putExtra(updatedYellowR, yellowR);
rit.putExtra(updatedBlueR, blueR);
rit.putExtra(updatedRedR, redR);
setResult(RESULT_OK, rit);
finish();
}//goBack
yelllowR, blueR and redR are instances of the same class ...
objects
On Aug 12, 12:05 pm, Mark Murphy mmur...@commonsware.com wrote:
On Fri, Aug 12, 2011 at 1:02 PM, hectordu...@yahoo.com
hectordu...@yahoo.com wrote:
Hi guys,
My app has two activities with a parcelable object going forward and
back between them, which works fine. The problem comes when user goes
back (from activity 2 to main activity) by using the hardware
keyboard. In that moment the method onStop suppose to be called and
the activity must launch an intent in order to save results into the
main activity, which doens not work :-(
I wonder what i am doing wrong? ...
Activity 2 should not launch an intent in order to save results into
the main activity.
If Activity 2 feels a bit like a dialog box (e.g., Please pick
something out of this list), have Activity 1 use
startActivityForResult() to start up Activity 2, with Activity 2
sending the result back via setResult(), followed by finish().
If Activity 2 is just some other activity (e.g., Please edit the
thing you picked in Activity 1), then Activity 1 and Activity 2
should be sharing a real data model (database, content provider,
etc.).
--
Mark Murphy (a Commons
Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy
Android Training...At Your Office:http://commonsware.com/training
--
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] Re: Activity Lifecycle question
On Fri, Aug 12, 2011 at 1:16 PM, hectordu...@yahoo.com hectordu...@yahoo.com wrote: have Activity 1 use startActivityForResult() to start up Activity 2, with Activity 2 sending the result back via setResult(), followed by finish(). ok, thats exactly what the activities do; but the result back doesnt work when the hardware keyboarb (back) is used. It's not supposed to. If they press BACK, that means they are not choosing something. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Android Training...At Your Office: http://commonsware.com/training -- 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
[android-developers] Re: Activity Lifecycle question
:-( so, if the user press back, the method setResult(RESULT_OK, rit), called from onStop() ... does not work? On Aug 12, 12:35 pm, Mark Murphy mmur...@commonsware.com wrote: On Fri, Aug 12, 2011 at 1:16 PM, hectordu...@yahoo.com hectordu...@yahoo.com wrote: have Activity 1 use startActivityForResult() to start up Activity 2, with Activity 2 sending the result back via setResult(), followed by finish(). ok, thats exactly what the activities do; but the result back doesnt work when the hardware keyboarb (back) is used. It's not supposed to. If they press BACK, that means they are not choosing something. -- Mark Murphy (a Commons Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy Android Training...At Your Office:http://commonsware.com/training -- 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] Re: Activity Lifecycle question
Try calling setResult from onPause - I believe onStop is too late, due to how Start/Stop/Pause/Resume are intermingled. 2011/8/12 hectordu...@yahoo.com hectordu...@yahoo.com: :-( so, if the user press back, the method setResult(RESULT_OK, rit), called from onStop() ... does not work? On Aug 12, 12:35 pm, Mark Murphy mmur...@commonsware.com wrote: On Fri, Aug 12, 2011 at 1:16 PM, hectordu...@yahoo.com hectordu...@yahoo.com wrote: have Activity 1 use startActivityForResult() to start up Activity 2, with Activity 2 sending the result back via setResult(), followed by finish(). ok, thats exactly what the activities do; but the result back doesnt work when the hardware keyboarb (back) is used. It's not supposed to. If they press BACK, that means they are not choosing something. -- Mark Murphy (a Commons Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy Android Training...At Your Office:http://commonsware.com/training -- 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] Re: Activity Lifecycle question
On Fri, Aug 12, 2011 at 2:12 PM, hectordu...@yahoo.com hectordu...@yahoo.com wrote: so, if the user press back, the method setResult(RESULT_OK, rit), called from onStop() ... does not work? Yes it does. More than likely you are handling onActivityResult incorrectly. Are you specifically checking for RESULT_OK? If so, then that's your problem. On back press, you will get RESULT_CANCELED instead. - TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago transit tracking app for Android-powered devices -- 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] Re: Activity Lifecycle question
On Fri, Aug 12, 2011 at 3:17 PM, Kostya Vasilyev kmans...@gmail.com wrote: Try calling setResult from onPause - I believe onStop is too late, due to how Start/Stop/Pause/Resume are intermingled. Last I checked, even onPause() is too late. Hector: The idea is that you call setResult() when the user makes a choice (e.g., from onListItemClick() of a ListActivity). The BACK button is effectively like hitting Esc on a desktop dialog box, indicating that you didn't really want to make that choice in the first place. As TreKing notes in his reply he sent while I was typing this, onActivityResult() is called with RESULT_CANCELED, so you can detect this case. Any activity started via startActivityForResult() must be designed to allow users to say sorry, never mind. In fact, pretty much everything in Android needs to support sorry, never mind. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Android Training...At Your Office: http://commonsware.com/training -- 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
[android-developers] Re: Activity Lifecycle question
thank you guys for comments,
i wonder if somebody has an idea to deal with this issue; i tried to
catch the RESULT_CANCELED but nothing happens,
the activity 1 is as follows:
public void onActivityResult(int requestCode, int resultCode, Intent
rit) {
super.onActivityResult(requestCode, resultCode, rit);
if (resultCode == RESULT_OK) {
yellowRoullete = (Roullete)
rit.getParcelableExtra(updatedYellowRoullete);
blueRoullete = (Roullete)
rit.getParcelableExtra(updatedBlueRoullete);
redRoullete = (Roullete)
rit.getParcelableExtra(updatedRedRoullete);
}else if (resultCode == RESULT_CANCELED) {
redButton.setText(hDART CANCELLED ...);
Log.d(hDART, CANCELLLED);
}else {
redButton.setText(INTERACTION ERROR ...);
Log.d(INTERACTION, ERROR);
}//if
}
after the user press back (in activity 2), application goes back to
activity 1 but result is lost ... same an ESC :-(
... yes, onResume() is also too late ...
thanks for help...
On Aug 12, 2:21 pm, Mark Murphy mmur...@commonsware.com wrote:
On Fri, Aug 12, 2011 at 3:17 PM, Kostya Vasilyev kmans...@gmail.com wrote:
Try calling setResult from onPause - I believe onStop is too late, due
to how Start/Stop/Pause/Resume are intermingled.
Last I checked, even onPause() is too late.
Hector:
The idea is that you call setResult() when the user makes a choice
(e.g., from onListItemClick() of a ListActivity). The BACK button is
effectively like hitting Esc on a desktop dialog box, indicating
that you didn't really want to make that choice in the first place. As
TreKing notes in his reply he sent while I was typing this,
onActivityResult() is called with RESULT_CANCELED, so you can detect
this case.
Any activity started via startActivityForResult() must be designed to
allow users to say sorry, never mind. In fact, pretty much
everything in Android needs to support sorry, never mind.
--
Mark Murphy (a Commons
Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy
Android Training...At Your Office:http://commonsware.com/training
--
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
[android-developers] Re: Activity Lifecycle question
Two questions: 1) why do you call super.onActivityResult()? The
ApiDemo examples do not. If you must call it, you should call if after
your own processing, since you want to catch the CANCELED first 2)
what code DO you have for handling other result codes? You should have
a default case at least so that you can put breakpoints there.
On Aug 12, 3:36 pm, hectordu...@yahoo.com hectordu...@yahoo.com
wrote:
thank you guys for comments,
i wonder if somebody has an idea to deal with this issue; i tried to
catch the RESULT_CANCELED but nothing happens,
the activity 1 is as follows:
public void onActivityResult(int requestCode, int resultCode, Intent
rit) {
super.onActivityResult(requestCode, resultCode, rit);
if (resultCode == RESULT_OK) {
yellowRoullete = (Roullete)
rit.getParcelableExtra(updatedYellowRoullete);
blueRoullete = (Roullete)
rit.getParcelableExtra(updatedBlueRoullete);
redRoullete = (Roullete)
rit.getParcelableExtra(updatedRedRoullete);
}else if (resultCode == RESULT_CANCELED) {
redButton.setText(hDART CANCELLED ...);
Log.d(hDART, CANCELLLED);
}else {
redButton.setText(INTERACTION ERROR ...);
Log.d(INTERACTION, ERROR);
}//if
}
after the user press back (in activity 2), application goes back to
activity 1 but result is lost ... same an ESC :-(
... yes, onResume() is also too late ...
thanks for help...
On Aug 12, 2:21 pm, Mark Murphy mmur...@commonsware.com wrote:
On Fri, Aug 12, 2011 at 3:17 PM, Kostya Vasilyev kmans...@gmail.com wrote:
Try calling setResult from onPause - I believe onStop is too late, due
to how Start/Stop/Pause/Resume are intermingled.
Last I checked, even onPause() is too late.
Hector:
The idea is that you call setResult() when the user makes a choice
(e.g., from onListItemClick() of a ListActivity). The BACK button is
effectively like hitting Esc on a desktop dialog box, indicating
that you didn't really want to make that choice in the first place. As
TreKing notes in his reply he sent while I was typing this,
onActivityResult() is called with RESULT_CANCELED, so you can detect
this case.
Any activity started via startActivityForResult() must be designed to
allow users to say sorry, never mind. In fact, pretty much
everything in Android needs to support sorry, never mind.
--
Mark Murphy (a Commons
Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy
Android Training...At Your Office:http://commonsware.com/training
--
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
[android-developers] Re: Activity Lifecycle question
1- i saw an example using super.onActivityResult()
using it after the if didnt make any difference!
2-the process code is for RESULT_OK:
yellowRoullete = (Roullete)
rit.getParcelableExtra(updatedYellowRoullete);
blueRoullete = (Roullete)
rit.getParcelableExtra(updatedBlueRoullete);
redRoullete = (Roullete)
rit.getParcelableExtra(updatedRedRoullete);
which means recovering the three instances which were returned from
activity 2.
thanks for comments
On Aug 12, 6:36 pm, Indicator Veritatis mej1...@yahoo.com wrote:
Two questions: 1) why do you call super.onActivityResult()? The
ApiDemo examples do not. If you must call it, you should call if after
your own processing, since you want to catch the CANCELED first 2)
what code DO you have for handling other result codes? You should have
a default case at least so that you can put breakpoints there.
On Aug 12, 3:36 pm, hectordu...@yahoo.com hectordu...@yahoo.com
wrote:
thank you guys for comments,
i wonder if somebody has an idea to deal with this issue; i tried to
catch the RESULT_CANCELED but nothing happens,
the activity 1 is as follows:
public void onActivityResult(int requestCode, int resultCode, Intent
rit) {
super.onActivityResult(requestCode, resultCode, rit);
if (resultCode == RESULT_OK) {
yellowRoullete = (Roullete)
rit.getParcelableExtra(updatedYellowRoullete);
blueRoullete = (Roullete)
rit.getParcelableExtra(updatedBlueRoullete);
redRoullete = (Roullete)
rit.getParcelableExtra(updatedRedRoullete);
}else if (resultCode == RESULT_CANCELED) {
redButton.setText(hDART CANCELLED ...);
Log.d(hDART, CANCELLLED);
}else {
redButton.setText(INTERACTION ERROR ...);
Log.d(INTERACTION, ERROR);
}//if
}
after the user press back (in activity 2), application goes back to
activity 1 but result is lost ... same an ESC :-(
... yes, onResume() is also too late ...
thanks for help...
On Aug 12, 2:21 pm, Mark Murphy mmur...@commonsware.com wrote:
On Fri, Aug 12, 2011 at 3:17 PM, Kostya Vasilyev kmans...@gmail.com
wrote:
Try calling setResult from onPause - I believe onStop is too late, due
to how Start/Stop/Pause/Resume are intermingled.
Last I checked, even onPause() is too late.
Hector:
The idea is that you call setResult() when the user makes a choice
(e.g., from onListItemClick() of a ListActivity). The BACK button is
effectively like hitting Esc on a desktop dialog box, indicating
that you didn't really want to make that choice in the first place. As
TreKing notes in his reply he sent while I was typing this,
onActivityResult() is called with RESULT_CANCELED, so you can detect
this case.
Any activity started via startActivityForResult() must be designed to
allow users to say sorry, never mind. In fact, pretty much
everything in Android needs to support sorry, never mind.
--
Mark Murphy (a Commons
Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy
Android Training...At Your Office:http://commonsware.com/training
--
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] Re: Activity Lifecycle question
On Fri, Aug 12, 2011 at 5:36 PM, hectordu...@yahoo.com hectordu...@yahoo.com wrote: i wonder if somebody has an idea to deal with this issue; i tried to catch the RESULT_CANCELED but nothing happens, the activity 1 is as follows: How and where are you calling your goBack() method? - TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago transit tracking app for Android-powered devices -- 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
[android-developers] Re: Activity lifecycle: invoking finish
If you've noticed, cleaning stuff up let's say clearing a bitmap or nulling an image before you call another activity will result in a temporary blanking out. So onDestroy has to happen after the next activity is fully drawn. If you use 14mb in Activity A and 14mb in Activity B on a 16mb heap device you will run out of memory. I use android:process in the manifest to get around this. On May 11, 11:12 pm, Vikram vikram.bodiche...@gmail.com wrote: This seems to be the order. B.onPause() - A.onStart() - A.onResume() -B.onStop() - B.onDestroy(). which makes sense! On May 12, 10:43 am, Vikram vikram.bodiche...@gmail.com wrote: I have two activities A and B. A is in the stopped mode and B is running. When I invoke finish() on B, A.onStart() and A.onResume() are being invoked before B.onStop() and B.onDestroy(). Is this normal behavior? I find this a little strange! I want to cleanup stuff before I hand over control to B. -- 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
[android-developers] Re: Activity lifecycle: invoking finish
This seems to be the order. B.onPause() - A.onStart() - A.onResume() -B.onStop() - B.onDestroy(). which makes sense! On May 12, 10:43 am, Vikram vikram.bodiche...@gmail.com wrote: I have two activities A and B. A is in the stopped mode and B is running. When I invoke finish() on B, A.onStart() and A.onResume() are being invoked before B.onStop() and B.onDestroy(). Is this normal behavior? I find this a little strange! I want to cleanup stuff before I hand over control to B. -- 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
[android-developers] Re: Activity lifecycle: invoking finish
If I remember correctly you can use onPause() on activity B that will block before any callback occurs on activity A. Beware though, not to do any long running operation in onPause() as it would stall the app. -- 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
[android-developers] Re: Activity Lifecycle Documentation Question
Yes! Having mostly lurked over this list for the last year and half, I see this thread come-up too frequently, and this area caused me a lot of confusion. I don't want to change the thread, but want to emphasize that to make intelligent suggestions, one has to understand the process. These questions actually seem to arise more from people with a lot of experience to other programming environments and lacking in Java depth rather than plain beginners and I think it is because developers are fearful of making assumptions to fill in documentation holes/conflicts because they KNOW that is where things can will break. The whole scenario was even muddier for me because I had constant questions in my mind as to the relationship of things like Java static initializers to these life-cycle Objects (I knew neither the framework (or similar frameworks and was new to Java (still feel like a newbie)) - for instance when the process is killed but the system decides to keep the Activitiy around, does the framework re-do static initialization of the Objects if it re-uses the killed activity? Since the document doesn't say, the developer has to black-box, then if the framework is every changed, unless you programmed defensively (assume statics are not repeated) your application may break. Clearer documentation would help a little (for those that read it :-), saving Dianne, Mark, and all the rest of you very generous contributors (thank you!) time for other replies. I can rock with documentation issues in most areas (I can always go peek at the source), but activity life-cycle is the back-bone of every application design; it deserves to be held to a higher standard, and end-consumer developers need a high degree of confidence that the process is accurately documented without having to look at the source -- to me, the documentation should be a contract between the framework developers and the framework users (programmatically)... thanks for all the replies and the people that are persistent in their pursuit of definitive answers. On Apr 28, 1:50 pm, Indicator Veritatis mej1...@yahoo.com wrote: Eric is not the first to observe that the documentation on these topics is too confusing. But where should he make this 'contribution' you suggest? Is the documentation somewhere under the Android Open Source project athttp://source.android.com/? On Apr 27, 10:23 pm, Dianne Hackborn hack...@android.com wrote: Yes if you call finish() you are saying you want to completely remove the activity from the stack. The system can have the activity destroyed in the same way, but just not remove it from the stack it maintains. At the end of the day, it would be fundamentally broken if there was a way for an activity to stop being used in a process without being destroyed. This means it would be IMPOSSIBLE to write a correctly working application. I agree you can find parts of the documentation to help you convince yourself that there are cases this can happen, if that is what you are looking for. But it won't. Because it would be broken. As I think is already obvious to you, since your original question was basically: if I read the documentation this way then there is nothing useful at all about onDestroy() or onStop() because they won't get called when they need to be. Right. So don't try to read the documentation in a way that makes it broken. You are welcome to contribute changed to the documentation for people to review if there are things you think can be improved. On Thu, Apr 28, 2011 at 12:29 AM, Eric e...@alum.mit.edu wrote: On Apr 28, 12:21 am, Dianne Hackborn hack...@android.com wrote: Asking it to finish means finishing the activity, which means destroying it. Politely asking it to finish isn't going to cause it to just not cleanly exit. It would be fundamentally broken if activities every just stop being used in their process without actually going through the lifecycle. In other words asking to finish - Activity.finish() - does what you expect. Ok, so when I 'finish' an Activity programmatically, never wanting it to show up in the Task stack again, how does the system know to remove my Activity from the back stack in that case, but it doesn't remove it from the stack when the system asks it to finish due to low memory conditions? Also, the documentation for onDestroy() adds to the confusion a bit: Called before the activity is destroyed. This is the final call that the activity will receive. It could be called either because the activity is finishing (someone called finish() on it), or because the system is temporarily destroying this instance of the activity to save space. You can distinguish between these two scenarios with the isFinishing() method. Note that it says if the Activity is being temporarily discarded to save space, then the 'isFinishing' method will return false. If
[android-developers] Re: Activity Lifecycle Documentation Question
Dianne, just a clarification on this thread. In the diagram of the Activity lifecyle at http://developer.android.com/reference/android/app/Activity.html Should the directed edge on the left hand side from #onStop to #onCreate actually be between #onDestroy and #onCreate? And is that behaviour just from 3.0 onwards? If not, what is the behavior for earlier versions of Android. William -- 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
[android-developers] Re: Activity Lifecycle Documentation Question
And more specifically, under what scenarios do I get each of #onPause, #onStop and #onDestroy called. For Activity destruction due to rotation? IN what versions. For Activity destruction due to an explicit Activity#finished? What versions. Process death due to memory restriction? And for what versions. Just trying to best straighten this out in my head. William -- 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] Re: Activity Lifecycle Documentation Question
On Sun, May 1, 2011 at 8:15 AM, William Ferguson william.ferguson.au@ gmail.com wrote: Dianne, just a clarification on this thread. In the diagram of the Activity lifecyle at http://developer.android.com/reference/android/app/Activity.html Should the directed edge on the left hand side from #onStop to #onCreate actually be between #onDestroy and #onCreate? And is that behaviour just from 3.0 onwards? If not, what is the behavior for earlier versions of Android. No that is fine. In Android 3.0, ignore the line from onPause() to onCreate() if you are setting android:targetSdkVersion=11 or greater; that is the change the doc mentions, the system will now try to avoid killing processes that have activities that haven't been stopped. -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- 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] Re: Activity Lifecycle Documentation Question
On Sun, May 1, 2011 at 8:19 AM, William Ferguson william.ferguson.au@ gmail.com wrote: And more specifically, under what scenarios do I get each of #onPause, #onStop and #onDestroy called. For Activity destruction due to rotation? IN what versions. For Activity destruction due to an explicit Activity#finished? What versions. Process death due to memory restriction? And for what versions. Just trying to best straighten this out in my head. It really is not very complicated. The series of calls are: onCreate() - onStart() - onResume() - onPause() - onStop() - onDestroy(). That is the order. Period. That is the core activity lifecycle. There are of course cycles between these: if your activity is resumed and another activity comes on top, it will be paused. If it then comes back on top, it is resumed. Likewise, it can be paused and then stopped, and later started and resumed. These are all just moving you between the states the activity can be in: on the top of the stack, not on the top, no longer visible. There is nothing special about rotation. The current activity needs to be destroyed, so it does the lifecycle callbacks to do that. A new one is created so it does the lifecycle callbacks. There is nothing special about being finished. The current activity needs to be destroyed, so it goes through the lifecycle callbacks. The *only* thing at all unusual about what Android does is its ability to kill processes. This also is very simple though: Android will call the activity's onSaveInstanceState() to save away the current state of the activity. By doing that, it is possible for it to kill the activity's process at any time and be able to later re-create a new activity instance from that last saved state. So once it has saved your state, your process can be killed. It sometimes seems people try to think too hard about this and make it something more complicated than it is. The callbacks tell you the states the activity goes in. It should be pretty easy to determine what makes sense to do in each callback, since they are pretty simple well-defined states. If you do that, you will be fine. There is certainly the interesting case of the process being killed. However the *only* thing that should matter about this for an application is to be sure to implement onSaveInstanceState() to save and restore the current state correctly, and to save any data to persistent storage that is needed prior to going into the killable state. (Which is after onPause() pre-3.0 and after onStop() if you target 3.0 or later.) If you were to compare this to something like MIDP: http://java.sun.com/javame/reference/apis/jsr118/javax/microedition/midlet/MIDlet.html Android's activities are actually very similar; we have one additional state because we distinguish between the UI being visible vs. not visible at all. -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- 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
[android-developers] Re: Activity Lifecycle Documentation Question
Eric is not the first to observe that the documentation on these topics is too confusing. But where should he make this 'contribution' you suggest? Is the documentation somewhere under the Android Open Source project at http://source.android.com/? On Apr 27, 10:23 pm, Dianne Hackborn hack...@android.com wrote: Yes if you call finish() you are saying you want to completely remove the activity from the stack. The system can have the activity destroyed in the same way, but just not remove it from the stack it maintains. At the end of the day, it would be fundamentally broken if there was a way for an activity to stop being used in a process without being destroyed. This means it would be IMPOSSIBLE to write a correctly working application. I agree you can find parts of the documentation to help you convince yourself that there are cases this can happen, if that is what you are looking for. But it won't. Because it would be broken. As I think is already obvious to you, since your original question was basically: if I read the documentation this way then there is nothing useful at all about onDestroy() or onStop() because they won't get called when they need to be. Right. So don't try to read the documentation in a way that makes it broken. You are welcome to contribute changed to the documentation for people to review if there are things you think can be improved. On Thu, Apr 28, 2011 at 12:29 AM, Eric e...@alum.mit.edu wrote: On Apr 28, 12:21 am, Dianne Hackborn hack...@android.com wrote: Asking it to finish means finishing the activity, which means destroying it. Politely asking it to finish isn't going to cause it to just not cleanly exit. It would be fundamentally broken if activities every just stop being used in their process without actually going through the lifecycle. In other words asking to finish - Activity.finish() - does what you expect. Ok, so when I 'finish' an Activity programmatically, never wanting it to show up in the Task stack again, how does the system know to remove my Activity from the back stack in that case, but it doesn't remove it from the stack when the system asks it to finish due to low memory conditions? Also, the documentation for onDestroy() adds to the confusion a bit: Called before the activity is destroyed. This is the final call that the activity will receive. It could be called either because the activity is finishing (someone called finish() on it), or because the system is temporarily destroying this instance of the activity to save space. You can distinguish between these two scenarios with the isFinishing() method. Note that it says if the Activity is being temporarily discarded to save space, then the 'isFinishing' method will return false. If Android is simply calling 'finish' to temporarily discard the Activity, as you state, then is it explicitly setting 'isFinishing()' flag back to false (assuming the call to finish() automatically sets it to true; because if it didn't, then when I programmatically call 'finish()' to permanently finish the Activity, the flag would probably never get set)? - Eric -- 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 -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- 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
[android-developers] Re: Activity Lifecycle Documentation Question
Eric is not over-thinking. Rather, he is showing a mindset towards software quality that has become all too rare these days. That mindset is: if the documentation says one thing, but the software does another, then it is a bug. Now I know that in today's FOSS atmosphere, that sounds quaint, even unsustainable out-dated, but I had an interesting conversation with one of the guys involved wtih Sun Java from the very early days: he made it clear that one of the key ingredients for Java's success was that they hired boatloads of inexpensive Russian programmers to take EXACTLY that attitude to JVM submissions. They went over the submitted JVM and the language specification with a great many finely toothed combs to make sure that even the least deviation would cause the JVM to fail. The result was that the first generations of JVMs really did go a long way to fulfilling the promise of write once, run anywhere. It was the KVMs for J2ME that failed to meet this goal, and failed badly, resulting in 'fragmentation' that was much, much worse than any fragmentation we see in Android today. On Apr 27, 3:08 pm, TreKing treking...@gmail.com wrote: On Wed, Apr 27, 2011 at 4:55 PM, Eric e...@alum.mit.edu wrote: It means the activity can be destroyed after onPause() by the system calling 'finish()' on it. calling finish() will result in onStop() - onDestory() when in the paused stated. It seems to me, in that specific case, if you've started another activity from the current activity, and right after your onPause() was called, Android decides 'finish' your activity due to memory constraints, I don't see anything in the documentation that says Android can't 'finish' your activity right there on the stop, thereby bypassing the call to onStop(), and going directly into onDestroy(). Where does it say the system bypasses onStop() and goes directly to onDestroy()? In this case, the process would still be running, your activity would be paused, archived, and 'destroyed', but never 'stopped'. No. The flow is pause - stop - destroy. There is no random skipping about. You say 'onStop()' will _definitely_ be called. I don't see that in the documentation I read. Look at the pretty graph - it pretty clearly indicates the only way to onDestroy() is from onStop(). Honestly, I think you're over-thinking this and confusing yourself. - TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago transit tracking app for Android-powered devices -- 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] Re: Activity Lifecycle Documentation Question
All of the documentation comes from the source code. The documentation in the Activity class comes from Activity.java in the source code. I don't need a lecture about the importance of documentation and the history of Java fragmentation. I am well aware of these things. You are also over-simplifying things -- outstanding documentation for the entire Java platform would not have helped the situation much, since the higher you go up in the stack the more complicated the overall behavior becomes (as each piece relies on the behavior of the parts below it). That is why we say that Android is not a specification, but an implementation. The big point where Java (especially MIDP) compatibility broke down is where multiple entities were doing their own completely independent implementations. On Thu, Apr 28, 2011 at 2:00 PM, Indicator Veritatis mej1...@yahoo.comwrote: Eric is not over-thinking. Rather, he is showing a mindset towards software quality that has become all too rare these days. That mindset is: if the documentation says one thing, but the software does another, then it is a bug. Now I know that in today's FOSS atmosphere, that sounds quaint, even unsustainable out-dated, but I had an interesting conversation with one of the guys involved wtih Sun Java from the very early days: he made it clear that one of the key ingredients for Java's success was that they hired boatloads of inexpensive Russian programmers to take EXACTLY that attitude to JVM submissions. They went over the submitted JVM and the language specification with a great many finely toothed combs to make sure that even the least deviation would cause the JVM to fail. The result was that the first generations of JVMs really did go a long way to fulfilling the promise of write once, run anywhere. It was the KVMs for J2ME that failed to meet this goal, and failed badly, resulting in 'fragmentation' that was much, much worse than any fragmentation we see in Android today. On Apr 27, 3:08 pm, TreKing treking...@gmail.com wrote: On Wed, Apr 27, 2011 at 4:55 PM, Eric e...@alum.mit.edu wrote: It means the activity can be destroyed after onPause() by the system calling 'finish()' on it. calling finish() will result in onStop() - onDestory() when in the paused stated. It seems to me, in that specific case, if you've started another activity from the current activity, and right after your onPause() was called, Android decides 'finish' your activity due to memory constraints, I don't see anything in the documentation that says Android can't 'finish' your activity right there on the stop, thereby bypassing the call to onStop(), and going directly into onDestroy(). Where does it say the system bypasses onStop() and goes directly to onDestroy()? In this case, the process would still be running, your activity would be paused, archived, and 'destroyed', but never 'stopped'. No. The flow is pause - stop - destroy. There is no random skipping about. You say 'onStop()' will _definitely_ be called. I don't see that in the documentation I read. Look at the pretty graph - it pretty clearly indicates the only way to onDestroy() is from onStop(). Honestly, I think you're over-thinking this and confusing yourself. - TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago transit tracking app for Android-powered devices -- 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 -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- 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
[android-developers] Re: Activity Lifecycle Documentation Question
Actually, I think you do need the 'lecture' because you got the facts wrong. Multiple independent groups were developing JVMs, too. Remember IBM? Sun, Microsoft, IBM and BEA all developed their own JVMs. Yet their multiple independence did not have the same effect on the JVM that you attribute to it in the MIDP case. Why not? The persnickety attitude enforcing strict matching of code and specification was one of the reasons, not the only one. And BTW, saying that Android is not a specification, but an implementation is an obvious cop-out. Can we bring the thread back on topic now? On Apr 28, 12:07 pm, Dianne Hackborn hack...@android.com wrote: All of the documentation comes from the source code. The documentation in the Activity class comes from Activity.java in the source code. I don't need a lecture about the importance of documentation and the history of Java fragmentation. I am well aware of these things. You are also over-simplifying things -- outstanding documentation for the entire Java platform would not have helped the situation much, since the higher you go up in the stack the more complicated the overall behavior becomes (as each piece relies on the behavior of the parts below it). That is why we say that Android is not a specification, but an implementation. The big point where Java (especially MIDP) compatibility broke down is where multiple entities were doing their own completely independent implementations. On Thu, Apr 28, 2011 at 2:00 PM, Indicator Veritatis mej1...@yahoo.comwrote: Eric is not over-thinking. Rather, he is showing a mindset towards software quality that has become all too rare these days. That mindset is: if the documentation says one thing, but the software does another, then it is a bug. Now I know that in today's FOSS atmosphere, that sounds quaint, even unsustainable out-dated, but I had an interesting conversation with one of the guys involved wtih Sun Java from the very early days: he made it clear that one of the key ingredients for Java's success was that they hired boatloads of inexpensive Russian programmers to take EXACTLY that attitude to JVM submissions. They went over the submitted JVM and the language specification with a great many finely toothed combs to make sure that even the least deviation would cause the JVM to fail. The result was that the first generations of JVMs really did go a long way to fulfilling the promise of write once, run anywhere. It was the KVMs for J2ME that failed to meet this goal, and failed badly, resulting in 'fragmentation' that was much, much worse than any fragmentation we see in Android today. On Apr 27, 3:08 pm, TreKing treking...@gmail.com wrote: On Wed, Apr 27, 2011 at 4:55 PM, Eric e...@alum.mit.edu wrote: It means the activity can be destroyed after onPause() by the system calling 'finish()' on it. calling finish() will result in onStop() - onDestory() when in the paused stated. It seems to me, in that specific case, if you've started another activity from the current activity, and right after your onPause() was called, Android decides 'finish' your activity due to memory constraints, I don't see anything in the documentation that says Android can't 'finish' your activity right there on the stop, thereby bypassing the call to onStop(), and going directly into onDestroy(). Where does it say the system bypasses onStop() and goes directly to onDestroy()? In this case, the process would still be running, your activity would be paused, archived, and 'destroyed', but never 'stopped'. No. The flow is pause - stop - destroy. There is no random skipping about. You say 'onStop()' will _definitely_ be called. I don't see that in the documentation I read. Look at the pretty graph - it pretty clearly indicates the only way to onDestroy() is from onStop(). Honestly, I think you're over-thinking this and confusing yourself. - TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago transit tracking app for Android-powered devices -- 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 -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed
Re: [android-developers] Re: Activity Lifecycle Documentation Question
On Thu, Apr 28, 2011 at 9:37 PM, Indicator Veritatis mej1...@yahoo.comwrote: Actually, I think you do need the 'lecture' because you got the facts wrong. Multiple independent groups were developing JVMs, too. Remember IBM? Sun, Microsoft, IBM and BEA all developed their own JVMs. Yet their multiple independence did not have the same effect on the JVM that you attribute to it in the MIDP case. Why not? The persnickety attitude enforcing strict matching of code and specification was one of the reasons, not the only one. Try writing a specification for a complete platform/OS that allows multiple entities to implement them independently and end up with compatible results. It's not going to happen. And BTW, saying that Android is not a specification, but an implementation is an obvious cop-out. No, it is a fundamental decision we made early in the design of Android. Can we bring the thread back on topic now? Hi, you were the one who went off in this direction. Good lord. -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- 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
[android-developers] Re: Activity Lifecycle Documentation Question
* onDestroy() is not guaranteed to be called, so if you create a Thread in onCreate(), the thread may never be stopped. * When the process hosting your activity is killed, the onDestroy won't be called... makes sense.. your process just died. The process is force-killed (I think): any thread that may be running, daemon or not, will die with its process. The same goes for onStop. The onStop isn't called when the process hosting your app is killed. Take a look at the diagram in the Implementing the lifecycle callbacks section of the link you provided. You'll see that after onPause and onStop the process can be killed. Any open resources (threads, cursors, etc) will die with the process when it's killed. In other words: Your process won't be killed until all its activities are at least paused (after their onPause have been called). To allow you to clean up unnecessary resources at appropriate times,* while your process keeps running in the background*, you can implement onStop, onDestroy and such. -- 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
[android-developers] Re: Activity Lifecycle Documentation Question
I would tend to disagree with the above two explanations. Let's say you implement onStop() to stop/kill the thread you created in onStart(). You then navigate to a new activity by starting it. Your activity gets paused. Android can 'finish' your activity at this point, WITHOUT killing the process. There is nothing in the documentation that says the process HAS to be killed if your activity is finished prematurely due to memory. Android could reclaim the memory by simply disposing of your paused Activity before showing the next activity that you just started, without killing the process. In that case, the thread you started in onStart will still be running. I think it makes much more sense for the documentation to clarify this, and recommend that people do all auxiliary setup/cleanup in onResume/onPause, and nowhere else. -- 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] Re: Activity Lifecycle Documentation Question
On Wed, Apr 27, 2011 at 3:22 PM, Eric e...@alum.mit.edu wrote: Let's say you implement onStop() to stop/kill the thread you created in onStart(). You then navigate to a new activity by starting it. Your activity gets paused. It will also get stopped, as it's no longer visible, and onStop() will get called. The best thing to do is implement all the life cycle methods with a debug line and run through the scenarios to see when and if each function gets called. - TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago transit tracking app for Android-powered devices -- 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] Re: Activity Lifecycle Documentation Question
On Wed, Apr 27, 2011 at 4:22 PM, Eric e...@alum.mit.edu wrote: You then navigate to a new activity by starting it. Which triggers onPause() and onStop() on the original activity. Your activity gets paused. Android can 'finish' your activity at this point, WITHOUT killing the process. Which triggers onDestroy() on the original activity. In that case, the thread you started in onStart will still be running. Only if developer did not stop the thread in onPause(), onStop(), or onDestroy(). I think it makes much more sense for the documentation to clarify this, and recommend that people do all auxiliary setup/cleanup in onResume/onPause, and nowhere else. You are welcome to think what you want. And, as I noted, it's not a bad idea to tend towards onPause() and onStop(). However, there is nothing directly wrong with waiting until onDestroy() to shut down a background thread, and there may be perfectly valid reasons for keeping that thread around as long as possible (e.g., chat client maintaining a socket connection to a chat server). -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy _Android Programming Tutorials_ Version 3.3 Available! -- 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
[android-developers] Re: Activity Lifecycle Documentation Question
The text and the diagram of the link you showed are indeed not saying the same: - The diagram only shows a direct path out of onPause or onStop only when the process is being killed. - The text says that the framework can just call 'finish' on the activity (without going through onDestroy). I must say that i *never *have seen this happen. The only time that onDestroy/onStop is not called at some point in time is when the process is being killed. -- 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] Re: Activity Lifecycle Documentation Question
Be very careful with cleaning up some resources in onPause. A dialog being shown could put your activity into paused-state, but not into stopped-state. This happens when a system dialog pops up (e.g. an activity chooser) and your activity is still visible in the background (blurred, but still visible). You may not want to clean up certain resources while your activity is paused but still visible. -- 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] Re: Activity Lifecycle Documentation Question
On Wed, Apr 27, 2011 at 4:53 PM, Streets Of Boston flyingdutc...@gmail.com wrote: Be very careful with cleaning up some resources in onPause. A dialog being shown could put your activity into paused-state, but not into stopped-state. This happens when a system dialog pops up (e.g. an activity chooser) and your activity is still visible in the background (blurred, but still visible). You may not want to clean up certain resources while your activity is paused but still visible. Technically, these are dialog-themed activities, which is why onPause() is called. onStop() is not called because the underlying activity is still visible. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy _Android Programming Tutorials_ Version 3.3 Available! -- 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
[android-developers] Re: Activity Lifecycle Documentation Question
On Apr 27, 4:45 pm, Mark Murphy mmur...@commonsware.com wrote: On Wed, Apr 27, 2011 at 4:22 PM, Eric e...@alum.mit.edu wrote: You then navigate to a new activity by starting it. Which triggers onPause() and onStop() on the original activity. This is where I disagree with you. Android is allowed to 'clean up' your activity right after onPause(), without killing the app, if it wants to reclaim memory. The Activity lifecycle documentation says the Activity is 'killable' after onPause(), which technically doesn't mean the process must be 'killed'. It means the activity can be destroyed after onPause() by the system calling 'finish()' on it. It seems to me, in that specific case, if you've started another activity from the current activity, and right after your onPause() was called, Android decides 'finish' your activity due to memory constraints, I don't see anything in the documentation that says Android can't 'finish' your activity right there on the stop, thereby bypassing the call to onStop(), and going directly into onDestroy(). In this case, the process would still be running, your activity would be paused, archived, and 'destroyed', but never 'stopped'. You say 'onStop()' will _definitely_ be called. I don't see that in the documentation I read. -- 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
[android-developers] Re: Activity Lifecycle Documentation Question
From the Activity documentation: http://developer.android.com/guide/topics/fundamentals/activities.html If an activity is **paused or stopped**, the system can drop it from memory either by asking it to finish (calling its finish() method), or simply killing its process. When the activity is opened again (after being finished or killed), it must be created all over. On Apr 27, 5:55 pm, Eric e...@alum.mit.edu wrote: On Apr 27, 4:45 pm, Mark Murphy mmur...@commonsware.com wrote: On Wed, Apr 27, 2011 at 4:22 PM, Eric e...@alum.mit.edu wrote: You then navigate to a new activity by starting it. Which triggers onPause() and onStop() on the original activity. This is where I disagree with you. Android is allowed to 'clean up' your activity right after onPause(), without killing the app, if it wants to reclaim memory. The Activity lifecycle documentation says the Activity is 'killable' after onPause(), which technically doesn't mean the process must be 'killed'. It means the activity can be destroyed after onPause() by the system calling 'finish()' on it. It seems to me, in that specific case, if you've started another activity from the current activity, and right after your onPause() was called, Android decides 'finish' your activity due to memory constraints, I don't see anything in the documentation that says Android can't 'finish' your activity right there on the stop, thereby bypassing the call to onStop(), and going directly into onDestroy(). In this case, the process would still be running, your activity would be paused, archived, and 'destroyed', but never 'stopped'. You say 'onStop()' will _definitely_ be called. I don't see that in the documentation I read. -- 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] Re: Activity Lifecycle Documentation Question
On Wed, Apr 27, 2011 at 6:04 PM, Eric e...@alum.mit.edu wrote: From the Activity documentation: http://developer.android.com/guide/topics/fundamentals/activities.html If an activity is **paused or stopped**, the system can drop it from memory either by asking it to finish (calling its finish() method), or simply killing its process. When the activity is opened again (after being finished or killed), it must be created all over. An activity in the paused state, when finished, goes through onStop() and onDestroy(). -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy _Android Programming Tutorials_ Version 3.3 Available! -- 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
[android-developers] Re: Activity Lifecycle Documentation Question
The text of the documentation says you're right. A call to 'finish()' is all that could happen to 'destroy' the activity. No killing of the process is necessary. However, the image in the documentation ( http://developer.android.com/images/activity_lifecycle.png inside http://developer.android.com/guide/topics/fundamentals/activities.html) states that the 'process is killed' when it skips the onStop or onDestroy. In my experience, the image is correct, the text is not correct. I have not seen any Activity in my apps whose onStop/onDestroy is not called without it being killed through a kill of the process. But i could be wrong... http://developer.android.com/images/activity_lifecycle.png -- 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] Re: Activity Lifecycle Documentation Question
On Wed, Apr 27, 2011 at 4:55 PM, Eric e...@alum.mit.edu wrote: It means the activity can be destroyed after onPause() by the system calling 'finish()' on it. calling finish() will result in onStop() - onDestory() when in the paused stated. It seems to me, in that specific case, if you've started another activity from the current activity, and right after your onPause() was called, Android decides 'finish' your activity due to memory constraints, I don't see anything in the documentation that says Android can't 'finish' your activity right there on the stop, thereby bypassing the call to onStop(), and going directly into onDestroy(). Where does it say the system bypasses onStop() and goes directly to onDestroy()? In this case, the process would still be running, your activity would be paused, archived, and 'destroyed', but never 'stopped'. No. The flow is pause - stop - destroy. There is no random skipping about. You say 'onStop()' will _definitely_ be called. I don't see that in the documentation I read. Look at the pretty graph - it pretty clearly indicates the only way to onDestroy() is from onStop(). Honestly, I think you're over-thinking this and confusing yourself. - TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago transit tracking app for Android-powered devices -- 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] Re: Activity Lifecycle Documentation Question
On Wed, Apr 27, 2011 at 5:55 PM, Eric e...@alum.mit.edu wrote: Android is allowed to 'clean up' your activity right after onPause(), without killing the app, if it wants to reclaim memory. By finishing the activity, thereby triggering the onPause()/onStop()/onDestroy() triad. If the activity is paused, finishing it will merely do onStop() and onDestroy(). I don't see that in the documentation I read. Documentation has gaps. If you can create a sample application that demonstrates that you're correct, please post it. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy _Android Programming Tutorials_ Version 3.3 Available! -- 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] Re: Activity Lifecycle Documentation Question
Hopefully I can clearly confirm what is actually happening. There are only two ways your entire activity instance can go away: 1. At some point the activity lifecycle completing and onDestroy() being called. 2. The process being killed. Thus you will not have a resource leak if you release the resources in onStop() or onDestroy(). Generally you pair onCreate() with onDestroy(), onStart() with onStop(), and onResume() with onPause(). You can however do variations if you are careful such as allocating in onStart() (if not already allocated) and releasing in onDestroy(). Also it may be worth mentioning -- there was a significant change to the activity lifecycle in 3.0 where onStop() is now guaranteed to be killed (prior to killing a process) like onPause() has always been. In fact if you are targeting API 11 or greater, you will find onSaveInstanceState() now being called between onPause() and onStop(). On Wed, Apr 27, 2011 at 6:14 PM, Mark Murphy mmur...@commonsware.comwrote: On Wed, Apr 27, 2011 at 5:55 PM, Eric e...@alum.mit.edu wrote: Android is allowed to 'clean up' your activity right after onPause(), without killing the app, if it wants to reclaim memory. By finishing the activity, thereby triggering the onPause()/onStop()/onDestroy() triad. If the activity is paused, finishing it will merely do onStop() and onDestroy(). I don't see that in the documentation I read. Documentation has gaps. If you can create a sample application that demonstrates that you're correct, please post it. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy _Android Programming Tutorials_ Version 3.3 Available! -- 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 -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- 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] Re: Activity Lifecycle Documentation Question
On Wed, Apr 27, 2011 at 6:44 PM, Dianne Hackborn hack...@android.com wrote: Also it may be worth mentioning -- there was a significant change to the activity lifecycle in 3.0 where onStop() is now guaranteed to be killed (prior to killing a process) like onPause() has always been. Just to clarify, shouldn't that read: Also it may be worth mentioning -- there was a significant change to the activity lifecycle in 3.0 where onStop() is now guaranteed to be **called** (prior to killing a process) like onPause() has always been. ? Thanks! -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy _Android Programming Tutorials_ Version 3.3 Available! -- 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
[android-developers] Re: Activity Lifecycle Documentation Question
On Apr 27, 6:44 pm, Dianne Hackborn hack...@android.com wrote: Also it may be worth mentioning -- there was a significant change to the activity lifecycle in 3.0 where onStop() is now guaranteed to be killed (prior to killing a process) like onPause() has always been. I am glad this change was made, it makes more logical sense to me to do it this way. Hopefully the documentation can also be updated to remove any doubt whatsoever that an Activity cannot possibly be 'removed' from memory in low-memory situations (when the process is _not_ killed), that would result in an inconsistent or leak state by not having balanced lifecycle methods called. -- 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] Re: Activity Lifecycle Documentation Question
Um, yes, called. I meant called. :) On Wed, Apr 27, 2011 at 6:53 PM, Mark Murphy mmur...@commonsware.comwrote: On Wed, Apr 27, 2011 at 6:44 PM, Dianne Hackborn hack...@android.com wrote: Also it may be worth mentioning -- there was a significant change to the activity lifecycle in 3.0 where onStop() is now guaranteed to be killed (prior to killing a process) like onPause() has always been. Just to clarify, shouldn't that read: Also it may be worth mentioning -- there was a significant change to the activity lifecycle in 3.0 where onStop() is now guaranteed to be **called** (prior to killing a process) like onPause() has always been. ? Thanks! -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy _Android Programming Tutorials_ Version 3.3 Available! -- 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 -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- 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] Re: Activity Lifecycle Documentation Question
On Wed, Apr 27, 2011 at 6:56 PM, Eric e...@alum.mit.edu wrote: I am glad this change was made, it makes more logical sense to me to do it this way. Hopefully the documentation can also be updated to remove any doubt whatsoever that an Activity cannot possibly be 'removed' from memory in low-memory situations (when the process is _not_ killed), that would result in an inconsistent or leak state by not having balanced lifecycle methods called. The only thing that happens in low-memory situations is processes being killed. -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- 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
[android-developers] Re: Activity Lifecycle Documentation Question
On Apr 27, 9:27 pm, Dianne Hackborn hack...@android.com wrote: On Wed, Apr 27, 2011 at 6:56 PM, Eric e...@alum.mit.edu wrote: Hopefully the documentation can also be updated to remove any doubt whatsoever that an Activity cannot possibly be 'removed' from memory in low-memory situations (when the process is _not_ killed), that would result in an inconsistent or leak state by not having balanced lifecycle methods called. The only thing that happens in low-memory situations is processes being killed. Yes, thank you for clarifying that, but unfortunately the documentation lead one to believe that Activities that are already paused can somehow be removed from memory by a different mechanism other than killing the process. For example, http://developer.android.com/reference/android/app/Activity.html If an activity is paused or stopped, the system can drop the activity from memory by either asking it to finish, or simply killing its process Note the 'either', 'or' language. I assume this situation is meant to address an Activity stack: A1, A2, A3 Where A3 was just started, but the system is so low on memory that it 'drops' the activities A1 and A2 from memory using the nebulous mechanism described in the documentation. The nebulous mechanism is described as 'the Activity being asked to finish'. However, my understanding of 'finishing' an Activity was that once an Activity is 'finished' it never again returns to the screen unless being explicitly started again. Therefore, I took the 'finish' in that above documentation to mean that Android removes the Activity from memory some other way, where the normal lifecycle is not followed. Hence the reason why I wrote this post in the first place. -- 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] Re: Activity Lifecycle Documentation Question
Asking it to finish means finishing the activity, which means destroying it. Politely asking it to finish isn't going to cause it to just not cleanly exit. It would be fundamentally broken if activities every just stop being used in their process without actually going through the lifecycle. In other words asking to finish - Activity.finish() - does what you expect. On Wed, Apr 27, 2011 at 11:01 PM, Eric e...@alum.mit.edu wrote: On Apr 27, 9:27 pm, Dianne Hackborn hack...@android.com wrote: On Wed, Apr 27, 2011 at 6:56 PM, Eric e...@alum.mit.edu wrote: Hopefully the documentation can also be updated to remove any doubt whatsoever that an Activity cannot possibly be 'removed' from memory in low-memory situations (when the process is _not_ killed), that would result in an inconsistent or leak state by not having balanced lifecycle methods called. The only thing that happens in low-memory situations is processes being killed. Yes, thank you for clarifying that, but unfortunately the documentation lead one to believe that Activities that are already paused can somehow be removed from memory by a different mechanism other than killing the process. For example, http://developer.android.com/reference/android/app/Activity.html If an activity is paused or stopped, the system can drop the activity from memory by either asking it to finish, or simply killing its process Note the 'either', 'or' language. I assume this situation is meant to address an Activity stack: A1, A2, A3 Where A3 was just started, but the system is so low on memory that it 'drops' the activities A1 and A2 from memory using the nebulous mechanism described in the documentation. The nebulous mechanism is described as 'the Activity being asked to finish'. However, my understanding of 'finishing' an Activity was that once an Activity is 'finished' it never again returns to the screen unless being explicitly started again. Therefore, I took the 'finish' in that above documentation to mean that Android removes the Activity from memory some other way, where the normal lifecycle is not followed. Hence the reason why I wrote this post in the first place. -- 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 -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- 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
[android-developers] Re: Activity Lifecycle Documentation Question
On Apr 28, 12:21 am, Dianne Hackborn hack...@android.com wrote: Asking it to finish means finishing the activity, which means destroying it. Politely asking it to finish isn't going to cause it to just not cleanly exit. It would be fundamentally broken if activities every just stop being used in their process without actually going through the lifecycle. In other words asking to finish - Activity.finish() - does what you expect. Ok, so when I 'finish' an Activity programmatically, never wanting it to show up in the Task stack again, how does the system know to remove my Activity from the back stack in that case, but it doesn't remove it from the stack when the system asks it to finish due to low memory conditions? Also, the documentation for onDestroy() adds to the confusion a bit: Called before the activity is destroyed. This is the final call that the activity will receive. It could be called either because the activity is finishing (someone called finish() on it), or because the system is temporarily destroying this instance of the activity to save space. You can distinguish between these two scenarios with the isFinishing() method. Note that it says if the Activity is being temporarily discarded to save space, then the 'isFinishing' method will return false. If Android is simply calling 'finish' to temporarily discard the Activity, as you state, then is it explicitly setting 'isFinishing()' flag back to false (assuming the call to finish() automatically sets it to true; because if it didn't, then when I programmatically call 'finish()' to permanently finish the Activity, the flag would probably never get set)? - Eric -- 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] Re: Activity Lifecycle Documentation Question
Yes if you call finish() you are saying you want to completely remove the activity from the stack. The system can have the activity destroyed in the same way, but just not remove it from the stack it maintains. At the end of the day, it would be fundamentally broken if there was a way for an activity to stop being used in a process without being destroyed. This means it would be IMPOSSIBLE to write a correctly working application. I agree you can find parts of the documentation to help you convince yourself that there are cases this can happen, if that is what you are looking for. But it won't. Because it would be broken. As I think is already obvious to you, since your original question was basically: if I read the documentation this way then there is nothing useful at all about onDestroy() or onStop() because they won't get called when they need to be. Right. So don't try to read the documentation in a way that makes it broken. You are welcome to contribute changed to the documentation for people to review if there are things you think can be improved. On Thu, Apr 28, 2011 at 12:29 AM, Eric e...@alum.mit.edu wrote: On Apr 28, 12:21 am, Dianne Hackborn hack...@android.com wrote: Asking it to finish means finishing the activity, which means destroying it. Politely asking it to finish isn't going to cause it to just not cleanly exit. It would be fundamentally broken if activities every just stop being used in their process without actually going through the lifecycle. In other words asking to finish - Activity.finish() - does what you expect. Ok, so when I 'finish' an Activity programmatically, never wanting it to show up in the Task stack again, how does the system know to remove my Activity from the back stack in that case, but it doesn't remove it from the stack when the system asks it to finish due to low memory conditions? Also, the documentation for onDestroy() adds to the confusion a bit: Called before the activity is destroyed. This is the final call that the activity will receive. It could be called either because the activity is finishing (someone called finish() on it), or because the system is temporarily destroying this instance of the activity to save space. You can distinguish between these two scenarios with the isFinishing() method. Note that it says if the Activity is being temporarily discarded to save space, then the 'isFinishing' method will return false. If Android is simply calling 'finish' to temporarily discard the Activity, as you state, then is it explicitly setting 'isFinishing()' flag back to false (assuming the call to finish() automatically sets it to true; because if it didn't, then when I programmatically call 'finish()' to permanently finish the Activity, the flag would probably never get set)? - Eric -- 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 -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- 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] Re: Activity lifecycle
On Mon, Apr 4, 2011 at 9:29 AM, Gino ginolee...@gmail.com wrote: In my tests, it looks like onSavedInstanceState() does not get called when switching from portrait to landscape mode, or vice versa. Do you have any flags set to lock the orientation? Rotating the device always causes a destroy - recreate under normal circumstances, AFAIK. - TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago transit tracking app for Android-powered devices -- 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
[android-developers] Re: Activity lifecycle
On Apr 4, 10:29 am, Gino ginolee...@gmail.com wrote: In my tests, it looks like onSavedInstanceState() does not get called when switching from portrait to landscape mode, or vice versa. There is no 'onSavedInstanceState' method in Activity. Is that a typo in your question, or a typo in your code? Did you mean 'onSaveInstanceState'? Eclipse will put a little arrow in the left margin if you are correctly overriding a base class's method. You can of course make a method of any name you want, but there is a very small likelihood that it will ever get called. -- 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
[android-developers] Re: Activity lifecycle
In my tests, it looks like onSavedInstanceState() does not get called when switching from portrait to landscape mode, or vice versa. It does get called if you press the Home button. This is on an Android 2.1 device, but it most likely applies to 1.6 and afterwards as well. Does anyone know an easy way to test the onSavedInstanceState() functionality ? I tried using a task manager to kill my app, but unfortunately it doesn't call the onSavedInstanceState() function. Gino. On Apr 2, 12:46 pm, Mark Murphy mmur...@commonsware.com wrote: On Sat, Apr 2, 2011 at 12:28 PM, b_t bartata...@gmail.com wrote: And is there any way to force stop activity A to test if my onRestoreInstanceState and onSavedInstanceState implementation works when returning from B? Sure. Rotate the screen. By default, that will destroy and recreate the activity. In my device A is never destroyed. That seems unlikely. -- Mark Murphy (a Commons Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy Android Training...At Your Office:http://commonsware.com/training -- 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
[android-developers] Re: Activity lifecycle
The best way I have found to handle this is: be ready to be killed _in_any_moment_. This may seem unlike to happed, but still you must be ready. How? By saving your state when your onSavedInstanceState() is called, gracefully releasing resources when onDestroy() is called, and restoring the state when onCreate() is called. This is a superset of the problem that you are describing, but I have found to be easier to think in this way than trying to solve every particular scenario. On 2 abr, 09:58, b_t bartata...@gmail.com wrote: Hi, Maybe an easy question. When activity A launches activity B then it is possible that A destroyes before the user navigates back from B? So A will be recreated and don't remain object state? T. -- 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
[android-developers] Re: Activity lifecycle
And is there any way to force stop activity A to test if my onRestoreInstanceState and onSavedInstanceState implementation works when returning from B? In my device A is never destroyed. -- 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] Re: Activity lifecycle
On Sat, Apr 2, 2011 at 12:28 PM, b_t bartata...@gmail.com wrote: And is there any way to force stop activity A to test if my onRestoreInstanceState and onSavedInstanceState implementation works when returning from B? Sure. Rotate the screen. By default, that will destroy and recreate the activity. In my device A is never destroyed. That seems unlikely. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Android Training...At Your Office: http://commonsware.com/training -- 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] Re: Activity lifecycle... still a mystery to me
On Mon, Mar 14, 2011 at 3:25 PM, Indicator Veritatis mej1...@yahoo.comwrote: But (and you knew there was a 'but' coming), even this leaves important questions unanswered. In particular, what does it mean to have input focus over any other activities? You imply elsewhere that it does NOT mean unconditional possession of focus, you imply it has something to do with windows, but exactly what it does mean is not stated here nor (anywhere I could find) in the original online docs. Windows are in Z order. The top-most window in Z order that wants input focus gets it. The window manager implements a simple policy for Z ordering. The parts of interest here are: 1. All windows associated with activities at the bottom, ordered by the global activity stack. 2. Toasts (which can't get input focus). 3. Status bar elements. 4. System dialogs (like crash / ANR dialogs). 5. Lock screen and its UI elements. Thus if your activity is resumed, it is at the top of the stack, and if it asks for input focus it will take it from all other activities since those are below it. However windows can still be on top of it, which can take input focus away from it. (Sorry about being slow on this, I have been having trouble with my account.) -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- 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
[android-developers] Re: Activity lifecycle... still a mystery to me
The only 'correction' needed, Roger, is that backing out is the wrong term. When Activity A 'calls' Activity B (really, sending an Intent), no backing out takes place. Backing out is a much more appropriate term for what happens when the user presses the Back key, which causes finish() to be called. This in turn results in onDestroy() being called. See http://developer.android.com/reference/android/app/Activity.html#onDestroy() to see how the documentation words the same thing I just said above (and see that I am not making things up). See also the description of onBackPressed(), which confirms that finish() is called. On Mar 19, 11:39 pm, Roger Podacter rogerpodac...@gmail.com wrote: No because I don't believe onDestroy would necessarily get called backing out of the activity. Only onPause would be guaranteed to be called. That activity's onDestrw would only get called at some random point in the future when the OS wants more memory. OnPause is the primary. At least that is my understanding. I hope someone corrects me. On Mar 19, 3:37 pm, lbendlin l...@bendlin.us wrote: If one activity calls another, and when you then press Back from that activity, wouldn't the calling of onDestroy() assure you that the called activity is truly gone and the memory is freed? (Or conversely, if it isn't called, the activity may live on due to dangling references?) -- 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
[android-developers] Re: Activity lifecycle... still a mystery to me
yes all things you specified could be done write overwrite back button code for 1 2 not clear 3 ok write overwrite onstop ,onpause,on resume On Mar 22, 7:59 am, DulcetTone dulcett...@gmail.com wrote: My app responds to speech commands. I want the behavior to be that 1. if back is hit on my initial activity, it exits. 2. My app has a few sub-activities it may launch on user speech- or GUI input 3. if home is hit on ANY of my activities, I want all of them to finish. That's basically it. Why I want this is uninteresting... few users of the app would find the desired behavior anything other than the one they'd want. It's possible that I could get some of this to happen by use of the activity flags/modes (single-top, etc), but their documentation also reads like Sanskrit after 10 reads through. tone -- 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] Re: Activity lifecycle... still a mystery to me
On Mon, Mar 21, 2011 at 10:59 PM, DulcetTone dulcett...@gmail.com wrote: My app responds to speech commands. I want the behavior to be that 1. if back is hit on my initial activity, it exits. That is normal behavior. 2. My app has a few sub-activities it may launch on user speech- or GUI input 3. if home is hit on ANY of my activities, I want all of them to finish. Again, I ask: why? Why I want this is uninteresting... Then don't expect much help. I'm not asking why because I expect the reason to be interesting, I am asking why because you are clearly confused, so I am trying to get to the real problem here. few users of the app would find the desired behavior anything other than the one they'd want. That's conceivable, but unlikely, since your users probably want your app to behave like all their other apps. What do you think the difference is between: if home is hit on ANY of my activities, I want all of them to finish and: if home is hit on ANY of my activities, the home screen should appear since the latter is the standard behavior? The home screen will appear in either case. Clearly, you think that there is some difference. We need to know what the behavior difference is that you are expecting, so we can guide you on how to achieve it. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy _The Busy Coder's Guide to Android Development_ Version 3.5 Available! -- 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
[android-developers] Re: Activity lifecycle... still a mystery to me
My app responds to speech commands. I want the behavior to be that 1. if back is hit on my initial activity, it exits. 2. My app has a few sub-activities it may launch on user speech- or GUI input 3. if home is hit on ANY of my activities, I want all of them to finish. That's basically it. Why I want this is uninteresting... few users of the app would find the desired behavior anything other than the one they'd want. It's possible that I could get some of this to happen by use of the activity flags/modes (single-top, etc), but their documentation also reads like Sanskrit after 10 reads through. tone -- 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
[android-developers] Re: Activity lifecycle... still a mystery to me
No because I don't believe onDestroy would necessarily get called backing out of the activity. Only onPause would be guaranteed to be called. That activity's onDestrw would only get called at some random point in the future when the OS wants more memory. OnPause is the primary. At least that is my understanding. I hope someone corrects me. On Mar 19, 3:37 pm, lbendlin l...@bendlin.us wrote: If one activity calls another, and when you then press Back from that activity, wouldn't the calling of onDestroy() assure you that the called activity is truly gone and the memory is freed? (Or conversely, if it isn't called, the activity may live on due to dangling references?) -- 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
[android-developers] Re: Activity lifecycle... still a mystery to me
that's beautiful, Diane! The matched-pair thing exactly what I was wanting to confirm - logcat messages are making a little more sense. Here's a summary as I understand it pulled from your interleaved response - let me know if I'm missing something. Matching pairs of events for an activity Any resources you create in the first of the pair should generally be released in the matching one. * onCreate() / onDestroy() - onCreate() is when it is first created - onDestroy() is when it is last being cleaned up * onStart() / onStop() - onStart() is when it is becoming visible - onStop() is when it is no longer going to be visible to the user * onResume() / onPause() - onResume() called when you are becoming the top activity on the global activity stack - onPause() called when you are going away from that state (prior to a different activity becoming the top) And... I would ignore onRestart()For the basics of the activity lifecycle, though, the 3 pairs are the important things to understand. On Mar 13, 4:42 am, Dianne Hackborn hack...@android.com wrote: 2011/3/12 Indicator Veritatis mej1...@yahoo.com Actually, comparing with the text, I don't think it means just what is says. There is an asymmetry in the states, an asymmetry I believe is deliberate, if poorly explained: that between onPause and onResume: when you enter onPause, you may still be partially visible, but you lose input focus. But when you enter onResume you must have both full visibility and input focus. onResume() is called when you are becoming the top activity on the global activity stack. onPause() is called when you are going away from that state (prior to a different activity becoming the top). I'm not sure how this is asymmetrical? There are important implications about being the top activity -- for example you will have input focus over any other activities, your window will be on top of all other activities, etc. However there are some subtle aspects of this. In particular, being the top activity does *not* guarantee being input focus; input focus is based on windows, and there are a number of Android UI elements that are implemented as pure windows. This includes the lock screen, and notification shade. When one of these elements is shown, the top activity's window will lose input focus for that time. There are really three important pairs to the activity lifecycle: onCreate() / onDestroy() onStart() / onStop() onResume() / onPause() Any resources you create in the first of the pair should generally be released in the matching one. For example, if you use registerReceiver() in onCreate(), you should generally call unregisterReceiver() then in onDestroy(). These pairs represent symmetric major states of an activity: onCreate() is when it is first created, onDestroy() is when it is last being cleaned up; onStart() is when it is becoming visible, onStop() is when it is no longer going to be visible to the user. And we already talked about onResume() and onPause(). Finish would cause it too - your activity is about to not be visible (since it's going away). Cause what, too? It causes your activity to go through onPause() and onStop() (if needed) since it is no longer going to be visible to the user, and then onDestroy() since the activity instance is being destroyed. But what does front-most position really mean? That is what confuses many, not just the OP when reading the online documentation about the Activity lifecycle. My best attempt at reading the mind of the online doc's author is that front-most position means not only 1) being fully visible, most likely completely covering up all other Activities, but also 2) capturing input focus from all input devices: touch screen, keyboard... It really just means top of the activity stack, and since the windows created by activities are Z-ordered in the window manager based on that stack, its windows are on top, bringing along all of the repercussions of that both visually and for input focus. 3. How is onPause() - onResume() different than onStop() - onRestart()? What circumstances differentiate the flow? onStart / onResume depend on what happened before. In what way do they depend? Isn't it just a matter of onPause() - onResume() being as the documentation says, the foreground lifetime of the Activity has started? While onStop() - onRestart() is quite different? I would ignore onRestart(). It is useful for some semi-common situations we saw during app developer, where one wants to do some work when being started but not duplicate stuff that was already done in onCreate(). For the basics of the activity lifecycle, though, the 3 pairs are the important things to understand. I actually did work on a project where they somehow defeated the normal behavior of the home key -- and I hated that feature. I am sure most users feel the same way. Generally we consider
[android-developers] Re: Activity lifecycle... still a mystery to me
If one activity calls another, and when you then press Back from that activity, wouldn't the calling of onDestroy() assure you that the called activity is truly gone and the memory is freed? (Or conversely, if it isn't called, the activity may live on due to dangling references?) -- 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
[android-developers] Re: Activity lifecycle... still a mystery to me
Thanks, Dianne, for this very valuable supplement to the mysterious documentation on the Activity lifecycle! But (and you knew there was a 'but' coming), even this leaves important questions unanswered. In particular, what does it mean to have input focus over any other activities? You imply elsewhere that it does NOT mean unconditional possession of focus, you imply it has something to do with windows, but exactly what it does mean is not stated here nor (anywhere I could find) in the original online docs. Or did you mean to imply that the ONLY time the Activity on the top of the activity task loses input focus is when it is shadowed by one of those Android UI elements that are implemented as pure windows? On Mar 13, 12:42 am, Dianne Hackborn hack...@android.com wrote: 2011/3/12 Indicator Veritatis mej1...@yahoo.com Actually, comparing with the text, I don't think it means just what is says. There is an asymmetry in the states, an asymmetry I believe is deliberate, if poorly explained: that between onPause and onResume: when you enter onPause, you may still be partially visible, but you lose input focus. But when you enter onResume you must have both full visibility and input focus. onResume() is called when you are becoming the top activity on the global activity stack. onPause() is called when you are going away from that state (prior to a different activity becoming the top). I'm not sure how this is asymmetrical? There are important implications about being the top activity -- for example you will have input focus over any other activities, your window will be on top of all other activities, etc. However there are some subtle aspects of this. In particular, being the top activity does *not* guarantee being input focus; input focus is based on windows, and there are a number of Android UI elements that are implemented as pure windows. This includes the lock screen, and notification shade. When one of these elements is shown, the top activity's window will lose input focus for that time. There are really three important pairs to the activity lifecycle: onCreate() / onDestroy() onStart() / onStop() onResume() / onPause() Any resources you create in the first of the pair should generally be released in the matching one. For example, if you use registerReceiver() in onCreate(), you should generally call unregisterReceiver() then in onDestroy(). These pairs represent symmetric major states of an activity: onCreate() is when it is first created, onDestroy() is when it is last being cleaned up; onStart() is when it is becoming visible, onStop() is when it is no longer going to be visible to the user. And we already talked about onResume() and onPause(). Finish would cause it too - your activity is about to not be visible (since it's going away). Cause what, too? It causes your activity to go through onPause() and onStop() (if needed) since it is no longer going to be visible to the user, and then onDestroy() since the activity instance is being destroyed. But what does front-most position really mean? That is what confuses many, not just the OP when reading the online documentation about the Activity lifecycle. My best attempt at reading the mind of the online doc's author is that front-most position means not only 1) being fully visible, most likely completely covering up all other Activities, but also 2) capturing input focus from all input devices: touch screen, keyboard... It really just means top of the activity stack, and since the windows created by activities are Z-ordered in the window manager based on that stack, its windows are on top, bringing along all of the repercussions of that both visually and for input focus. 3. How is onPause() - onResume() different than onStop() - onRestart()? What circumstances differentiate the flow? onStart / onResume depend on what happened before. In what way do they depend? Isn't it just a matter of onPause() - onResume() being as the documentation says, the foreground lifetime of the Activity has started? While onStop() - onRestart() is quite different? I would ignore onRestart(). It is useful for some semi-common situations we saw during app developer, where one wants to do some work when being started but not duplicate stuff that was already done in onCreate(). For the basics of the activity lifecycle, though, the 3 pairs are the important things to understand. I actually did work on a project where they somehow defeated the normal behavior of the home key -- and I hated that feature. I am sure most users feel the same way. Generally we consider this a security hole and fix this. The current platform has closed all the holes I know of; if there are new ways people have found to prevent the home key from working correctly, I would love to get a hold of the app to fix it. :) -- Dianne Hackborn Android framework engineer
Re: [android-developers] Re: Activity lifecycle... still a mystery to me
2011/3/12 Indicator Veritatis mej1...@yahoo.com Actually, comparing with the text, I don't think it means just what is says. There is an asymmetry in the states, an asymmetry I believe is deliberate, if poorly explained: that between onPause and onResume: when you enter onPause, you may still be partially visible, but you lose input focus. But when you enter onResume you must have both full visibility and input focus. onResume() is called when you are becoming the top activity on the global activity stack. onPause() is called when you are going away from that state (prior to a different activity becoming the top). I'm not sure how this is asymmetrical? There are important implications about being the top activity -- for example you will have input focus over any other activities, your window will be on top of all other activities, etc. However there are some subtle aspects of this. In particular, being the top activity does *not* guarantee being input focus; input focus is based on windows, and there are a number of Android UI elements that are implemented as pure windows. This includes the lock screen, and notification shade. When one of these elements is shown, the top activity's window will lose input focus for that time. There are really three important pairs to the activity lifecycle: onCreate() / onDestroy() onStart() / onStop() onResume() / onPause() Any resources you create in the first of the pair should generally be released in the matching one. For example, if you use registerReceiver() in onCreate(), you should generally call unregisterReceiver() then in onDestroy(). These pairs represent symmetric major states of an activity: onCreate() is when it is first created, onDestroy() is when it is last being cleaned up; onStart() is when it is becoming visible, onStop() is when it is no longer going to be visible to the user. And we already talked about onResume() and onPause(). Finish would cause it too - your activity is about to not be visible (since it's going away). Cause what, too? It causes your activity to go through onPause() and onStop() (if needed) since it is no longer going to be visible to the user, and then onDestroy() since the activity instance is being destroyed. But what does front-most position really mean? That is what confuses many, not just the OP when reading the online documentation about the Activity lifecycle. My best attempt at reading the mind of the online doc's author is that front-most position means not only 1) being fully visible, most likely completely covering up all other Activities, but also 2) capturing input focus from all input devices: touch screen, keyboard... It really just means top of the activity stack, and since the windows created by activities are Z-ordered in the window manager based on that stack, its windows are on top, bringing along all of the repercussions of that both visually and for input focus. 3. How is onPause() - onResume() different than onStop() - onRestart()? What circumstances differentiate the flow? onStart / onResume depend on what happened before. In what way do they depend? Isn't it just a matter of onPause() - onResume() being as the documentation says, the foreground lifetime of the Activity has started? While onStop() - onRestart() is quite different? I would ignore onRestart(). It is useful for some semi-common situations we saw during app developer, where one wants to do some work when being started but not duplicate stuff that was already done in onCreate(). For the basics of the activity lifecycle, though, the 3 pairs are the important things to understand. I actually did work on a project where they somehow defeated the normal behavior of the home key -- and I hated that feature. I am sure most users feel the same way. Generally we consider this a security hole and fix this. The current platform has closed all the holes I know of; if there are new ways people have found to prevent the home key from working correctly, I would love to get a hold of the app to fix it. :) -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- 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] Re: Activity lifecycle... still a mystery to me
13.03.2011 10:29, Indicator Veritatis пишет: I want to perform certain actions when the BACK or HOME keys are pressed, and ignore cases where a third-party activity simply pops up on part of the screen and then goes away. If you find yourself needing this, perhaps you need a Service. Why a Service? Services are meant for either 1) long-running operations in the background, operations that do not need UI or 2) exposing this component's functionality to other components, using IBinder if the latter are in other applications. Because he's trying to determine when the user really leaves his activity vs. when it's temporarily occluded. This is most likely to either continue or stop doing something. I'm speculating, but it seems likely. An oath he should take seriously. He asked for a response that could be vouched for - and since I can't sign in blood using email, that was the best I could do :) Let's hope he hasn't heard the famous Turgenev quote, каждый Русский -- неисправаемый лгун;) Turgenev was Russian, too, so that's just like All Cretans are liars :) -- Kostya Vasilyev -- http://kmansoft.wordpress.com -- 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
[android-developers] Re: Activity lifecycle... still a mystery to me
I recently wrote my first android app, and I too did not grasp the life cycle functions and they just didn't seem to work correctly, or the way I thought they should based on the graph. Here's my learned knowledge from writing my app. OnPause and onResume turned out to be by far and above the only functions that are used and needed, at least for me. At first I was trying to add in all the functions and never saw onStop or onStart called, ever. So I press back or home, and onPause is the first to get called, ALWAYS, no matter what for me. And going right back to my app, OnResume is the one that gets called, ALWAYS, no matter what. My app is simple so I had no need for saved state stuff, but I experimented with it anyway putting it in my OnCreate and saved instance state, just to see it work. OnDestroy I never used, never seen it called, and I believe its only needed if the OS closes it for more memory. And this condition virtually never happens from my testing, so its almost not even needed in a way. I later added a service to my app, and that's where I then used onStart and onStop. They didn't turn out to be used or needed in an activity, only a service. That's about it unless you want more details of my experience. Pause and resume are the ones to use unless you have very complex conditions happening in your app. On Mar 12, 12:55 pm, DulcetTone dulcett...@gmail.com wrote: I find the flowchart of Activity lifecycle pretty ambiguous. In a perfect world, it would receive a little more work to resolve the gray, but I'll throw out some example issues. 1. The phrasing on the legs into and out of onPause() are vague. Does another activity comes in front of the activity pertain to the case where my activity is simply going away because finish() was called? Does the activity is no longer visible mean that my activity is entirely concealed, and would this then differ from the case where another activity appeared partially in front of my own? 2. what happens if you call finish() from within onCreate()? onStart()? just about anywhere except the green activity is running blob? 3. How is onPause() - onResume() different than onStop() - onRestart()? What circumstances differentiate the flow? 4. minor nits: the clarity of the chart is actually diminished by having an exit from the The process is killed state, and some mention as to whether the Activity object may be re-used should follow the onDestroy() state The thing I am specifically trying to do is this: I want to perform certain actions when the BACK or HOME keys are pressed, and ignore cases where a third-party activity simply pops up on part of the screen and then goes away. Not all phones are traversing the lifecycle graph the same way, it seems, and since I do not have one of every phone (Droids seem notoriously different), writing test cases is not a viable means of educating myself. I'd like some clarity on the designed behavior that can be vouched for. tone -- 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
[android-developers] Re: Activity lifecycle... still a mystery to me
Interesting summary, but I don't think it addresses ALL the OP's legitimate concerns, hence my own questions/comments below: On Mar 12, 1:49 pm, Kostya Vasilyev kmans...@gmail.com wrote: See below: 12.03.2011 23:55, DulcetTone пишет: 1. The phrasing on the legs into and out of onPause() are vague. Does another activity comes in front of the activity pertain to the case where my activity is simply going away because finish() was called? It means just what it says - one case is another activity coming in front of yours (from your application or not), not necessarily completely occluding it. Actually, comparing with the text, I don't think it means just what is says. There is an asymmetry in the states, an asymmetry I believe is deliberate, if poorly explained: that between onPause and onResume: when you enter onPause, you may still be partially visible, but you lose input focus. But when you enter onResume you must have both full visibility and input focus. Finish would cause it too - your activity is about to not be visible (since it's going away). Cause what, too? Or the user switching away from your activity (Home key, status bar notification, incoming call, etc.). Putting it another way - onPause means the activity is about to lose its front-most position. But what does front-most position really mean? That is what confuses many, not just the OP when reading the online documentation about the Activity lifecycle. My best attempt at reading the mind of the online doc's author is that front-most position means not only 1) being fully visible, most likely completely covering up all other Activities, but also 2) capturing input focus from all input devices: touch screen, keyboard... Does the activity is no longer visible mean that my activity is entirely concealed, and would this then differ from the case where another activity appeared partially in front of my own? Yes. It means complete occlusion in case another activity pops up in front, or the user entirely switching away from your activity (Home key, status bar notification, incoming call, etc.). Partial occlusion == just onPause, without onStop. 2. what happens if you call finish() from within onCreate()? onStart()? just about anywhere except the green activity is running blob? For onCreate, your activity will never appear on the screen, just the transition effect that comes before the onCreate(). Haven't tried calling finish from onStart. 3. How is onPause() - onResume() different than onStop() - onRestart()? What circumstances differentiate the flow? onStart / onResume depend on what happened before. In what way do they depend? Isn't it just a matter of onPause() - onResume() being as the documentation says, the foreground lifetime of the Activity has started? While onStop() - onRestart() is quite different? Recall the docs read: the foreground lifetime of an activity happens between the call to onResume() and the call to onPause(). During this time, the activity is in front of all other activities on screen and has user input focus. If onStop was called, you'll get onRestart/onStart and then onResume when the user switches back. If just onPause, you'll get onResume. 4. minor nits: the clarity of the chart is actually diminished by having an exit from the The process is killed state, and some mention as to whether the Activity object may be re-used should follow the onDestroy() state If the process is killed, the Java object obviously is lost as well. However, if the user switches back to the activity, Android will relaunch the process, create a new instance of your activity class, and pass the previously saved state into onCreate as a bundle, so ideally, the activity can restore itself without the user noticing. The thing I am specifically trying to do is this: I want to perform certain actions when the BACK or HOME keys are pressed, and ignore cases where a third-party activity simply pops up on part of the screen and then goes away. If you find yourself needing this, perhaps you need a Service. Why a Service? Services are meant for either 1) long-running operations in the background, operations that do not need UI or 2) exposing this component's functionality to other components, using IBinder if the latter are in other applications. Nothing the OP has said suggests either need. He certainly needs UI, and has suggested nothing about communicating with other application components. Shouldn't he just go ahead and override all the callbacks? Not that there is anything he can do about the Home key -- nor should there be. The user really does want Home to work as it always does in all other applications. I actually did work on a project where they somehow defeated the normal behavior of the home key -- and I hated that feature. I am sure most users feel the same way. Not all phones are traversing the lifecycle graph the same way, it seems,
[android-developers] Re: Activity lifecycle... still a mystery to me
As you say, onPause() and onResume() are by far the most commonly called. But if you run your app on a G1, and run it with other apps, you will see onStop() and onDestroy() called. You should also see onDestroy() called whenever the user presses the Back button, which calls finish(); but when finish() is called, the system calls onDestroy() See eveloper.android.com/guide/topics/testing/testing_android.html, which says, inter alia: If the Activity code calls the *finish*() method, the * onDestroy*() method is called . -- 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
[android-developers] Re: Activity lifecycle difference between device and emulator
On Jun 18, 1:18 pm, Jay jband...@gmail.com wrote: In the emulator, the calling activity is paused, and right after the new activity is resumed, the calling activity is destroyed. More than likely the emulator is simply running out of memory, so it's destroying the first activity to make room. There's probably some way to boost the memory size on it and see if it still happens. -- 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
[android-developers] Re: Activity lifecycle problem on Nexus One - onStop not called
So I have modified my thread to be a singleton and mimplemented it
like this. Hope it helps someone else who might be facing the same
issue.
public class SingletonThread extends Thread{
private static SingletonThread _instance;
public static boolean IS_RUNNING = false;
private static Context mContext;
private SingletonThread(){
}
public synchronized static final SingletonThread getInstance(Context
context){
mContext = context;
if(instance == null){
instance = new SingletonThread();
}
return instance;
}
public synchronized void run(){
IS_RUNNING = true;
//Implement your requirements.
IS_RUNNING = false;
}
}
And whenever I call the getInstance, from any other UI thread, I will
check for IS_RUNNING also and will start the thread only if IS_RUNNING
is false/will wait till IS_RUNNING is false.
There might be better ways to do this, so please post your feedbacks,
Thank you.
On Mar 11, 2:44 pm, Dianne Hackborn hack...@android.com wrote:
On Thu, Mar 11, 2010 at 1:40 PM, Achanta krishna.acha...@gmail.com wrote:
Yes I am trying to redesign it to use AsyncTask. One reason why I did
not take this approach is that I just wanted a plain thread that sits
and logs user events that are occurring throughout my app and it made
more sense to just start that thread when the app starts and shut it
down when the app closes. I had a handler which grabs the logs and
puts them in db and the thread just sits there and logs them to
server.
For this model, manage the thread through a separate static singleton, have
clients tell it when they are using it (in onCreate() or whatever) and when
they are done (in onDestroy() or whatever), and have that class take care of
stopping the thread when there are no more clients.
Also please be careful about what this thread is doing. An application
should be careful to be doing very little work any time it is not in the
foreground, or it will be consuming battery... and has a good chance of
showing up high up in the battery meter as it eats the user's battery.
--
Dianne Hackborn
Android framework engineer
hack...@android.com
Note: please don't send private questions to me, as I don't have time to
provide private support, and so won't reply to such e-mails. All such
questions should be posted on public forums, where I and others can see and
answer them.
--
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
[android-developers] Re: Activity lifecycle problem on Nexus One - onStop not called
Thank you Dianne, Its not even passing onStop and onDestroy at some point in the future. It is only doing it in some point in the future when more activities are started. I tested it 4-5 times and let it run for atleast 5 minutes. So I don't know how long I have to wait for the thread to close. Can anyone suggest a work around for this issue. I have a background thread which starts in the onCreate methos and which I close in the onDestroy method. But because of this bug in the sdk 2.1 my thread never stops. But when the user closes the app[onDestroy hasn't been called] and opens my application again, I try to create the thread in the onCreate. But after this is done at some point the onDestroy from the earlier activity is called which sends a messahe to my thread's handler to stop the thread. So the app runs now but the background thread doesnot run. Another problem that I face with the same issue is since the handle passes the message to stop the thread even while it is supposed to run, my events trigger actions where i have to write to database from the background thread. Now since that is null it shows the force close message. The only option that I see is to detect the build version each time my app starts and try to limit the things the user can do in those versions, which ofcourse is not much more than just undesirable thing. Please let me know if anyone has a workaround for this one. thank you. -- 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] Re: Activity lifecycle problem on Nexus One - onStop not called
Achanta wrote: Can anyone suggest a work around for this issue. I have a background thread which starts in the onCreate methos and which I close in the onDestroy method. But because of this bug in the sdk 2.1 my thread never stops. But when the user closes the app[onDestroy hasn't been called] and opens my application again, I try to create the thread in the onCreate. But after this is done at some point the onDestroy from the earlier activity is called which sends a messahe to my thread's handler to stop the thread. So the app runs now but the background thread doesnot run. You may be able to redesign your application to not require a permanent background thread. For example, use discrete AsyncTasks that do some work and end. Another problem that I face with the same issue is since the handle passes the message to stop the thread even while it is supposed to run, my events trigger actions where i have to write to database from the background thread. Now since that is null it shows the force close message. I have no idea what this means. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://twitter.com/commonsguy Android Training in US: 14-18 June 2010: http://bignerdranch.com -- 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
[android-developers] Re: Activity lifecycle problem on Nexus One - onStop not called
Thank you Mark, Yes I am trying to redesign it to use AsyncTask. One reason why I did not take this approach is that I just wanted a plain thread that sits and logs user events that are occurring throughout my app and it made more sense to just start that thread when the app starts and shut it down when the app closes. I had a handler which grabs the logs and puts them in db and the thread just sits there and logs them to server. I saw the google tracker but the apis for analytics are not yet good enough to provide us all the data which we can integrate into our marketing tools. I still hope this issue will be resolved soon. On Mar 11, 2:26 pm, Mark Murphy mmur...@commonsware.com wrote: Achanta wrote: Can anyone suggest a work around for this issue. I have a background thread which starts in the onCreate methos and which I close in the onDestroy method. But because of this bug in the sdk 2.1 my thread never stops. But when the user closes the app[onDestroy hasn't been called] and opens my application again, I try to create the thread in the onCreate. But after this is done at some point the onDestroy from the earlier activity is called which sends a messahe to my thread's handler to stop the thread. So the app runs now but the background thread doesnot run. You may be able to redesign your application to not require a permanent background thread. For example, use discrete AsyncTasks that do some work and end. Another problem that I face with the same issue is since the handle passes the message to stop the thread even while it is supposed to run, my events trigger actions where i have to write to database from the background thread. Now since that is null it shows the force close message. I have no idea what this means. -- Mark Murphy (a Commons Guy)http://commonsware.com|http://twitter.com/commonsguy Android Training in US: 14-18 June 2010:http://bignerdranch.com -- 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] Re: Activity lifecycle problem on Nexus One - onStop not called
On Thu, Mar 11, 2010 at 1:13 PM, Achanta krishna.acha...@gmail.com wrote: Its not even passing onStop and onDestroy at some point in the future. It is only doing it in some point in the future when more activities are started. I tested it 4-5 times and let it run for atleast 5 minutes. So I don't know how long I have to wait for the thread to close. What I was trying to say is that it will not completely forget to destroy it -- onDestroy() WILL be called, just at some time later. Possibly a lot later if the user sits in home for a long time. Can anyone suggest a work around for this issue. I have a background thread which starts in the onCreate methos and which I close in the onDestroy method. But because of this bug in the sdk 2.1 my thread never stops. But when the user closes the app[onDestroy hasn't been called] and opens my application again, I try to create the thread in the onCreate. But after this is done at some point the onDestroy from the earlier activity is called which sends a messahe to my thread's handler to stop the thread. So the app runs now but the background thread doesnot run. This is actually a bug in the app -- there is no guarantee that onDestroy() will be called before a new instance is created. For example, if you press back to exiting the activity and then very quickly start a new instance, the new instance will be started before onDestroy() because we wait until the apps are idle until destroying activities. The bug here just makes this case a lot more likely to happen. You should keep the state from two instances of an activity distinct -- for example if your onDestroy() is called it should only impact state in the activity being destroyed. -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- 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] Re: Activity lifecycle problem on Nexus One - onStop not called
On Thu, Mar 11, 2010 at 1:40 PM, Achanta krishna.acha...@gmail.com wrote: Yes I am trying to redesign it to use AsyncTask. One reason why I did not take this approach is that I just wanted a plain thread that sits and logs user events that are occurring throughout my app and it made more sense to just start that thread when the app starts and shut it down when the app closes. I had a handler which grabs the logs and puts them in db and the thread just sits there and logs them to server. For this model, manage the thread through a separate static singleton, have clients tell it when they are using it (in onCreate() or whatever) and when they are done (in onDestroy() or whatever), and have that class take care of stopping the thread when there are no more clients. Also please be careful about what this thread is doing. An application should be careful to be doing very little work any time it is not in the foreground, or it will be consuming battery... and has a good chance of showing up high up in the battery meter as it eats the user's battery. -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- 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
[android-developers] Re: Activity lifecycle problem on Nexus One - onStop not called
Hey Dianne, Thank you for the tip on battery life. Will definitely try to make it as good as possible for the battery life. Yes I considered using singleton pattern but again I still face with the issue where onDestroy will be called after onCreate when it should not happen and I need to keep track of that case also. So I would just go with AsynkTask but take care that my app is not eating up the battery. Thank you. On Mar 11, 2:44 pm, Dianne Hackborn hack...@android.com wrote: On Thu, Mar 11, 2010 at 1:40 PM, Achanta krishna.acha...@gmail.com wrote: Yes I am trying to redesign it to use AsyncTask. One reason why I did not take this approach is that I just wanted a plain thread that sits and logs user events that are occurring throughout my app and it made more sense to just start that thread when the app starts and shut it down when the app closes. I had a handler which grabs the logs and puts them in db and the thread just sits there and logs them to server. For this model, manage the thread through a separate static singleton, have clients tell it when they are using it (in onCreate() or whatever) and when they are done (in onDestroy() or whatever), and have that class take care of stopping the thread when there are no more clients. Also please be careful about what this thread is doing. An application should be careful to be doing very little work any time it is not in the foreground, or it will be consuming battery... and has a good chance of showing up high up in the battery meter as it eats the user's battery. -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- 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] Re: Activity lifecycle problem on Nexus One - onStop not called
On Thu, Mar 11, 2010 at 1:59 PM, Achanta krishna.acha...@gmail.com wrote: Yes I considered using singleton pattern but again I still face with the issue where onDestroy will be called after onCreate when it should not happen and I need to keep track of that case also. So I would just go with AsynkTask but take care that my app is not eating up the battery. As I said, it is not true that this should not happen. In fact it can and will happen. The system bug here just makes it (a lot) more likely to happen. And for anyone wondering, the singleTask or singleInstance launch modes do not impact this, that is not what they are for. -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- 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
[android-developers] Re: Activity lifecycle problem on Nexus One - onStop not called
This issue has been causing serious problems for users of my audiobook player application on 2.1 phones. The problems with the activity life cycle cause corresponding problems with the service life cycle. A service allows onStart to be called multiple times for the same service instance. This is normal expected behavior for a service. But when the start and stop intents being given to the service get reordered it causes serious problems. This is because the sequence: Service.onCreate Service.onStart Service.onStart Service.onDestroy is a valid sequence to execute on a service, and even though onStart is called multiple times it is correct behavior that the service to be destroyed on the first stop service command. Take the simple case where an activity starts a service in onCreate and stops the service in onDestroy. Bringing up the activity two times should result in the following sequence: 1st use Activity.onCreate (starts service) Service.onCreate Service.onStart Activity.finish Activity.onDestroy (stops service) Service.onDestroy 2nd use Activity.onCreate (starts service) Service.onCreate Service.onStart Activity.finish Activity.onDestroy (stops service) Service.onDestroy Because of this activity life cycle bug the following is occurring on 2.1 phones: 1st use Activity.onCreate (starts service) Service.onCreate Service.onStart Activity.finish (the destroy gets delayed) 2nd use Activity.onCreate (starts service) Service.onStart (service still exists) delayed Activity.onDestroy (stops service) Service.onDestroy At this point the 2nd activity instance is running but the service is it using has now been destroyed. The point at which the service gets destroyed randomly occurs when the delayed Activity.onDestroy was called. The way I plan to work around this issue is to change my activity to send the stop service intent just prior to calling Activity.finish. This way the stop service intent will be executed at the correct point in time even if the activity onStop and onDestroy get delayed until later. This problem has been difficult to track down not having a 2.1 device myself. I should have validation from some of my customers soon as to whether this work around resolves the problems they have been having. -- 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] Re: Activity lifecycle problem on Nexus One - onStop not called
Note again that though this bug makes this issue happen much more frequently, it CAN happen in normal situations. I am sorry for the trouble this has caused, however as a rule it is correct to design your code without the assumption that onDestroy() will happen before onCreate(). On Thu, Mar 11, 2010 at 8:15 PM, skyhigh skyhigh1...@gmail.com wrote: This issue has been causing serious problems for users of my audiobook player application on 2.1 phones. The problems with the activity life cycle cause corresponding problems with the service life cycle. A service allows onStart to be called multiple times for the same service instance. This is normal expected behavior for a service. But when the start and stop intents being given to the service get reordered it causes serious problems. This is because the sequence: Service.onCreate Service.onStart Service.onStart Service.onDestroy is a valid sequence to execute on a service, and even though onStart is called multiple times it is correct behavior that the service to be destroyed on the first stop service command. Take the simple case where an activity starts a service in onCreate and stops the service in onDestroy. Bringing up the activity two times should result in the following sequence: 1st use Activity.onCreate (starts service) Service.onCreate Service.onStart Activity.finish Activity.onDestroy (stops service) Service.onDestroy 2nd use Activity.onCreate (starts service) Service.onCreate Service.onStart Activity.finish Activity.onDestroy (stops service) Service.onDestroy Because of this activity life cycle bug the following is occurring on 2.1 phones: 1st use Activity.onCreate (starts service) Service.onCreate Service.onStart Activity.finish (the destroy gets delayed) 2nd use Activity.onCreate (starts service) Service.onStart (service still exists) delayed Activity.onDestroy (stops service) Service.onDestroy At this point the 2nd activity instance is running but the service is it using has now been destroyed. The point at which the service gets destroyed randomly occurs when the delayed Activity.onDestroy was called. The way I plan to work around this issue is to change my activity to send the stop service intent just prior to calling Activity.finish. This way the stop service intent will be executed at the correct point in time even if the activity onStop and onDestroy get delayed until later. This problem has been difficult to track down not having a 2.1 device myself. I should have validation from some of my customers soon as to whether this work around resolves the problems they have been having. -- 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.comandroid-developers%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- 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
[android-developers] Re: Activity lifecycle problem on Nexus One - onStop not called
I'm having a similar lifecycle issue on the Nexus One. Start the app -OnCreate Hit back - no OnDestroy is called Run app again -OnCreate, followed by OnDestroy The wierd thing is that it doesn't actually kill our application, so it is left in a broken state since we are tearing things down in OnDestroy. -Alex On Mar 7, 11:27 am, skyhigh skyhigh1...@gmail.com wrote: Very few of my activities used onStart and onStop until recently when I instrumented my application with Flurry Analytics. If you follow the Flurry instrumentation instructions then you add calls to notify Flurry about your application activity in the onStart and onStop methods for everyoneof your activities. I am not sure what impact it will have on the Flurry statistics gathering if these routines don't get called. I have had users reporting problems with my application on 2.1 phones which may be related to the service life cycle not behaving properly on these phones. I don't currently have a 2.1 phone to test this on (I am waiting to get my device seeding phone). I built an instrumented beta build that will log the service life cycle information for me, and am waiting for a customer to run the instrumented beta build on their 2.1 phone and send me back the logcat, so I can see if there is a similar issue with services. -- 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
[android-developers] Re: Activity lifecycle problem on Nexus One - onStop not called
I too have the same issue and Mark, we discussed it earlier in another thread. I was trying to use the onStop and onDestroy to stop Location updates and other background threads that I start from onCreate method. Here is what I observed. Here is what I have seen. I am using Nexus one [2.1]. Pressing on Home button or the Back button from my main activity does not call the onStop method or onDestroy method in this case Activities A, B. Activity A has a Button which starts activity B. Now when the activity A is started normally and it does not start another thread then the Back button from Activity A is called onStop and onDestroy. But if the Activity B is started from Activity A or if there is another thread that has been started from Activity A and if we come back to Activity A from Activity B and then press on the Back button, then onStop and onDestroy are not immediately called. But they are called after some other activity/application are opened. I even observed that they are not always immediately called after opening the same activity A. Sometimes they are called after activity A starts Activity B. 1. start A Press Back. onStop and onDwstroy called. 2. start A. Start another thread or activity from A and come back to A. Click on Back Button From A. onStop and onDestroy are not called. Start another application or the same application. onStop and onDestroy are sometimes[not always immediately] called. start opening more activities. onStop and onDestroy will be called at some point. 3. Start Activity A. Click on Home button. onStop is never called. [or atleast on two nexus one phones that I tested atleast a few times]. it will be called at a later point when another application or the same application is opened. And just like onStop, this is not in any predicted manner but is called at some point. On Mar 10, 10:07 am, Alex acni...@gmail.com wrote: I'm having a similar lifecycle issue on the Nexus One. Start the app -OnCreate Hitback- no OnDestroy is called Run app again -OnCreate, followed by OnDestroy The wierd thing is that it doesn't actually kill our application, so it is left in a broken state since we are tearing things down in OnDestroy. -Alex On Mar 7, 11:27 am, skyhigh skyhigh1...@gmail.com wrote: Very few of my activities used onStart and onStop until recently when I instrumented my application with Flurry Analytics. If you follow the Flurry instrumentation instructions then you add calls to notify Flurry about your application activity in the onStart and onStop methods for everyoneof your activities. I am not sure what impact it will have on the Flurry statistics gathering if these routines don't get called. I have had users reporting problems with my application on 2.1 phones which may be related to the service life cycle not behaving properly on these phones. I don't currently have a 2.1 phone to test this on (I am waiting to get my device seeding phone). I built an instrumented beta build that will log the service life cycle information for me, and am waiting for a customer to run the instrumented beta build on their 2.1 phone and send mebackthe logcat, so I can see if there is a similar issue with services. -- 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] Re: Activity lifecycle problem on Nexus One - onStop not called
Hi, there is an issue in 2.1 with the new launcher that causes the onStop()/onDestroy() to be delayed longer than typical when going back to home. Note these are not delayed -forever-, but just until later in the future (when the next activity switch happens). These methods are defined to happen at some time in the future so technically it is not really broken, but this is certainly not the desired behavior here. This will be fixed in the next release. Fwiw, this happened because the new launcher has a special surface view on top of itself to display the 3d all apps, and this caused the window manager to be confused and not realize that the app behind it had been hidden so it could then be stopped/destroyed. On Wed, Mar 10, 2010 at 6:33 PM, Achanta krishna.acha...@gmail.com wrote: I too have the same issue and Mark, we discussed it earlier in another thread. I was trying to use the onStop and onDestroy to stop Location updates and other background threads that I start from onCreate method. Here is what I observed. Here is what I have seen. I am using Nexus one [2.1]. Pressing on Home button or the Back button from my main activity does not call the onStop method or onDestroy method in this case Activities A, B. Activity A has a Button which starts activity B. Now when the activity A is started normally and it does not start another thread then the Back button from Activity A is called onStop and onDestroy. But if the Activity B is started from Activity A or if there is another thread that has been started from Activity A and if we come back to Activity A from Activity B and then press on the Back button, then onStop and onDestroy are not immediately called. But they are called after some other activity/application are opened. I even observed that they are not always immediately called after opening the same activity A. Sometimes they are called after activity A starts Activity B. 1. start A Press Back. onStop and onDwstroy called. 2. start A. Start another thread or activity from A and come back to A. Click on Back Button From A. onStop and onDestroy are not called. Start another application or the same application. onStop and onDestroy are sometimes[not always immediately] called. start opening more activities. onStop and onDestroy will be called at some point. 3. Start Activity A. Click on Home button. onStop is never called. [or atleast on two nexus one phones that I tested atleast a few times]. it will be called at a later point when another application or the same application is opened. And just like onStop, this is not in any predicted manner but is called at some point. On Mar 10, 10:07 am, Alex acni...@gmail.com wrote: I'm having a similar lifecycle issue on the Nexus One. Start the app -OnCreate Hitback- no OnDestroy is called Run app again -OnCreate, followed by OnDestroy The wierd thing is that it doesn't actually kill our application, so it is left in a broken state since we are tearing things down in OnDestroy. -Alex On Mar 7, 11:27 am, skyhigh skyhigh1...@gmail.com wrote: Very few of my activities used onStart and onStop until recently when I instrumented my application with Flurry Analytics. If you follow the Flurry instrumentation instructions then you add calls to notify Flurry about your application activity in the onStart and onStop methods for everyoneof your activities. I am not sure what impact it will have on the Flurry statistics gathering if these routines don't get called. I have had users reporting problems with my application on 2.1 phones which may be related to the service life cycle not behaving properly on these phones. I don't currently have a 2.1 phone to test this on (I am waiting to get my device seeding phone). I built an instrumented beta build that will log the service life cycle information for me, and am waiting for a customer to run the instrumented beta build on their 2.1 phone and send mebackthe logcat, so I can see if there is a similar issue with services. -- 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.comandroid-developers%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email
[android-developers] Re: Activity lifecycle problem on Nexus One - onStop not called
Very few of my activities used onStart and onStop until recently when I instrumented my application with Flurry Analytics. If you follow the Flurry instrumentation instructions then you add calls to notify Flurry about your application activity in the onStart and onStop methods for every one of your activities. I am not sure what impact it will have on the Flurry statistics gathering if these routines don't get called. I have had users reporting problems with my application on 2.1 phones which may be related to the service life cycle not behaving properly on these phones. I don't currently have a 2.1 phone to test this on (I am waiting to get my device seeding phone). I built an instrumented beta build that will log the service life cycle information for me, and am waiting for a customer to run the instrumented beta build on their 2.1 phone and send me back the logcat, so I can see if there is a similar issue with services. -- 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
[android-developers] Re: Activity lifecycle problem on Nexus One - onStop not called
I agree with Mark Murphy, it seems a problem only when the home screen is displayed after the activity, if I open another activity on top of that (long press on HOME) or if I receive a call the onStop is correctly called... seems to me quite a big issue, think about all the activities that use the onstart and onstop methods to coordinate their work, how come so few people have noticed that? Zuli On Mar 5, 6:00 am, Streets Of Boston flyingdutc...@gmail.com wrote: mm... my app makes use of saving and restoring instance state a lot and it works as well on theNexusOneas on the Droid or G1. But i don't use the onStop callback at all. And I don't use the onRestoreInstanceState either. Instead, i use the onRetainNonConfigurationInstance() and getLastNonConfigurationInstance() methods. These work well for me. On Mar 4, 8:25 pm, Zsolt Vasvari zvasv...@gmail.com wrote: I think there are some issues with the background activity life cycle management on theNexusOne. In my app, I have a background and foreground activity. When I tilt the phone so it switches orientation, the first time around the state is properly saved and restored for the background acrivity. But if when flip it back, onCreate is called with NULL for the Bundle, so I lose state. (and no, onRestoreInstanceState is not called, either) I'd create a small app that demonstrates this, but frankly, it would be a waste of my time as it probably wouldn't get looked at anyhow. So just take my word for it Zsolt Vasvari On Mar 5, 4:29 am, Mark Murphy mmur...@commonsware.com wrote: Mark Murphy wrote: schwiz wrote: It should be called when you press back but not home, but I have noticed this problem using openeclair on my G1. Perhaps its a new feature/bug in 2.1? No, onStop() should be called when you press either BACK or HOME. For some reason, it is not doing that in theNexusOne. My best guess is that it has to do with theNexusOne'shome screen implementation, but that's just a guess. BTW, here's the open issue: http://code.google.com/p/android/issues/detail?id=6094 -- Mark Murphy (a Commons Guy)http://commonsware.com|http://twitter.com/commonsguy _Android Programming Tutorials_ Version 2.0 Available!- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Activity lifecycle problem on Nexus One - onStop not called
I think a lot of apps don't use the onStop or onStart. I never found a use for them (so far...). onCreate, onResume, onPause and onDestroy are the most important ones. The NonConfigurationInstance() methods for configuration changes. On Mar 5, 9:26 am, Zuli paolo.zuli...@gmail.com wrote: I agree with Mark Murphy, it seems a problem only when the home screen is displayed after the activity, if I open another activity on top of that (long press on HOME) or if I receive a call the onStop is correctly called... seems to me quite a big issue, think about all the activities that use the onstart and onstop methods to coordinate their work, how come so few people have noticed that? Zuli On Mar 5, 6:00 am, Streets Of Boston flyingdutc...@gmail.com wrote: mm... my app makes use of saving and restoring instance state a lot and it works as well on theNexusOneas on the Droid or G1. But i don't use the onStop callback at all. And I don't use the onRestoreInstanceState either. Instead, i use the onRetainNonConfigurationInstance() and getLastNonConfigurationInstance() methods. These work well for me. On Mar 4, 8:25 pm, Zsolt Vasvari zvasv...@gmail.com wrote: I think there are some issues with the background activity life cycle management on theNexusOne. In my app, I have a background and foreground activity. When I tilt the phone so it switches orientation, the first time around the state is properly saved and restored for the background acrivity. But if when flip it back, onCreate is called with NULL for the Bundle, so I lose state. (and no, onRestoreInstanceState is not called, either) I'd create a small app that demonstrates this, but frankly, it would be a waste of my time as it probably wouldn't get looked at anyhow. So just take my word for it Zsolt Vasvari On Mar 5, 4:29 am, Mark Murphy mmur...@commonsware.com wrote: Mark Murphy wrote: schwiz wrote: It should be called when you press back but not home, but I have noticed this problem using openeclair on my G1. Perhaps its a new feature/bug in 2.1? No, onStop() should be called when you press either BACK or HOME. For some reason, it is not doing that in theNexusOne. My best guess is that it has to do with theNexusOne'shome screen implementation, but that's just a guess. BTW, here's the open issue: http://code.google.com/p/android/issues/detail?id=6094 -- Mark Murphy (a Commons Guy)http://commonsware.com|http://twitter.com/commonsguy _Android Programming Tutorials_ Version 2.0 Available!- Hide quoted text - - Show quoted text -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Activity lifecycle problem on Nexus One - onStop not called
Zuli, onStop() is called when your Activity is no longer visible, this may happen if a new activity is created (full screen mode) and is positioned in front of yours, also it may be caused because another Activity is resumed and brought to front (also full screen) and in the last case onStop() is called when your Activity is about to be destroyed (prior to onDestroy). After onPause() is called there are two options, onRestart() is called to restart your Activity or onDestroy() is called to kill your activity. Hope this helped. Bye On 4 mar, 13:26, Zuli paolo.zuli...@gmail.com wrote: Hi, I have a problem with the activity lifecycle specifically on Nexus One (2.1 running on emulator works fine). If I just create a simple empty Activity with no special launchModes that logs the calls on the onStart and onStop methods, this is what I see: - launch app: onStart called; - home button: onStop NOT called; - launch app: onStart NOT called; - home button: onStop NOT called: and so on. Sometimes if I press the back button then the onStop is not called, but the when i launch the activity again the onStart is called and right after the onStop is called. Similar results with different launchModes... What is going on? Can anyone confirm this? Zuli i found an android issue for the problem here:http://code.google.com/p/android/issues/detail?id=6094 and a similar thread herehttp://groups.google.com/group/android-developers/browse_thread/threa... -- 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
[android-developers] Re: Activity lifecycle problem on Nexus One - onStop not called
Hi Matias, thanks for your reply, but that's not the point. Because onStop() is called when the activity is no longer visibile, it should be called when the user presses the HOME or BACK button, and that is not happening on the Nexus One... well not on mine at least :) Zuli On Mar 4, 8:23 pm, Matias Alberto de la Vega delavega.mat...@gmail.com wrote: Zuli, onStop() is called when your Activity is no longer visible, this may happen if a new activity is created (full screen mode) and is positioned in front of yours, also it may be caused because another Activity is resumed and brought to front (also full screen) and in the last case onStop() is called when your Activity is about to be destroyed (prior to onDestroy). After onPause() is called there are two options, onRestart() is called to restart your Activity or onDestroy() is called to kill your activity. Hope this helped. Bye On 4 mar, 13:26, Zuli paolo.zuli...@gmail.com wrote: Hi, I have a problem with the activity lifecycle specifically on Nexus One (2.1 running on emulator works fine). If I just create a simple empty Activity with no special launchModes that logs the calls on the onStart and onStop methods, this is what I see: - launch app: onStart called; - home button: onStop NOT called; - launch app: onStart NOT called; - home button: onStop NOT called: and so on. Sometimes if I press the back button then the onStop is not called, but the when i launch the activity again the onStart is called and right after the onStop is called. Similar results with different launchModes... What is going on? Can anyone confirm this? Zuli i found an android issue for the problem here:http://code.google.com/p/android/issues/detail?id=6094 and a similar thread herehttp://groups.google.com/group/android-developers/browse_thread/threa... -- 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
[android-developers] Re: Activity lifecycle problem on Nexus One - onStop not called
It should be called when you press back but not home, but I have noticed this problem using openeclair on my G1. Perhaps its a new feature/bug in 2.1? On Mar 4, 1:54 pm, Zuli paolo.zuli...@gmail.com wrote: Hi Matias, thanks for your reply, but that's not the point. Because onStop() is called when the activity is no longer visibile, it should be called when the user presses the HOME or BACK button, and that is not happening on the Nexus One... well not on mine at least :) Zuli On Mar 4, 8:23 pm, Matias Alberto de la Vega delavega.mat...@gmail.com wrote: Zuli, onStop() is called when your Activity is no longer visible, this may happen if a new activity is created (full screen mode) and is positioned in front of yours, also it may be caused because another Activity is resumed and brought to front (also full screen) and in the last case onStop() is called when your Activity is about to be destroyed (prior to onDestroy). After onPause() is called there are two options, onRestart() is called to restart your Activity or onDestroy() is called to kill your activity. Hope this helped. Bye On 4 mar, 13:26, Zuli paolo.zuli...@gmail.com wrote: Hi, I have a problem with the activity lifecycle specifically on Nexus One (2.1 running on emulator works fine). If I just create a simple empty Activity with no special launchModes that logs the calls on the onStart and onStop methods, this is what I see: - launch app: onStart called; - home button: onStop NOT called; - launch app: onStart NOT called; - home button: onStop NOT called: and so on. Sometimes if I press the back button then the onStop is not called, but the when i launch the activity again the onStart is called and right after the onStop is called. Similar results with different launchModes... What is going on? Can anyone confirm this? Zuli i found an android issue for the problem here:http://code.google.com/p/android/issues/detail?id=6094 and a similar thread herehttp://groups.google.com/group/android-developers/browse_thread/threa... -- 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] Re: Activity lifecycle problem on Nexus One - onStop not called
schwiz wrote: It should be called when you press back but not home, but I have noticed this problem using openeclair on my G1. Perhaps its a new feature/bug in 2.1? No, onStop() should be called when you press either BACK or HOME. For some reason, it is not doing that in the Nexus One. My best guess is that it has to do with the Nexus One's home screen implementation, but that's just a guess. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://twitter.com/commonsguy _Android Programming Tutorials_ Version 2.0 Available! -- 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] Re: Activity lifecycle problem on Nexus One - onStop not called
Mark Murphy wrote: schwiz wrote: It should be called when you press back but not home, but I have noticed this problem using openeclair on my G1. Perhaps its a new feature/bug in 2.1? No, onStop() should be called when you press either BACK or HOME. For some reason, it is not doing that in the Nexus One. My best guess is that it has to do with the Nexus One's home screen implementation, but that's just a guess. BTW, here's the open issue: http://code.google.com/p/android/issues/detail?id=6094 -- Mark Murphy (a Commons Guy) http://commonsware.com | http://twitter.com/commonsguy _Android Programming Tutorials_ Version 2.0 Available! -- 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
[android-developers] Re: Activity lifecycle problem on Nexus One - onStop not called
mm... my app makes use of saving and restoring instance state a lot and it works as well on the Nexus One as on the Droid or G1. But i don't use the onStop callback at all. And I don't use the onRestoreInstanceState either. Instead, i use the onRetainNonConfigurationInstance() and getLastNonConfigurationInstance() methods. These work well for me. On Mar 4, 8:25 pm, Zsolt Vasvari zvasv...@gmail.com wrote: I think there are some issues with the background activity life cycle management on the Nexus One. In my app, I have a background and foreground activity. When I tilt the phone so it switches orientation, the first time around the state is properly saved and restored for the background acrivity. But if when flip it back, onCreate is called with NULL for the Bundle, so I lose state. (and no, onRestoreInstanceState is not called, either) I'd create a small app that demonstrates this, but frankly, it would be a waste of my time as it probably wouldn't get looked at anyhow. So just take my word for it Zsolt Vasvari On Mar 5, 4:29 am, Mark Murphy mmur...@commonsware.com wrote: Mark Murphy wrote: schwiz wrote: It should be called when you press back but not home, but I have noticed this problem using openeclair on my G1. Perhaps its a new feature/bug in 2.1? No, onStop() should be called when you press either BACK or HOME. For some reason, it is not doing that in the Nexus One. My best guess is that it has to do with the Nexus One's home screen implementation, but that's just a guess. BTW, here's the open issue: http://code.google.com/p/android/issues/detail?id=6094 -- Mark Murphy (a Commons Guy)http://commonsware.com|http://twitter.com/commonsguy _Android Programming Tutorials_ Version 2.0 Available!- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: activity lifecycle
The activity is destroyed. This doesn't mean the process is killed. There could be other components in the same application using that process. Also the platform may keep the process around for a variety of reasons, including the fact that starting processes is expensive. On Dec 5, 11:41 am, dane131 orestis...@gmail.com wrote: By default, pressing the BACK key finishes (destroys) the current activity and displays the previous activity to the user. I made and run an app and pressed the back key and returned to the main menu.However, when i typed the 'ps' command in the terminal emulator the process of my app was still there..My app constists only of this activity..shouldn't the process be killed? -- 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
[android-developers] Re: Activity Lifecycle Cause Memory Leaking
I experienced similar problems. Depending on how you navigate back to your Activity, Android does not know that it should reuse the existing instance and creates a new one. You can fix this easily with the activities launch mode, which you set in the AndroidManifest.xml. Setting it to singleInstance will ensure that there is only ever one instance. Depending on your app this might have other disadvantages, so you should check this part of the documentation: http://developer.android.com/guide/topics/fundamentals.html#acttask On 7 Aug., 07:23, efan e...@efansoftware.com wrote: Tested on both 1.5-R2 and R3, same result. On Aug 6, 10:22 pm, efan e...@efansoftware.com wrote: http://developer.android.com/reference/android/app/Activity.html The Activity Lifecycle could have implementation and or design bug: One case is to initialize a big image in onCreate(), try to reuse the image during the whole lifecycle, and then recycle the image in onDestroy(). Test showed that onCreate() is called every time one navigate away from the activity and back again, but onDestroy() is not called at all. This behavour causes memory leaking for the big image (size 960*1920). After 6+ times away and back to activity, the system runs out of memory and has tokillthe process. One workaround is to initialize the big image in onResume() and recycle in onPause(), but that's not so good reuse. Could it be better to change the process (as shown in the diagram) a little bit such as: Call onDestroy() first when a process is killed? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Activity Lifecycle Cause Memory Leaking
Tested on both 1.5-R2 and R3, same result. On Aug 6, 10:22 pm, efan e...@efansoftware.com wrote: http://developer.android.com/reference/android/app/Activity.html The Activity Lifecycle could have implementation and or design bug: One case is to initialize a big image in onCreate(), try to reuse the image during the whole lifecycle, and then recycle the image in onDestroy(). Test showed that onCreate() is called every time one navigate away from the activity and back again, but onDestroy() is not called at all. This behavour causes memory leaking for the big image (size 960*1920). After 6+ times away and back to activity, the system runs out of memory and has to kill the process. One workaround is to initialize the big image in onResume() and recycle in onPause(), but that's not so good reuse. Could it be better to change the process (as shown in the diagram) a little bit such as: Call onDestroy() first when a process is killed? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Activity lifecycle and static variables ....
Statics are statics -- they are global to the process. So their value will last for the lifetime of the process, which is usually much longer than an individual activity instance. On Tue, Jul 14, 2009 at 12:52 PM, Richard Schilling richard.rootwirel...@gmail.com wrote: I just ran into a situation where it looks like a static variable reference is persisted across activity sessions. I didn't expect that because I thought that when an activity exits, it's de-referenced and garbage collected. I am wondering if anyone can shed some (more) light on when the VM eliminates object references for Activities and Services and in particular when static variables get reset to default values? Thanks. Richard Schilling Root Wireless -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Activity lifecycle and static variables ....
Thanks Dianne. Very helpful indeed. For process lifetime, I don't think you're referring to the entire lifetime of an Activity as defined on the API reference page for Activity (http://developer.android.com/reference/android/app/ Activity.html): The entire lifetime of an activity happens between the first call to onCreate(Bundle) through to a single final call to onDestroy(). Rather, you're referring to a broader lifetime of the process that underlies the Activity correct? This would be the lifetime associated with android.os.Process I assume Richard Schilling Root Wireless On Jul 14, 1:23 pm, Dianne Hackborn hack...@android.com wrote: Statics are statics -- they are global to the process. So their value will last for the lifetime of the process, which is usually much longer than an individual activity instance. On Tue, Jul 14, 2009 at 12:52 PM, Richard Schilling richard.rootwirel...@gmail.com wrote: I just ran into a situation where it looks like a static variable reference is persisted across activity sessions. I didn't expect that because I thought that when an activity exits, it's de-referenced and garbage collected. I am wondering if anyone can shed some (more) light on when the VM eliminates object references for Activities and Services and in particular when static variables get reset to default values? Thanks. Richard Schilling Root Wireless -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Activity lifecycle and static variables ....
Yeah, the process lifetime, which is outlined here: http://developer.android.com/guide/topics/fundamentals.html#proclife On Tue, Jul 14, 2009 at 1:38 PM, Richard Schilling richard.rootwirel...@gmail.com wrote: Thanks Dianne. Very helpful indeed. For process lifetime, I don't think you're referring to the entire lifetime of an Activity as defined on the API reference page for Activity (http://developer.android.com/reference/android/app/ Activity.htmlhttp://developer.android.com/reference/android/app/%0AActivity.html ): The entire lifetime of an activity happens between the first call to onCreate(Bundle) through to a single final call to onDestroy(). Rather, you're referring to a broader lifetime of the process that underlies the Activity correct? This would be the lifetime associated with android.os.Process I assume Richard Schilling Root Wireless On Jul 14, 1:23 pm, Dianne Hackborn hack...@android.com wrote: Statics are statics -- they are global to the process. So their value will last for the lifetime of the process, which is usually much longer than an individual activity instance. On Tue, Jul 14, 2009 at 12:52 PM, Richard Schilling richard.rootwirel...@gmail.com wrote: I just ran into a situation where it looks like a static variable reference is persisted across activity sessions. I didn't expect that because I thought that when an activity exits, it's de-referenced and garbage collected. I am wondering if anyone can shed some (more) light on when the VM eliminates object references for Activities and Services and in particular when static variables get reset to default values? Thanks. Richard Schilling Root Wireless -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Activity lifecycle and static variables ....
Yes. I had read that, and I understand that the VM tries to stratify
processes depending on their function and keep my process alive as
long as possible. What I'm really interested in is detecting when the
the VM (re)-instantiated and garbage collects my Activity class, and
how that relates to the process identifier...
So, with this code, would procewssIDChanged ever be true? I know it's
a mundane question, but it tells me a lot about Android process
management
public IfWeirdAlWasAProgrammer extends Activity{
private static boolean newInstance = true;
private static int currentProcessId = -1;
private boolean processIDChanged = false; // non-static on purpose
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
if (newInstance){
Log.i(WeirdAlWasHere, Like a surgeon, cuttin' for the
very first time.);
newInstance = false;
currentProcessId = android.os.Process.myPid();
}
if (!newInstance (currentProcessId !=
android.os.Process.myPid()){
processIDChanged = true;
Log.i(WeirdAlWasHere, I lost on Jeapordy, baby!
O!);
}
}
}
Thanks again.
On Jul 14, 1:41 pm, Dianne Hackborn hack...@android.com wrote:
Yeah, the process lifetime, which is outlined here:
http://developer.android.com/guide/topics/fundamentals.html#proclife
On Tue, Jul 14, 2009 at 1:38 PM, Richard Schilling
richard.rootwirel...@gmail.com wrote:
Thanks Dianne. Very helpful indeed.
For process lifetime, I don't think you're referring to the entire
lifetime of an Activity as defined on the API reference page for
Activity (http://developer.android.com/reference/android/app/
Activity.htmlhttp://developer.android.com/reference/android/app/%0AActivity.html
):
The entire lifetime of an activity happens between the first call to
onCreate(Bundle) through to a single final call to onDestroy().
Rather, you're referring to a broader lifetime of the process that
underlies the Activity correct? This would be the lifetime
associated with android.os.Process I assume
Richard Schilling
Root Wireless
On Jul 14, 1:23 pm, Dianne Hackborn hack...@android.com wrote:
Statics are statics -- they are global to the process. So their value
will
last for the lifetime of the process, which is usually much longer than
an
individual activity instance.
On Tue, Jul 14, 2009 at 12:52 PM, Richard Schilling
richard.rootwirel...@gmail.com wrote:
I just ran into a situation where it looks like a static variable
reference is persisted across activity sessions. I didn't expect that
because I thought that when an activity exits, it's de-referenced and
garbage collected.
I am wondering if anyone can shed some (more) light on when the VM
eliminates object references for Activities and Services and in
particular when static variables get reset to default values?
Thanks.
Richard Schilling
Root Wireless
--
Dianne Hackborn
Android framework engineer
hack...@android.com
Note: please don't send private questions to me, as I don't have time to
provide private support, and so won't reply to such e-mails. All such
questions should be posted on public forums, where I and others can see
and
answer them.
--
Dianne Hackborn
Android framework engineer
hack...@android.com
Note: please don't send private questions to me, as I don't have time to
provide private support, and so won't reply to such e-mails. All such
questions should be posted on public forums, where I and others can see and
answer them.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
