how do i send device token from my native iphone app with a specific timer request so that after the specified time push notification alert comes to device.
The title of your question and the text of it don't exactly match.
The easiest way to set up a timer request for push is to sign up with a push service provider that offers timed requests (UrbanAirship does but you may also want to check others like iLime or push.io).
The other option is to write a server where you can queue the requests then run a cron job to push them out. Obviously, that'll take more work. To actually post the message, you could use something like ASIHTTPRequest.
You may also want to tell your users not to rely on exact timing. A lot of variables enter into the process especially if user is on WiFi.
Related
I am creating an application which has a follow mechanism where the followed user has to accept the request of a following (similar to private accounts on instagram).
I then want the following user to find out when the other user has checked a million times (every time the following user opens the screen if I did the query in viewDidLoad). However, the problem with this, is that there will be a lot requests which will expensive to me as I will have to pay for the requests to Parse so I want to minimise these queries.
Currently, the best thing I can think of is to check once a day at midnight for example but this doesn't seem very seamless.
Is there a better way of doing this?
For starters consider how stale you are willing to allow an app's view of the world to be and cache the response that long. If a user views that screen every 30 seconds you might only want to actually check with the server 5 minutes after the last successful response (or the last response which had 0 follow requests).
You might consider switching from this sort of "pull" polling where the client decides when to ask the server if anything has changed to a "push" model where the server can inform the client when a change occurs. For example you can send a silent background push notification to a user's devices when they have a follow request, the app can then respond by performing your existing query.
You might still want polling or user triggered requests (like a "pull to refresh" gesture) as a fallback for missed notifications or devices with notifications disabled but you should be able to drastically reduce request volume.
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.
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.
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.
I heard that push notification is not reliable. What could be the alternative for this?
The use case I am trying to handle is:
1. I have a app which will be shared by three kind of groups. Each group contains certain set of persons.
2. A request is submitted by first kind of group and it will be serviced by second kind of group. So, all persons who are part of second group should be notified and no one apart from them should get the notification.
3. Similarly, A request is submitted by first kind of group and it will be serviced by third kind of group. So, all persons who are part of third group should be notified and no one apart from them should get the notification.
4. Even second group persons can submit a request to third group.
Please provide your thoughts as how should I handle these scenarios.
Push notifications rely on the network (3G/WiFi) presence to deliver the notification. Also, there is no response back from the Apple Push Notification Server which guarantee the delivery of the notification. Having said all these things... iPod touch is higly unreliable for delivery of notification because one, it do not have 3G; second, for saving battery its notifications are internally turned off for some time....
One Alternative to this is to keep polling the server in a background thread for any modification. But this will work only when app is running.
Another Alternative can be writing our own APNS kinda infrastructure.
you're right to say Push Notifications are not reliable.
For one thing, if the device is not connected to the internet, APNs only keeps one push notification to be sent when the device connects again (the last notification sent from the provider). Since there's no way to determine if a notification has been already sent or not after your servers sent them to APNS, you can't even try to queue the notifications on your end.
Other than that if your app depends on PN the user can easily break it's functionality by turning notifications off.
So you're absolutely right, if the data you want to send is critical, then you shouldn't use Push Notification. But I believe there's really no solution to your problem. you simply can't rely on them for your app to work.
I think the best approach would be like the email app for example, where you can download your emails when you start the app wether you have PN turned on or not, and the PN just notify you of new email, even though it's not guaranteed you'll get it at all.
There is no alternative, since Apple does some very low level communication. You would need to work together with the mobile providers to build something like the notification services.
That said, I don't think the service is not reliable. Maybe you should check your implementation.
You are right that APNs does not guarantee delivery: From their docs, they say that:
Important: Because delivery is not guaranteed, you should not depend
on the remote-notifications facility for delivering critical data to
an application via the payload. And never include sensitive data in
the payload. You should use it only to notify the user that new data
is available.