Prevent/control SM ack

Hello,

I have a big problem on an Android app I’m using Smack with.

Sometimes, Android just kills my service because it needs resource. Because my app often operates in background and this happens sometimes during login, SM sends in reply to received by the server, but not before the app has saved the incoming messages into its local storage. Outcome is: messages are lost forever, because for the server they are delivered, but the client didn’t make it to save them locally.

Is it possible to suspend or delay sending of when the servers asks for ? I need to delay that at least after it saved the messages to the storage (which implied having called the relevant stanza listener).

As a sidenote, I’d rather not mark the service as a foreground service by using a foreground notification. If the system kills it, it has its good reasons. I just want to have an opportunity to save my messages or got them redelivered if I couldn’t make it.

Is it possible to suspend or delay sending of when the servers asks for ? I need to delay that at least after it saved the messages to the storage (which implied having called the relevant stanza listener).
I’m not sure if I would want Smack to go down this path. The is send by the core reader thread, i.e. as soon as the stanza has been parsed. And I don’t like the idea of delaying the until userspace has cleared the stanza.

I think the proper solution for your use case would be MAM, which you want to use anyways. And since it solves your issue too, I don’t see a need to change Smack’s handling of .

As a sidenote, I’d rather not mark the service as a foreground service by using a foreground notification. If the system kills it, it has its good reasons. I just want to have an opportunity to save my messages or got them redelivered if I couldn’t make it.

That’s the spirit and right approach. You have earned a star for that, Daniele.

Thanks for the answer Flow.

Really no real alternative to this instead of adding yet another XEP? I need to add one more module to the server (more server load), one more extension in the client (more client load + bandwidth + requests initiating from the client), instead of using the already very well working offline messages mechanism.

Besides, I don’t think it’s a wrong approach to add a listener there IMHO. XEP-0198 states:

“[…] until a stanza has been affirmed as handled by the server, that stanza is the responsibility of the sender (e.g., to resend it or generate an error if it is never affirmed as handled by the server).”

Since SM acks work both ways, I assume this sentence is valid also for clients.

I can provide a patch if you can tell me you will approve it :slight_smile:

Perfect valid argumentation if you don’t need MAM. I haven’t made up my mind entirely on this. Maybe I could be made configurable when Smack will count the Stanza. I’ll come back to you in a few days. You could prepare a small patch in the meantime, showing me what you would change.

I tried to focus on altering as less code as possible. Here is the result:

https://github.com/kontalk/androidclient/compare/8b574965a23d428641aaa3429116b1f e203ed201…8ede4302dc22d8da2cca6831c0aa…

Instead of forking the whole library, I only took XMPPTCPConnection, removed the deferAndBundle parts because they required protected access to other classes, and modified it a bit. It could be done better I know, but as I said I just wanted the feature I needed with very few code modifications.

In the same page you can see my class KontalkConnection overriding the processPacket method which now suspends ack replies until another class resumes it.

No listeners involved :slight_smile: What do you think?

For the record. The Project issue is: Sometimes MessageListener doesn’t make it · Issue #589 · kontalk/androidclient · GitHub