Hi all, quick question that I can’t seem to figure out. So I have a mobile/desktop version of my app that public visitors can check out.
Is there a way to automatically detect their device info and only show them the correct home page based on their device info?
My understanding right now is that I have to create the “get device info” column and thats where I’ll capture that info and can do an ite column. But what if it’s a public user and no columns are generated when they hit the home page…How can I detect it then?
I have a Get Device Info in my User Table and nowhere else in my app, but my visibility settings still apply for users who are not signed in, even when on another screen thats based on a different table.
I think @Eric_Penn mention it, but I assume both of you are not retrieving those values directly from the User Profile, but instead grabbing it from the User Table instead one way or another? Can I also assume that it’s just referencing the first row of the user table and the user table is not under row ownership?
I use Row Owners in my Users Table. I have 2 containers, one that displays for Desktop and one for Mobile, but only 1 container will show at any one time, regardless if you’re actually signed in or not. This particular example / screen is built using the User Table, but I have used these same Desktop/Mobile filters on other screens based on Helper Tables.
Very interesting. Borderline disturbing that it’s even finding any kind of user profile row to pull values from when theoretically it shouldn’t find any. I don’t like when something happens to work, but everything within me says it shouldn’t work at all. Coming from a code background, that can sometimes mean an error just waiting to rear it’s head when the right conditions are met. Glide must have some kind of default hidden row for non-signed in users, or default column values for cases when a user row may not exist. Kind of a failsafe to prevent the app from blowing up.
If I ever had a case where I knew users would not be signed in, I would definitely be using a helper table and single value columns to pull values into other tables. Logic tells me not to use the user table or user profiles when a user is not a user and does not have a profile.
It’s either an undocumented feature or an unintentional consequence, which could have the potential to stop working in the future.
Very interesting though, and something I definitely need to try out for myself. Could be useful for me in some cases.
I go back and forth on this, but I’ve always felt that we really need a type of global single row table for cases where using the user profile doesn’t make sense. Something that’s available everywhere like user profiles, but not tied to a specific user.
It was surprising when it worked for me as well. Like you said, logic states that if you arent a signed in user, then the user table, especially with row owners would be meaningless. But, if there is a phantom row for non-signed in users where these computed columns still calculate, that would make sense. Not sure how it effects security.
