I might try adding the functionality myself by changing the source code. Before I do that, though, is there some reason it hasn’'t been added? Is it reasonable to go down this rabbit hole?
If you could possibly give a little bit of information about your use case. Why isn’'t it possible to create a new XMPPConnection object? That would help to answer the question of whether it is reasonable or not to venture down the rabbit hole.
I’‘m working on an application that will use XMPP (with Jive & Smack (Thank you! )) to do one-to-one chats, group chats and system messaging. We’'d like to have one XMPPConnection for all these purposes.
My part in the project is the one-to-one chat stuff. User presence is handled by other means so I need to sync that with the Roster. I need to listen for Message packets from users not already involved in a chat to launch a new chat (I call these “chat invites”). The group and messaging parts have packet listeners for other reasons and I don’‘t want to mix them up. That is, I don’'t want to have an overarching manager object controlling all. I want to keep them more decoupled.
For the one-to-one chat stuff I’'ve used dependency injection so far. I have a UserChat object that knows how to do just our (limited) chat requirements. One of the objects injected into it is a UserChatChannel. One implementation of UserChatChannel has an XMPPConnection. (Another impl is a mock object.)
But what happens if the XMPPConnection closes? Who is responsible for fixing it? The group chat part? The messaging part? The UserChatChannel? … None sound like a good candidate to me. To me it seems the likeliest candidate is the XMPPConnection itself.
I like what you’‘ve said about keeping the Smack API as simple as possible, though. So maybe another way would be to create a SelfHealingXMPPConnection that could deal with fixing connections and such. It could send events when a connection is reestablish or a timeout period has elapsed. It would also know how to replicate an XMPPConnection. Maybe this would also be the better way to go for handling SSL variations (??? I don’'t have a clue here ???).
So, just to extend the metaphor, do I go down the hole, or cage the rabbit?
I’‘ll admit I was a little confused by your implementration strategy but I won’'t let that distract me from helping you solve your problem.
I think your proposed solution is a good one. Having an object that controls the XMPPConnection, creating a new one when it dies etc, would seem to be the most apt solution in your case. You could create an event driven framework to notify the different classes that need notifying when a new connection is created or the old one is disconnected.
Smack is used for many things by many people. I know I have cooked it up to do things that when it was first created weren’'t ever dreamed of or smack never had that intended purpose. My first option always in these cases is to attempt to implement it myself without changing the API and when I am complete, if I see that it is something that may be worthwile contributing back to smack or the community in general, I do so.