iOS chat application design, sending/relaying the message over to the end user

Question

I have a design question. Let us say you were tasked with building a chat application, specifically for iOS (iOS Chat Application). For simplicity let us say you can only chat with one person at a time (no group chat functionality).

How then can you achieve sending a message directly to an end user from phone A to phone B?

Obviously there is a web service layer with some API calls. One of the API calls available will be startChat(). After starting a chat, when you send a message, you make another async call, let us call it sendMessage() and pass in a string with your message. Once it goes to the web service layer, the message gets stored in a database.

Here is where I am currently stuck. After the message gets sent to the web service layer, how do we then achieve sending/relaying the message over to the end user? Should the web server send out a message to the end user and notify them, or should each client call a receiveMessage() method periodically, and if the server side has some info for them it can then respond with that info?

Finally, how can we handle the case in which the user you are trying to send a message to is offline? How can we make sure the end user gets the packet when he moves back to an area with signal?

Answer 1

Other users have suggested APNS but you should be aware that if you late r decide to port your application to Android and/or Windows Phone, this will be harder to achieve if you are tied to a platform-specific push API. There are several alternatives that are suitable for use on all 3 platforms listed in this stack overflow question: https://stackoverflow.com/questions/9801720/push-notifications-on-all-3-platforms-android-ios-windows-phone

Answer 2

I´m assuming there is some sort of client ID involved in this solution. Then it´s simple, Client A sends a messages to the server with Client B´s ID, the server stores the Messages (perhaps a flag indicating that it hasn´t been read). Whenever Client B connects it asks the server if there is any unread messages, and if so, polls them.

In the case that Client B is connected whilst Client A sends a message then the server should directly distribute the message to Client B.

Best of luck

Answer 3

I've done something similar. iOS --(Sends request with message and id of recipient)--> Server --- Sends message over to recipient --> iOS

However I used notifications to do the final delivery. This means the server has the tokens for the devices stored, once it determines who is who it sends a request to APNS.

Answer 4

APNS is the most obvious way to do this. It does mean you will need a central server, and it also means there will be some maintenance, as you are expected to clean up expired tokens. There's also registration with Apple when it comes to doing your certificates, but nothing too stressful. One thing to take note of is the relatively low character limit.