calling finish() in onResume() a bad idea?

[OldSkoolMark]

I've been using code like:

activity.finish();
activity.startActivity(new Intent(activity, activity.getClass()));

in two places: onResume(), and in an onClick() method of an
AlertDialog. I'm getting the desired results when the code is called
from onClick(), but I get mysterious null pointer exceptions while the
runtime is trying to execute my onPause(). Is calling finish() from
within one of the Activity lifecycle callbacks always a bad idea?

This code makes me nervous even though it works in the onClick().
After I call activity.finish(), I would think activity is in a
questionable state by the time activity.startActivity() is invoked.
Seems like an invitation to race conditions.

My use case is setting UI preferences (e.g. a different layout) in a
PreferenceActivity. When I return to the main activity's onResume(), I
check for preference changes and if a new layout is requested, I use
the code snippet above.

Alternative design approaches would also be greatly appreciated.

[TreKing]

Post by OldSkoolMark
My use case is setting UI preferences (e.g. a different layout) in a
PreferenceActivity. When I return to the main activity's onResume(), I
check for preference changes and if a new layout is requested, I use
the code snippet above.

I would call PreferenceActivity with startActivityForResult, then
onActivityResult of the calling activity check if you need to "reset", then
do what you're doing there instead.

-------------------------------------------------------------------------------------------------
TreKing <http://sites.google.com/site/rezmobileapps/treking> - Chicago
transit tracking app for Android-powered devices

[Arjun]

Ok, here are some reasons why you get null pointer exception

activity.finish() is an asynchrnous call..so you cant predict when
finish will be called.
Thinking that finish has been called before your next call to
startActivity will always result you a null pointer exception.

Thanks,

Post by TreKing

Post by OldSkoolMark
My use case is setting UI preferences (e.g. a different layout) in a
PreferenceActivity. When I return to the main activity's onResume(), I
check for preference changes and if a new layout is requested, I use
the code snippet above.

I would call PreferenceActivity with startActivityForResult, then
onActivityResult of the calling activity check if you need to "reset", then
do what you're doing there instead.
-------------------------------------------------------------------------------------------------
TreKing <http://sites.google.com/site/rezmobileapps/treking> - Chicago
transit tracking app for Android-powered devices

[Kostya Vasilyev]

Try calling startActivity first, then finish. Both are processed
asynchronously (afaik), after the calling method returns control to the
framework.

--
Kostya Vasilyev -- http://kmansoft.wordpress.com

08.09.2010 23:51 ÐÏÌØÚÏ×ÁÔÅÌØ "OldSkoolMark" <***@sublimeslime.com>
ÎÁÐÉÓÁÌ:

I've been using code like:

activity.finish();
activity.startActivity(new Intent(activity, activity.getClass()));

in two places: onResume(), and in an onClick() method of an
AlertDialog. I'm getting the desired results when the code is called
from onClick(), but I get mysterious null pointer exceptions while the
runtime is trying to execute my onPause(). Is calling finish() from
within one of the Activity lifecycle callbacks always a bad idea?

This code makes me nervous even though it works in the onClick().
After I call activity.finish(), I would think activity is in a
questionable state by the time activity.startActivity() is invoked.
Seems like an invitation to race conditions.

My use case is setting UI preferences (e.g. a different layout) in a
PreferenceActivity. When I return to the main activity's onResume(), I
check for preference changes and if a new layout is requested, I use
the code snippet above.

Alternative design approaches would also be greatly appreciated.

--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-***@googlegroups.com
To unsubscribe from this group, send email to
android-developers+***@googlegroups.com<android-developers%***@googlegroups.com>
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[TreKing]

Also ...

Post by OldSkoolMark
but I get mysterious null pointer exceptions while the
runtime is trying to execute my onPause().

What mysterious exceptions?

Post by OldSkoolMark
Is calling finish() from within one of the Activity lifecycle callbacks
always a bad idea?

No idea, but this is something I would avoid, just because it "feels" wrong.

-------------------------------------------------------------------------------------------------
TreKing <http://sites.google.com/site/rezmobileapps/treking> - Chicago
transit tracking app for Android-powered devices

[Kumar Bibek]

I can't think of a problem with that. Do you see anything weird?

-Kumar Bibek
http://techdroid.kbeanie.com

Post by OldSkoolMark
activity.finish();
activity.startActivity(new Intent(activity, activity.getClass()));
in two places: onResume(), and in an onClick() method of an
AlertDialog. I'm getting the desired results when the code is called
from onClick(), but I get mysterious null pointer exceptions while the
runtime is trying to execute my onPause(). Is calling finish() from
within one of the Activity lifecycle callbacks always a bad idea?
This code makes me nervous even though it works in the onClick().
After I call activity.finish(), I would think activity is in a
questionable state by the time activity.startActivity() is invoked.
Seems like an invitation to race conditions.
My use case is setting UI preferences (e.g. a different layout) in a
PreferenceActivity. When I return to the main activity's onResume(), I
check for preference changes and if a new layout is requested, I use
the code snippet above.
Alternative design approaches would also be greatly appreciated.

[Mark Murphy]

Post by OldSkoolMark
Alternative design approaches would also be greatly appreciated.

Step #1: Refactor such that your UI initialization is not in
onCreate(), but is in some other private method (referred to here as
setupViews()).

Step #2: In onResume(), on a change in layout, call setupViews().

Step #3: There is no step #3.

In other words, why destroy and recreate the activity just to load in
a different layout? Heck, developers grumble constantly about Android
doing that by default for orientation changes...
--
Mark Murphy (a Commons Guy)
http://commonsware.com | http://github.com/commonsguy
http://commonsware.com/blog | http://twitter.com/commonsguy

Android Training in London: http://skillsmatter.com/go/os-mobile-server

[OldSkoolMark]

I did a little more homework:

http://stackoverflow.com/questions/3483182/activity-finish-method-waits-to-finish
http://stackoverflow.com/questions/2590947/about-finish-in-android

This makes me feel better about calling finish() and then
startActivity(). I may take the refactoring advice,
but in the meantime, I've isolated the problem to a thread that uses
AudioTrack to play short samples. I've arranged for it not to be
running
when the UI is being reset and all is good.

Post by Mark Murphy

Post by OldSkoolMark
Alternative design approaches would also be greatly appreciated.

Step #1: Refactor such that your UI initialization is not in
onCreate(), but is in some other private method (referred to here as
setupViews()).
Step #2: In onResume(), on a change in layout, call setupViews().
Step #3: There is no step #3.
In other words, why destroy and recreate the activity just to load in
a different layout? Heck, developers grumble constantly about Android
doing that by default for orientation changes...
--
Mark Murphy (a Commons Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy
Android Training in London:http://skillsmatter.com/go/os-mobile-server

[niko20]

You definitely have to guarantee that any AudioTrack instances are
done playing (stopped) AND released BEFORE you call finish().
Otherwise you will get Null exceptions on your app closing, just as
you found.

So basically if you have another thread you have to put some kind of
flag that waits for the AudioTrack to actually clear and release
before your app exits.

-niko

http://stackoverflow.com/questions/3483182/activity-finish-method-wai...http://stackoverflow.com/questions/2590947/about-finish-in-android
This makes me feel better about calling finish() and then
startActivity(). I may take the refactoring advice,
but in the meantime, I've isolated the problem to a thread that uses
AudioTrack to play short samples. I've arranged for it not to be
running
when the UI is being reset and all is good.

Post by Mark Murphy

Post by OldSkoolMark
Alternative design approaches would also be greatly appreciated.

Step #1: Refactor such that your UI initialization is not in
onCreate(), but is in some other private method (referred to here as
setupViews()).
Step #2: In onResume(), on a change in layout, call setupViews().
Step #3: There is no step #3.
In other words, why destroy and recreate the activity just to load in
a different layout? Heck, developers grumble constantly about Android
doing that by default for orientation changes...
--
Mark Murphy (a Commons Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy
Android Training in London:http://skillsmatter.com/go/os-mobile-server

[OldSkoolMark]

I already flush(), stop(), and release() when I clean up. How do I
tell when AudioTrack is done?

Post by niko20
You definitely have to guarantee that any AudioTrack instances are
done playing (stopped) AND released BEFORE you call finish().
Otherwise you will get Null exceptions on your app closing, just as
you found.
So basically if you have another thread you have to put some kind of
flag that waits for the AudioTrack to actually clear and release
before your app exits.
-niko

http://stackoverflow.com/questions/3483182/activity-finish-method-wai...
This makes me feel better about calling finish() and then
startActivity(). I may take the refactoring advice,
but in the meantime, I've isolated the problem to a thread that uses
AudioTrack to play short samples. I've arranged for it not to be
running
when the UI is being reset and all is good.

Post by Mark Murphy

Post by OldSkoolMark
Alternative design approaches would also be greatly appreciated.

Step #1: Refactor such that your UI initialization is not in
onCreate(), but is in some other private method (referred to here as
setupViews()).
Step #2: In onResume(), on a change in layout, call setupViews().
Step #3: There is no step #3.
In other words, why destroy and recreate the activity just to load in
a different layout? Heck, developers grumble constantly about Android
doing that by default for orientation changes...
--
Mark Murphy (a Commons Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy
Android Training in London:http://skillsmatter.com/go/os-mobile-server