Social Distancing … a CloudDB / Location Marker Tutorial
Determine how close an individual you share an app with is to you. You use a CloudDB, LocationSensor/GPS receiver, Map component, design time Markers and a StayAwake routine. Sound an alarm when someone comes too close or just have fun with the app to keep track of your family circle’s whereabouts. Observe where everyone is on a Map. The app continually updates and calculates distance separation.
The Social Distancing screen looks like this:
and has the following controls:
How this is Built
Everything is constructed using a single screen.
Four design time Markers represent four individuals keep the programming simple. Are you ambitious: code something similar using run time Markers
or additional design time Markers. Either option can allow more users (Social Distancing can only support four individuals) and flexibility. You add more users at the cost of a larger level of coding complexity. This app can presently have four users using it simultaneously. Every User will report their location information to the CloudDB. The CloudDB, in turn, plots the location on the Map on the Android you are using and the Android of everyone else using the app. The app reports how close the other Users are to each other and you. If the Users are too close, Social Distancing complains.
The LocationSensor reports a location every 30 seconds as hard coded in the Screen1.Initialize. The sampling takes place using a TimeInterval of 30000 ms (a half a minute) to attempt to evoke a LocationChanged event.
Certainly, thirty seconds is more frequent location polling than necessary for most usage but the value works great for testing purposes.
A CloudDB Tag is created for each user. For this Project the Tags are:
- Mom assigned to Marker1
- Dad assigned to Marker2
- Son assigned to Marker3
Daughter assigned to Marker4.
A tag is also created to keep track of the User rememberedUser Tag .
Name these Tags anything you like and modify the code or create a way for each user to change the User names. Presently, all User names are ‘hard’ coded. There is no user log in to the CloudDB (but you can make it work with a Log in).
Each user selects ‘who they want to be’. No safe guards. Someone can masquerade as another User. The example has only limited safeguards to the way the app can be used; add whatever constraints you require because YOU can modify the Project. If two or more individuals select the same user; there will be conflicts.
Once, selected, the app ‘remembers’ the User choice. The choice is saved in a TinyDB. The contents of the saved rememberedUser Tag is queried when the app starts, that remembered value is assigned to the theUser variable and the appropriate remembered User box is checked on start up. For example, if theUser=Mom then set CheckBox1.Checked to true. See the Blocks in the Screen1.Initialize event handler.
The User selection check boxes are coded to allow them to perform together as a Group Box. Selecting one CheckBox, de-selects the current choice so only one of the choices can ‘beacon’ at a time from a single device.
The performance you get using the app depends on the quality of the GPS receiver and the network / WIFI connection you and the other users have on their phones (or tablets).
The ‘simple’ app has complex code. I provide only minimal documentation. Documentation is the most difficult part of programming a complex app and also the most time consuming.
I assume you all know how a CloudDB works. Each user must have a copy of the original, compiled apk loaded on their Android. The apk must be shared by the developer. Sorry, you cannot each use the aia, compile it and expect to connect with someone else who compiled his or her own aia. All must use the same apk file. Look for tutorials showing how to use a CloudDB to learn more if you get stuck modifying this code.
When run the app for the first time, your CloudDB will be empty. The database needs to be populated with the coordinates of four individuals (but can work with only one).
These are three ways to test the app and provide the initial data:
Install a copy on each of four phones. Ask one user to be Mom another Dad…you get the idea. Have each user select a different option. If no one selects, their individual User defaults to Dad.
Load the aia, then experiment. Give the app sufficient time for the GPS to get a satellite fix. The initial satellite fix might take a minute. When the app’s GPS achieves a fix, an icon appears on the Map showing your current location. Place your Android on a desk; select Mom (even if you are a dad) and let the app plot a red Marker point. this might take a minute. Now select Dad as the User; wait until a blue Marker plots. Do the same for Son and Daughter. Soon you should see four Markers on your screen . ZOOM in until you see all four Markers.
Use the first way on only one phone. Test as described in #2.
StayAwake: the app uses a Notifier and a Clock to force the screen open to prevent the app from going to sleep. Use the check box. If the app goes to sleep the app will hibernate until you revive it. While hibernating, it will cease to access the CloudDB. Users will ‘see’ your last reported location prior to the device going to sleep.
Sounds: an aural prompt is provided that indicates when the CloudDB is updated. Use the switch to enable or disable this feature.
The Map re-centers itself using the coordinates of the currently selected User Marker.
When you experiment with the second way to test the app, you realize that the location Markers plot at different geocoordinates, without moving the Android from a desktop. The locations of any single User vary with offset differences of five or so meters to as much as 50 meters from where the device is physically located. As stated in many previous tutorials involving a GPS, the GPS does not know exactly where it is (unless the points with large Accuracy values are filtered out before reporting positions). For example you could provide code like: If Accuracy >10…do not use the location. This app does not filter out ‘bad’ or uncertain geocoordinate values. Filter out the suspect locations - just do not report (add to the database) locations with an Accuracy greater than 10 meters or so in your version of the app. The multi-colored image of Markers showed above was generated with a device setting on a desktop, never moving. Regardless, you can see all the places the Android ‘thought’ it was.
There is a popup Description and Title for each Marker. Touch an icon and the popup bubble will tell you a little bit about the Marker location. The Titles (User names) are set on the Designer; the Description is a time stamp showing when the Marker was last updated. The time stamp is set in the DataChanged Block and it is not entirely accurate. A better place to encode it would be to place it as an item in the Tag, save it along with the location coordinates as a List or csv. The time should be assigned at the same time an individual creates the location. Again, this app is coded as a simple ‘solution’. Posted time is ‘accurate’ as long as everyone in the ‘chat’ is current. If a Marker does not have a time stamp, that means that User is inactive and the location you see is that User’s last known location
I included a button to clear all Tags (Button1); you may want to be able to clear all Tags for debugging. Presently the Button exists but is hidden. Be aware, using the Block clears the entire CloudDB for the app immediately (there is no request to ask if you really intend to do it.
The default CloudDB server is on MIT’s campus. The server occasionally goes offline or glitches. Usually it returns shortly or within a few hours. If you see this message (or something similar)
when you open your app, try again later. To provide controllable reliability of a CloudDB app, host the CloudDB on your own Redis server or build this app using the FirebaseDB controls. Firebase runs on Google’s servers. CloudDB components are ‘similar’ to FirebaseDB and generally can be substituted one for one. Sorry, you cannot mix and match. All CloudDB or all FirebaseDB.
When you are done and turn off your android, the other Users may continue; however your icon will cease to move.
Don’t run your battery down to dangerous levels using StayAwake. The app does not provide a warning if your battery gets dangerously low.
Be aware, if you share this, those that you share with know your location if you have it enabled and they too.
How to Use the App
- Start the app
- Wait (up to a minute) for the GPS receiver to achieve a satellite fix. When a Map Marker icon appears, you know that has happened. If other Users have ever beaconed their locations; their last beaconed location Marker will also appear on your map.
- Watch your ‘family circle’ or friends movements on the real time map. The others will show movement as long as their app is beaconing and not asleep and the app will show how far each is separated from the others. Distance is meters. You can code this to respond in kilometers, feet, miles etc but you have to code that feature.
- Touch a Marker to see a bubble with the User and a time stamp.
- If the app tells you Users are too close, any two individuals are within two meters or six meters of one another. Two meters is hard coded (see below). Re-code these Blocks to set any distance interval you want. Because of the Accuracy of the satellite fix, individuals might be closer or farther away than indicated. Know the capabilities of the LocationSensor, see the tutorials in Using the LocationSensor
- Prevent the app from going asleep (Use the StayAwake; App Inventor apps cannot run in the background).
Some of the Key Blocks
StayAwake StayAwake uses a Clock and a Notifier with it’s Text set to color set to none.
Store User Location
Location Sensor TimeInterval . The Blocks determine how frequently the location sensor will attempt to achieve a fresh satellite fix (Using values lower than 30 seconds has limited value) and link the LocationSensor to the Map component.
Social Distancing was tested on a 7" Android 4.2.2 tablet, a 10" Android 8.1 tablet and two different Android 4.2.2 cell phones using both WIFI and a 4G network. Sometimes there are small issues using the 4G network; probably due to the small amount of memory in these older Android versions.
The app uses the default CloudDB server. Do not use the default server to host commercial apps. Use your own Redis server.
Is the app optimized. No, I avoided the Anycomponent Blocks and design time Markers on purpose. Advanced developers can make this more complex as required. How many Users before the default CloudDB server freezes … I do not know how many users an app built like this can handle. If you have lots of users, please use your own Redis server or rebuild the app using the FirebaseDB.
The app is provided as an educational tool. Use it freely for personal use. Please do not slightly revise the app and claim as your own and commercialize it. Please feel free to use the algorithms and ideas in your own app.
Hope you find the app interesting. SocialDistancing.aia (41.0 KB)