addConnectionListener suggestion for v1.5

Smack Smack Dev
1

Matt and others,

I’‘ve created XMPPConnection(server,port,connect) as mentioned in XMPPConnection.connect thread today. Now I have a comment about the connectionListeners. They are split into separate interfaces for connection established and disconnect. With this split I can’'t have the same object implement both ConnectionListener and ConnectionEstablishedListener interfaces. The compiler complains when I try to add my dual listener object connectionDisplay with con.addConnectionListener(connectionDisplay);

Here’'s my question. Why are the connection listeners split into two interfaces? Why not just have a single connection listener with methods

connectionEstablished

connectionClosed

connectionClosedOnError

and remove the ConnectionEstablishedListener interface. With the current implementation of XMPPConnection, you can’‘t use ConnectionEstablishedListeners anyway (you can’‘t add a ConnectionEstablishedListener until after the connection is created and you can’'t call XMPPConnection.init to reconnect because its private).

If this sounds good, then I’‘ll make these changes and send someone my diffs. If you don’‘t want this kind of change, then I’'ll hack XMPPConnection and change the method called

addConnectionListener(ConnectionEstablishedListener connectionEstablishedListener) to addConnectionEstablishedListener and be done with it. Let me know.

Thanks,

Craig

2

After careful examination of XMPPConnection, PacketReader, and PacketWriter, I’‘ve determined implementing a reconnect mechanism for XMPPConnection is not a trival task. Using existing classes, a reconnect will require instantation of new PacketReader and PacketWriter objects (I think). Listeners are attached to these objects using lists, so somehow the listener lists will need to be copied to the new objects or the lists themselves moved out of the PacketReader and PacketWriter classes. This became quite involved quickly. So I think I’'ll abandon simple hacks on the code and request that reconnection be given consideration in a future smack release.

Craig