So the packet that’s being sent out to the server doesn’t contain the updated name, but only the old name.
The question referenced above already provides a patch to fix this issue and from what I saw in jira, this patch should have been applied at some point.
But I guess it wasn’t applied to master in the end.
Is there any workaround for changing the name of a roster entry at the moment ?
I’d love to provide/apply this patch by the way, but according to Guidelines for Smack Developers and Contributors · igniterealtime/Smack Wiki · GitHub it seems like it’ll take a bit for me to get used to everything since I’m very new to Smack.
Thanks for reporting SMACK-662. I’ve uploaded a new version of Smack 4.1.1-SNAPSHOT which should fix the issue: Fix RosterEntry.setName(String) · Flowdalic/Smack@26fe968 · GitHub . Could you try and report back if it fixes the issue for you?
After that, I’m getting the NoResponseException for pretty much every operation on the roster.
I have a very basic ejabberd test server (with pretty much all configuration as per default) and I didn’t change anything on the server between these tests. General communication works fine.
These are the packets logged by my server concerning the first NoResponseException:
The changes between 4.1.0 and the HEAD of the 4.1 branch which is what 4.1.1-SNAPSHOT is build from are Comparing 4.1.0…4.1 · Flowdalic/Smack · GitHub
I didn’t spot any change that looked like it could introduce the behavior you are describing. Please see How to ask for help or report an issue · igniterealtime/Smack Wiki · GitHub how you can provide more information which helps to analyze the situation. Ideally you are able to attach a debugger to the (JVM) process running Smack, determine good places for breakpoint(s), set those, and find out e.g. why the filter doesn’t match the stanza.
Ok so it took me quite a long time to figure out that these no response exceptions were actually normal and occurred because the Android debugger is extremely slow, thus the events would simply not fire as expected even after 5 seconds (default packet reply timeout).
Anyway, so the your change does work, but it won’t fire the updated event of the roster listener which it did before (because the new name was set before the result with the old name came back from the server).
It won’t fire because now, once the server acknowledges the new element, it is equalDeep() with the one having the new name.
If I can assume that the event shouldn’t be fired here (after all, it’s the library user setting the name, he knows that it has changed), then all is fine.
However, it might be more logical to fire the event anyway, because the roster has been updated after all, so in that case, you’d either have to fire the event manually after sending the packet:
// ...
// Set the new name, it's important that the value is set before we send the IQ request
this.name = name;
RosterPacket packet = new RosterPacket();
packet.setType(IQ.Type.set);
packet.addRosterItem(toRosterItem(this));
try {
connection().createPacketCollectorAndSend(packet).nextResultOrThrow();
roster.fireUpdateEvent(this);
} catch (...) {
//...
}
// ...
or you could go back to how it was before but use a different item to send the packet:
// ...
// create a new roster item to update the server
RosterItem updatedItem = new RosterItem(...);
RosterPacket packet = new RosterPacket();
packet.setType(IQ.Type.set);
packet.addRosterItem(toRosterItem(updatedItem));
connection().createPacketCollectorAndSend(packet).nextResultOrThrow(); // Set the new name once the result has been received
this.name = name;
// ...
If I can assume that the event shouldn’t be fired here
Absolutely. There are multiple reasons why the event should be triggered, for example you may want a single callback on which you update your UI.
I’ve replaced the commit with Fix RosterEntry.setNames(String) · Flowdalic/Smack@9cce2b8 · GitHub and uploaded a new snapshot. Please give it a try.