Is the APP a user queuing function pull or push?

APP function Overview: a user opens the APP and receives a queuing number. After receiving the number, the user waits. The waiting process will show the number of queues you have received. How long will it take, the user will see changes in the queue information in real time. It is a bit like queuing up a bank for business. Problem: I am currently using AP... APP function Overview: a user opens the APP and receives a queuing number. After receiving the number, the user waits. The waiting process will show the number of queues you have received. How long will it take, the user will see changes in the queue information in real time. It is a bit like queuing up a bank for business.

Problem: I am currently using the APP to send requests to the server interface through regular polling. If the APP suddenly breaks the network, the team will be stuck and the people behind will not be in the front. I have written a plan task to clear these abnormal users in the background. I personally don't feel very good. Ask Daniel if the push method is more advantageous than client round-robin? (The number of people in the queue will certainly not exceed 1000). If the push is triggered by a scheduled task or by a user who has completed the service or just joined the team, is there any other way?

At present, if the APP polling request interface is used, once the APP enters the background, that is, pressing the home key, and so on, it will not continue to request my interface, it is also considered by the background program to be cleared by abnormal users.

Reply content:

APP function Overview: a user opens the APP and receives a queuing number. After receiving the number, the user waits. The waiting process will show the number of queues you have received. How long will it take, the user will see changes in the queue information in real time. It is a bit like queuing up a bank for business.

Problem: I am currently using the APP to send requests to the server interface through regular polling. If the APP suddenly breaks the network, the team will be stuck and the people behind will not be in the front. I have written a plan task to clear these abnormal users in the background. I personally don't feel very good. Ask Daniel if the push method is more advantageous than client round-robin? (The number of people in the queue will certainly not exceed 1000). If the push is triggered by a scheduled task or by a user who has completed the service or just joined the team, is there any other way?

At present, if the APP polling request interface is used, once the APP enters the background, that is, pressing the home key, and so on, it will not continue to request my interface, it is also considered by the background program to be cleared by abnormal users.

I personally think this is the case. In terms of your business needs, the customer's requirements for timeliness are not high. If you want to see changes like Didi taxi, you can round-robin and push; if the requirement is not high, you can push only. I feel that pushing is more important than polling.

The main reason is that he does not know the user's queuing policy. If the user enters the background, the user will be deemed to have automatically given up, then the round-robin is acceptable. Otherwise, he will not know when the user is ranked, you cleared him. This is a correct question ~ It is not a problem of system design.

I personally think a common queuing strategy is that the client sends a request to the end of the queue; it is a user's turn to send a push to him and ask him to confirm; if the timeout is not confirmed, it's the next person's turn. If you need to be able to see the queue status in real time, add a round-robin scheduled update; otherwise, you can update it manually or when you enter the interface.

I don't know what your business needs are ~ The system design should fit the business needs.

If the real-time requirement is high, the round-robin + push method can be used. The 'websocket 'method can be used to optimize the round-robin '.
If the above method does not meet your requirements, we recommend that you use 'sockets 'to notify the client to refresh.
Both 'websocket 'and 'socket' only complete the notification refresh task, the data retrieval method or the Http method, which can reduce the development workload on the existing basis.

We recommend that you push data. Polling is too costly for server resources!

Round Robin + push ~

Is it estimated that you use a third-party push? Therefore, you cannot rely too much on third-party push. When there are so many android devices and the push process is killed by anti-virus software or something, the app is rushed to the streets ....