I’‘m developing a client on top of Smack 3.x and am having trouble with spurious Chats being created when using File Transfer and Message Notification. I’‘ve followed the docs as best I can tell, so now I’'m stumped.
Here’'s the scenario: I have a ChatManagerListener listening for new Chats and reacting when a non-local Chat is created. I would expect to only see genuine incidences of new Chats triggering the chatCreated method, but instead I see the following:
In some cases, when I initiate a chat with a Spark client, the Spark client changes the thread ID and the response message shows up as a new Chat.
In some cases, when composing notifications come in, they create a new Chat
In some cases, when transferring a file, each Message packet triggers a new Chat (hundreds are created very quickly)
I haven’‘t quite pinpointed the patterns of when these things happen and when they don’'t, but they happen quite a bit. Any thoughts on what to look for?
This means that if messageType == null as in FileTransfer data messages or in Composing events the filter will process those messages. Since both kind of messages doesnt have a Message.Thread, they will locate the chat using the From field and probably create a new chat associated to the receiver JID. Since it uses a weak reference map and no one uses the created chat, it will be eventually garbage collected and forcing a new chat creation when receiving a new message (thus a new notification). This explains why you cannot observe the pattern of chat creation notification.
IF this is the problem:
FIX 1: Change the filter at the smack code to catch only MessageType = Message.Tyoe.chat (this stanza is RECOMMENDED, so some clients may not implemment it, if u know that the remote side client use it, than this can be done)
FIX 2 (Better?): Filter reacts when there is a body in the message (getBody returns something other than null). Since its a chat, u can presume that there is a body. (But some clients could try to send a message without body to start a chat, which is not a big issue).
I could not test here… But I hope that this will be helpful…
Good catch on the Smack code filters. Frankly, though, I am loathe to go in and modify Smack since that leaves me in the position of having to merge changes with each new version of Smack. I wonder why it was implemented that way.
I find it curious that Smack (2.5) does not use Chat or ChatManager- it just processes raw packets… I have to assume that means that the Chat impl is not as used or tested, and perhaps not as robust, as other areas of the API. I guess I should look at doing my own impl as well.
The reason is that the ChatManager is just really new and it is probably just a bug. It was just added for Smack 3.0 and you are correct that it hasn’'t been through robust testing yet. I already submitted a bug and got it fixed for the chat states that were added in the same release. You just have to make sure that the devs see this thread and they will get the issue logged and fixed for you.
Well, you are supposed to just post a thread, so this should be enough. Recently, though it seems the devs haven’'t had as much time to monitor the Smack forum. I have had better luck e-mailing them or posting about it during the Wednesday developer chat. Matt (matt@jivesoftware.com) is the Smack lead and Alex (alex@jivesoftware.com) is the one that implemented the new chat stuff.