I was under the impression that you could (basically) only ship Parcelables over an RPC call, so the service can't return an interface, but must return a specific parcelable class. Methods invoked on this MyPool (object/interface) will not automagically pass though the RPC mechanism... am I missing what you are trying to say?
On Jul 2, 11:15 am, Dianne Hackborn <[email protected]> wrote: > No, have a method on the top-level interface that returns another > object/interface based on whatever parameters you give it: > > interface MyPool { > void doSomething(); > > } > > interface MyService { > MyPool getPool(int sel1, String sel2); > > } > > If needed you can have a release() method on MyPool for the client to > indicate when they are done with it. > > > > On Wed, Jul 1, 2009 at 11:45 PM, Gert <[email protected]> wrote: > > > 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. > > -- > 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 -~----------~----~----~----~------~----~------~--~---
