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?