RemoteEventService.addListener() may or may not call back

[GoogleCodeExporter]

RemoteEventService.addListener() is documented as calling back only if this
is the first listener for the domain [for this client, apparently].

In my application, I need to know when I am actually listening to the
domain and ready to receive events.  The callback is perfect for this,
*unless* another class (eg some sort of plug-in) happens to have registered
with the domain already.  If that happens, I may not have any easy way of
knowing that my callback will never be called.  (Everything is working for
me at the moment because I don't have plug-ins yet.)

I think the API would be more consistent if it always guaranteed to call
back.  If the RemoteEventService is already listening to the domain, it
could simply call back as soon as the listener is stored.  Technically,
such a change would break the existing API contract, but I'm not sure if
anyone would ever pass in a callback and be annoyed if it actually got
called.  The opposite is far more "surprising"!

Anyway, another option (which doesn't break the API contract) would be to
add a method such as 
RemoteEventService.isDomainActive(Domain aDomain) {
  return myDomainListenerMapping.contains(aDomain);
}

By calling that method, I could check whether the domain is active before
adding my listener, and I would know whether I can expect a callback.

Original issue reported on code.google.com by sean.flanigan@gmail.com on 15 Feb 2010 at 7:35

[GoogleCodeExporter]

The idea behind the callback usage is, that it is only called when a server 
call is
executed and a server call is only executed with the first listener 
registration call
for a domain. The server side does only know the domain registration and nothing
about listeners. That is why only a new domain registration executes a server 
call.
The second listener for the same domain won't execute a server call. But you are
right, the current handling of the callback is confusing and the callback 
onSuccess
should be simulated when no server call is done.

With version 1.1, there is a new access method 
RemoteEventService#getActiveDomains(),
but I think that method wouldn't help to solve your problem, because the domain 
is
directly marked as active and the server call may not already be finished.

It isn't possible to solve that for version 1.1, because the time is too short 
to the
release. I think it would be make sense to change the API contract with version 
1.2.
Maybe the callback could be replaced by a new interface which allows methods 
like
beforeRegistration and afterRegistration. That wouldn't need to "simulate" a 
callback.

Original comment by sven.strohschein@googlemail.com on 23 Feb 2010 at 10:15

• Changed state: Accepted

[GoogleCodeExporter]

Actually, I was thinking the other new method,
RemoteEventService#getRegisteredListeners(Domain), might solve my problem, in a
roundabout way: if getRegisteredListeners() returns a non-empty list, I know the
registration has already happened, and thus the callback will never happen.  
(I'm
assuming that getRegisteredListeners() only knows about local registrations, ie 
on
the same client.)

But the new interface you suggest certainly sounds cleaner, in the long run.

Original comment by sean.flanigan@gmail.com on 24 Feb 2010 at 12:01

[GoogleCodeExporter]

Yes, with that check it does also work, but it could be that the server call 
isn't
finished when the second listener is just registered. The listener can directly 
be
got with RemoteEventService#getRegisteredListeners(Domain) when
RemoteEventService#registerListener(...) is called (also when the callback 
wasn't
executed at the time). Is that a problem for your use case?

Original comment by sven.strohschein@googlemail.com on 28 Feb 2010 at 12:48

[GoogleCodeExporter]

So, what I said: "if getRegisteredListeners() returns a non-empty list, I know 
the
registration has already happened, and thus the callback will never happen" is 
not
true, because the server callback may not have happened yet?

Actually, none of this is a problem for my current use case, but I'm a little
concerned about the implications for modularity of client code.  Ideally, 
different
modules shouldn't have to know about each other (and whether they use 
GWTEventService).  

For now, I think the only approach which is both safe and modular is for all 
access
to RemoteEventService to go through a gatekeeper which knows whether the 
callback has
happened or not, and proxies the callbacks itself.  That's what I've got as a
workaround, but I wouldn't mind getting rid of it someday.

Original comment by sean.flanigan@gmail.com on 1 Mar 2010 at 3:44

[GoogleCodeExporter]

This handling should be optimized with future versions, but isn't a defect 
because it is working like intended and documented. Issue category changed to 
"enhancement".

Original comment by sven.strohschein@googlemail.com on 12 Sep 2011 at 9:33

• Added labels: Type-Enhancement
• Removed labels: Type-Defect