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 <hack...@android.com> 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 <gsch...@gmail.com> 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 <hack...@android.com> 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 <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.
>
> --
> 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
-~----------~----~----~----~------~----~------~--~---
