I am using Titanium to develop an iPhone application, in which has a small chat component between the iPhone users (not SMS, but actual client-server chat)
This is my approach: my back end will be in ASP.NET, every time a user sends a message, it will store [message_id, from_id, to_id, message_content], and then the receiver will have a timer that refreshs every 5 seconds to pick up new messages from the ASP.NET server database.
But this raises a concern. If I keep doing a refresh every 5 seconds, it will constantly stream and exhaust the receiver's bandwidth. Is there a better to way to implement a listener/receiver when there is a new message?
I have heard of socket programming but is it a good approach for this situation and how do i get started with it?
Thank you
You won't just use bandwidth, you'll eat up battery power too. Use push notifications instead.
It would be advisable to use push notifications only for when the application is running in background, not for when the user is actually chatting. That's what push notifications were designed for in the first place.
Polling the server via http is a good solution and there are techniques to save bandwith that you can use such as updating the frequency of the polling depending on user activity (no chats since a few minutes, reduce the polling time to 30 seconds).
You cannot use push notifications for a chat application because you cannot obtain so many notifications per minute to make the chat appear to be in real-time. And a simple http poll to a server can be as small as one binary package and not affect the user's bandwith significantly.
Why don't you just use Apple's push notification system?
Whenever a user receives a message your back end can send a push notification to the iphone and the iphone either downloads new messages whenever it receives a push, or if the message isn't too long you just send the message directly in the push notification
Related
I am trying to write an iOS app that will notify the user on price changes of products I access as JSON information via an API. I want to have a background task that will repeatedly check the server every n minutes for new JSON and send the user a notification if certain conditions are met. What would be the correct way to do this?
As previous posters mentioned, this is better done server side rather than via polling. However, using Apple Push Service to notify the client device is not the ideal solution. The issue is that delivery is not guaranteed (per Apple) and you cannot confirm delivery. The user could decline push notifications, Apple could decline to send the notification if you are sending too many, etc. You are much better off using a service like PubNub or Pusher, which push notifications to the client in a reliable way and both have iOS APIs. They are very inexpensive. If you wanted to reinvent the wheel and save money, you could look up how they work and write your own version.
You could of course do client side polling, in which case an asynchronous NSOperation is particularly well suited (it will run on a background thread and you can post notifications to NSNotificationCenter when things change). You can find out more about how to implement that here.
This does not work well. Here is a probably better solution:
Set up a server that polls the JSON data source.
When the data source changed, use Apple Push Service to notify the user.
Upon receiving of the notification, start a background fetch session.
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 reliable enough that I can use it as my core server-to-client messaging mechanism?
2. Will apple approve potentially thousands or hundreds of thousands push notifications a day from my server?
Is APNS reliable enough that I can use it as my core server-to-client messaging mechanism?
NO. Just for the sake of being complete let me iterate over the reasons.
Apple itself disclaims the reliability read the Programming Guide
Also, APNS, has a QoS component which may increase the reliability at the cost of being realtime (For Eg. I can ask APNS to deliver the notification anytime within 4 weeks and retry if devices are not reachable) which is not useful in your case.
As per your requirement, if you send a silent push (a push with no user visible message), it can not be sent as a HIGH priority push which decreases the reliability even further. Here is a relevant quote
"Silent notifications are not meant as a way to keep your app awake in
the background, nor are they meant for high priority updates. APNs
treats silent notifications as low priority and may throttle their
delivery altogether if the total number becomes excessive. The actual
limits are dynamic and can change based on conditions, but try not to
send more than a few notifications per hour."
Will apple approve potentially thousands or hundreds of thousands push notifications a day from my server?
Generally, APNS will not have any issues with this in terms of load, but it has throttling in place and they might throttle your notifications, see point 3 above
IMHO, you should look at XMPP as this protocol is designed just use-cases like yours and they have wide community support on all platforms. I will suggest you look at something like https://github.com/robbiehanson/XMPPFramework and setup an XMPP server at your backend which will handle the messaging and presence messages as well as admin messages.
If you have already evaluated XMPP and do not want to go with it, I would suggest you need to put together an intelligent system in iOS App which employs different strategies based on App State, something like following, you can have following strategies
A Realtime Socket based approach -> Establish a permanant socket connection and keep the data in sync as much as possible (This is when your app is running into foreground or background)
The Polling System You talked about in question, which can be utilised when your app is invoked for background fetch/location updates etc.
Use APNS with user visible messaging + custom data, when your server detects that the device does not have active socket and also have not polled for a very long time
I have worked in this area for a while and from my modest experience I think your approach to solve your problems will reach you nowhere. Allow me first to highlight some important facts on the APN characteristics:
APNs are not reliable, they are not 100% guaranteed to reach the client.
As of Apple's documentation, APNs are best effort, so many times they might not reach.
APNs don't hold data inside them, so even if they reach your client app they hold nothing inside them for the app.
APNs are just notifications for the user that something related to your app has occurred, while there message (the text that appears in the Alert Box of the APN) is handled by the iOS and not your app. This is why devices with iOS 4 will display the APN in a different way than devices with iOS 5, it is OS job not your app.
The badge value that appears on your app icon when notifications come is the responsibility of your server, and not the device OS. Put differently, when an APN reaches the device it should come having the new notification count value for your app. The OS won't do anything for this.
Having said that I would like to explain a bit how usually such applications are designed. First, it is not done by URL Connections and the clients don't check the server every period of time. Usually you have a client/server architecture where your client is the app on the device and the server is a real server program that resides on a server machine. The server could be Microsoft (using C# for example) or MAC (using Objective C). The server has a database that it stores information inside it. Some important information (related to your question) is the APN Count Value, the Message that you want to deliver, the state of the client if online or offline.
When a client likes to send something to another client, or when the server wants to send something to a client (or all the client), a check is made to the recipient client to see if he is online or offline. If he is online the message is sent directly, and usually the communications are done on TCP Sockets. If the user is offline then the server will store the message that needs to be sent to the client, increase the APN Count value, send an APN to that recipient. When that recipient becomes online, the server will notice that (because there is establish connection and handshaking) and therefore will fetch all undelivered messages from the database and send them to him...
It is a long process, I hope I was able to explain things a bit to you. In all cases I don't think your way is practical or enables you to reach real work.
Im using restkit and push notifications and I have also built the interface, so here is my question I wanna know your opinion on how to build the structure of a chat app with restkit.
Should I update the incoming messages every 5 min ? OR
Should I update when I receive a push notification ? OR
AND
should I use the restkit queue to do this?
Should I use restkit core data ?
So, I guess my question is the best way t ask the server new messages.. so what is your recommendation???? mmmm... is there any example or framework ??
THANKS!!!
If you're building any sort of chat application, your users will expect that their messages are received immediately. I will assume that your server dispatches a push notification as soon as it receives a message. You should poll the server for new messages when the following events occur:
A user launches the app.
The application resumes after being suspended to the background.
The user launches the app in response to a push notification. (probably the same code as 1).
The application receives a push notification while it is active.
If your server reliably sends push notifications when an event occurs, you shouldn't need to manually poll.
You shouldn't need to directly interact with the RestKit Request Queue for something as trivial as this. RKClient can safely manage it for you.
Remember that the user will expect the app to handle network reachability issues well. The request queue will do reachability tests for you and appropriately queue requests until the network is available, however you may need to listen for notifications and provide an appropriate response. To do so, you should register for RKReachabilityStateChangedNotification NSNotificationCenter notifications posted by the RestKit framework. You may also need to save unsent messages locally and retry them later, especially if the application is suspended/terminated.
Remember to keep track of some sort of unique identifier you can use to tell the server what message you most recently acquired. The server should then send you an array containing every message after that point.
Finally, Core Data is a great way to store data that must persist between launches. With RestKit (and inherently with core data) your data is conveniently available as a collection of objects, and you can perform powerful queries against this data.
i m making an application where data is accesed from website and displayed with an application.i have made an action which will tell the user that new data has arrived.this will work properly if the application is open .but if the application is closed than ,is there any way to tell the user that new data has arrived ,,so that he can open the application and check the data?
If you are using the Apple Push Notification Service (APNs), your messages will be delivered whether the application is running or not. For information on how to control what information is presented to the user, read the Apple Push Notification Programming Guide.
You should use Apple Push Notification Service, like codelark said.
I would recommend looking into Urban Airship for help getting started. It's a third party service, but it makes things much easier. Urban Airship does have their own tutorials and code samples which may be easier than Apple's.
As a follow up to the reference to apple push notification, as of ios4.0 I believe you, you may have a few more options, 1) you can send local notifications (just like push notifications, but they originate from inside your app) that could be timed to be delivered even if the app is not running..assuming you know approximately how long it will take for data to arrive. 2) if your data update will occur soon after the app closed.. your app can request a certain amount of time to complete an operation (even though the user has closed the app) and wait for the data, then send a local notification to tell the person to come back into the app. 3) if your functions based on gps updates, music streaming, or voip you can set a flag so your app continues to run in the background
sorry for the unstructuredness of the answer, this was just off the top of my head, hope it helps
How are push notification better than pull notification on iPhones?
Are there any links with more information about this?
Any help would be appreciated.
Pull notification requires the user to be running your app, and your app to be wasting battery power constantly polling some server (or waiting on some network socket in another thread , or using the new background services).
Push notifications, when enabled by the user, and if the phone has a network connection, allows a message to be sent to a phone even when it's not running your app, prompting the user that your app wants some attention. It uses a much lower power network connection than any frequent polling method.
If you want to know about push notifications, I'm guessing you are interested in the Apple Push Notification Service.
You can read about its architecture here:
http://developer.apple.com/iphone/library/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/ApplePushService/ApplePushService.html
There is no such thing as a "pull" notification, but using APNs gives you the advantage that you don't have to manually poll a server every so often within an app, which usually saves you a lot of battery life in the long run if you are interested in telling the user about sporadic, infrequent events. Using push notifications also allows you to interrupt the user if they are not currently running your app, which of course can be very useful in certain use cases.
You should think about what kind of message flow you expect to see between your app and any server components in your system. Push notifications make the most sense where some event external to your app is going on which requires the app to be updated in some way, and where the frequency of those updates is low or highly variable.