Today we checked in several important new features that represent a major leap forward for Smack. We are now closer to the final release and a beta version may be released in a few weeks. This time it was the turn for:
Add support for reconnection when connection is abruptly closed
Presence of available contacts should be changed to offline when connection is closed
Update XMPPError to be compliant with RFC3920
One of our major goals for the next Smack release is to be fully XMPP 1.0 compliant. We are now working on:
Add support for multiple bodies and support for setting the body language
Add support for JID as an object
Add support for pub-sub
Almost all of the above new features were contributed by community members. And I want to thank you all for your support. In particular, the reconnection feature was implemented by Francisco Vives so I will let him give you a more in depth description of the new cool feature.
The purpose of the ReconnectionManager is to make the XMPPConnection auto recoverable under a crash. When the XMPPConnection went down, the listener ReconnectionManager starts a thread that will attempt to reconnect frequently.
Additionally the XMPPConnection can connect() and disconnect() as many times as it is needed.
How to upgrade
There are some modifications that an XMPPConnection client MUST perform to keep it working:
Afther XMPPConnection creation, invoke connect();
In the previous version, the XMPPConnection constructor makes a new instance and performs the connection. Now the constructor only create the instance and the method connect() performs the server connection.
Every ConnectionListener implementor MUST implement the following methods:
a. connectionClosed()
Used when the user manually closed the connection through disconnect(). Implementations of this method should clean the listener.
b. connectionClosedOnError(Exception e)
After an exception occurs the connection temporarily goes down and the reconnection mechanism will try reconnect periodically. Recommended implementation of this method is do nothing.
c. attemptToReconnectIn(int seconds)
Every second left to the reconnection attempt. This method is useful to advice the user that a reconnection will happened.
d. conectionReestablished()
After a connection was closed on error, the reconnection will attempt to reconnect periodically, when succeed this method is invoked. Implementors offen do nothing, while others report the reconnection to the user.
e. reconnectionFailed(Exception e)
A reconnection attempt has failed. Typical implementations do nothing.
The ReconnectionManager doesn’‘t sound like anything a mindful programmer wouldn’'t have already done themselves.
I have a process that pretty well does exactly what your “new feature” does. I have a ConnectionListener and if it detects the connection being lost I enter a loop that tries to reconnect every 10 seconds. While it is trying to reconnect it is in a “degraded mode” i.e. it still maintains its data models based on events it is receiving from another process but it doesn’'t attempt to forward those messages on to the chat server (using it like pub/sub).
Surely this is something that is best left to the application programmer and not in the smack library?
Also, what is this new pub/sub feature all about? I didn’'t have any problem implementing a pub/sub application with the current version of Smack.
According to Francisco, in order to establish a connection using the new XMPPConnection, the connect() method must be invoked. In my opinion, this change breaks the fundamental method of making a connection using Smack, i.e. all existing clients need to change their code to work with the new Smack.
For better backward compatibility, would it be better to try maintain the existing behaviour of the XMPPConnection constructor, but add a new Constructor or factory method for those who are keen on using the new method with the new API?
According to Francisco, in order to establish a connection using the new XMPPConnection, the connect() method must be invoked. In my opinion, this change breaks the fundamental method of making a connection using Smack, i.e. all existing clients need to change their code to work with the new Smack.
There are many other changes that require a code audit anyways. For example, most psuedo-enums were moved to real enums (since Java 5 supports that natively).
Adding a connect method is the least of the problems when moving from 2.2 to 3.0.
Hi stoopidboi, backward compatibility was not possible since one of the objectives of the development was to have an XMPPConnection able to tell connect and disconnect many times, and also to deal with an XMPPConnection before a connection is established.