listener - XMPP receive messages sent to different resource -
how receive xmpp chat messages sent different resource?
e.g. message listener receives messages fine, until message gets replied resource (like gmail google talk). point on messages sent client resource , not listener.
i'm using smack library java (well, asmack port android)
after connecting service (google talk server), add listener this:
connection.addpacketlistener(new packetlistener() { public void processpacket(packet packet) { log.i(tag, "processpacket: chat"); message message = (message) packet; log.d(tag, "message: " + message.toxml()); if (message.getbody() != null) { string fromname = stringutils.parsebareaddress(message.getfrom()); log.i(tag, "got text [" + message.getbody() + "] [" + fromname + "]"); } } }, filter);
this works fine initially, receive messages google talk. these messages sent multiple clients, desktop google talk, google talk app android, , implementation.
but when reply message, in desktop application, subsequent messages sent desktop application resource, , nothing received in implementation.
so i'm not sure how receive these messages. google talk application seems this. doesn't appear new message (before it's replied to), updated in google talk application thread.
any great!
if i've understood right, logged in same user on different applications (resources). receive messages contacts in roster, when reply 1 place, creates dialogue between 2 nodes?
this implementation specific. clients follow recommended behaviour in rfc 3921, reply full jid (user@domain/resource) if message received full jid. free reply using from bare jid (user@domain), future response in sequence sent bare jid, resulting in available resources (assuming priority equal) receiving it.
from example reply desktop application, it's application setting 'from' header full jid, , other party whom receives reply desktop application using value 'to' header response. of course means unique resource messages.
so it's got nothing code. it's code in desktop application, working in conjunction code @ other endpoint (the buddy you're talking to), cutting implementation out of loop.
Comments
Post a Comment