Best practices for push notifications in multi user applications?

Question

I'm working on a push architecture that needs to support applications which allow for multiple users. This means more than one user can log into the application with their credentials. The problem I'm running into is what if user A allows push notifications, then logs out, then user B logs in and starts getting user A's push notifications?

What are some best practices for handling this type of thing? One thought I had was you could remember the last user who logged in and only display push notifications to the "logged in" user. You would have to send some sort of user context in the message payload so it could be checked against the logged in user. However this feels a little funky.

Anyone else ran into this? It's seems like a really relevant problem, especially for tablets where families tend to share the device.

Backus

Whilst your app can check if notification for a match between intended recipient and the currently logged in user; when the application is in the background or not running at all, notifications for the previously register token will still arrive on the phone/tablet and, depending on settings, be displayed as banner or alert pop-ups. I think ultimately your server has to know when a user has logged out (either explicitly, or after a time-out, or when someone else logs in) and not send notifications for that user until they log in again. – Orpheus

Answer 1

I think your suggestion is acceptable in a multi-user app. It is much simpler to implement this in the client side, than on the server side. The downside is extra bandwidth wasted to send an unneeded notification. But vast majority of the usage is probably single-user so this may not matter much.

The alternative is to track the logged on users on your server and their current reg_ids. This could be more complicated because A could be logged on on multiple devices, then logs out from device 1, and B logs onto device 1, etc. and your server has to track all of these. So probably another table to track the relationships between 'Logged On Users' to 'Reg Ids'.

If you hate the idea of sending unneeded notifications, go with the server route. If you value Keep-It-Simple principle, go with the client route.

Killdeer

great analysis - thanks for sharing your thoughts. Giving me some good stuff to consider here. – Backus

Answer 2

We're implementing this by Registering the device with APSN, getting the device token and sending this to our server through a ws.

On the server side the device token is only associated with the last logged in user.

New app
User A (first ever user) uses IPAD A
Register with APSN, get token
Send token to our servers through ws
Search for token in db, token is new, store it
assign token to USER A

Next user logs into app
Register with APSN, get token
Send token to our servers through ws
Search for token in db, token exists already
Remove connection to USER A
assign token to USER B

SEND Notification to device WITH USERNAME
if username is logged in show it - else dont

Still not perfect as its sent to home screen first so to ALL users

Uriiah

Answer 3

Let's suppose users of your app can logging on multi devices.

We have to make two API on server side:

    func setUserDeviceNotifyToken(userId: Int, deviceToken: String) {}
    func removeUserDeviceNotifyToken(userId: Int, deviceToken: String {}

On your app side, you have to call setUserDeviceNotifyToken API on every Login In and call removeUserDeviceNotifyToken on every logout.

On server side, you can track every user with its deviceNotificationToken and send notification for correct device.

Notice: If your service doesn't suppose to support multi device login with one user, you can handle it just by one updateUserDeviceNotifyToken and pass null for remove user's device token.

Notice 2: Do not let user logout before calling removeUserDeviceNotifyToken API.

Punctuation

Answer 4

I know I'm a bit too late, but thought I would share some of my experience with others.

When pushing notifications to multiple users, it is imperative to ensure that the client side is subscribed (listening) to a specific or in this case multiple queues.

For instance, in the case of a group called top customers, the mobile app should actively listen to two channels:

• customer_id (target message to a single user)
• top-customers (target to a group of users)

By adhering to this setup, any message published on either of these channels will be promptly received by the app.

Owsley