Chapter 3.9 - Map Tour with Storage

Time Estimate: 45 minutes

3.9.1. Introduction and Goals

This version of Map Tour will extend the original app in two ways: (1) by incorporating a Location Sensor, Thunkable’s GPS sensor, and (2) by incorporating stored variables, Thunkable’s local database. The Location Sensor will allow us to extend the list of destinations by adding one’s current location (as determined by the GPS sensor) to the list of destinations. The stored variable will allow us to persist our list of destinations between different uses of the app -- that is, the destinations list will be saved and restored when one quits and restarts the app. Objectives: In this lesson, you will create an app that uses Thunkable’s GPS sensor to determine the user’s location and use it as a destination; learn basic concepts about databases data persistence; incorporate a stored variable local database into an app to permanently save app data on the device.

Introduction: Persistent Data and stored variable

Up until now, the data in our apps has been stored either in app variables or as the value of the properties of the app’s various components. For example, when you store a piece of text in a Label, that data is stored in the computer’s main memory, in its RAM, or random access memory. And as we’ve learned, RAM is volatile, meaning that any data stored there will be destroyed when the app is exited.

By contrast, data stored in the computer’s long-term storage -- e.g., on the phone’s flash drive -- will persist as long as the app is kept on the device. There are various ways to store data permanently on a computer. For example, you could store it in a file, such as a document or image file. Another way to store persistent data is in a database. Thunkable provides us with a very simple, easy-to-use local database in its stored variable. Any data that we store in the stored variable will not disappear when the app is exited. Instead, it will persist between uses of the app -- even if you turn off the device.

Getting Ready

To get started, open the app that you created in the previous lesson. Then follow along with the following tutorial.

The User Interface

We would like to clean up the UI a bit by adding a Menu button. We will add all the other buttons to a Group component. We will add a Save My Location button, a Text Input, an Add New Location button, a Remove Location button to the Group, and the following blocks:

• LocationSensor - for tracking the device’s location.

• Alert - for displaying messages.

Adding the Menu Button

Drag and drop a Button component onto the app, rename it ButtonMenu and set its Text property to “Menu”.

Adding the Group

Drag and drop a Group component onto the app and drag the other buttons aside from the Menu button into the Group. The Menu button should remain outside of the Group.

Adding the Save My Location Button, Text Input, Add New Location Button, and Remove Location Button

Drag and drop a Button component into the Group, rename it ButtonSaveLocation and set its Text property to “Save My Location”.

NOTE: If your device does not support GPS, you won’t be able to use the LocationSensor to acquire new addresses to add to the destinations list. In that case, here is an alternative way to add new locations to the destinations list:

• Add a Text Input component to the Group and rename it TextInputNewDestination.

• Add a Button to the Group, named ButtonAddNewLocation

• Code the ButtonAddNewLocation Click handler to use the value in the text input to add to the destinations list.

Drag and drop a Button component into the Group, rename it ButtonRemoveLocation and set its Text property to “Remove Location”.

Adding the Alert

In the Blocks view, add an Alert blockto the app from the App Feature’s Alert category. No need to rename it, since there is only one. Change the Title property to Location Saved. We will code its behavior in the blocks editor.

Adding the LocationSensor

If you did not already add the Location Sensor in the previous lesson, add a LocationSensor from the Sensors category to the app.

Coding the App’s Behavior

Before working on the app itself, let’s review some information about Thunkable’s LocationSensor.

GPS and the Location Sensor

Thunkable’s Location Sensor (in the Sensors category in App Features) is a block that provides location data about the device’s latitude and longitude.

A mobile device can detect its location in one of three ways:

• Using its built-in GPS sensorwhich acquires a fix on its location from GPS satellites. This is the most accurate but, ideally, requires that the phone has a clear shot of the sky so that it can receive readings from at least 3 GPS satellites. This is accurate within a few meters but uses the most battery power.

• Using a WiFi signal from the surrounding WiFi router. The phone’s location would be the latitude and longitude of the router. This might work indoors and uses less battery power.

• Using the Cell ID -- i.e., signals from surrounding cell towers. This is the least accurate but uses the least power.

This app will use the Location Sensor to determine the device’s latitude and longitude.

Adding Your Location to the List

If your device has a GPS capability, it is easy in Thunkable to add your current location to the list picker’s list. The Location Sensor has the following function, which will get the device’s latitude and longitude:

When it runs, it provides the device’s latitude and longitude. We want to run this when we click on ButtonSaveMyLocation to add it to the list of destinations.

Coding ButtonSaveLocation

When the user clicks the ButtonSaveLocation, we want to add the device’s location to the destinations list, using the in list insert at last block:

This block will add a new item to the destinations list. We also want to update the List Viewer’s elements and call the Alert

Running and Testing the App

Here’s a test to run.

1. Press ButtonSaveLocation to save the current location to the destinations list.

2. Press the Choose Destination list picker to confirm that the new address has been added to the list.

3. Quit the app.

4. Restart the app and look for the saved address on the Choose Destination list.

If you perform these steps, you should notice that the address you saved is no longer on the destinations list. Why is that? The reason is that the destinations list is an app variable and, as such, it is stored temporarily in the app’s RAM (random access memory). When the app is quit, its RAM memory is (effectively) erased. So, when the app is restarted, the destinations list is re-initialized to its original state.

Persisting the Saved Locations with stored variable

As you saw from that test run, the locations that you save while running the app do not persist between uses of the app. To remedy this, we will store the destinations list in a stored variable. We need to add the stored variable in the blocks. Name the stored variable locations:

There are two stored variable actions that need to be taken in order to save and restore the locations:

1. When the app starts up, it needs to read the locations list from the stored variable.

2. When the user clicks ButtonSaveLocation the app needs to store the destinations list to the stored variable.

Inputting the Destinations List from stored variable

The algorithm for inputting the destinations list is complicated by the fact that the first time the app is used, there won’t be a destinations list in the stored variable.

if not (stored locations = empty value)

{

destinations ← stored locations

}

ListViewer text items ← destinations

The algorithm begins by reading the stored locations list from the stored variable. If this is the first time the app is being used, then the attempt to read the stored locations from the stored variable will return an empty value -- the app hasn’t yet stored any data under that variable. In that case, we do not need to store the stored locations in the destinations list and skip over this part. If it is not an empty value, then we do need to store the stored locations in the destinations list. We then set the ListViewer items.

In Thunkable, we want to place this algorithm in the Screen1 Starts block, which will fire as soon as the app starts up.

Saving the Destinations List to stored variable

The algorithm for storing data into a stored variable will go into the ButtonSaveMyLocation Click handler, which now looks like this. Note the added set stored variable locations to app variable destinations.

Adding New Location Button

The Add New Location button will perform a similar algorithm to the Save My Location button, but will not use the Location Sensor and instead insert the Text Input text into the list.

Cleaning up

The User Interface of the app can get very cluttered with all the buttons, especially when adding multiple locations. We have added two buttons that will help with that: Menu and Remove Location.

We want our Menu button to hide/show the Group when the button is clicked. For this, we need to toggle the visibility of the Group. We can use a NOT function to do this.

We want our Remove Location button to remove locations from our list. For simplicity, we will just remove the last item from the list, but you may wish to implement a way to remove specific items later. We will use the in list remove block to remove items from the list and update the ListViewer and stored locations.

Running and Testing the App

Testing this will require you to close and run the app again and use it to save some new destinations to the List Viewer. Now, when you quit the app (or turn off the device), the destinations you saved will be re-loaded from the stored variable into the app when it starts up again. By storing data in a local database, stored variable, the app is able to persist data that would otherwise disappear when the app stops running. The saved data will remain associated with the app as long as the app is on your device.

Extension (optional)

Monitor Your Device’s GPS. As you may have experienced in using this app, the performance of your device’s GPS may vary widely depending on your location and your environmental conditions. If your device’s GPS is turned on, then obtaining a fix on its location (from satellites) will work best when you have a clear view of the sky. It will also depend on how long it takes the device to locate at least 3 GPS satellites, which depends on a variety of factors, including whether the device has been powered off for a long time or not. To monitor this, create a function that will display some of the data that you can obtain from the Location Sensor. Create a function named displayGPSdata that gets called whenever you save your location. The function should display (in a label or Alert) the value of certain properties; an example of how to do this is available here.

3.9.3. Summary

In this lesson, you learned how to:

Learning Objective DAT-2.D: Extract information from data using a program.

Learning Objective AAP-1.C: Represent a list or string using a variable.

Learning Objective AAP-1.D.a: For data abstraction: a. Develop data abstraction using lists to store multiple elements.

Learning Objective AAP-1.D.b: For data abstraction: b. Explain how the use of data abstraction manages complexity in program code.

3.9.4. Self-Check

Vocabulary

Here is a table of the technical terms introduced in this lesson. Hover over the terms to review the definitions.

database

Check Your Understanding

Complete the following self-check exercises.

Q-1: Which of the following statements are true for a TinyDb component. Choose all that apply.

A. Data stored in a TinyDb is stored in the cloud.

B. Data stored in a TinyDb can easily be shared with other devices and users.

C. Data stored in a TinyDb disappears when you quit the app.

D. Only strings (text) can be stored in a TinyDb.

E. Data stored in a TinyDb will persist between different uses of the app.

Q-2: What value would the global variable userName have after the blocks shown here are executed? Type your answer into the textbox. Spelling counts.

Q-3: What value would the global variable userName have after the blocks shown here are executed? Type your answer into the textbox. Spelling counts.

Q-4: In the block shown here why is it necessary to test whether the highestScore equals the empty string?

A. Because that would be the value returned by TinyDb if nothing had yet been stored under the tag "highest".

B. Because that would be a bad score.

C. Because TinyDb returns an empty string whenever the network is not available.

D. Because TinyDb can only be used to store numbers, not strings.

Q-5:

Consider the following depiction of the contents of a TinyDb for an app.

Tags	Values
school	Trinity College
trinity	Trinity College
college	Amherst College
university	Harvard

And suppose your app just executed the following block:

Which of these statements best describes the current state of the database?

A. The tag 'school' is still associated with 'Trinity College'.

B. This would cause an error because the tag 'school' has already been used.

C. The tag 'school' would now be associated with 'Bowdoin College' instead of 'Trinity College'.

D. There are now two colleges, Trinity and Bowdoin, associated with the tag 'school'.

Q-6: True or False: It is possible to have an empty list – i.e., a list with no elements.

A. True

B. False

3.9.5. Reflection: For Your Portfolio

Answer the following portfolio reflection questions as directed by your instructor. Questions are also available in this Google Doc where you may use File > Make a Copy to make your own editable copy.