I have an instant messaging app in iOS. I want to use push notification to let the user know if he has received a message while the app is minimized.
Initially i ve implemented the app such that when the app is minimized, the app informs my server which in turn contacts the APNS to inform that a message is received.But there is a delay for the app to inform the server. Hence if the user minimizes the app and , at the same time a message is being sent to him, he does not get the notification since my server is still sending the message to the app and not the APNS.
I am wondering how this scenario is overcome in chat apps. Are they sending all chat messages to APNS irrespective of whether the user has minimized the app or not. If i send all messages to APNS will that be a good design?
On iOS, you can't rely on any processes that are working when the app is "minimized" (actually in background). Your process can be killed by the OS for a variety of reasons and in any case, unless you qualify for exceptional extended background processing, your app can not process for more than 10 minutes.
Typically, for a chat-type app, every time a message is received by a client, the same client sends back a message to let the server know that it has received said message. This way, if your server doesn't get a signal that the message was received after a few seconds, you can assume that the app is not running on the device and can send the message via push instead.
There is no need to use excessive processing on the client which will drain the battery and there is no need to send a push for every single message.
Related
I'm developing an app for our security company, that needs to receive alarm events in a matter of seconds. So this is the main event flow:
An alarm goes on in one of the buildings
Our server gets that alarm info immediately
Server distributes the alarm message straight to the app of
responsible person
app starts beeping, until the responsible person doesn't interact
with the app and sends a "message received" status back to the server
location tracking of the person is triggered, and data being sent to the server.
I tried using APNs, but the delivery time there $uck$. Since this data should be delivered ASAP, I'm wondering if someone has any clue, how to deliver some data to the iPhone in realtime?
I see PushKit is available, but only for VoIP applications, which this isn't. And the app wont pass the approval in the AppStore if I use that.
Any pointer will be welcome!
Thanks!
Please note that all Push Notification services must go through APNS, and APNS is the fastest method since it is socket-based, for any other way without push notifications, you need to setup a socket listener on your server and handle the socket on the client using SocketIO for example, this is the fastest method for real time interactions.
And you can use a cron job to fetch data by API each X seconds for example, but it is not fast or real-time as socket-based platform.
Lets say I have a chat application and I am messaging another user (User B), our messages are being received normally using sockets, however when the User B goes offline he is disconnected from the socket server however user A is continues to text him so my server issues a push notification to User B's device for every message User A sends. My question is will APNS act as a message broker and queue all the messages until User B logs back in and receives them? Or do I have to store unreceived messages elsewhere
The answer is readily found in Apple's documentation
Apple Push Notification service includes a Quality of Service (QoS) component that performs a store-and-forward function. If APNs attempts to deliver a notification and the destination device is offline, APNs stores the notification for a limited period of time and delivers it when the device becomes available again. This component stores only the most recent notification per device and per app. If a device is offline, sending a notification request targeting that device causes the previous request to be discarded. If a device remains offline for a long time, all its stored notifications in APNs are discarded.
So, no, you can't use APN as a message broker.
You can use the push notification as a signal to wake up and sync with a server-side message queue. RabbitMQ or Kafka might be candidate brokers, and MQTT looks promising as a protocol. You will need to work out how and when you discard the contents of message queues that are not successfully delivered to a device.
a simple question: is it possible to get a message, notification or similar when the internet connection is available when app is killed or not running?
For my purpose, I need a way to synchronize all my notifications because APNs can send only the last message.
EDIT:
I'm wondering how some apps (e.g. whatsapp) are able to sync their notifications when the internet connection is up. If I kill whatsapp, I can receive multiple notification when internet connection is reachable, but the APNS server provides only last message and, for this case, I'm not able to send silent notification. If I should develop a chat application, what are the best practices to work with Apple notifications?
If you send a push notification with a title, text, sound and/or badge property while the app is suspended (was killed / force closed), the device will still receive it, e.g. will show the text as a notification, play a sound and/or change the badge count.
However, your app won't be launched or woken up in the background in this case, so you have no way to handle the notification before the user taps on it. (See this question:
Will iOS launch my app into the background if it was force-quit by the user?)
So if the app was force closed by the user, your only option is to send a notification to be displayed as it is and if the device is offline, only the last notification will be received and displayed by the device.
For more control, you could use silent push notifications to implement "push-to-sync". In this case, the push notification only signals that there is new data to be fetched. The app (if not force closed) loads the data from the server then and triggers local notifications with the right data in the right order. But this won't work, if the app was force closed.
Apple push notifications have a lot of restrictions, so you won't be able to implement a perfect solution. In my opinion, it's fine if the user gets only the last notification when the device gets online after being offline for a while. At least he is informed that there is a new message and after opening the app, he can see the other new messages too. For the "push-to-sync" scenario, I would say that the user has no right to expect that the app works as desired, if he force-quits it.
Push notifications were never intended to be used in the way they are used by a lot of apps by now. E.g. they shouldn't contain sensitive data such as a chat message. They were intended to inform the user that there is new data for the app, so he can launch it to see the new data. E.g. instead of sending the actual chat message text a push notification should just contain the text "You have a new message". Then, you don't have the problem you described. Of course this is a terrible solution in terms of usability.
My app gives and takes message by APNS.
but if client's notification set off , client doesn't receive message by the other client sent by APNS.
Is this wrong way?
If it is not, how does client receive message When client's notification sets off?
You can't rely on APNs alone for this. Notifications can be turned off and even if they are on, APNs is a "best-effort delivery" service. This means it makes no guarantee that the client will ever receive the notification, but it tries its best to deliver it. Your app should query the server for new messages, and notifications can help you make the query at the right moment. Your server can notify your app that there's a new message, then the app calls the server to get that message. But of course since notifications aren't guaranteed, your app has to reach out to the server at other times also i.e. when it enters foreground.
I am building a very simple messenger app just to get my feet wet with this type of app. The general idea that I came up with is: Client 1 types a message, sends to client 2. Message goes to my tcp/http server, then the message is sent to Client 2. I am not sure however how this last step happens.
How can the server locate the phone and push the message to it? Should the app check every few seconds to see if they have a message waiting? How would you do this if the app is suspended (background)?
Would this qualify under background fetch under UIBackgroundModes?
The app regularly downloads and processes small
amounts of content from the network.
You can do it remote push notifications using apple's APN (apple push notification). Essentially, once the server receives the http/tcp message, it has to do a push notification to the device 2 thru apple's apn server. More information here