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 ;) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
