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