This is not a problem. The calling activity supplies the request code, and
the called activity supplies the result code. This is why they are two
distinct values, so there can be no overlap or ambiguity in the assigned
values.
On Sun, Dec 28, 2008 at 9:40 PM, brnzn wrote:
>
> Something like An
Great points!
I am going to try and produce this patch. You are welcome to join me
in this effort.
Am going to download the source.
-
Anil
On Dec 28 2008, 11:40 pm, brnzn wrote:
> Something like Anil is suggesting is probably eventually going to be
> essential for the platform as without it re-u
Something like Anil is suggesting is probably eventually going to be
essential for the platform as without it re-using 3rd party activities
is problematic.
Imagine a case where from your activity you want to invoke two
different 3rd party activities to do some particular tasks and give
you back r
I am willing to collaborate with anyone interested to implement this.
I don't have the ability, knowledge or desire to implement it alone.
BTW, are you the Dianne in the Android video here?
http://www.youtube.com/watch?v=3aUjukCdPyQ
On Dec 12, 3:01 pm, "Dianne Hackborn" wrote:
> Whoops, sorry I
Whoops, sorry I missed that you were talking about having the callback be a
method name. That would indeed be more possible to implement... but still,
this is not nearly as high a priority as many other things, so the way to
get this done is to contribute a patch.
On Fri, Dec 12, 2008 at 12:59 P
(This would be more appropriate for the android-framework group to talk
about changes to the platform.)
There is currently no plan for doing this kind of thing, because it is
extremely problematic to deal with the case when the activity's process is
killed and restarted between startActivityForRes
6 matches
Mail list logo
