How to get notified when our app is uninstalled in iOS - iphone

We are developing an iPhone application that allow users to send messages to others via Apple Push Notification Service when the target user have installed our application or SMS when haven't.
We want to get notified immediately when our app is uninstalled so that we can decide how to send the message to the target user.
We find the APNS feedback server have a long time delay that doesn't agree with our requirement. So we use another way: when our server recorded the target user have installed our application, we send him message via APNS, if he haven't read the message in 30 minutes, we believe that he has uninstalled the application, so we send the message via SMS.
Is there any way better?

As Oleg said, there is no way to accurately detect if your app was uninstalled.
The APNS feedback service returns a timestamp and a push token for messages it was not able to deliver. Sometimes, this indicates an uninstallation but it can also simply indicate a user that was simply offline at that moment. The Feedback service does have some lag so can not be used for time-sensitive intel gathering.
Based on your requirements, I'd say you're doing it right.
One suggestion that may or may not work for you would be to include a link (via url handler) to your app when you resort to sending an SMS. If it makes sense for the user to return to your app, clicking on that link should launch the app and you'll have a trace on your server if you make a simple call. If, however, after sending the SMS the user is not detected as coming back into the app, chances are highly likely that the app was indeed uninstalled or that the user is offline for an unusually long amount of time which may require some other type of action on your part.

Related

How to handle multiple push notifications with user data arrived at different times?

My app is receiving APNs sent from server to Apple backend. Naturally a user may not open the app once a notification arrives to user's device. In meantime my server may push more notifications. They all contain some user data that is important when a notification is processed. So how to deal with it? iOS won't bundle and give me a batch, will it?
Here are ways how I am going to tackle it, none of which is simple.
Server keeps track of not seen data and upon arriving a new request always sends a batch of all new notifications, reflecting the count as badge count.
Client is opened by taping on notification popup. In this case it has all needed data in didReceiveRemoteNotification.
OR
Client ignores notification popup and opens app (possibly later) by tapping on app icon. In this case didReceiveRemoteNotification is not called and thus app has to fetch all needed data from server.
OR
Server never sends any user data and client always checks for new stuff every time it starts or fetches data in didReceiveRemoteNotification.
Anything else? Something simpler I am missing?
Number 4 is the right approach. There is no guarantee that any of your app code will run when an APN is received, except on iOS7. So when your app starts, it has to check with your servers for any new information that it should display.
It's simplest to code this to alway ask your servers for the latest information to display, rather than rely on the information in the APN. Use the information in the APN only to determine which new information to navigate to, so that the app displays whatever the user tapped on.
This has changed with iOS7, where you can use the remote-notification background mode to be launched whenever a push message arrives. See https://developer.apple.com/library/ios/documentation/UIKit/Reference/UIApplicationDelegate_Protocol/Reference/Reference.html#//apple_ref/occ/intfm/UIApplicationDelegate/application:didReceiveRemoteNotification:fetchCompletionHandler:

Call status change web-service when my App is deleted

In my application , i works with web-services and when user log in into my app my app is sending a request with status 1 means loged in and when on log out button click sending a request with status 0.
Now problem is , when user removes app from devices , status in my server is remain 1(log in) , hence other user can see him available while his app is not in device. so is there any way by which i can send request when my app removes from device (i don't think it is possible) or is there any other way that i can do in my backend side ?
Thanks in advance.
It is not possible to call a web service when the user deleting the app from an ios device. There are three methods to came to know that whether your application is there in user's ios device. But there are few limitations also.
Activate Push notification: By doing this, device will get registered with Apple's push notification service. When user delete the app from device, the registration will be revoked from APNS server and through the APNS feedback service, you can get to know whether the application is existing. (Limitation: If the user did not agree with receiving push notifications, then the app will not be registered with APNS and you never came to know that whether application is existing or not)
Activate Location Based service: If your application enables location based service, then your application will get periodic location updates in a location delegate method. In this delegate, you can call a webservice and keep update the status of user even the application is in background. (Limitation: If user disables the location update, then your server will not get info about user status)
Periodically Call a Webservice From you app: This is possible only if your app is active. (Limitation: When you application pushed in to background, your application will be in suspended mode, so it will not possible to call webservice)
Sorry Unfortunately Apple not provide any method that user Uninstall app from user's device, There is no such method.
When user delete any application device does give the alert "Do you want to delete this application" with option "Delete" and "Cancel". You don't have to write any specific code for this.
I just assume that There is one method in which you can find out when user is about to delete your app. That is you need to implement push notification Apple server will inform you when you try to push to an uninstalled instance. Other than that there's no way to detect it but i am not sure its helpful or not.
You can't do this from within the app. You would want to do something like have a periodic task which runs on the backend, checking the last activity date of logged in users and setting them to 'not available' after some configured period of inactivity. This will probably require some changes to the backend to record last activity date and a change to the app so that while it's open it sends a periodic 'heartbeat' to the backend. You probably want to make the timeout quite big (say 15 minutes, big enough to not have a large impact on performance).

Checking for other UIRemoteNotifications waiting, inside didReceiveRemoteNotifications

In didReceiveRemoteNotification, is it possible to see if there are other/older push notifications that haven't been responded to?
I have a scenario where each notification contains different data, and unless you exit app and select every single notification for your app. You app wont be able to get to that data.
I'm thinking that iOS must be storing that information in an array somewhere, but haven't been able to find anything through Google.
Advice please? Last chance saloon would be re-writing it to poll a server for notifications.
You cannot guarantee that your app will ever receive any push notification sent to it. The only way it does is if it is running when it receives the message or if the notification is used to launch your app.
I would recommend implementing a web service on your server that allows your app to pull down the data it needs from these notifications when it is running.

Push Notifications for iPhone - accepted methodolgy

I’m looking at the designing and developing a service for Push notifications, and am trying to understand the order of processing in the Apple App when it comes to Registering for Push Notifications and storage of the Token.
What I’m developing currently is a service that allows subscription to individual changes that happen to particular processing on our server.
When they happen, the phone user may receive a message of type “A”, “B”, or “C”.
The phone user has to “subscribe” to each of these types individually if they want them. Otherwise they can ignore it and not subscribe.
So User Fred, on Phone #4, starts our App, logs in, and then has the ability to turn on or off subscriptions to events that are sent as Push Notifications.
So I need to tie details from Fred’s login, to Phone #4’s device Token, with particular subscriptions.
So my particularly important questions are.
When the Phone connects to the APNS server to get its device token, is this automatic on app start? Or can this be initiated at a later step? Ie, after going through a loging screen on our app.
Can we (are we allowed to) store the device token on the phone in the App's data store?. Or, should the App be connecting to the APNS server every time the app is run?
How does the App know if it as already called the APNS server and retrieved a token, or as above, should it call the APNS server time the app is run?
Can we (are we allowed to) store the token in the App’s memory as it runs, so we can properly subscribe and unsubscribe for particular messages?
We need also to be able to list all the subscriptions that a particular user may have across all their devices so the user can remove old devices (if they change phones). Or can we rely upon data back from calls to the APNS – when we attempt to push a notification - to inform us that a device token is no longer valid?
Or is there some better way of tying this all together?
When the Phone connects to the APNS server to get its device token, is
this automatic on app start? Or can this be initiated at a later step?
Ie, after logging into our app.
After the app has started, the app gets the token by calling registerForRemoteNotificationTypes. This will prompt the user for permission, and call a callback with the device token if permission is granted.
Can we (are we allowed to) store the device token on the phone in the
Apps data store?. Or, should the App be connecting to the APNS server
every time the app is run?
You'll need to build an APN provider, which is a web server that calls apple to send the pushes. The thing to do with the token is post it to your server that uses the APN provider. The app doesn't connect to APNS, your provider does, and it does it when it has pushes to send.
Can we (are we allowed to) store the token in the App’s memory as it
runs, so we can properly subscribe and unsubscribe for particular
messages?
You can keep the token on the client, but you don't really need to. It's your web service that calls APN, so it needs to be kept aware of your users' subscription prefs.
We need also to be able to list all the subscriptions that a
particular user may have across all their devices so the user can
remove old devices (if they change phones). Or can we rely upon data
back from calls to the APNS – when we attempt to push a notification -
to inform us that a device token is no longer valid?
APN also provides a feedback service that you call in batch which returns the device tokens that are no longer valid. Not only can you use this service, but you must. Apple will get mad at apps that repeatedly send to no longer valid devices.
Or is there some better way of tying this all together?
Yes! Parse.com provides a nice wrapper on the client code, does the provider and feedback service, abstracts the idea of single devices to the idea of a "channel" which sounds like just what you need for multiple notification types A, B, C, provides a super-easy step by step setup, and loads of other useful cloud services for iOS. (I'm not affiliated, but a big fan).

Push vs polling with web service on iPhone

I'm using the ASIHttpRequest library to ask a web service every minute for updates. The app receives a json string and parses it. It works OK.
But I'd like to make this more efficient.. what would be the best way of getting the server to send to the app info whenever there is an update.. rather than constantly polling the web service?
Apple PUSH notification is not a good solution
1) You can only package a limited amount of data to it
2) It may be difficult to figure out if users have the app launched, or exited. If you keep sending PUSH even after users exit the app, they will end up with lots of spam. If you try to send something to the server to indicate that users have closed the app so it should stop sending PUSH, it may not work when the app crashes.
I suggest you use Sockets.
Or just use a scheduled loop to make requests every minute.
.....
But I wonder if you can just send a PUSH without alert body and sound, and just sending a 0 badge. If app it opened, it will be able to feedback to the server to continue sending update. If there is no feedback, stop sending push .
Apple's push notifications may be what you are looking for. However, you'd need to implement something on the website to support them I believe. I haven't used them myself (I haven't gotten that far into my application development), but here is a link to the developer documentation for it:
http://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Introduction/Introduction.html
Apple's push notification is one way. Here's a guide on building a push notification provider server.