I have a few different tabs set-up using the visibility feature. When a user opens the app, the wrong tab is seen for a few seconds before the visibility condition kicks in and then they see the tab they are supposed to see. The transition time is of a couple of seconds only but it happens everytime the user logs in.
1 Like
Same here, it seems like the time for the backend to check all the visibility conditions but agree it should not happen.
2 Likes
While it’s loading, if we could show a loader or the sign-up screen that would be better.
I wonder if you could create a new tab that acts as a splash screen with the conditions set so it only shows when none of the other conditions have kicked in yet. A little bit of a hack, but might take care of the wrong screen showing for a couple of seconds.
1 Like
That would work I’m sure
1 Like
I tried this but then it is disturbing my onboarding flow. Can’t think of a way to solve both problems.
My app: gopluhg.com
Yeah…glad to see I’m not the only one experiencing this issue. Pretty huge bug in my opinion.
4 Likes
I’m having a similar issue where I have the “home” tab hidden after a form submission. This reveals a new tab (acts like a submission screen) and this new tab is the far left tab of the app once the “home” tab is hidden. When I close and reopen the app, the app loads on a tab that isn’t the far left tab, but rather a tab that is always visible (in this case it’s a My Profile tab).
I’ve also tried moving this submission screen to the far left of the tab layout, so it would be the first tab if there were no visibility conditions, but it still loads on the My Profile view when it do this.
Hmm now it’s opening on a tab that’s only in my menu. @Mark how is the “opening tab” determined when using tab visibility conditions? I have an app that is ready for distribution but this issue is making me want to hold off on sending it out for fear of bug reports and negative feedback.
Right now, if Glide hasn’t yet loaded the data to determine which tab to show, it will open the first tab that doesn’t have visibility conditions.
We’ll fix this problem, but I can’t give you a timeline.
2 Likes
Thanks for the added information. I tried a work-around by user giving every tab a visibility condition but it still behaved unpredictably. Glad you’re aware of the issue.
I had the same issue for last few days. It’s a problem associated with user-specific onboarding column.
I believe I have fixed it by creating a regular onboarding column in users sheet with numeric values only. This fixed the intermittent display of initial onboarding screens when an existing user logs on.
As each row is user specific, I don’t think there is a need for user-specific onboarding column.
I am not a Glide expert. Please make changes at your own risk.
1 Like
Do you experience much lagging when users use the increment button in the Sheets instead of a user-specific column? I want to keep it in Glide to avoid the syncing back and forth, also the number of edits as well on free apps.
It’s faster and doesn’t revert back to previous screen and loose user entered data (so far).
Makes sense. I’d recommend less number of onboarding screens.
1 Like
Yeah if you have 3 screens right now, what I would recommend is to use a button to link to the same sheet and design the new details layout in the new screen. Only the last onboarding screen will contain a button with increment action.
1 Like
Interesting. Didn’t think of this approach. I will try it if I continue facing same issue. You approach is definitely more efficient.
1 Like
It also allows the users to press the “Back” button to edit the previous screen’s inputs if they suddenly remember they input something wrong.
1 Like
1 Like
Just take caution here, you won’t be able to change the number of onboarding screens later. If you want to, you will have to create the increment button and the logic all over again.
Yeah, if we need another onboarding “tab” somewhere in there let’s say after the 2nd one, then the flow must be built again from that point onwards.
1 Like