Usually we do a timely communication of the message, are the use of the socket, the reason is many, the most important thing is that the socket can be actively pushed by the server message to the client.
We all know that in iOS, our app can be switched to the background, when our app is switched to the background, the official saying is that can give us 300 seconds to deal with some things from the foreground into the backstage, but not necessarily 300 seconds, if the memory is tight when the situation, Will be ruthlessly killed by the operating system.
Usually the client-to-server connection method is usually through the heartbeat packet maintenance socket connection, when our app is switched to the background, if the connection is continuous, then we can theoretically use the connection, but when the server pushes the message to the client, how should we display it?
When I was doing this, I used 2 different ways to deal with it:
1, when I entered the background, I entered the background state, tell the server, let the server push the message to the client (APNS), so that the message can be displayed on the desktop, but this way the message is often slow to reflect. Let's just imagine how users will use our software.
The steps should look like this: Open the app----> Chat-------> Cut to the front desk------> receive a message--------> open the app to chat, and then after discussion we used the 2nd way.
2, Online mode server push message.
In fact, when our app is in the background, and the socket is alive, the socket message, using the timer, simulates the way the operating system (analog APNs), sends the display to the desktop.
The approximate flowchart is as follows:
How messages are processed in iOS instant Messaging