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 results. It's possible both those activities might use the same requestCode and resultCode values, meaning that in your onActivityResult() method, you're going to have a hard time figuring out what actually happened. There's a post on the developerLife blog where the author basically implemented what Anil is suggesting in his own Activity sub-class: http://developerlife.com/tutorials/?p=302 While this works, it re-purposes the requestCode parameter which should represent the verb (Add, delete, whatever) to instead be a unique identifier for the request. It would be better if the framework provided direct support for this. On Dec 15, 11:24 am, Anil <[email protected]> wrote: > 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" <[email protected]> wrote: > > > 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 PM, Dianne Hackborn > > <[email protected]>wrote: > > > > (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 startActivityForResult() and eventually > > > receiving the result. > > > > If this is something you really want, you are welcome to work on a patch > > > you can contribute to add the feature. On the priority list of the people > > > currently working on the platform, though, it is very low because: > > > > (1) Given the processing killing issue, an API as simple as being > > > described > > > is impossible to do, so it would need to be more complicated, making its > > > utility unclear. > > > > (2) Whatever "desired" API there is can just as easily be implemented by > > > the application, it doesn't need to be done in the framework. There is > > > very > > > little additional capabilities the framework has to do this, except > > > possibly > > > the chance to change the result from an int to a string (and so being able > > > to make it say a class name that it dynamically instantiates when > > > delivering > > > the result). > > > > On Fri, Dec 12, 2008 at 9:39 AM, Anil <[email protected]> wrote: > > > >> Objective: simpler and arguably more elegant design by making object > > >> oriented and remove the mass of switch statements that result using > > >> only > > >> one fixed callback method - onActivityResult(), Request Code and > > >> Result Codes. > > > >> Suggestion: modify API so that calling startActivityForResult() will > > >> be > > >> instead startActivityForResult(callbackMethodName). > > > >> where callbackMethodName is a method. We could simply use a String > > >> rather > > >> than Method, to keep things simple. > > > >> callbackMethodName(Bundle result) { > > >> } > > > >> If an error happens in the sub activity, then the exception that is > > >> thrown, > > >> is delivered to callbackMethodName() which must contain an empty try > > >> block > > >> at the beginning. > > >> try{ > > >> } catch(e1){ > > >> handle exception e1 thrown in the call to the sub activity > > >> } catch(e2) { > > >> handle exception e2 thrown in the call to the sub activity > > >> } > > >> now other normal code in callbackMethodName() > > > >> Any other result information is communicated by the Bundle result > > >> parameter. > > > >> (I have submitted it as a suggestion in issue tracker. > > >>http://code.google.com/p/android/issues/detail?id=1520) > > > > -- > > > Dianne Hackborn > > > Android framework engineer > > > [email protected] > > > > 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. > > > -- > > Dianne Hackborn > > Android framework engineer > > [email protected] > > > 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
