> 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 android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
No comments:
Post a Comment