I have an ios chat application that uses openfire, what I need to do is send push notification when the message (1) can't be delivered for any reason, (2) app is in suspended state, i.e. can't generate a notification on its own.
I have read most of the related questions/suggestions on this on stackoverflow and elsewhere and I have concluded few solutions to my problem. I am not an ios developer nor did I know anything about openfire or xmpp before a couple of days, so I am afraid my understanding of things may not be complete and my solutions might be flawed.
Kindly confirm my understanding of it and suggest if I am missing something or if there is a better approach. Please also suggest about how complex it is going to be to implement a particular solution listed below.
Challenge here is to identify when the push is required and where the process be initiated, so
1) one way is to use the xep-0184 implementation of xmpp to check if the message is delivered. to do this we should have some delivered flag with message in ios database, which is updated when the delivered response is received form other end. So we need check for this flag after a little while and if the delivered status is false, initiate push process with the message. Looks to be a complicated solution (wait for response.. check flag with some time lag.. not very impressive)
2) A more straight forward approach is to do something in openfire, when openfire can't deliver a message it stores it in offline table, we can do some interception on that part and initiate the push process with the message. This looks to be the correct approach but I am really afraid of getting that much inside openfire and change something(It might be easy also, somebody who has worked a little with openfire can tell?)
3) This is my last resort, and this is not a solution.. but if I can't do it correctly within expected timeframe (which is a week from now) , We plan to send a push notification for all the messages. oppenfire will takecare of normal chat while a push will be sent from our server for each message but when the app is in foreground, we do something to handle the extra push messages that need not be shown, otherwise a push is received whenever there is a message. What do you guys think of this temporary way around (we will of course have to change this as soon as we can), is this doable (or I am missing something here as well).
P.S. Can anyone tell how Whatsapp and other popular apps handle this?
Many thanks for your help.
XMPP requires a persistent socket connection or a "persistent" BOSH connection during your whole XMPP session. I think your challenge is that iOS does not allow you to run your app and socket in background. Whenever your iOS app goes in background iOS kills your socket connection, and your Openfire server kills your XMPP session. This means the user goes offline. Which is also the reason why incoming messages for this user go to the offline storage.
Sorry for this response, but all 3 solutions you suggested are terrible hacks ;-). If you want to come up with a good solution you have to go very deep into XMPP and iOS. 1 week is a very short timeframe for this.
Can anyone tell how Whatsapp and other popular apps handle this?
They keep the XMPP session alive. This works only with highly modified XMPP servers, some "XMPP Client Proxy" in between which keeps your session running while your app is in background, or a combination or both.