I am building an app that needs to use push notifications. Currently it is only an iPhone app and i have already implemented a manual version for push notifications.
There are quite a few services that do this kindof thing for you... Are there any benefits to using them? Having a nice API is not really relevant because of the fact that i have already implemented pushing manually.
The main reason i ask is that i downloaded the app Path and noticed that their push notifications seem to be a lot faster and a lot more reliable than my app...
Btw, Im using GAE for the backend.
Thanks
The most obvious benefit to using a push notification provider is not having to write the code yourself. Writing an efficient and reliable provider of Apple Push Notifications is not simple. If you want a quick solution and are willing to pay for it, using an existing provider is probably the way to go.
In my opinion the APNS API is bad. The fact that you don't get an acknowledgement for a successfull notification makes it hard to code a reliable provider. If you want to make sure you're not missing error responses from Apple, you have to attempt reading often from the connection, and with large timeouts, which will make your provider slow. On the other hand, if you want to send your notifications as quickly as possible, you'll have to sacrifice the reliability (because you won't be able to rely on getting all the error responses that Apple send). Of course, if you make sure that your DB doesn't contain invalid device tokens, and that you always send valid payloads, you can assume that you won't get error responses from Apple, which would allow you to send notifications quickly.
That said, I'm not sure how reliable and/or fast are the existing APN providers.
The best way to be sure of the quality of the provider you use is to write it yourself (unless you are willing to spend the time on testing the reliabily and speed of existing providers).
Related
In my research, I see this question has been asked a few times, but generally the response seems to be somewhere between "why would you do this?", "it's theoretically possible but not practical" and "yes, but there are technical issues".
I have a real world case where push messages will originate on an iphone and terminate on another iphone. The app is designed for family/couples, who can scan each other's phones to get device tokens, and store them within the app.
Most of the questions I found around this subject are pretty old and mentioned Apple's requirement to keep the APNS connection open for as long as possible, however I am not sure if this still holds with the HTTP2 interface that is now available.
Another comment is that it is difficult, but I'm not worried about that - I've written the server side for APNS and HTTP2, so it's "just" a case of rewriting it in objective C.
I realize that certificates are an issue, and might require users to update regularly to keep it working, although I wonder if there's some way to store them and just have the app update them automatically, without needing to update the whole app. No biggie either way.
So my question is, in 2018, is it possible to implement an iphone to iphone push notification and (taking into account what I said above), are there reasons not to? I could easily make a server for it, but the less third parties the message has to pass through, the better it is from a privacy/transparency perspective, hence peer to peer would be the ideal option.
I originally used http://www.easyapns.com/ as a guide for building my backend and sending push notifications. However I quickly realized that this no longer works, and I'd love to find another solution that works similar.
Essentially I need to store the device and tokens on my backend, and send out push notifications to certain devices in the DB.
Any help is GREATLY appreciated
Thanks
If it's your only requirement, there are many services to do this without creating specific backend, like pusher, push robot, google push notification service, etc.... All take care of registration of the token.
If you need to create a specific backend, then it depends of the others requirements, but Web and Github are full of examples on this topic.
I am implementing the push notification in iOS for sending offers and deals. Right now I am working in the development environment. I see that some of the devices are not being notified. Could anybody explain possible causes? I have also read that if a push is sent to same device multiple times then APPLE disables them for that particular device? Could some one verify this or provide any documentation where I can find the issue. Any feedback would be appreciated.
Not directly answering your question, but what you asked about in the comments and an alternative. You could use a push-notification service such as Parse.
They allow you to send Push Notifications to Web, iOS and Android, also offer data storage and backend infrastructure. The best thing about Parse is that they're free. Unless you have one million unique recipients, which is rather hard to accomplish. Parsee allows you tons end Push Notifications in multiple ways, some including automatic messages based on their tables or other events. You can program those in their cloud code. You can do so using their REST API or their Java Script API if you have a website. You could also send from the Push window on their website.
Setting up is fairly easy. I'll give you the most important links below.
iOS Quick Start Guide
Rest API
PHP Guide
Hope that helps, Julian
If you are dependent on APNS then there is no guarantee provided regarding the delivery of the push notification. And regarding sending multiple notifications. Like if you send notification every min then many may not deliver. Else it will. This service is free and many including myself using it on a regular basis. It has been delivered regularly even though apple will not provide any guarantee. i'm using a php script on server side to send push notification. Refer the below link if you want to know how to send a push notification using php.
tutorial
I have been reading Apple's documentation on Local and Push Notifications. Technically speaking I understand both solutions. However, technical docs sometimes lack details that only experience can teach - and this is the reason why I'm here. I need to know what's the best solution for my current problem.
What I need to do:
I need to implement a notifications system that triggers at specific pre-programmed dates, chosen by the user. These notifications should be synched accross devices, meaning the user can turn these notifications on/off from several devices (which share the user account for the app).
My question:
What's the best way to implement this: local or push notifications?
My analysis:
Local notifications are much easier to set up, plus they should be enough to display pre-programmed notifications that don't depend on server events. The problem is I would need to implement a custom synchronisation mechanism for all of the user's devices through our server.
Push notifications seem a bit of an overkill to me. They are not really necessary for pre-programmed notifications and are possibly better fit for other types of notifications. On the bright side they seem to provide synchronisation across devices out of the box.
I was hoping to find one of the two methods I asked about was clearly superior to the other, but apparently you just have to pick one based on your scenario.
I'll copy a snippet of what I posted above, that proved to be a good list of pros and cons.
PS: In our particular case we went with Local Notifications (we are synching them ourselves across devices when the app is running).
Wich method to pick:
Local notifications are much easier to set up, plus they should be enough to display pre-programmed notifications that don't depend on server events. The problem is you will need to implement a custom synchronisation mechanism for all of the user's devices through your server (if you want the app to run nicely on multiple devices for the same user). As pointed out in a comment by nickbona (above), a custom synch mechanism will only work while your app is running.
Push notifications seem a bit of an overkill and require more effort to set up. They are not really necessary for pre-programmed notifications and are possibly better fit for other types of notifications. On the bright side they seem to provide synchronisation across devices out of the box.
I'm trying to make an iOS 5 app that features real-time things coming from the server. It will only use these whilst the app is running.
To make it real-time without polling I have been evaluating two design routes:
Creating a socket from the app to the server, and exchanging information via streams.
Pros: Relatively simple and would not involve a 3rd party.
Cons: Battery life drain.
For an overview of how this might work, check
out this excellent tutorial:
http://www.raywenderlich.com/3932/how-to-create-a-socket-based-iphone-app-and-server
Using standard HTTP to communicate with the server, and with each request from the app let the server know what they are viewing. If something new is available for user, send an Apple Push Notification (with no visible alert) to let app know it can go and download new thing.
Pros: Not opening up a new TCP connection, so battery life not drained unnecessarily.
Cons: Feels like a poor hack.
The official docs on APNs http://developer.apple.com/library/mac/#documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/ApplePushService/ApplePushService.html
I think a socket would be the way to go, but before I commit to it I wanted a second opinion, as this is the first time I've made anything like this!
Sockets would be my choice. I do not know how time critical your application is, but sockets might perform better as APNs if realtime is a must.
Does it really need to be "full real time"? From my point of view i would prefer http since it is already well integrated into the iOS SDK. Its easy to understand, maintain and implement and plenty of documentation is on the web. So maybe a http poll every minute or so will be enough (depending on the app and the number of users). Please consider firewalls too! Traffic to unknown ports maybe denied due to firewall policies of provider or local wifi. So if you really need realtime connectivity I guess you have to use sockets.