I have an app in which I have created an error message that detects if a user’s device Location Services is OFF by using the Here() expression as an initial value when a form is started. This is used to prevent the user executing a specific task in the form. My question is based the following scenarios:
Scenario 1
If the user’s Location Services are OFF and they try to execute the given task, my app displays and error essentially saying “You can not do this. Please turn on location services”. During testing I have confirmed that the user can leave AppSheet open, go to settings, turn Location Services ON, come back to the open AppSheet app, try the task again and it will function fine. So without even needing to be synced, AppSheet has detected that Location Services have been turned ON. This is perfect, happy days!
However is anyone able explain why the opposite does not seem to be the case and maybe have a magic answer?. e.g.:
Scenario 2:
The user’s device Location Services are ON, they leave AppSheet open (as before), go to settings, turn Location Services OFF, come back to the open AppSheet app, execute the given task which still, unfortunately functions fine and uses their previous know location. So AppSheet has not detected that Location Services have been turned OFF. During testing I confirmed that this change could only be detected if the app is closed and restarted. THIS IS NOT GOOD as I absolutely have to know where they are when this action is executed. In other words a clever, devious user can cheat the system.
Does anyone have any thoughts on this? Is this a bug that can be fixed? or is it just not possible for some reason? Any help would be appreciated.
Thank you for this response. I have already read through this document and as far as I can see it doesn’t actually explain the reason for what is happening, unless of course I am not understanding it. Are you (or anyone else) able to highlight the part in this document that relates to the problem?
Or maybe you can simply confirm that the behaviour I was hoping for is just not possible?
What you are looking for may or may not be possible. However to better understand your requirement, you may want to clarify what you mean by
Do you mean a form view that is open during this switch on switch off mode of location services?
What you exactly mean by “task” as far as AppSheet operations are concerned?
Also if possible, you may want to mention if the task is related to filling in timesheet. This is so because there is an extensive previous discussion thread on that topic wherein many AppSheet senior app creators have contributed.
I have a card view (as a “Home” page) with a number of different panels which when tapped execute different actions via the “On click”. One of these actions (“tasks” maybe the wrong word) opens the form. So NO to your first question.
Yes it is related to filling timesheets, can you maybe point me to that previous discussion please?
Bottomline of discussion: It is not at all easy to ensure correct time capture in a distributed system as that of AppSheet. You may give it a try to certain suggestions such as server time etc. but those will need the app to be online and there may be sometimes delays in server recording time.
The reason for your issue, I think, is because of the polling described in the document. The AppSheet container app POLLS the device once a minute. If you turn off the Location services, I suspect the app cannot detect that Location Services are OFF until the next polling cycle.
You can easily test that assertion by turning off Location Services and waiting a couple of minutes and then trying the function in your app that detects that location services are off.
HOWEVER, since it seems like your goal is to detect that person is physically onsite when they are entering their time, I can tell you, from experience, that you WILL NOT be able to handle that 100% accurately with AppSheet’s GPS polling. There are other issues. Namely, just like any other GPS device, phones must be able to TRIANGULATE their location - meaning they need to read location information from 3 different satellites.
When the phones move to a new location (such as driving from home to a work facility), that triangulation may be delayed and inaccurate up to several miles!! You can include the LatLong field in the Form that will allow a user to re-calculate the GPS location and keep retrying until the device can confirm they are onsite. This can take several minutes and is very cumbersome to an employee.
I think a MUCH better approach is to use NFC scanning. The employee MUST place their phone near the NFC tag so you KNOW they are onsite without GPS. Additionally, the NFC tags can be programmed with details to detect automatically exactly where that person has scanned in. Security codes can be included in the programmed details to prevent someone from attempting to spoof the NFC tag with their OWN programmed version.
I have tried using barcodes, but some employees figure out they can simply take a picture of it and use that to scan in. I have NOT yet implemented a scanning system using NFC tags so there may be some issues even with that approach I have yet to encounter.
The post I shared touches the GPS capture also. The essence is we cannot ensure through app either the time entry or location capture with 100 % guarantee that it is what it should be.
The reason for your issue, I think, is because of the polling described in the document. The AppSheet container app POLLS the device once a minute. If you turn off the Location services, I suspect the app cannot detect that Location Services are OFF until the next polling cycle.
With reference to above, what I don’t understand is that AppSheet happily detects when Location Services have been turned ON with no polling, syncing or app restarts but NOT when it has been turned OFF. This is the only bit I don’t get. In addition if a user turns location services OFF, it’s likely because they are about to engage in a “fraudulent” clock IN/OUT so I don’t really care if it takes a while to reset everything.
I think a MUCH better approach is to use NFC scanning. The employee MUST place their phone near the NFC tag so you KNOW they are onsite without GPS. Additionally, the NFC tags can be programmed with details to detect automatically exactly where that person has scanned in. Security codes can be included in the programmed details to prevent someone from attempting to spoof the NFC tag with their OWN programmed version.
The above is a very interesting subject into which I have done a lot of research. I do already have this built in to my solution (as well as geolocation tagging). The results of my in-house testing proved that this works perfectly and thinking I had found my solution I decided to ditch the need to know where someone is. e.g. no need for geolocation tagging as you point out. However during my first “field” trials I very quickly discovered that almost all Android phones (particularly cheap ones) struggled to detect the NFC tag lengthening the clock IN/OUT times causing frustration for many users. I also believe that some “really” cheap Android phones may not have NFC capability at all but this is something I could live with. iPhones on the other hand were generally MUCH better.
So if the geotagging is going to prove too unreliable I may have to return to the NFC idea but I will need to prevent them being cloned so I am very interested in your comment:
Security codes can be included in the programmed details to prevent someone from attempting to spoof the NFC tag with their OWN programmed version.
My research gave me the impression this was not possible so I would be VERY grateful if you could help me implement this.
Also during my research I explored the possibility of using a dynamically programmable NFC solution to which I could regularly fire a timestamp but I couldn’t find anything “off the shelf” that offered this and a bespoke solution would be too expensive. Do you know of anything?
Anyway I hope I haven’t waffled on too much and thanks for your help.
Sorry I may have given the impression this was something provided with the out-of-the-box NFC tag implementation. I was writing quickly and didn’t use correct terminology.
To provide secured data on a tag, you would simply use encryption. The data to be written is encrypted before writing it. When read it is decrypted into the details. This can be built easily with webhook calls. There are several 3rd party encryption services. Google Apps scripts even have encryption libraries you can use.
You mentioned “dynamic” abilities. This can be achieved by embedding onto the NFC tag a lookup key that is used to retrieve from a lookup table. Then you can change the retrieved values from the table without the need to re-write the NFC tag.