A discussion on StackOverflow recently has me convinced I'm still not sure when using AIDL is good and when it is bad.
-------------- Somebody was inquiring about the techniques described in the REST applications in Android Google I|O 2010 presentation. In particular, he asked about ways a service could let an activity know when work was done. I rattled off a roster of typical approaches -- broadcast Intents, listener objects supplied via local binding, etc. While the presentation was discussing the still-not-open-sourced Twitter app, we believe that some of the same techniques are used in the Google I|O 2010 conference app. As it turns out, that app uses none of my standard bag of tricks for service->activity communications. Rather, the activity supplies a ResultReceiver implementation *as an Intent extra* on the startService() call...and the service can call back to the activity using this ResultReceiver. Now, I hadn't stumbled across ResultReceiver before, and I couldn't quite figure out how something passed as an Intent extra could have a custom implementation like this. After all, the object gets rebuilt from pieces by the receiver of the Intent, much like Serializable does, so the receiver of the Intent would wind up with some generic ResultReceiver implementation...right? Looking at the ResultReceiver source code -- which I don't fully grok -- it appears as though if you pour a ResultReceiver into a Parcelable structure, it creates an AIDL-based bridge between the original instance (the custom one from the activity) and the new instance (used by whoever gets the Intent). So when the service calls its ResultReceiver, that ResultReceiver uses AIDL and the Binder system to communicate back to the original ResultReceiver created by the activity. This, of course, is seriously cool. And, across process boundaries, this makes perfect sense. However, it does mean that within a process, we're going through AIDL and the Binder system when we use ResultReceiver, or at least when we pass one as an Intent extra. Does that mean: -- that the performance overhead I thought we had with AIDL/Binder within a process isn't really there? Or... -- that the overhead is there, but so long as you don't use it much, it won't be a big deal (which I suspect is the answer)? Or... -- that the overhead is there, should be avoided, ResultReceiver is a bad idea, and its use in stuff like the Google I|O 2010 conference app is merely unfortunate? I'm just trying to make sure I am giving the proper advice to people. Plus, if ResultReceiver is considered A Really Good Thing, I have some writing to do. Thanks! -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy _The Busy Coder's Guide to *Advanced* Android Development_ Version 1.6 Available! -- 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
