I'm trying to figure out how to create a push notification server for a twitter app. I'd like to be able to set up push notification for mentions, stars, follows, etc etc. This is all possible with the API, as Tweetbot does it. If someone could point me in the direction of creating the actual server part of handing the storing of the usernames and pushing the messages out, that would be great. If there is a tutorial on how to do this that would be grand! I'd like to be able to do this through ruby but any method is completely fine.
Thanks
The way I built my push server was like this:
1) Symfony 2 web framework to build an admin portal to manage my entities (Symfony2 is similar to Ruby)
2) A Node.js server that allows me to maintain a persistent connection to Apple's push notification server. (This Node.js beast is epic I tell ya)
3) Node.js will make a HTTP Post request to my Symfony server asking it for new notifications
4) My Symfony server will receive the response from my Node.js server, finds all the new notifications that needs to be sent and returns JSON formatted list of notifications that needs to be sent, the notification contains the message to be sent and an array of unique push tokens (also selectively of the token environment - development vs production) that is to receive the push notification
5) Finally, my Node.js server receives the JSON data, parses the JSON and sends the notification binary stream to Apple's PNS server through TLS socket stream, asynchronously for high performance throughput :D
This method has allowed me to separate PHP Symfony server to manage my data without interfering with my Node.js push server that is abstracted from any data-related logic. The Node.js push server just needs to know the message that needs to be sent and the array of tokens to send it to. At the same time, I can extend and enhance my notification entities such as token groups (allows me to quickly fetch a bunch of token just by choosing a group e.g. members, friends and if you like, enemies :D), notification date (so the notification can be sent at a future date rather than immediately) and more.
Hope that helps.
Related
I am creating an iOS application in which user orders an item, when the order ready, the vendor is supposed to inform the user via push notification.
My question is, is it possible to send push notification from one device to another?
For this purpose I want to use FCM. I read that they allow two sorts of messages.
Downstream, messages from server to device.
Upstream, messages from device to server.
Will upstream messages serve the purpose according to my requirement? If so, how am I supposed to implement them?
Let's say you were using Firebase, so for every registered users there is an ssociated device token id save into some collection right. (Registering flow)
Let's say you were using cloud functions (a vague definition would be function that are running into serverless architecture, and they get executed when there are called)
so you'd call this function from your app via HTTP with Post Method
logic:
- extract that http request
- who is sending the message (uid, message)
- who needs to receive that message (someone)
- query that someone's device token id and save it to recipient_device_token_id
- construct to push notification payload (message)
- send push notification for recipients using its recipient_device_token_id
- end the http response
Voila, I am sure there is other way of doing it, but this extracting all the logic from your app to the cloud.
I am new to iOS development and started a tutorial on a simple messaging app using Parse as the server. The way they have it coded, the app queries parse every time a message is sent(to save the message) but seeing as Parse only allows 30 req/sec under its FREE plan how would one go about making a messaging app? Is it standard convention to save data to the server for each message? It just doesnt seem practical to have a substantial user base on an app that can only query the serve 30 times a second.
The question simplified is: what is the standard convention for the relationship with servers for a simple messaging apps? Does the app save each message to a server or is there a work around using push notifications? (But even with push notifications the app would have to be opened to receive them, at least thats from my limited understanding of pushes)
It is not practical to have a substantial user base for a messaging app with only 30 queries per second. Parse is running a business. They give you 30 API req/sec so that you can try out their service and see how it works. But if you are designing an app for a significant user base, you will surely have to pay, as you are expecting Parse to run the servers for you.
With that out of the way, it would be normal for a (typical) messaging app to make at least one API request per sent message to the server. The server is responsible for accepting, routing, holding, and delivering messages. It would also be normal for that sent message to result in a push notification, and an API request from the client app to retrieve the message. The general workflow would be:
User sends message
App uploads message to server
Server determines where message is headed
Server sends push notification to recipient
Recipient app queries server for pending message(s)
Recipient app displays message(s) for recipient user
That's two API requests and a push notification for each sent message.
Beyond that, depending on your messaging service design, the server may also store all messages so that later, on a different device, a user can open the app and it will download the history, so as to appear synchronized.
Now, surely there are ways to reduce the number of server API requests. Your app could batch messages locally, your server could batch push notifications, and your clients could batch queries (or you could do all three). All of these options could help dramatically reduce the number of server API requests you pay for, but they will also reduce the responsiveness and user experience of your messaging service.
You could also design a sophisticated peer-to-peer communication system (like Skype was in the past) removing servers from the messaging flow. However, you would have to design complicated authentication and verification systems, complicated routing systems, complicated storage systems, etc. A lot of work. And even if you did, I don't know if Apple would allow it on the App Store. A lot of time, work, and uncertainty to avoid paying the small cost for a server.
Regarding push notifications: Push notifications are sent from a server to a recipient client app. Your iPhone cannot push notification another iPhone. There will always be a server in the middle. Your app does not need to be open to receive a push notification. iOS will receive it, and then deliver it to your app. If your app is closed, iOS will (partly) open it in the background to deliver the message.
I cannot seem the have my head around this. APNS as stated in the documentation has best-effort delivery, i.e. delivery is not guaranteed. However, if I am to use the push-notification model in my client/server application, I have to use them somehow.
The general model looks as follows: there is new data on the server -> the server then sends a push notification informing the client(s) that there is new data available -> client downloads new data.
The question is then, if I cannot rely 100% on the notification to be delivered, what kind of fallback mechanism can I use so that I can ensure that the client receives the new data available on the server ? What is the way to ensure that the client has the most-up-to-date data using APNS ?
What is the way to ensure that the client has the most-up-to-date data using APNS ?
There is no way to do this with just APNS. Your client needs to query your server when the app is brought to the foreground to see if there is new data, regardless of any push notifications you may have lost or received.
It all depends on how you are planning on using APNS.
Lets say you were making an App that sold items like eBay. You have:
- bids being placed by multiple users
- countdown to item closing time
You would not use APNS to update the timer on the persons device or notify them of the current price of the item. These are too crucial to rely on a best-effort delivery and was not the intended use of APNS.
It would be best if, in this scenario, you had the app poll the server every X seconds for updated information. You could then user APNS for non-crucial features like notifying the user if they are outbid or if they have won the item.
How can an iOS app be notified that it needs to update its content?
I would like to have an app that listens for update alerts that trigger a download rather than doing a data request to be able to stay in sync with the server.
What is the correct way to have an iOS app that needs to be in sync with a server stay in sync while minimizing network activity?
Im aware of using a cache locally, NSURL Cache or Core data etc. and adhere to the timeout in the http header etc. but I would like to correctly setup a sync mechanism without having an update button that a user needs to press to get updates.
I have thought of implementing a dispatch_source on a socket but wont that keep the network active and drain battery?
Rather than request a token for the version of the data to sync from the server I would rather like the server to notify the device that it needs to update. Is this practical?
How does the OS handle listening to push notifications? Is it on POSIX level?
You really have two options here:
Client Side Polling: call the server and ask every so often. For 99% of apps this is fine as it's not that big a deal for someone to run the old version during the interval between polling.
Real-time Server Push: If for some reason you need to disable the old version as soon as you push a new version, you could do a server side push. You would not want to use APNS for this (user may deny APNS, delivery not guaranteed, etc). You would want to use a cheap push service like PubNub or Pusher for this to guarantee real-time delivery. Or code you own version using the same principles of these services, but really why re-invent the wheel?
There are two common, as far as I am aware, approaches to doing this on iOS;
Regular GetUpdates calls to the server at an interval (Fairly standard across any platform I think)
Apple's Push Notification Server(APNS) if anything changes on the server you can push a notification to the device.
At work we typically implement both options because there are a few issues with APNS;
They are not guaranteed to reach the device, if the device is offline the APNS service will store the Notification for a limited time in the APNS system upon which it is forwarded (if it hasn't expired)
If multiple Notifications are sent while the device is offline only the most recent notification is sent
If the device is offline for a long enough period of time all stored notifications will be discarded
the user has to allow Push Notifications to be sent to their device because it suppliers and identifier that you can use to determine the device
lets suppose I have a PHP web service, and I have an iphone app that communicates with it. If the iPhone want info from the web services, it makes an http call to the server ans retrieves information. But how do you do this the other way around, how does would the server notify the the application when some state has changed, and what is the most efficient way to do this?
What you are looking for is Push Notifications. You will need to create a push notification server that will send notifications to your users. http://developer.apple.com/library/mac/#documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/ApplePushService/ApplePushService.html