Edit Question - KnowledgeHub

Title Body

I'm working on a messaging app and I have a dilemma about how to send data from server to client. I'm using a centralized server design, where clients uses NSURLConnection to send messages to the server, the server doesn't keep and manage open sockets and can't send a message for one of the clients. So clients use a timer and query the server every 2 seconds to see if new data is waiting for them. The problem with this approach is that polling the server every 2 second seem to kill the battery very fast, so I thought maybe instead of clients polling the server, to use APNS* so when the server has some new information ** for the client, the server will send a push notification * ** to the client, then the client will fetch the data from the server. * use APNS - if client allows it, client can of course disable this option. So I will check if push allowed every time the app enter foreground and if not I'll return to the polling approach. ** New information can be anything from text messages to server admin messages. (and there are a lot of admin messages...) For example, in my app users can see their friends status (online/offline), so if user1 and user2 are friends, and user2 just change his status from online to offline, then server needs to send this new info (admin message = user2_offline) to user1. *** The push notifications server sends are empty (with no data/sound), it's just a trigger for the client to fetch the new info, so if a push was sent to the client and the client app was close, he will not notice anything. (if the app is running, then it will fetched the new info from server) Will this approach work with a massive messaging app requiring massive push notification uses? To be clearer my main concerns are: 1. Is APNS rel

Tags (comma-separated) Cancel