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.
Related
I have an application which has communication with a remote server. The server should push data into it using remote notification silently, and I need to get and store these data into a CoreData database. The user won't be aware of the whole process.
I can successfully get notified when the app receives a remote notification, while it is either in the foreground or background mode. However, I need to get data while the app is terminated as well.
I searched for the possible solutions. For example, this SO question was good if I don't tend to use silent notification. I also saw the PushKit capability, but I am not sure about the Apple Review result.
What is the possible solution?
If I want to use VoIP and PushKit to get notified when the app is terminated, would Apple reject my application?
If you’re not creating a VoIP app and you want your app to be in the App Store then the correct answer is: it is not possible. The only thing that can be done is adjusting your requirements in some way.
For instance you can send some notifications that will be visible for user in the Notification Center and wait until the user taps the notification or starts the app the usual way. Then the app will be able to do all the operations you need.
The delivery of push notifications is not guaranteed, so you should not rely on them to synchronise data.
For example, if multiple push notifications are sent while the device is offline, only the last notification is delivered when the device comes back online; the earlier notifications are lost.
When your app launches one of the first things it should do is check with your server for new data.
Suppose there are 2 people A and B, they are chatting using my instance messaging app, A or B may switch to other app or lock screen when the peer sends a message. As you know, the message comes from A will first send to server, then the server will send it to B. If the app of B is not in foreground, it will not get the message instantly, so I should use remote notification.
What I want to know is how my server side to achieve the Remote Notification functionality. I have two option.
I send message to APNS every time when the server gets a message.
I keep the app status(foreground or background) of A and B, when a message comes in, if the peer is in foreground, don't send the notification to APNS, otherwise send the notification.
The first one is a easy way but it may increase the pressure of APNS server.
The second one is complicated, it must keep the app status for every user and it may be not accurate. Suppose when the app of "A" comes to background and the network is very bad then, "A" fails to notify the server that it goes into background, the server consider that "A" is in foreground, so when "B" sends a message to "A", server won't send a remote notification to APNS.
Anyone who has experience on that please share your solution, thanks in advance.
I send message to APNS every time when the server gets a message.
Exactly! Just send a push notification for each message. If the app is in foreground, the notification won't be displayed anyways.
The first one is a easy way but it may increase the pressure of APNS
server.
APNS will be able to handle it, don't worry about that.
If you try to synchronize the app state with the server, you will sooner or later run into race conditions and other problems, so don't make things more complicated than necessary...
Although Push(remote) Notifications are delivered almost instantaneously (APNS is scaled to take load), I would suggest you to explore third part libraries. Here is a good tutorial on this. It would be worth exploring XMPPFramework. This may also be useful.
It is widely known that:
app doesn't receive push notification if it is in background or offline mode (app gets it once after user's action: tap on notification or app icon).
Apple push Notification service keep only ONE last notification when device is offline. Once device is connected to internet, APNs sends the last notification.
How to solve this?
very latest notification that just reached the app (not device) must reflect the actual number of notifications that are not implemented in the app yet. So, then I can download from the server last n notifications and implement them in the app at any time.
The question is:
How the server knows what notifications were implemented in the app, and which one not?
Notifications must be per device. Why? For instance, notification "remove object from Core Data" must be implemented in every device. Because only one user can be logged in on multiply devices at time.
You should track the state of the task (delete record or whatever your app needs to do) on the server and have the client report back when the task is done. Then flag the task as done.
Don't use push notifications as a reliable delivery method for your tasks, you will fail. Use the notifications as complementary part of your setup.
So for example when your app receives a notification, it can sync with the backend, to retrieve the tasks flagged as not done, execute them and then let the backend know that it's done.
How can an iOS app be notified that it needs to update its content?
I would like to have an app that listens for update alerts that trigger a download rather than doing a data request to be able to stay in sync with the server.
What is the correct way to have an iOS app that needs to be in sync with a server stay in sync while minimizing network activity?
Im aware of using a cache locally, NSURL Cache or Core data etc. and adhere to the timeout in the http header etc. but I would like to correctly setup a sync mechanism without having an update button that a user needs to press to get updates.
I have thought of implementing a dispatch_source on a socket but wont that keep the network active and drain battery?
Rather than request a token for the version of the data to sync from the server I would rather like the server to notify the device that it needs to update. Is this practical?
How does the OS handle listening to push notifications? Is it on POSIX level?
You really have two options here:
Client Side Polling: call the server and ask every so often. For 99% of apps this is fine as it's not that big a deal for someone to run the old version during the interval between polling.
Real-time Server Push: If for some reason you need to disable the old version as soon as you push a new version, you could do a server side push. You would not want to use APNS for this (user may deny APNS, delivery not guaranteed, etc). You would want to use a cheap push service like PubNub or Pusher for this to guarantee real-time delivery. Or code you own version using the same principles of these services, but really why re-invent the wheel?
There are two common, as far as I am aware, approaches to doing this on iOS;
Regular GetUpdates calls to the server at an interval (Fairly standard across any platform I think)
Apple's Push Notification Server(APNS) if anything changes on the server you can push a notification to the device.
At work we typically implement both options because there are a few issues with APNS;
They are not guaranteed to reach the device, if the device is offline the APNS service will store the Notification for a limited time in the APNS system upon which it is forwarded (if it hasn't expired)
If multiple Notifications are sent while the device is offline only the most recent notification is sent
If the device is offline for a long enough period of time all stored notifications will be discarded
the user has to allow Push Notifications to be sent to their device because it suppliers and identifier that you can use to determine the device
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.