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.
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 was wondering how social networking apps, such as Twitter, Facebook and WhatsApp update their user interface in real-time when another user interacts with the user of the app. To use the best example I can think of: when you have a chat window open in WhatsApp, the UI updates automatically (without any user actions required) when the user you're chatting with interacts with you. Messages appear on your screen without refreshing and the "last seen" status at the top of the screen updates automatically when your chat partner either goes offline or comes back online. I can think of two ways to achieve this:
Remote push notifications: this approach strikes me as the 'cleanest' way to do this, but it's probably also the riskiest way. Using silent notifications (content-available) to pass data to another device at the moment a user does something, would probably save you a lot of HTTP requests and therefore would make your app consume a lot less data and CPU usage. The risk of this approach is that a user can easily disable ALL push notifications to save battery power (including silent notifications) and then your app wouldn't be able to get notified on events remotely.
Local UI refreshing: This approach is obviously the safest, but I think it's really 'nasty' and eventually everyone would feel the downside of it. Constantly refreshing the UI and re-retrieving data from the database to make sure the latest messages and statuses are displayed to the user would be safe in the way that your app doesn't have to rely on the device's battery and background mode settings, but the downside is that this will make your app consume a lot of data and battery power, which would be bad for the user's data plan and his device. I also don't think Apple would approve of an app that's consuming so much data and power.
I've just implemented a chat function into my own app, and I want to enable the same real-time UI updating that WhatsApp uses. What would be the best way to do this? Should I use one of the two methods above or can someone think of another way to do this? By the way, I'm a relatively new programmer who just recently learned how to develop iOS apps (Swift). I'm very far from being a pro, so please go easy on the explanations and work method capabilities. Thanks!
The chat apps make use of WebSockets to create a constant connection with the client and a backend server.
This article on Appcoda can help you start learning about Socket.io. It answers your questions and also helps you to create a demo app.
I want to write a feature in my app that checks local data daily (at a specified time eg. 12:00pm), and alert if needed. Really, I want something kind of like setTimeout() in Node.js.
Does Trigger.io's API give me a way to 'background' a small check, or fire an event at a specific time? Something via the OS,so that the app doesn't have to be running all the time?
I've searched through the API, but might be using the wrong terminology (as a non-mobile dev).
This isn't something currently supported, mainly because its difficult to provide a consistent experience across Android and iOS.
A common solution to this kind of problem is to have the check performed on a remote server, then use a push notification to notify the user if required. (see http://docs.trigger.io/en/v1.4/partners/parse.html#partner-parse)
The reason doing this on the device is difficult is that on iOS you cannot just run code in the background, it is possible to send a notification to the user at a specific time but this notification has to be set in advance.
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).
Building a multi player iOS game where players compete one against the other. Nature of the game is synchronous. Basically, players either invite each other through facebook, email, etc and then start playing.
We debate what is the best strategy for facilitating the real time communication between players (sending events, etc). Coming from web development, we used comet and long polling which worked great. However, it's not clear what's the best way to achieve that on iOS.
Seems like APN (Apple Push Notifications) is not suitable in our case for two reasons: the delay can be pretty significant, up to few seconds, as far as we understand. Also, using APN requires the user to authorize notifications. If the user doesn't authorize this then it won't be possible to play the game.
Also, we understand Apple's Game Kit (Game Center) can be of value in our case however it's not clear how it interacts with invites through facebook etc. Also, not clear if we need to get into bed with Apple's Game Center and how it'll affect the user experience.
Any guidance on this matter as well as other options that you might think of would be greatly appreciated.
Thanks for your help.
Before you read the rest, a disclaimer: I work for Realtime.co but I do believe I can help here so I'm not trying to "pitch a sale".
If you need to have real time updates, you can check out Realtime (www.realtime.co). It's basically a set of tools for developers to use real time technologies on their projects. It uses websockets but does fallback to whatever the user's browser supports (such as long polling, for example) if you are using a browser (which is not your case, but it's always good to know).
Behind Realtime you have a one-to-one/one-to-many/many-to-many messaging system that will transport your messages to and from your users.
There's a iOS API too which you can use in your project. You can download it here: http://www.xrtml.org/downloads_62.html#ios and check the documentation here: http://docs.xrtml.org/getting_started/hello_message.html#ios.
There's also a plus which is the fact that the Realtime framework is actually cross-platform. This means that you can even have your iOS players to communicate with players using Android, Windows Phone, HTML5, Flash, etc. if you decide on expanding your game to other platforms.
I hope that helps!
I'll just provide some insights on the question.
APN should never be used for synchro communication as for iOS at least, you'll never have both way communication (basically the Apple APN servers are pushing an information to the device).
You should probably play with C sockets in order to open a tunnel (depends if your game is real time or not).
Using the Apple Framework GameKit is great! But might take some time to understand all the functionnalities.
Check out Gree
https://developer.gree.net/en/
Parse:
https://www.parse.com/
Sparrow:
http://gamua.com/sparrow/
There are a few things that your talking about, there is the joining/starting of a game, and then the communication between the players. They are not necessarily related.
You can use game-center and at the same time another framework for facebook, they are not mutually exclusive (but it would be more work.)