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
-~----------~----~----~----~------~----~------~--~---
