powered by Jive Software

Found a bug concerning Presence.Mode


I wondered why I always reveived an “available” when I did a


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:


However, the next text can be indented like this:


_ = 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) {



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


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?


– Gato

hmmm, it’‘s Iain Shigeoka’'s server adding those blanks. My clients are built upon smack and send the correct


the server delivers the message and blows it up to


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!



Errr, and the values are incorrect because of the blanks, right?

Yes, the blank spaces are causing the Available presence.

– Gato