Push Notifications Questions

27shutterclicks · August 30, 2023, 4:51pm

I am gearing up to add push notifications to an app with a deadline for next week and I have some questions.

So far, I have been experimenting with the basic functionality as per the docs and those work fine:

Subscribing user to various topics
Sending notifications to a user or a topic
Configuring deep links

Here are the questions:

How can I tell what topics a user is subscribed to?
It is unclear to me how the subscribe queries actually work. From what I see, they seem to run whenever an input changes and there is no way to modify that. This means that all subscriptions run for all users all the time? How can I then subscribe only certain users to certain topics?
How can I confirm that a subscription actually worked for a certain user? (Well, maybe this is the same as question 1)
How do I remove a user from a topic? (Not possible at the moment it seems, based on what I read in another forum post)
Is there a reason why it's not possible to use variables in Deep Link > Screen? This basically forces me to create at least a query for every screen, which is unnecessary overhead, I think.
Can deep link parameters contain objects with multiple keys? So instead of defining multiple parameters, I could define a single one with multiple keys - or point to a (temp state) variable that has multiple keys already.
If a user already subscribed to some topics, can they then subscribe to additional topics? If so, how would that work? Do they have to reload the app, do they have to log in and out? Will there be a prompt to the user at all?
Based on #7 above, should the additional topics be (or can they be) separate subscribe queries - or should there be a single subscribe query?

Thanks for helping in clarifying these points.

Kabirdas · December 1, 2023, 12:25am

Hey @27shutterclicks! Just want to circle back to this post, curious to know more about what you accomplished and to hear more about your use case for push notifications.

We currently have a couple of internal feature requests open around them that we can report back here on but for the most part, CRUD operations on push notification topics are pretty limited at the moment (e.g. no read operation). You can subscribe a user to any number of topics and they'll be unsubscribed from all their topics when they log out.

That means you can subscribe users to additional topics after page load by, for instance, using a temporary variable. When you set that variable it will be the same as triggering since push notification queries are locked to run when inputs change so if you have multiple parameters it might be best to set the variable with a JavaScript object that contains the parameters you want to pass. If you don't want to subscribe certain users to a particular topic you can also conditionally disable the query:

The suggestions above are certainly far from ideal though. The topic model was created to be a foundation for future features and, as such, the dev team is eager to get feedback about how people are using push notifications and how they'd like to use them, to help determine how the feature ends up looking.

27shutterclicks · December 1, 2023, 8:17pm

Hi @Kabirdas , thanks for following up on this. It's been a while since, so I'll try to remember details around the use case. I think the biggest issue for me was the lack of sufficient information or documentation on push notifications - hence the list of questions above.

I ended up running many tests at a moment when I didn't have the time to do this, just so that I can get a better grasp on how it works. Eventually, I ended up putting together something that I wasn't fully sure would work given the lack of options for testing, as mentioned above (question 1 and 3).

Overall, I feel the entire execution of the notifications features is not at all intuitive (although the overall approach based on topics, subscriptions, etc. makes a lot of sense).

Here are some specific pain points that if addressed may make adoption and implementation much easier:

Subscriptions that run on every input change - Other than being a potential performance issue, I wonder if these queries are even showed in the Debugger - I don't remember noticing them. If they are not and there are issues with the logic, how would we know specifically and manually running the query?

Regardless, it feels like a potential source of problems, since users may get "instantly" subscribed (or at least trigger a subscription prompt) to a topic unintentionally. And since we can't know if a user is subscribed or not to a given topic, it makes everything even grimmer.

Unsubscribing users - This probably makes the least sense to me currently, not being able to control a user's subscription status to a specific topic at any given time. If users get unsubscribed only on log out, it means that they will continue receiving potentially unintended details (incl. sensitive data) until then. And last I checked, there was no way to force log out a user.

For example, in my use case, I had a topic intended only for admin and devs with notifications on various user actions and details I definitely did not want non-admins and non-devs to ever receive them (not only because of the contents of the notifications but also the timing and frequency of them).

As part of the process flow of the app, users were granted permissions dynamically based on various needs (controlled by a user like an admin) and notifications varied based on those permissions. This means that if a user was promoted from a lower role and then a higher role temporarily, then back to a lower role, they'd continue to receive higher role notifications unless they were cornered by security and forced to log out of their Retool app (kidding!).

In other words, if there is a Subscribe action, there should absolutely also be an Unsubscribe action.

Conditional subscriptions UX - you mentioned that if users shouldn't be subscribed to a particular topic, the query can be conditionally disabled. Besides the fact that combined with other aspects mentioned above this is not logically intuitive, practical access to this critical aspect is somewhat buried lower in the Advanced tab. This is accentuated by the fact that for mobile notifications, Disable query has a default value ({{ !retoolContext.devicePushToken }}) that I didn't really understand initially and looked like something I didn't want to mess with, out of fear of not breaking everything.

If this condition absolutely needs to be there, it should be added in such a way that is not visible to the user.

More importantly though, as an improvement, I would suggest adopting an approach more consistent with other logic of the app that we use all the time - actions/events that only run when, as needed (instead of not run when). As a dev/app builder, we come across this everywhere in Retool, from actions/interactions to query success/fail event handlers, etc. You create an action or event and you specify when and if it should run, right on that screen, without having to switch to an Advanced tab.

I put together a mockup to show how notification subscription (or maybe all) queries could be more intuitive by bringing the conditional run field forward on the general query screen.

There's a number of other aspects with push notifications that I had trouble with (both because of lack of docs and overall functionality), like deep linking and parameter configuration but I don't remember exact details right now.

I'd be happy to provide mode details and work with the team to improve the notifications feature, which I think is essential to mobile apps building.