I'm doing research for making a chat based app for the iPhone (it's not really text chat in the regular sense, but the principles are the same).
Maximum 6 people can be logged into the same chat room at any one time, and the most basic question is how to efficiently check for new messages?
Would I need to simply poll the server periodically? Or is there a way I could trigger an event on the phone from the server whenever there is some new content to pay attention to?
If having to poll all the time, I worry about the resulting lag as each participant will have to wait longer for others before they can post their own responses to others. And, potentially it might also be too much to handle for the server to respond to lots of requests all the time. It would also waste bandwidth, which is not free for the user...
Unfortunately I will not be able to set up a socket server for this app, it has to be based around a regular LAMP configuration.
I think you can either go with push notifications, or XMPP (Jabber) server.
XMPP will allow your iphone app to receive data even when in the background using the new multitasking features (listening for a socket), and i'm pretty sure you should find ready to use servers for LAMP (or at least open source implementations).
Note that the iOS4 multitasking API doesn't support polling in the background, so your only other option should be push notifications. If you're new to push notifications, you can maybe use a service like Urban Airship that might make the process easier.
XMPP sounds good for you idea, i think this is the best technology for Chat. It alos works great in iOS apps.
Maybe this code sample will be helpful to start using XMPP in iOS app - look at this QuickBlox Chat code sample. It demonstrates how to integrate 1-1 Chat, Chat in room into your android application. Also there is guide how it works. I think there will be no problem to integrate it into your application. Otherwise - Comments system below allows to ask any question you want and get fast answer.
Also there is Demo video http://www.youtube.com/watch?feature=player_embedded&v=SncQaJBBW_0 how this Chat works.
In my opinion the best solution is socket, but you say that you can't implement the server side for this.
You could also implement it with push notifications. You can receive the push also when your app is running and send all the data you need inside the push. Usually chat messages are short...
If you don't want to mess with push notifications on the server then the only thing left, as long as I know, is the polling.
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 want to create an application which will be notified by server for new events. (lets say I have a shop and I need to inform all my iPhone users for my sales or something like this) Users who will download my application and run it and then put it in background wil have to be notified by this. Im quite new to iOS and Objective-C but if im not wrong this could be done via apple push notifications. Ive been reading about this and found out there are some providers that let you send this notifications. My question is, are there ways to create your own notification "center" in lets say c# and send notifications to iPhone-s by yourself, also if this could not be done are there any free providers?
and another thing. In objective-c app you have to subscribe your app to listen to that kind of events. Could you create app in phonegap or some other technologies so it will work with notifications? could you lets say embeed your app in objective-c (like web app in objective-c)
For sure you can do your own C# program that will push APNs to your clients (in fact I did that myself in many apps). What you have to understand is that the architecture of APN has 2 critical facts:
APNs are best effort, so no guarantee that they will reach every time.
APNs can not hold a lot of information with them when they reach your client (they have a limited number of bits, refer to the Apple documentation).
Due to these facts you might need to have your own server application (also could be in C#) that will handle sending the real information to the clients and will make sure that the data reached your client as well. Needless to say, this server application should sit and run on a real server. Maybe due to this fact some developers start looking for a third party solution, but personally I prefer not to use a third party and I do everything myself.
Other than having your own server application, your iPhone app will need to have some sort of database (probably SQLite3) to store the received news and display them later on.
EDIT: Answer of your questions in the comments below:
For the first question "why iPhone app must have sql db". In fact it is not a must, as I said in my answer above, it is probable or a possibility. To know if you will need a database or not this depends on the nature of your app itself. For example you might be pushing text and images to your clients and in that case you can not fit such data in the payload of the APN. Another possibility, you might want not to lose the sent notification even if the user discarded the APN message, you might want to show it again when he opens the app later on... So the nature of the app decides whether you will need a server or not.
For the second question "you said you dont need to send notification via third party", let me clarify something in my answer. As an Apple developer I don't consider Apple servers as third party. Put differently, the real APN will only be sent via Apple servers and we can not change this fact (nor do we want to change it too). So at the end of the day the real APN will be sent to Apple servers and Apple servers will work on delivering it to the actual client. What I consider a third party is someone that has his own server, you send the message you want to him, and then he sends it to Apple servers. In that case there is someone between you and the Appl APN servers and this is what I called a third party, and this third party can be avoided as your C# code can directly connect to the Apple APN servers and ask it to send the message to the client. I hope I clarified my point.
Yes, you can use APNS with the phonegap application: Receiving push notification on PhoneGap for iOS
Regarding the server, there is another option for you besides doing everything from scratch. You can use the third-party server via API, seems that pushwoosh (http://pushwoosh.com) guys offer this option (and they provide phonegap integration as well)
I am currently starting my way on developing iPhone applications, and I have recently encountered a problem which I could not find a proper answer to.
In my application, I want one iPhone to send a request and another, far iPhone respond to that request using an Alert View, almost like the way Game Center works when you invite someone to play with you.
Do I do that with Push Notifications? Some server? Or what?
Thanks ahead,
A Newbie Developer.
Not the simplest things to try and do when you are new - but have a look at GameKit.
There is a sample application called GKTap which shows how to hook up two iPhones.
Don't be fooled by the word Game. This framework makes it easy to set up communication between phones, even using Bluetooth.
It depends on what you mean by "far". If you mean in another room, but within Bluetooth range or on the same local network, then there is GameKit. If you mean on a different network, or a long distance away, then you are looking at needing to have a server that keeps track of the devices and the connections between the devices so you can use Push Notifications. If you are thinking of something like Words With Friends where it sends a message to another user to tell them it is their go, then you would need the server.
I'm new to iPhone programming. So far I've only written a couple of simple apps just to get the hang of it. In a short time I will have an assignment to write an app that will let iPhone users communicate directly using short messages, and probably they will add a requirement to be able to send files to each other attached to the messages. Of course this sounds a lot like a mail client. For several reasons the client does not want to use mail, if possible, and attaching files would leave SMS messaging out. I've been reading Apple's documentation on local, push and broadcast notifications. Would any of these be the way to go?
Thanks
User bonjour if you are one the same network: http://www.mobileorchard.com/tutorial-networking-and-bonjour-on-iphone/. Otherwise it sounds like you want to use Push. I'd recommend checking out Urban Airship