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.