How To Prevent App From Redirecting To Login/Signup Screen On Start Up


#1

My app can be installed and opened, logged into, but when you close the app (without logging out) when you re-open it on your device it directs you to the login screen again.

Is there a way to prevent this?

I have my landing page set to login:

image

Not sure if this matters… But if the user is alread logged in, they should be taken to a different page of the app when the app starts back up again after being closed.


#2

Hi @justincrabbe, create a device variable : login in- type yes/no, and when the user login set the variable to yes.

In your home page , on load - If the variable login in=yes show home, otherwise show login or go to page login.

when the user login out, set the variable to no.

Hope this help u :+1:t2:


#3

@wade this worked for me on Android, now i’m replicating on iOS, but for some reason when I setup my if… else… on ios to check whether the user is logged in (bool) it still keeps the home page open even though the user hasn’t logged in and it should direct them to the login page.

I’m wondering if iOS functions differently and the bool is Blank or otherwise not false?


#4

I just tested in an app to make sure it would all work within the Page Loaded event and it worked fine. I think you might want to test the logic out in your device variable to make sure what you expect the values to be is correct.

From your screenshot, you are correctly assessing the value of a Boolean device variable. checking that it’s true/false like you show here is how you want to do it. Perhaps go back where you’re setting it and make sure that component is working correctly so that it has the value you expect it to have by the time it gets here.


#5

How are you testing to see if this is working on the Page Loaded event?

I am using the web viewer (I don’t own an iphone) and even when I switch the if… else… logic to the opposite (testing to see if it’s true = user logged in is, yes) and setting the page to the home page, even though the web viewer is “installing” the app fresh, meaning that the user isn’t logged in, and it should be false/blank (vs. true), it doesn’t re-direct the user to the login page.

I’m wondering if you’re testing some way else?

This logic works fine on Android on both web viewer + on device but either way I structure the if… else… logic here it doesn’t want to direct the user to the home page.


#6

I’m testing the same way as you in that regard. I’m using the Web Simulator.

I have 3 pages.

Page 1: Has a button, when button tapped I set a Device Var Bool to TRUE , then a Go to page to Page2
Page 2: On Page 2 load event I have an if statement if Device Var Bool == true, Go to Page3
Page 3: Has nothing

When I run the app, I tap the button, it makes that Device Var assignment, then goes to Page 2, and then quickly transitions to Page3 instead since the if statement shows true.


Try force Assigning that Device var to FALSE before your if statement. See if making sure the Device var is FALSE (By doing a Set Value) just before your If Statement triggers, makes a difference? It seems like it should be working so I want to know if that Device Var is DEFINITELY False when the If Logic is going to test it.

Might be redundant, but it’s the next thing to test.


#7

Got it.

If I set my home page to set User Logged In to False (before the if… else…) every time the page is created, it will loop the user back to login every time though.

I tried to use an Application Launched event so that when it’s initially launched it sets it to False but that will create a bad UX with the user constantly having to re-login each time they close the app and re-open/launch it.

Right now… If user logged in = TRUE then a series of actions result, but if it’s False on home page load, it’s supposed to redirect to login. It doesn’t want to work for me on ios like it does on Android for whatever reason. Can’t figure out why when I’m setting it up the same way and the same way you are testing.

Is it ‘False’ by default and not ‘blank’ or ‘null’?

I’m testing for ‘True’ (and have tested for 'False by reversing it all) but neither works for me for some reason.


#8

Boolean values are null until they are assigned a TRUE/FALSE value.

…Yea an application launched event that essentially turns LoggedIn to False is probably not desirable UX.

Looking at what you wrote here…

Right now… If user logged in = TRUE then a series of actions result, but if it’s False on home page load, it’s supposed to redirect to login. It doesn’t want to work for me on ios like it does on Android for whatever reason. Can’t figure out why when I’m setting it up the same way and the same way you are testing.

I want to make sure… Are you testing to ensure it is indeed FALSE at exact point you expect it to be? Maybe stick a test just before the if-statement to set a test label based on that LoggedIn BOOL value just to see in your app that it is indeed the value you expect it to be.

I emphasize this because I want to make sure this isn’t a logic issue with how/where you’re setting TRUE/FALSE at since you said as well…

If I set my home page to set User Logged In to False (before the if… else…) every time the page is created, it will loop the user back to login every time though.

The above sounds like you when you hard set that LoggedIn BOOL before the if-logic, the correct path triggers, and things work fine. That leads me to believe that the logic is sound and it’s potentially that you’re getting a potential unexpected result because the LoggedIn BOOL isn’t actually the value you are expecting it to be at a particular time in your app. Let’s run that test to make sure it’s not null or something funky like that. Test for it to be triggered TRUE when you expect it TRUE and FALSE when you expect it FALSE as well.


This is a little more high level but I just want to bring up your strategy of managing State (Logged In) in your app…

Let’s also go back to the question “How do you want this to actually work?”. I agree that probably setting LoggedIn to FALSE every time the app is launched is not ideal. Who wants to log in every time. It’s not a banking app after all.

Are you attempting to manage all the spots where that LoggedIn switch needs to be TRUE/FALSE in your app everywhere? If so, I’ve been here before and can tell you, it’s not ideal to manually manipulate state. As your app grows in complexity, this will get tied in knots more and more as more edge cases continue to occur.

I want to suggest a way to save you the trouble of all that manipulation. I learned this after getting myself tied in knots and a backend engineer teammate dropping a little seed in my brain over lunch 1 day…

Instead of taking the responsibility of state on yourself… Give it to the Single Source of Truth. This oftentimes is the backend.

Do you maybe want to make an API call on every page’s Page Loaded/Appeared event that checks with the backend to ask if the token being used is valid or expired? Then make the appropriate trigger occur based on the Boolean that comes back? This is a good practice in any secured environment. Let the backend handle the state instead of manually since it’s the single source of truth as to whether a user is logged in/out really deals with the tokenization process.

You might very well know all this and this was a waste of typing but hearing how you might be going about this Logged In State manually brings me back to when I took a 100lbs off my shoulders when I built a little logic in an app to check token validity and react to that 1 API calls response everywhere it made sense to.


#9

I am testing out the back end integration and basically am pinging the server to receive either a 200 or a 401 (authorized vs. not authorized)

But how do i setup the if… else… to react if the message received back from the server is X and status is 401?

image


#10

That’s when you use the API’s response events to either make the action occur or perhaps set some value to a Device variable that you can then run if-else logic against somewhere else in the app.

You know how you trigger actions to happen in the API responses 200 event, 400 event, etc… That’s where you can create action based on API responses.

With these, you wouldn’t do if/else in these events… just setup to do what you want given the response code. Only the 1 event will trigger for the appropriate response code that is received.

This photo is from an example app showing where you find those response events for API requests.


#11

Got it.

My hurdle now, is that Bubble doesn’t include code 401 in their swaggar and that is the one that is being sent back in the response (of which i am trying to trigger the Event to direct the user to login).

How do I add the 401 into the swaggar? Is there a way to manually add the single response inside of dropsource? What will happen if i try and Update the api via the Bubble exported json link going forward as well? I assume the 401 response won’t be there and it will remove the fix i’m trying to apply here…


#12

Hmm… A 401 error is a pretty standard error code. I would check with Bubble’s support/forum to see why it’s not included as any error code that can come back as a response should always be accounted for in the Swagger. I wonder if it’s a setting or something on their side you need to turn on maybe? They would know more on that. You shouldn’t have to manually add any error codes to your swagger. That’s part of the ease of using Bubble in this situation is that they handle these details for you.