Queue-Fair Native Android App in Action

You can protect your busy Apps as well as your website with a Queue-Fair Virtual Waiting Room. See https://queue-fair.com for more information about Queue-Fair.

We have native Android and iOS (iPad and iPhone) and also MacOS Adapter libraries available at our GitHub repository, https://github.com/Queue-Fair . The Adapters also come with a Demo app and full tutorial instructions.

This is a video of the Android demonstration app in action. In the Demo app, Queue-Fair has been configured to protect the launch of a second activity, though it can be used to protect any app operation at all.

The queue display is completely customisable - we give you full access to and control over the HTML that produces the queue display, so you can rebrand it to your own brand, change all wording, colours and display styling to suit your user needs, and choose which information you wish to display - so for example, if you only want the Progress Bar, you can have just that. You can combine HTML elements with native Android or iOS UI components like buttons and labels as you see fit too.

The Progress Bar shows that the user's place in the queue is saved when they leave the queue and come back (abandon and rejoin) - so rather than being sent to the back of the queue when they come back, the user has progressed through the queue as if they had left the app open all along. The user's place is saved no matter how the user leaves the app - whether by the back button, by opening another app, or even by terminating the app completely. You can also see this in the Join toasts that appear at the bottom - the request number is the same each time.

Once a user is passed by the queue, this status information is also persistently stored, and the user remains Passed for the Lifetime that you specify in the Queue-Fair Portal, so they won't have to queue again while they use the protected activity or secondary activities. You can see this for yourself towards the end of the video - once this user has been Passed by the queue, the protected activity launches straight away, with no queue, and status of Repassed, even if the app is terminated completely.

When there is no queue, because things are not busy, the user goes to the protected activity straight away (SafeGuard), without seeing any Queue display at all - but your app will still know that the user has been Passed. When your app gets busier than the SafeGuard threshold you set in the Queue-Fair Portal, the app will start queueing additional users automatically.

The buttons "Reset Adapter" and "Reset Queue-Fair" you can see in the video are convenience tools for developers and would not be present in a production release of your app. The Toast messages that appear at the bottom would also not be present in a production app. In the Demo app, these messages appear when the Queue-Fair Adapter calls methods in your app to which your app can respond in any way you see fit.

To send Push Notification to users who have abandoned and not come back to the app or queue when their turn is called is a simple matter. The user's request number (100000 in the video, visible in the Join toasts) is automatically persistently stored. When the user abandons, your app tells your Push Notification server that a notification should be sent, sending the stored request number as part of that message to your Push Notification server. Your Push Notification server consults the Queue-Fair Status API periodically to query the current Serving number. When this is greater than a particular user's request number, it's time to send that user the notification. If the user returns to the queue ("Showing Queue-Fair") or is Passed before a Push Notification has been sent, your app tells your Push Notification server that the notification is no longer required.

Further detail, documentation and source code is available at our GitHub iOS and Android repositories.