-
-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dispatch better disconnect events #39
Dispatch better disconnect events #39
Conversation
That lets us distinguish between an expected and unexpected disconnect.
@@ -29,7 +29,7 @@ public WebSocketClient createInstance(WebSocketClient.WebSocketClientCallback we | |||
return new OkHttp3WebSocketClient(mClient, webSocketClientCallback, hostUrl); | |||
} | |||
|
|||
class OkHttp3WebSocketClient implements WebSocketClient { | |||
static class OkHttp3WebSocketClient implements WebSocketClient { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was otherwise being linked to the outer class at runtime, leading to a possible memory leak. The Factory and Client do not need to be tied together for any reason, so this should be declared static.
callbacks.transcript.assertEventsSoFar("onLiveQueryClientDisconnected: false"); | ||
} | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
extra space here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Whoops. Will fix
|
||
|
||
@Test | ||
public void testCallbackNotifiedOnDisconnect_expected() throws Exception { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this should be camel case
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, ok - I've typically used _
to delineate a related test with different expectations or states.
Looking at the Parse-SDK-Android repo though, I see that does not appear to be the case. Will rename.
A socket failure implies that the socket also died, so it makes sense to also dispatch a disconnected event.
First, the close() call was wrong, because the RFC expects a close reason in the 1000-1999 range, but we were passing 200.
I confirmed that changing to
1000
properly closes the socket, and cleans up the connection (which was otherwise causing a memory leak because it didn't close properly).This also adds the
userInitiated
boolean to theonLiveQueryClientDisconnected()
callback, so that listeners can choose how to respond based on if it was expected or not (an error disconnect may mean it needs to be reconnected; while an expected disconnect() close should not auto-reconnect)