Use .asBinder() to retrieve the IBinder that the stub is talking through (or
of the local implementation). This object will be the same every time you
receive the interface.
On Mon, Dec 1, 2008 at 1:04 PM, DulcetTone <[EMAIL PROTECTED]> wrote:
>
> I have found it convenient to make AIDL interfaces in pairs -- one for
> how the client calls the server, and one by which a server can call
> back into the client. However, I find that the design of the Proxy/
> Stub model (which I confess I don't fully grasp) causes me issues in
> the method I use to have a client identify itself.
>
> I have calls in the server interface where the client hands in a
> reference to its CLIENT interface (which is convenient, as they are
> all Parcelable). If the server ever decides it wants to call back to
> the client, it simply calls methods on this interface. HOWEVER...
> each time an interface is handed in to the server, it arrives in
> server space as a new stub -- there is no means by which they can be
> compared against each other and so each client appears new and
> distinct every time it calls a function on the server.
>
> Is there any way I can see which of these interfaces are for the same
> client, or do I have to code up my own Parcelable class that has a
> unique hash of some kind? For instance, do instances of the "same"
> interface already HAVE a hash function on them that would return the
> same value?
>
> e,g.: if I do this...
>
> ServiceConnection serviceConnection = new ServiceConnection() {
> public void onServiceConnected(ComponentName name, IBinder
> service)
> {
> myService =
> IMyService.Stub.asInterface((IBinder)service);
> try {
> myService.registerClient(myClientInterface);
>
> myService.doubleCheckThatClientHandle(myClientInterface);
> } catch (RemoteException e) {
> }
> }
>
> public void onServiceDisconnected(ComponentName name) {
> myService = null;
> }
> };
>
> and the server's implementation of registerClient() and
> doubleCheckThatClientHandle() examine the client interface, there is
> no way for it to easily see that the same client is being referred to.
>
> I suppose the lightest weight fix might be for the service to return a
> unique GUID when a client registers, and map them on its side. The
> client, in turn, could provide that GUID each time it wants to
> identify itself on subsequent function calls.
>
> I hope this makes sense.
>
> tone
>
> >
>
--
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. 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
[EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
