When I call client.close and get the void clientDisconnected(Client client, DisconnectInfo di) event. DisconnectInfo is always null.
looking at the source
Google Code Archive - Long-term storage for Google Code Project Hosting.
[java]public void close()
{
checkRunning();
closeConnections( null );
} [/java]
[java]
protected void closeConnections( DisconnectInfo info )
{
if( !isRunning )
return;
// Send a close message
// Tell the thread it’s ok to die
for( ConnectorAdapter ca : channels ) {
if( ca == null )
continue;
ca.close();
}
// Wait for the threads?
// Just in case we never fully connected
connecting.countDown();
fireDisconnected(info);
isRunning = false;
} [/java]
The help page (https://wiki.jmonkeyengine.org/legacy/doku.php/jme3:advanced:networking?s[]=disconnect&s[]=info) hints at it working.
public void clientDisconnected(Client c, DisconnectInfo info){} Implement here what happens after the server kicks this client. For example, display the DisconnectInfo to the user.
Is this feature just not implemented yet? or should I be taking another approach to get the functionality.
Thanks again!
You only get DisconnectInfo if the server kicked you (and I think on error, also but I can’t remember for sure). Otherwise, if you are closing the client yourself then presumably you already know why you were disconnected.
My main concern is that the method signature in ClientStateListener is public void clientDisconnected(Client client, DisconnectInfo di) and di is going to be null in large number of use cases. This functionality isn’t make or break for me, It is just that method implies to me I should have some sort of information about the disconnect. The DisconnectInfo class has an error and reason property, I would assume if it is a normal disconnect the error would null and reason would still be populated.
The reason is set only if the server provides one when it disconnects you. Otherwise, that will be null, too.
I could have five different methods all with different method signatures that you could have to implement to catch all of the different cases… or we can have one method and make the users check for null. I think the second case is better.
The only reasonable alternative would be to let you provide your own DisconnectInfo on close()… because I cannot guess what you’d want included in it. But that seems a little strange to be sending an object to your own code with the reason that you would already know.
Maybe the tutorial needs to be updated (I don’t know, I didn’t write it)… but I think the Javadoc is pretty clear:
http://hub.jmonkeyengine.org/javadoc/com/jme3/network/ClientStateListener.html#clientDisconnected(com.jme3.network.Client,%20com.jme3.network.ClientStateListener.DisconnectInfo)
Called when the client has disconnected from the remote server. If info is null then the client shut down the connection normally, otherwise the info object contains additional information about the disconnect.
Like I said its not the big of deal to me, just wanted to voice my opinion. Thanks for taking the time to look at it.