I am working on an application that must notify the user of a server-initiated event. These notifications are only useful for a short space of time (30-60 seconds). For this reason, I am looking for a method that can both deliver a notification quickly, and, importantly, can somehow invalidate (retract/cancel/timeout) the notification after it has already been delivered.
My understanding is that the APNS is not suitable for this. They 'send and forget', giving no ability to check/modify/delete a notification. This functionality is integral to my app though, so I am open to any suggestions for methods or services that might let me achieve this.
In my mind there are several options:
Server sends notification to user. Server then later sends 'cancel' message to user, which removes the notification.
Server sends notification to user, which has a built in timer. This timer is monitored locally, and once it elapses, the notification is removed.
App periodically polls server and schedules/cancels a local notification according to what the server says.
My preference is option 2, because it is self contained and efficient. One message initiates both the scheduling and cancellation. Option 3 has issues with iOS shutting down the app if it's in the background (not to mention the rate at which it would have to poll the server given the notification would only be useful for ~30 seconds).
Do any services such as Urban Airship offer some functionality that could achieve this? Any other suggestions/complete work around methods? All very appreciated.
Thanks for your time!
Matt
EDIT: In the interests of encouraging out of the box thinking, another idea might be that the server initiates an automated phone call with the app user. If the user answers the call, the required information is given to them. If not, the information is no longer available. Bit wacky, and my instinct is that it would be costly, but I'm open to anything!
Anything that happens asynchronously can be done with push notifications as it already provides a unidirectional, instant communication channel between you and your customers, so no need to do strange phone calls (which can interrupt your users' activities, bothering them).
You can go for a dual solution, in which you notify your users of how many unread notifications they have in their inbox. Then can you implement your own in-app message inbox, which connects to your servers and fetches the relevant data (in case it hasn't expired - if it has, just let the user know -).
This way users would be able to know how many notifications have been made available to them, but they could only check the ones that are still valid. UrbanAirship employs this approach for their Rich Push feature.
Apart from this, you need to bear in mind push notifications can be very intrusive for the user, so use them wisely or you'll see your users unsubscribing from them or even worse, uninstalling your app.
Well my guess you are out of luck, since your only option is APNS.
There is no support for canceling notifications.
Apps can't access the notifications for the app, only the one the user uses to open the app. Also you can't really run apps in the background is they are not used for location, media, VOIP or need to access some kind accessory.
See my point where you can't really run app in backgroud.
Third party services can not add extra functionality to the APNS server as provided by Apple.
As to your suggest that the server will the app, you can't intercept call, sms,... on iOS. I really you only solution is to build a VOIP app that will call the user when ever the notification needs to be displaid.
Apple has no solution that will suite you needs, guess it will have to be an android app then :S
Related
Since push notifications may not be delivered sometimes (you can lose a few of them), you can not run code after the iPhone is turned on to check if there is new information available from the server, and you can not run code if your iOS App is closed... What can you do if you want to be as more accurate as possible in for example a Chat App in iOS?
I mean, inform the user as faster as possible that he has new info available. Comparisons: WhatsApp is updated without any delay.
You can do background fetch if your App is in background. But if the App is closed and you miss a push, it's not going to be up to date until the next push arrives or user opens the App. The same with silent notifications. If the app is terminated by the user, you are not going to receive it. Is there any way to solve it? It must be because other Apps do it... If there is any "private and secret" API that they are using (I read about this answer when no one know how to do that)... Is there any way to apply to use it?
UPDATE:
I'm using push notifications. The goal is to fix when a push doesn't arrive. Example: User A send chat message to user B. User B doesn't have the App open. The system lose the push. User B is not going to receive the message until he open the App.
Push notifications seems to be your only way even if you do loose a few of them, which I don't know how you would since they are pushed to apples secure server... but what do I know. As long as the user turns on the push notifications you should be fine. They may be delayed due to apples way of handling them. Honestly push seems to be the future, having your app constantly every minute or two check for new messages is a huge battery water in conjunction with normal texting apps. Your app should provide the best live data but since apple restricts to push notifications when the app is off or not running just stick to push notifications and only push major events to the user. I believe you can set up a job scheduler using quartz or schedulator to setup your server to push notifications to your app.
I'm looking for a way to push data to an app similar to APNs but that doesn't use APNs. Is there a way to do this? The reason I want to do this is if the User disables notifications I want to still be able to send data to the app without needing user input such as a pull to refresh or what have you. I only want it to happen when the App is in the foreground.
Basically, I want it to use push notifications like normal, so if there is new data available the user is notified if the app is closed so the user can click on it and have the app open and display the new info. Then if the user disables push notifications through the settings the user will no longer receive notifications, but the app will still refresh if there is new data available.
I tried using GCM/FCM but that just piggybacks off of APNs so it won't work if the setting is turned off for notifications.
Is this even possible?
If the app is in the foreground, you have two options:
1) Poll - For example, every few seconds to you make a network call to poll for new data. This may be possible if you can guess a frequency at which you get new data. But as you can imagine, this is pretty impractical/wasteful if you have to do this very often.
2) Push - You can open a persistent HTTP connection (web socket) and push new data to the client from server. This is more difficult architecture (publish-subscribe) to implement than polling, but definitely worth the time if you implementing any sort of real time system (think new Facebook posts on the timeline, new tweets). For websockets, you can use a home grown solution (eg http://socket.io/) or you can use many available 3rd party solutions (like http://pubnub.com etc.)
Suppose I have an e-commerce ios app (like snapdeal, flipkart etc.) and I want to make my app notified when there is any change in the data stored on the server.
For instance, take an example of price change of any product in any category, so how can I update the price for that product without putting it to user's knowledge, whether the user is on that particular screen (currently seeing that product for which the price is changed) or on any other screen.
is it possible to do? if YES, how can I achieve that?
Thanks in advance!!
You have to use Apple Push Notification Service to do that.
It allows your server to send data to your app, that warns user or not (you choose), and your app is awake by this push a can work on background mode.
In order to allow you app to work in background, you have to enable Background fetch options
From Apple Background execution guide :
Apps that need to check for new content periodically can ask the system to wake them up so that they can initiate a fetch operation for that content. To support this mode, enable the Background fetch option from the Background modes section of the Capabilities tab in your Xcode project. (You can also enable this support by including the UIBackgroundModes key with the fetch value in your app’s Info.plist file.)
Edit about BaaS
As mentioned in comments, implementing the whole push notification system yourself can be difficult, especially if you are doing it for the first time.
That's why you can use a BaaS (Backend as a Service) that handle push notification for you like Parse.com, Firebase or whatever you want. It simplify a lot the process, but it remains APNS on the back, so it's important to understand how it works.
I'd recommend, like Mr. Blackus said in his answer, to use Apple Push Notification service. However, I will add one bit of information -
Don't use the service to send the actual data, only send a small packet of information telling your application to request more data from the server.
The process should be something like this:
Server asks Apple service to send Push notification to your app.
App receives push notification (but does not show any badge to the user).
App interprets the data sent from the server as a "refresh data" notification.
Fire POST or GET request upon determining type of notification received.
Update your data from the request response.
1.) Polling - app asks for list of products whose prices has changed. You can setup a timer, which triggers itself after every X seconds.
2.) Socket connection - between app and the server. App can generate a unique token (such as identifierForVendor), and use it in the socket conenction. Server can notifiy all the apps (using this token), to notify about the changed prices.
Approach 2 is better, as it is less expensive ( in terms of networking).
Hope this helps.
I want to create an iOS chatting app using APNS. If I have 10,000 active and they are continuing chatting, will apple block my developer account ? Is there any limitation regarding this?
I would discourage you from using APNS as a backbone of an "chatting app".
If you need fast chatting functionality you should write your own TCP-socket based server.
If every-few-second syncing is o.k. you can get away with a HTTP-based server backend (but all the pull-syncing can be hard on network traffic - so TCP-socket is still better choice).
You could however use APNS for fallback - when your app on certain device is not responding (i.e. is not connected to server) you can send an initial message trough APNS (to wake up your app & to notify the user there is a message waiting for him).
As soon as the user opens your app you should switch back to your TCP-socket or HTTP request based server communication.
As for your question: no, Apple would most probably (one can never know for sure) not reject your app just because of using APNS for chatting. But note (as the others said allready): messages between two users will get "lost" if they would interact too frequently - see the link Roman Barzyczak gave you.
"If you are sending multiple notifications to the same device or computer within a short period of time, the push service will send only the last one."
more information: http://developer.apple.com/library/ios/#technotes/tn2265/_index.html
but Apple wont block your developer account :)
You can use them for messaging but you are going to quickly find out that there is no guarantee they will arrive. This is known as the black hole of push notifications. ;-)
I like this answer here.
First try to use an APNS only solution.
Make your push notifications stateless (they only serve as "Hey you have some new stuff in the server").
So when the client gets a push notification it asks the server for new data (messages or other stuff).
Use OneSignal to simplify the code that sends push notifications (from the back-end). If a user in your app gets a message after 10 seconds he dose not care if you used TCP,socket.io or xmpp...
Even Whatsapp's messages can take couple of seconds to arrive.
A chat app is not a realtime game. A delay of couple of seconds will be acceptable by end users.
My company offers an iPhone app for day traders which basically tells them when it's a good time to buy or sell. A cluster of servers generate these BUY and SELL signals and need to be delivered to a customer's iOS device in a minute or less. For all other mobile clients we've developed, we are allowed to poll the server in the background (once per minute), to check for updates.
In iOS, however, it seems that doing anything in applicationDidEnterBackground that has to do with times or polling isn't an option.
This led me to look at push notifications, but from what I am reading, they aren't reliable. They employ a send-and-forget methodology, which there's no guarantee they will be received.
You can see the problem with this. If we issue a BUY signal and the user acts on it, then a SELL signal is generated 10 minutes later and send via push, but never arrives, they could lose a lot of money.
So, is there a good way to do this or am I out of luck? Thanks!
There are two intermediaries between your server and the user's device: a) Apple and b) the network.
Apple does not guarantee the delivery of all notifications; only the most recent is guaranteed to arrive and only for a limited period of time. For more information, check out the "Quality of Service" section in Apple Push Notification Service.
If the device is accessing the network through a mobile carrier, things may get ugly. I have experienced situations where, some notifications didn't arrive until much later, and some got lost entirely. From my experience, carriers protect -with zeal- the quality of their own services, rather than those of third parties like Apple. An SMS/MMS will not normally be lost, while a push notification might.
Polling the server would be a viable alternative for your app. Alas, Apple doesn't allow networking operations to take place for apps that have been put in the background state (except for Newsstand downloads and VoIP).
Some apps seem to do push notifications really well (GroupMe) while others don't. If you're really worried, you could use a service like Twilio to send the user an SMS message with a link that would open your app and give it some information. So the SMS could say "SELL SELL SELL yourapp://stock=APL" or something like that. This obviously won't work for iPod touch users or iPad users (although I don't know if that will be a problem for you.
Try using Apple's own push notification service: http://developer.apple.com/library/mac/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/ApplePushService/ApplePushService.html
It's quite easy to implement, with just a few lines of code in the application and a bit of PHP and JSON on the server to do the sending. The good thing is that your server sends the request to Apple, and Apple's own servers handle the delivery to the device securely and reliably. Notifications are usually delivered within 10 seconds of being sent (unless the device is offline, then it will be delivered when the device comes online).
From my experience with push notifications, I haven't lost a single one, and there is a delivery option that continuously attempts to deliver it until it is successful, and there is even a server side callback API of some sort available that lets you check the status of your notifications. You could also try a service like Urban Airship to do the work for you.
You could also try using one of Apple's background modes as part of this (such as receive the 'BUY' as a notification and have the app wait for the 'SELL' in the background. The biggest limitation is that the app can only run in the background for about 10 minutes at a time, so you would have to use a workaround like playing music in the background (or making stock announcements like a music track ;P), or prompting the user to reopen the app to continue the background session.