iOS Question Server synchronisation. How does WhatsApp and Threema do that?

[schimanski]

I'm lokking for some better idea to sync my ios-messenger-app with the b4j-server. Under IOs, we have the following problem: In most cases, the user starts the app over the app-icon instead over the notification. The next point is, that under IOs only the last push-message is saved by the push-service, when the app is not reachable for some time and IOs did not process the message when the app is in background. Now it is required to sync the app with the server to load all the messages, which are not delivered. So far, the server holds a map with a minimum informations about each message. When the client starts, it downloads the map, looks if the message was delivered or not and if not, the client creates the message and sends back a timestamp to the server, that the server knows, which message was delivererd successful. In that case, the sever deletes this messeges from the map. This runs good, if there is a good internet-connection.

The problem is, if there is a bad internet connection and the last push will arrive. When the user starts the app over the app-icon, the client tries to download the map with the undelivered messages. In areas with bad network coverage, the synchronisation takes to long time or fails and has to start from the beginning. That leads to confusin by the user because of the time warp.

How does WhatsApp and Threema do that? When swichting off the internet connection and sends a lot of messages to the client, it seems, that all the messages are part of only one push-message. A lot of messages will arrive in fractions of a second even if the internet coverage is bad.

Does anybody have a solution for this behavior?

Under android i did not have such problems because the push-service saves up to 100 messeges for each device and the app could process each message in the background.

I'm thankful for every idea...

 

[Erel]

You can use the fetch background mode to update things in the background from time to time.

I assume that Whatsapp use CDN so internet requests are always local.

 

[schimanski]

Puuh, i read something about CDN. It is to much costly for my project. Fetch background mode does not solve my problem. When a message arrives, the user starts the app over the app icon and with bad internet coverage, the latency is to long, even if the download data is small.
I thought today, that I could do the map with all the download in the push-message up to the limit of push-size (4096kb). But i think, it works only, if the user starts the app over the notification. On my risk to repeat, but i need something like checkforpushmessages after starting the app. I can't belive, that i have to thrown away the data out of the push-message, only because not to start the app over the notification...

 

[mindful]

You could optimize your traffic. On the client you could save a variable with the timestamp of the last message arrived from the server so this way you can ask the server only for messages after that timestamp - so payload should be lower. And on each message that arrives from server you should update the timestamp variable so when the push arrives you can check the message timestamp and if <= than the timestamp you don't process that message because it's already there... you could optimize this process even further but the above one is how i see it working in generally.

 

[schimanski]

Thanks for your efforts. I think, that is one step to a better solution and I will change my code like that. But I think, that it is not enough because even when payloaddata is very small, the delay takes to much time under edge.