Advanced Application Scenario
Each Message Needs to be Received
In some scenarios, such as corporate office class and order status notifications, the pushed messages need to ensure that users must receive them; if they are not received in time, further measures need to be taken.
Pushing notifications/messages through the network has a possibility that the notifications cannot reach the users in a timely manner (because of the mobile phone and the network). Therefore, you need to check in a timely manner to confirm whether the client has received.
- The JPush Report API provides delivery statistics for a message. This statistic is real-time, and be checked immediately by calling this Report API after push. It allows continuous checks for multiple times at a certain interval;
- The developer app feedbacks the confirmation of push message received to their application server.
Implement Chat Based on JPush
To meet the developer's IM functional requirements, Jiguang provided JMessage. JMessage is based on the long connection technology of JPush and adds the IM feature to meet the typical IM App usage scenario. The App that integrates the JMessage SDK and JPush share the same connection and have full JPush functionality. Detailed Reference: JMessage Guide
Offline Messages with Multiple Account Logins
The client app is a QQ-like (chat) client application that supports multiple account logins.
The chat account UID is set to a JPush alias so that chat users can push messages to each other through aliases.
After the A account is logged in (binding A uid to an alias), you can push messages to A through JPush.
After A quits, log in to B (update bound B uid to alias). At this time, you can push messages to B through JPush. However, if you continue to push a message to A, you will get an error and cannot find the target user by alias A uid.
The JPush alias is set for the device. Only one alias can be bound on one device. The new alias will be overwritten, and the alias that is overwritten will no longer correspond to the device.
This is the mechanism of JPush.
In this scenario, if the A user does not log out, you can still push a message to him and let JPush save the offline message so that A can continue to receive the message when he logs in again.
This business scenario requirement is overly dependent on JPush.
JPush just does the "push" this only function. JPush provides offline messages for a limited period of time. It is part of the push mechanism, not to save the history message.
If the developer application wants to do recording of history message, it should be done by its own application server.
After the user A logs off, when there are other users who want to send messages to user A, the developer application server should save the message history and not push it to user A. Only user A can log in again, you can push messages to them.
Alias Setting for Multiple Account Login
Client App supports multiple account logins.
When each user logs in, the UID of the account is set as an alias so that the user's push message is received.
However, there is a problem: After A logs out, the push message sent to A before B updating its alias will be received by B.
The alias is bound to this device (this application). Before B succeeds in setting up an alias, the information pushed to A is always received.
Before A user logs out, make an alias setting: Set the alias to blank.
Then the push to A will not be pushed to this setting.