Since Glide does not automatically capture (or give us the ability to see it if they do) if a user has allowed push notifications, has anyone come up with a smooth way to capture that from the user?
I know how to use the “Push notifications access granted” action to set a Boolean column, but I can’t decide where to put the Action. I tried combining it in the initial profile creation action where the “Request push notification permissions” action runs, but I’m assuming it doesn’t work there because the popup for push notifications occurs after the action finishes running.
I’d prefer not to have a button that says something like “Did you accept push notifications?”, because that seems like it would be an unnatural question to ask a user after they’ve already seen the popup dialogue.
However, I can’t think of another button with an action to combine the “Push notifications access granted” action on that the user will definitely press, but only press once (I’m assuming if it was on a button that was pressed multiple times, then it would count as an update every time it ran “Push notifications access granted”).
The best solution I’ve come up with so far is to have an additional screen after the profile creation onboarding screen that has a welcome message and a button that says something like “Tap to Get Started” that has the “Push notifications access granted” action on it.
Has anyone come up with a simpler solution that doesn’t require any specific additional action from the user?
That column doesn’t appear to work in my experience. I have that column in my user table, but it shows checked for every user, even when I’ve specifically made a test user where I selected “Don’t Allow”.
I’m not sure exactly what that column even does. It appears almost like it’s a special type of User Specific Column, but it’s always checked on every row no matter which user I select.
It should be working correctly. It’s just a matter of understanding what it’s doing. It pulls the value of the current user…or more accurately, it checks the permissions of the current device. If the device allows the permission for that app, then the device is able to receive push notifications. It’s a computed value based on the device. Not a saved value based on a user’s prior acceptance of push notifications. You would probably have to still do something in your flow to permanently write it to a basic column in the user’s profile row, but you aren’t reliant on using the action.
Okay, that makes sense about how it works… similar to “Get device info”, but I can’t think of how I could use it to help me accomplish my goal.
Would I not still have to put an action somewhere to set a Boolean column in the User table based on that column value? How would this be better or different than using the action?
Yeah, you would still need an action of some sort to set it permanenly, so probably not much different.
I guess either way you wouldn’t necessarily have to rely on calling the action or using the column immediately after requesting permission. Maybe instead you could merge it with some other existing action in your app where you discreetly set it when the user does something else. Basically what you already mentioned, but not using an obvious Tap to Continue screen.
If you describe your app flow when a user first signs in up until they are fully using the app, we could maybe point out some places to integrate and store that value.
The potential user receives the link to the app via email or by scanning a QR code.
The app is set to “Required sign-in” via email with pin or Gmail.
If the user doesn’t install the app, once they sign in, they won’t be shown anything except instructions to install the app (using a visibility condition displaying/hiding certain components on the Welcome tab when displayMode (JavaScript column) is not “standalone”).
Once the user has installed the app and signs in, they get a welcome message “Please tap the button below to create your profile and gain access to the app.”. All other tabs are hidden via a visibility condition on if “profileCompletedOn” is empty.
The button is set to “Show edit screen” for “User profile row” which collects info needed for their profile. A special value is used to record current date/time to profileCompletedOn upon submission. 3 actions occur, first “Add row” to a Profile table, second “Set column values” for the user profile row and finally the “Push notifications access granted” action.
The Welcome tab is hidden and the user is taken to a Home tab where the Push Notification popup is shown first, then a Welcome Message, Announcements and Today’s Schedule section. All other tabs are also now visible based on if profileCompletedOn is not empty.
The Announcements section has a custom action assigned to it in place of “Show detail screen” that does a few things that I could set the value from, but I don’t know how many times a user will open announcements. Perhaps I could add a condition with two different action forks, with one that runs "Push notifications access granted” action only when pushNotifications boolean column is empty? Will “false” be treated as “empty” on a boolean column or will Glide see that a value of False has been added after the action runs for the first time?
I think this might be the best approach. It sounds like it will have a natural flow for the user.
Regarding the conditional branching logic…if the user denies permission and you end up writing false to your boolean column, would you ever want to do the check again? If they later grant permission manually, I assume you would want a true written to that boolean column? One thought I have is to add the action granted column like I mentioned before, then compare it to your boolean column and only go down that branch if the two don’t match. That way it will only update the boolean when the status of the permission changes and save on unnecessary updates. Regardless if the user allows or denies the permission, it will only set the boolean once unless the permission changes. Hope that makes sense.
