Implement push notification on mobile and browser

#1

I’m developing a application will have both mobile (CRNA) and web (react) front-end with Node.js server.

Is it possible to use the Expo push notification to both side? Or any other possible solution for this situation?

#2

we don’t support web push notifications right now but you could have your server either send a push notif through the expo service if the user has an expo push token or another service if web

1 Like
#3

We currently use Pusher on our Expo client and web app (the pusher-js library) and it works well enough, but there’s a number of other web-sockets-as-a-service platforms, as well. I definitely recommend using one for sending a message from server to client while the app is open, and saving mobile OS push notifications for only when you would want to put a notification in the user’s notification tray/ lock screen. A service like Pusher can be faster than OS push notifications, you can use them even in situations where you wouldn’t normally show the user a notification in the tray (e.g., telling the client app to refresh some data), and OS push notifications technically aren’t guaranteed to be delivered.

1 Like
Is it possible to replace the push message service with 3rd party one?
#4

So the flow can be sth like:

push data by socket
if no ack response after x seconds
    push data by expo push notification
end if

or

if user.webToken not expired
    push data by socket
    if no ack response after x seconds
        push data by expo push notification
    end if
else
    push data by expo push notification
end if

right?

#5

You actually shouldn’t need to conditionally push by web socket or push notification. If you’re using a service like Pusher, always send the Pusher message when you want the client to take action. When clients come online, they subscribe to channels to receive the messages from Pusher. If no client is subscribed, they never get the message- you don’t really have to think about it. If you’re rolling your own web sockets, there may be more thinking involved, but you should probably use a standard library that does the work of determining if a client is subscribed for you.

Always send the OS/ Expo push notification if you would want a notification to show up in the user’s tray if the app is not open. This behaves a little differently on iOS and Android. On iOS, push notifications are suppressed by default if the app is open, so you shouldn’t need to do anything else with them. On Android, they’re not, but they’re also less intrusive if they app is open - they just collect in the tray without otherwise bugging the user. You’ll then probably want to implement some of the dismiss API calls (https://docs.expo.io/versions/latest/sdk/notifications.html#exponotificationsdismissnotificationasynclocalnotificationid) to clear out the tray if you know the user has already received the message because your app was open.

For instance, in our app, we clear the Android notification tray when the user backgrounds the app. This seems like approximately what the Slack client does.

#6

I suggested the previous flow since I want to handle different cases, like user login my system by web, or through mobile apps(even it is not open).

Is it really impossible by just using plain JS with Expo SDK?

And seems that websocket/socket.io push notification would still work if the app is opened and is on background. If the previous flow not work, I think I would like to use this one to avoid ejecting the app.

#7

I don’t see any reason you need to eject your app. Expo push notifications work with a non-ejected app, and a web socket system like Pusher works with any JS client.

I assumed the workflow you’re describing is happening on your API server (since you’ll want to notify clients based on data changes on your server). There’s nothing preventing your workflow from working that I can see. I’m just saying you may want to avoid the complication of sending a websocket notification in some cases and a push notification in others. Instead, just send both all the time. For example, in your first workflow, you could still get an ack in a situation where the app may no longer be on the user’s screen due to timing issues and you would end up not sending an Expo push notification in a case where you actually would have wanted to send one.

1 Like
closed #8

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.