Aaah, _that_ is what you meant, I understand it now :) You bind the service, getting an (AIDL defined) interface back for the RPC calls, then you just call a method on that interface to get another AIDL defined RPC interface back, the same way the API example does the other way around for the callback. (Possible) extra ISomething.Stub creation, no extra bind and connection.
Thanks :) On Jul 2, 6:53 pm, Dianne Hackborn <[email protected]> wrote: > MyPool is an aidl interface, and you can pass references to such interfaces > across processes. The code I wrote was intended to be pseudo-aidl code, not > Java code, though I realize now that is probably not clear. > > On Thu, Jul 2, 2009 at 6:06 AM, Gert <[email protected]> wrote: > > > That would be impossible, unless android does some very fancy magic - > > since the service can run in a different process. > > > On Jul 2, 12:24 pm, Bart van Wissen <[email protected]> wrote: > > > Is the MyPool object actually passed by reference here, from the > > > service to the client? > > > So changes to the object are reflected at the service side and at any > > > clients that may share the same reference? > > > > On 2 jul, 11:15, 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 > > ... > > read more » --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
