You can call it a design flaw, but the design is that at the point you say to finish your activity, the current result is bundled up and delivered, and than we go through the normal pause etc flow to transition from that activity to the previous. At this point in time this just isn't going to change.
On Wed, Mar 4, 2009 at 6:20 AM, Chronos <g358279012044...@gmail.com> wrote: > > Thanks for your input ;) > > I'm also discussing this with my colleagues - and I consider this > either a bug or a design flaw... > onPause() should be guaranteed to run before onActivityResult() - in > more detail: setResult() in onPause() should have an effect in > onActivityResult(). > > > On Mar 4, 3:03 pm, Stoyan Damov <stoyan.da...@gmail.com> wrote: > > So you really don't want to *return*, hence the setResult() isn't > > appropriate in your case. You just want to communicate something back > > to the parent activity, is that right? In this case you want to use a > > broadcast receiver. > > > > Cheers > > > > On Wed, Mar 4, 2009 at 3:28 PM, Chronos <g358279012044...@gmail.com> > wrote: > > > > >> You should set the result when your child activity is about to exit - > > >> for example I set the result from my child activity when a button is > > >> clicked and just before exiting it, e.g.: > > > > >> // in a button click handler > > >> setResult(...); > > >> finish(); > > > > > This is the way they do it in the samples, but it makes not much sense > > > - I don't want to have an "exit" or "save" button; users should be > > > able to hit "back" (listening for "back" is my current workaround, but > > > it will probably fail under certain circumstances). > > > > >> The documentation for Activity mentions that "When an activity exits, > > >> it can call setResult(int) to return data back to its parent." > > > > > Yes - it says so. But it doesn't say WHEN - this is my problem; I > > > don't know when to setResult efficiently: onPause() doesn't work, > > > onSaveInstanceState() doesn't work; listening for "back" ain't > > > failproof; listening for data changes is ineffective. *sigh* > > > > >> When you're getting a NPE what does you stacktrace look like? > > > > > Nevermind the NPE - it comes from RESULT_CANCELLED and Intent.getExtras > > > () returning null. > > > > >> btw, you shouldn't assume that the parent activity will outlive the > > >> child one - that is, the fact that your parent activity has spawned > > >> another one for result doesn't mean it won't be destroyed should the > > >> system need to destroy it because it's not in the foreground. > > > > > Yes, I don't. > > > > > On Mar 4, 1:58 pm, Stoyan Damov <stoyan.da...@gmail.com> wrote: > > >> On Wed, Mar 4, 2009 at 2:41 PM, Chronos <g358279012044...@gmail.com> > wrote: > > > > >> > Thanks for the idea - but this is not my problem: the result sent is > > >> > the result I set in the onCreate method (a default result); if I > fail > > >> > to do this, I will get a java.lang.NullPointerException, which > > >> > underlines my point - setResult() in onPause() is too late; my > > >> > activity is not cancelled either - I always get an > Activity.RESULT_OK. > > > > >> You should set the result when your child activity is about to exit - > > >> for example I set the result from my child activity when a button is > > >> clicked and just before exiting it, e.g.: > > > > >> // in a button click handler > > >> setResult(...); > > >> finish(); > > > > >> The documentation for Activity mentions that "When an activity exits, > > >> it can call setResult(int) to return data back to its parent." > > > > >> When you're getting a NPE what does you stacktrace look like? > > > > >> > Do you think, onPause() is the correct point to setResult() ? It > seems > > >> > to me, that the result has already been transmitted in some > > >> > communication queue at this point - all calls to setResult() are in > > >> > vain. > > > > >> btw, you shouldn't assume that the parent activity will outlive the > > >> child one - that is, the fact that your parent activity has spawned > > >> another one for result doesn't mean it won't be destroyed should the > > >> system need to destroy it because it's not in the foreground. > > > > >> > On Mar 4, 12:39 pm, Stoyan Damov <stoyan.da...@gmail.com> wrote: > > >> >> Actually read carefullyhttp:// > developer.android.com/reference/android/app/Activity.html#star...) > > > > >> >> On Wed, Mar 4, 2009 at 1:31 PM, Stoyan Damov < > stoyan.da...@gmail.com> wrote: > > >> >> > Re: > > > > >> >> > - setResult() in client.onPause() is called TOO LATE; the result > has > > >> >> > already been transmitted to the parent (although the method > > >> >> > client.onPause() seems to be called in time). > > > > >> >> > If the result has been already set, this means that the result > value > > >> >> > is CANCELLED immediately after your child activity started. > > >> >> > Read carefully about the launchMode property - > > >> >> > > http://developer.android.com/guide/topics/manifest/activity-element.h... > > > > >> >> > Cheers > > > > >> >> > On Wed, Mar 4, 2009 at 12:59 PM,Chronos< > g358279012044...@gmail.com> wrote: > > > > >> >> >> Hello there ;) > > > > >> >> >> I have some - maybe simple - problem; unfortunately I cannot > find a > > >> >> >> solution: > > > > >> >> >> I have two activities which communicate via: > startActivityForResult(), > > >> >> >> setResult(), onActivityResult. I will call the first activity > "parent" > > >> >> >> and the second one "client", although this may not be > technically > > >> >> >> correct; so the order of calls must be: > > > > >> >> >> parent.startActivityForResult() > > >> >> >> client.setResult() > > >> >> >> parent.onActivityResult() > > > > >> >> >> Now, where should I call setResult in the client activity ? > > > > >> >> >> I have already tried various possibilities which have all > failed: > > > > >> >> >> - setResult() in client.onPause() is called TOO LATE; the > result has > > >> >> >> already been transmitted to the parent (although the method > > >> >> >> client.onPause() seems to be called in time). > > >> >> >> - client.onSaveInstanceState() is not guaranteed to be called > at all > > >> >> >> (and the documentation hints at the same timing problem). > > >> >> >> - The only TECHNICALLY POSSIBLE solution seems to implement a > change- > > >> >> >> listener for any screen element and set the result there. This > may > > >> >> >> work in theory, but is NOT VIABLE in practice: (1) it is > strenuous and > > >> >> >> error-prone for activities with many elements; (2) it gets even > more > > >> >> >> complicated, when side-effects kick in (change one field in > dependency > > >> >> >> to another); (3) it is really slow, since one must write ALL > contents > > >> >> >> any time, a SINGLE element changes (and the generic Intent > > >> >> >> communication is already slow by design). > > > > >> >> >> To me, it would seem most natural to overload the onPause() > method and > > >> >> >> setResult() there - once and for all. There MUST be some easier > way > > >> >> >> than implementing zounds of listeners ... > > > > >> >> >> Am I overlooking something ? Another listener I haven't stumbled > over > > >> >> >> yet ? Please prove me wrong ;) > > > -- 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. 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 -~----------~----~----~----~------~----~------~--~---
