iOS apps exist in millions out there, and most of them communicate with servers to exchange data. In their majority, the server implements and provides RESTful APIs that apps can use for the communication. When an app needs to send data to the server, or fetch from it, it makes the proper request and after a while the data has been returned. That happens several times during the app runtime period.
The above covers the most use cases, but not all. What if, for example, an app should show some sort of a news feed that needs to be updated all the time? Or what if real-time conversation between users should be supported as an app feature? A solution would be to let the app ask for new data the server quite frequently, so anything new to be grabbed as soon as possible. However, this is not the best approach for two basic reasons: First, performing endless and repeated requests leads to unnecessary waste of resources without any doubt at all, and that’s critical when talking about mobile devices. Second, there is no guarantee on how soon the new-to-be-fetched data will be really fetched, even if a short interval between requests is set.
Thankfully, there’s a better solution when it’s necessary to receive data from a server instantly (every time such data becomes available), and without having the app to send any request to the server at all. That solution is based on making use of websockets, and it totally erases the couple aforementioned issues. You can find a couple of interesting topics about websockets here and here, but also feel free to search the web for additional information. On my part, I’ll give you the big picture in simple words, so you are able to better understand what comes later.
The websocket communication relies on the client-server logic, where a persistent connection between a server and a client always exists. To be more precise, the server “opens” a dedicated port where clients get connected to it. Once that happens, all the connected apps can send messages to that port (outgoing messages), and listen to it for any incoming messages. And as that’s the default behaviour when connecting to sockets, every connected client to a server will automatically get its messages without any additional request at all. Most importantly, when a message is sent to that port by a server, the recipient clients will instantly receive it, so they can take any further actions (like updating a news feed for example) immediately.
A word of notice: Keep in mind that from now on I’ll mostly use the term “socket(s)” instead of “websocket(s)” just for simplicity. Besides that, the term “client” refers to any application that can get connected to a server: Web, mobile or desktop app. However, by saying “client” in this text we’ll be referring to iOS apps, and to our demo app more specifically later on.
Implementing the connection to a socket and communicating through it with a server is not the easiest task on the world. Even though the whole idea sounds fascinating, there might exist several problems until it’s possible to achieve a proper communication. Thankfully (once again), here it comes into the play a really handful framework that takes charge of all the connection issues behind the scenes, and makes the socket-based communication a real piece of cake. It’s called Socket.IO.
It happened to me to work with Socket.IO in a big project recently, and I had the chance to see how easy it actually is to have bidirectional communication with the server, and get messages instantly to the app. I strongly advice you to pay a visit to the official website, so you understand what is all about and how it works. Even though Socket.IO has been designed mostly for web applications, it offers a library for iOS that can be integrated into a project in no-time at all.
With all the above in mind, I intend to give you in this tutorial a first taste of the Socket.IO. I’ll show you how to integrate it and use it so you can exchange messages with a server, and I’ll try to explain through examples how the client-server communication works. As this introduction has become quite long already, I leave the details for later. As a last word though I’d like to say that the server-side part will operate on your own computer (localhost), and I’ll provide you all the details and code you need for doing that.