Game changer!
YES! This is a great addition. Thank you, AppSheet devs!
Curious, cause I just donโt know:
Where might this feature be useful?
Will a device ALWAYS get the same unique ID?
I just tested and got a different ID for each tab I tried. This may not be as useful as I thought.
Hopefully the ID is at least persistent on mobile.
Iโm told:
Itโs stored in the browserโs local storage at the domain level. It should be the same across multiple tabs in the same browser but will be different across different browsers. If theyโre seeing a new one in each tab it would suggest their local storage isnโt being persisted. I think that would also be the case for the editor preview iframe.
and:
if you have the โrun in a browserโ link in an iframe on your website it should still maintain the same ID provided that the browser allows iframe access to localstorage (it seems Safari doesnโt). But the preview pane in the editor is not loading the app data from local storage because it always syncs the latest
What I take from this is that it isnโt a reliable โdeviceโ identifier for browsers (CONTEXT("Host") = "Browser"
), but might still be good (enough?) for mobile devices (CONTEXT("Host") = "Device"
).
I just did a few more tests. CONTEXT("Device")
does return the same ID for multiple tabs of the same browser but not when the app is run in the editor/emulator, iFrame, or in a private tab.
Yesterday I checked the emulator against another tab, but skipped checking two different tabs in full screen view. So itโs somewhat consistent under certain conditions, but I still see 3 different IDs under Chrome just by using the emulator or a private tab.
I havenโt tested yet, but Iโm guessing that a mobile device will always have the same value when accessing via the app. But the user could always connect via the mobile browser, in a private tab, or iFrame.
If devices always have the same ID, then could we not use this as a security filter on applications that donโt require logins?
Then we could have an application not requiring login but still have device/user-specific data.
Jonathon, I thought the same thing as you and is the reason why I asked the question.
Unfortunately, from what I am gathering, from session to session, the device ID may be different. Which means it couldnโt be used in Security Filter criteria.
This brings me back to my other question.
Again because I just donโt know, where could such a feature of a Device ID be useful?
There are currently only four allowed options:
five*
What do these IDs look like? I donโt have a chance in the next couple hours to look at it.
Yeah - definitely could be a game changer, although without proper documentation itโs hard to know what exactly is possible.
Iโve used this expression a couple of times where my apps are used both over desktop and mobile, i.e:
Used for the same function:
ifs(
context(โHostโ)=โDeviceโ,โTap Below To:โ,
context(โHostโ)=โBrowserโ,โClick Below To:โ)
Just looks better and give a more professional feel in my opinion.
Iโm sure there are more valuable ways of using this expression but for now:
Thumbs up from me!
ifs(
context(โHostโ)=โDeviceโ,โPlease use browser instead !โ,
context(โHostโ)=โBrowserโ,โPlease use device instead !โ
)
Ha,
Should keep them away.
Hi Steve, @Steve
Thank you for addition of Context() to your perfect docs, appreciate for your works as usual.
I should test this with my hands to consider the practical use cases, but can I borrow your thoughts what sort of use case this expression will be found useful?
I reckon if the app is requiring sign-in or not is nothing to do with the expression to return the value.
So it should return the unique value to identify the users specific device associated ID number.
In that sense, we are able to capture those ID to get the id from non-sign-in requiring app, i.e. public apps? If so, I assumed we captures the ID when the user access to public app and then do a quick stat to count number of unique access to App by each different unique users, most precisely count by each unique device.
Overhauled.
So, what Iโm reading is, basically:
If CONTEXT(โHostโ)=โDeviceโ
then CONTEXT(โDeviceโ)=A UUID that should not change, unless the user changes devices, even if the cache is cleared or app is uninstalled and reinstalled, correct? Or would those also reset the UUID?
After reading Steveโs updated doc page, that is what I am understanding too. That does make more sense to me and does make it useful for Security Filters and such.
Though I wonder WHERE that UUID gets stored?
And Iโd still like know when such a feature might be useful. Iโm probably not seeing it because I donโt have that need yet. But if we knew how this might be used, it may spark app feature ideas in the rest of us. Anyone?
I canโt say for sure. I suspect the UUID on devices might change if the app data (not the cache) is cleared or the app is reinstalled, and may be different for different device users on multi-user devices. Would be something to test.
Letโs say you have one device in a factory, you could set your app in a way that you are able to use it ony from that one device even you could login with another device.
Excellent. Then I believe I came up with (in my mind anyway) to use CONTEXT(โDeviceโ) for multiple iPads that are stationary and logged into the same email account. Using CONTEXT(โDeviceโ), I should be able to allow each iPad to maintain its own personal temporary โcartsโ or โwishlistsโ. Since I really only needed it for the user experience, and really didnโt want to create three unique email address which will never be used again.
I can indeed use it as such. And so far in my testing, the emulator UUID will persist at least as long as I keep it open during the day - even through saves and refreshes. Either way this proves my concept overall works AND everything is equally fast or faster now.
Is there a way with Context(โdeviceโ) to infer the maker? โapple/android?โ
Nope.
User | Count |
---|---|
40 | |
34 | |
29 | |
23 | |
17 |