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