ClientListener

Event handler that receives a notification when the ClientListener instance is removed from a LightstreamerClient through LightstreamerClient#removeListener. This is the last event to be fired on the listener.

Event handler that receives a notification when the ClientListener instance is added to a LightstreamerClient through LightstreamerClient#addListener. This is the first event to be fired on the listener.

Event handler that receives a notification each time the value of a property of LightstreamerClient#connectionDetails or LightstreamerClient#connectionOptions is changed.

Event handler that is called when the Server notifies a refusal on the client attempt to open a new connection or the interruption of a streaming connection. In both cases, the ClientListener#onStatusChange event handler has already been invoked with a "DISCONNECTED" status and no recovery attempt has been performed. By setting a custom handler, however, it is possible to override this and perform custom recovery actions.

Event handler that receives a notification each time the LightstreamerClient status has changed. The status changes may be originated either by custom actions (e.g. by calling LightstreamerClient#disconnect) or by internal actions.

The normal cases are the following:

• After issuing connect(), if the current status is "DISCONNECTED*", the client will switch to "CONNECTING" first. Then it will try to open a connection to the Server, by trying WebSocket first, then bare http. After a successful connection, the status will switch to "CONNECTED:STREAM-SENSING".
  • Now, if a WebSocket is available, the client will still check if the browser/environment permits the communication; then the status will switch to "CONNECTED:WS-STREAMING", otherwise the client will resort to http.
  • If only http is available, the Client will check if the browser/environment permits streaming at all; then the status will switch to "CONNECTED:HTTP-STREAMING", otherwise it will switch to "CONNECTED:HTTP-POLLING" as a last resort.
  
  On the other hand if the status is already "CONNECTED:*" a switch to "CONNECTING" is usually not needed.
• After issuing disconnect(), the status will switch to "DISCONNECTED".
• In case of a server connection refusal, the status may switch from "CONNECTING" directly to "DISCONNECTED". After that, the ClientListener#onServerError event handler will be invoked.

• In case of Server unavailability during streaming, the status may switch from "CONNECTED:*-STREAMING" to "STALLED" (see ConnectionOptions#setStalledTimeout). If the unavailability ceases, the status will switch back to ""CONNECTED:*-STREAMING""; otherwise, if the unavailability persists (see ConnectionOptions#setReconnectTimeout), the status will switch to "DISCONNECTED:TRYING-RECOVERY" and eventually to "CONNECTED:*-STREAMING".
• In case the connection or the whole session is forcibly closed by the Server, the status may switch from "CONNECTED:*-STREAMING" or "CONNECTED:*-POLLING" directly to "DISCONNECTED". After that, the ClientListener#onServerError event handler will be invoked.
• Depending on the setting in ConnectionOptions#setSlowingEnabled, in case of slow update processing, the status may switch from "CONNECTED:WS-STREAMING" to "CONNECTED:WS-POLLING" or from "CONNECTED:HTTP-STREAMING" to "CONNECTED:HTTP-POLLING".
• If the status is "CONNECTED:*-POLLING" and any problem during an intermediate poll occurs, the status may switch to "CONNECTING" and eventually to "CONNECTED:*-POLLING". The same may hold for the "CONNECTED:*-STREAMING" case, when a rebind is needed.
• In case a forced transport was set through ConnectionOptions#setForcedTransport, only the related final status or statuses are possible. Note that if the transport is forced while a Session is active and this requires a reconnection, the status may do a preliminary switch to CONNECTED:STREAM-SENSING.
• In case of connection problems, the status may switch from any value to "DISCONNECTED:WILL-RETRY" (see ConnectionOptions#setRetryDelay), then to "CONNECTING" and a new attempt will start. However, in most cases, the client will try to recover the current session; hence, the "DISCONNECTED:TRYING-RECOVERY" status will be entered and the recovery attempt will start.
• In case of connection problems during a recovery attempt, the status may stay in "DISCONNECTED:TRYING-RECOVERY" for long time, while further attempts are made. On the other hand, if the connection is successful, the status will do a preliminary switch to CONNECTED:STREAM-SENSING. If the recovery is finally unsuccessful, the current session will be abandoned and the status will switch to "DISCONNECTED:WILL-RETRY" before the next attempts.

By setting a custom handler it is possible to perform actions related to connection and disconnection occurrences. Note that LightstreamerClient#connect and LightstreamerClient#disconnect, as any other method, can be issued directly from within a handler.