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