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.
Related
I am writing a messaging app in Swift where people can chat similar to how text messages or other popular chat apps work. The supporting API is on AWS, written in C#.
There are some points of interest here:
Hoping to avoid third party stuff like Firebase, etc, but open to listening to advice
Alert notifications are not desired for now - no popups, banners, etc. Simply want to show message bubbles arrive in real time on one viewcontroller - if and only if the person is staring at the message screen. If they're somewhere else on the app, nothing happens.
We don't want to prompt the user to ask them if they're OK with this app sending notifications because we're not sending them banners or anything visual, aside from a new chat arriving. Is that a requirement with APNS? I feel like this means someone can say NO, and then we have no way to update the chat app in real time, which won't fly.
I assume a simple approach would be some sort of timer/loop that runs from the message viewcontroller, where every second or two it hits the API and asks if there are new messages, but that seems inherently wrong to me - the app must be robust, and there could be thousands or hundreds of thousands of people using this - that's a lot of API requests, and in many cases there could be no new messages, thus a wasted call. This is clearly not the way to go, correct?
Question # 1
I was thinking, then, that I should use APNS, however am not sure if it requires you to prompt the user to ask them for permission to receive anything from Apple? Again my concern is the chat bubbles should come in at real time and don't want to give the user the ability to somehow not see these (breaking the app)
If APNS is the way to go, and I must prompt them, then I assume the flow is I will gather my device ids (created in appdelegate, saved in my C# db, and associated to each message thread) and whenever someone types a message, it goes to my API, I save it in the message database table, and then I send out a message to APNS to everyone's device id.
Apple queues this up, and sends to everyone, and if they're on the screen, then the message comes in.
Is this how I should leverage APNS to achieve what I want?
Question # 2 I've seen others recommend using SNS (in conjunction with APNS) however I don't understand why. Doesn't APNS both act as a proper queue, as well as a notification service, thus invalidating the need to use AWS's SNS/SQS at all? It seems redundant to me but maybe I just don't understand the idea behind why you need both technologies.
Appreciate anyone's time in advance if they can shed some light on this for me!
Thanks!
Question 1
Even if you're using WebSockets (As #stevenpcurtis mentioned), you still need to inform user about the fact that user received message when application is in background/suspended. And yes, you must "force" your user to enable notifications for the application and explain why he needs it. Empirically, if user installs messenger, he understands what are notifications used for and why he enables it.
Question 2
From the mobile perspective SNS will still deliver Push notifications when user receives notification while the application is in background or suspended. From the backend perspective you can use SNS.
Conclusion:
From the mobile perspective you have 2 modes:
Application is active - it's generally up to you how to receive messages. (Web Sockets, pushes, e.t.c.)
Application is in the background or is suspended: You need a tool to inform user about changes without having a control on application. This is the job for Push Notification Service. The way you will send pushes from the backend is up to you.
You can also check This question to get some more information.
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 making an iphone app that uses NSURLConnection to download some data from the web. I need to store this data somewhere, so my app can send out push notifications when the data changes in a particular way. For example, the data being stored is a number and a push notification will be sent out when that number changes by +-10.
I'm new to this, so I'm probably overcomplicating how I think this can be accomplished. I'm thinking I need to create a database and some server-side code that continuously pulls the data. When the data changes to my specifications (ex. +-10), it somehow pushes the data to the app which then sends out a push notification.
Is there an easier way to accomplish staying within xcode dev?
The app doesn't send the push notification. The point of push notifications is your app can be in the background so it can't poll/check for a given condition (like your +-10).
When that interesting even happens server side, it can push a notification to the device. The device can handle that notification by (1) showing text (2) playing a sound or (3) updating a badge on an icon.
So, it's not about your device downloading the data into database (although that has value for offline and occasionally connected scenarios).
So, you'll need a server side component that detects that +-10 change (on data change or polling) and then sends the push to the device. Now, it's possible that devices are sending data to your service (uploading) and when and interesting event happens it could notify other instances of the app.
This link may help clarify push notifications: http://www.raywenderlich.com/3443/apple-push-notification-services-tutorial-part-12
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
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.