On Fri, Jun 25, 2010 at 3:50 PM, Dianne Hackborn <[email protected]> wrote: > AIDL/Binder by design don't have a performance impact when making a call in > the same process. This turns into a direct call on to the target's > interface implementation.
Ah! That's good to know. > The big thing this introduces is a whole lot more effort and complexity for > the developer, as they now need to deal with AIDL interfaces. At least that's hidden for ResultReceiver, which has the AIDL stuff baked in. > If the purpose of this code (and I haven't looked at it to know) is to send > a command to the service and get told later when it is done, then this is a > reasonable approach. There are some potential edge cases where the result > won't be delivered though (if the process is in the background and gets > killed and its service restarted), so I would recommend giving it a > PendingIntent to deliver a result to the activity rather than an interface > to a live object. You can make this with Activity.createPendingResult(). :: scribbles furiously in notebook :: > On the other hand, if the purpose of this is to tell the service about the > activity running for it to know about and send information back during that > time, it is bad because this is not the semantics of startService(). You > want to use bindService() for that. Yeah, I haven't fully investigated the app, so I don't know precisely what your team's intentions were when they wrote it. But, this info is fantastic -- many 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
