That would mean prefixing all the methods with their dynamic identifiers to select the correct serivice object, such as: void myPoolMethod(poolId, <real parameters>) void myCollabMethod(poolId, collabId, <real parameters>); and then looking up the specific instance with a global lock in some form of registry. The poolId and collabId need to be unique over (undesired) service destruction, which means lookups of strings in hashtables... getOrCreatePool(poolid).getOrCreate(collabId).myMethod(...); Do you know how expensive is it to keep another connection object around (well, setting it up most likely) versus 1-2 hashtable lookups in every RPC call?
I chose this design since the expectation is 0-1 bindings to a single pool and, depending on the activity, one-few bindings to one of those collaboration objects per activity. You could compare the basic structure to the more traditional content (provider) based apps that work with a "list of items" (pool), and "specific item" (collab thing). Not all activities will need a binding to the pool, or more then one collab object. Also, if you bind to a binder linked to a specific pool/collabobject, you can do easy refcounting allowing for dynamic destruction of the server object trees, else I think you'll have to force the client app to not only unbind the service, but also remove their references. This might not be an real point though, just more bookkeeping. On Jul 2, 1:11 am, Dianne Hackborn <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> 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 <[email protected] > > >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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 > > > > > > [email protected] > > > > > > > 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 > > > [email protected] > > > > 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 > [email protected] > > 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 [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 -~----------~----~----~----~------~----~------~--~---
