I also wonder what the correct implementation would be.
If the design philosophy is "save on back", then why does this default
to
RESULT_CANCELED?
My workaround is to call "finish()" in the "onPause()" method, right
after "setResult(...)".
This results in 2 calls to onActivityResult(..): One with
RESULT_CANCELED, and one with RESULT_OK with the correct bundles
passed.
Furthermore, LogCat says:
W/ActivityManager( 6246): Duplicate finish request for
HistoryRecord{4009e378 {org.openintents/
org.openintents.shopping.share.ListShareSettingsActivity}}
Since there is a warning, this can not be 100% correct, but it seems
to work. I wonder what the "correct" solution would be - to pass a
bundle from a subactivity when the user presses the back button...
Peli
On Mar 27, 5:54 am, tenacious <[EMAIL PROTECTED]> wrote:
> I've encountered this paradigm too and would also like to know why
> results can't be set as late as onPause? Hopefully somebody
> knowledgeable can chime in...
>
> Having the differing behaviors between "confirm" and onPause() is
> causing pain because I want to have the "cancel" button act like
> confirm (the user is always saving unless explicitly clearing all
> fields or clicking a cancel/delete button)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[EMAIL PROTECTED]
Announcing the new M5 SDK!
http://android-developers.blogspot.com/2008/02/android-sdk-m5-rc14-now-available.html
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
