RosterListener not receive presence- version 4.1.0-beta1

Smack Smack Dev
1

Hi everybody,

Currently I am working on chat application using Xmpp SMACK API with version 4.1.0-beta1 for Android, but I have a problem when I call addRosterListener(), the Roster add the listener correctly but then I am not receive any presence thought the last method presenceChanged(). I test changing the presence with an Adium client for XMPP. Also, I debugged my method and never start the presence method or any method inside RosterListener. I don’t understand because is the documentation code.

public void getRoster(){
        roster = connection.getRoster();
        roster.addRosterListener(new RosterListener() {
            // Ignored events public void entriesAdded(Collection<String> addresses) {}
            @Override
            public void entriesAdded(Collection<String> addresses) {
            }
            @Override
            public void entriesDeleted(Collection<String> addresses) {
            }
            @Override
            public void entriesUpdated(Collection<String> addresses) {
            }
            @Override
            public void presenceChanged(Presence presence) {
                Log.d("Roster", "Presence changed: " + presence.getFrom() + " " + presence);
            }
        });
    }

Thanks.

Note: I have users in the presenceMap attribute but I don’t have nothing on entries hashmap.

2

Also, I debugged my method and never start the presence method or any method inside RosterListener.
Debug the code that is supposed to invoke presenceChanged().

3

Hello again,

I discover (reading this post - “Ignoring roster push with not exaclty one entry.” - Is this right? ) that the communication between my Tigase server and Smack have a problem, this communication is performed by this way:

// Request

// 1st Response

// 2nd Response

<item jid=user2@xxx.test.com" name=“User 2” subscription=“both”/>

According to RFC6121 - Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence - a roster push MUST contain one and only one element. Maybe my server it is not updated to last version.

4

I recommend reporting this bug to the tigase devs then.

5

I reported the bug to Tigase developer team, but they answer me the following:

Thank you for the link to the spec. The spec indeed says that only one element is allowed. I also remember discussions on the XMPP mailing lists about this and many members suggested that more elements should be allowed. This is probably the reason why most of clients accept more than 1 element in the “set” request.

The specification allows for sending only one element because it discusses a different use case. This section is about changing an item (adding, removing, updating). In this scenario it makes sense to allow for only one item in the request. However, in case of out use-case where we push entire roster, putting a single item in a request would be highly inefficient.

So I can see a few options for you:

  1. Modify the library you use to accept more than one item in roster “set” request
  2. Modify Tigase’s code to push only 1 item in the “set” request
  3. Switch to a different library which accepts more items in “set” request out of the box. Our, Tigase JaXMPP library handles this very well.
    Anybody could say me if exist a workaround in smack for Dynamic Roster?, or I have to modify the framework.

Thanks again.

6

However, in case of out use-case where we push entire roster, putting a single item in a request would be highly inefficient.

What is that use case, where a server would push the entire roster? Why would it want to do that? I don’t see that anywhere in RFC 6121 and can’t imagine a scenario. I also think Tigase is the only server doing this.

That said, I like how Smack is strict about the spec and checks against the roster push rule.

7

What CSH said, or at least it’s unclear to me what they mean with “The specification allows for sending only one element because it discusses a different use case.”. Would be nice if they would have elaborated on that. Oh, and I think they also forget mentioning a fourth option:

  1. Switch to a standards compliant XMPP server