You may want to seriously consider just having a single service and Binder interface, with calls on to that top-level binder interface to get the secondary interface(s) the client wants. In general I find this cleaner than setting things up where there are an unbounded number of Intent objects you can bind to (keep in mind that the activity manager needs to set up and hold a new kind of connection object for each of these), or ending up with multiple service components.
Once you have a binder interface, you have a mechanism for very rich interaction between the service and client through whatever API you want to describe in aidl. On Wed, Jul 1, 2009 at 3:56 PM, Gert <gsch...@gmail.com> wrote: > > For completeness, I ended up going this: > > My service is maintaining (dynamic) pools of (dynamic) collaberation > objects, so I ended up with 2 services: > MyPoolService, bound with: > action=package.IMyPoolSerivice > data=package:poolname > and MyCollaberationService, bound with: > action=package.IMyCollaberationService > data=package:poolname#id > > This way I return a binder per pool, and a binder per pool- > collaberation pair, and I can keep (and dynamically create) the state, > in the binders. Perhaps using the data Uri to select a specific > (binder) instance isn't the way this is intended, but it does map well > to "this service operates on that data". > > Regards, > Gert Scholten > > On Jul 1, 11:57 pm, Dianne Hackborn <hack...@android.com> wrote: > > Good point, you can make up whatever action string you want (provided it > has > > your appropriate namespace); it is a convenient convention for this to be > > the fully qualified name of the interface that is being requested. > > > > On Wed, Jul 1, 2009 at 1:42 PM, Bart van Wissen <bartvanwis...@gmail.com > >wrote: > > > > > > > > > > > > > I think you can actually use the Intent's action to select the > > > implementation stub that you need. In the examples, the class name is > > > used, but I think you can use anything you want, as long as you create > > > the appropriate intent filter for the service. > > > > > On 1 jul, 20:33, Gert <gsch...@gmail.com> wrote: > > > > I have a service working with selectable backends internally, and the > > > > user is able to select which on to bind to. I was hoping to optimize > a > > > > bit by have that selection made by the bindService call, and just > keep > > > > a single Binder per backend implementation. Guess I'll just create a > > > > new Binder per bindService, and point it to the backend to use. > > > > > > Anyway, thanks for the information - following the the documentation > > > > it is :) > > > > > > Regards, > > > > Gert Scholten > > > > > > On Jul 1, 6:24 pm, Dianne Hackborn <hack...@android.com> wrote: > > > > > > > Yeah that is a little wrong... the extras are very complicated, > > > because the > > > > > bind is cached in various places. So you will see the extras for > > > -some- > > > > > request to bind, but not necessarily the current one. > > > > > > > I would strongly strongly strongly urge against using extras here. > > > There > > > > > really is no need at all -- you will be getting back a full IPC > > > interface to > > > > > the object, through which you can do whatever interaction and data > > > passing > > > > > you want. The Intent in this API is intended -only- to identify > which > > > > > interface you are interested in. (I think I had intended the code > to > > > strip > > > > > out the extras because of how undefined it is about what you will > get, > > > but > > > > > apparently had forgotten to do that.) > > > > > > > On Tue, Jun 30, 2009 at 11:25 AM, Gert <gsch...@gmail.com> wrote: > > > > > > > > Hi, > > > > > > > > I have a question about the availability of the extras in an > intent > > > > > > passed to Service.onBind(). The documentation at > > > > > > http://developer.android.com/reference/android/app/Service.html#onBin...)< > > >http://developer.android.com/reference/android/app/Service.html#onBin.. > .> > > > > > > specifically states "Note that any extras that were included with > the > > > > > > Intent at that point will not be seen here.". However, extras are > > > > > > available (emulator, SDK 1.5). > > > > > > > > Is the documentation off/outdated and are the extras available > > > > > > intentionally, or are they unintentionally exposed to the onBind > > > > > > method? Can we rely on extras remaining available at this point? > > > > > > > > Regards, > > > > > > Gert > > > > > > > -- > > > > > Dianne Hackborn > > > > > Android framework engineer > > > > > hack...@android.com > > > > > > > Note: please don't send private questions to me, as I don't have > time > > > to > > > > > provide private support, and so won't reply to such e-mails. All > such > > > > > questions should be posted on public forums, where I and others can > see > > > and > > > > > answer them. > > > > -- > > Dianne Hackborn > > Android framework engineer > > hack...@android.com > > > > Note: please don't send private questions to me, as I don't have time to > > provide private support, and so won't reply to such e-mails. All such > > questions should be posted on public forums, where I and others can see > and > > answer them. > > > -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
