Hi,
I wondered why I always reveived an “available” when I did a
presencePacket.getMode()
And so I went deep into the code until I found it:
When Smack (the PacketReader) reveives a packet (with presence in it) it creates a new Presence and tries to set its Mode:
presence.setMode(Presence.Mode.fromString(parser.nextText()));
However, the next text can be indented like this:
____away
_ = spaces
(as it is done by Iain’'s Server )
You should add a trim() statement to the method
Presence.Mode.fromString(String value){
if (value == null) {
return AVAILABLE;
}
value = value.toLowerCase().trim();
…
}
and/or to the constructor of Presence.Mode
I hope I helped you and others, not getting trapped as I did.
Greets Chriss
Message was edited by: chriss
Chriss,
We could certainly send the #trim message to get rid of possible blank spaces but the thing is that the show value that you are receiving is incorrect. The correct show values are: ‘‘away’’, ‘‘chat’’, ‘‘dnd’’ and ‘‘xa’’.
Could you check who is adding those blank spaces? Is the other XMPP client sending those spaces?
Regards,
– Gato
hmmm, it’‘s Iain Shigeoka’'s server adding those blanks. My clients are built upon smack and send the correct
dnd
the server delivers the message and blows it up to
__dnd
2*blank after EVERY opening or closing tag, so the complete packet looks like:
<presence from=’‘schmitz@bla.de/res’’ to=’‘bla.de’’ id=’‘7pnN7-6’’> dnd
However, not ALL packets are like that. Some of them - it seems as if it were the ones originally generated by the server itself - are correctly formed. And I didn’'t find where those 2 blanks are added.
I gonna post this issue to Iain’‘s forum; it’'s his thing, so…
Errr, and the values are incorrect because of the blanks, right?
thx a lot!
Chriss
Chriss,
Errr, and the values are incorrect because of the blanks, right?
Yes, the blank spaces are causing the Available presence.
– Gato