Get device info from non users (Not signed in)

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?

Thanks in advance!

You can still do it. You just need to add the Device Info column to the table that your Home Screen is attached to.

I don’t know what I would do without you or Jeff :sweat_smile: :pray:

Thank you!

1 Like

Just to add to this… if you copy the device info column with a single value to the user profile… you could use it anywhere in your app

Not if users are not signed in :wink:

Have you tried it :wink:

Not in the users profile… copy it to user profile from
another table

I haven’t tried it, but how could it possibly work?

If a user is not signed in, then they are not attached to any row in the users table, then they don’t have access to user profile values.

Or am I missing something?

Probably it works because it’s a computed column targeting a table you have access to

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.

1 Like

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.

Screenshot 2024-04-19 at 5.22.20 PM

Screenshot 2024-04-19 at 5.22.29 PM

Screenshot 2024-04-19 at 5.22.45 PM


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.


It’s very helpful to have the user profile as a global resource. For edge cases that don’t compute… use a helper table + single value.

1 Like

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.

1 Like

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.

1 Like

As long as it’s not able to pull values from an actual user row, then I suppose it’s fine security-wise. :man_shrugging:

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.