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 <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
