7.6. Clicker App with CloudDB (optional)

Time Estimate: 90 minutes

7.6.1. Introduction and Goals

In earlier apps that we designed in this course, we used TinyDB to store and retrieve data on our physical device (phone or tablet). In this lesson, we will build a simple Clicker App that will store and retrieve data from a cloud database on the web. Imagine a teacher asking the class a question and students voting on it. We want to design an app that can not only store the results from each student in one central place but also allow the teacher and the students to view the results in real time.

Learning Objectives: I will learn to differentiate between synchronous and asynchronous operations create an app using the CloudDB component to store data on the web so it can be shared by different users Language Objectives: I will be able to describe and give examples of syncrhonous and asyncronous operations describe how using a database helps reduce detail in an app use target vocabulary while describing app features and User Interface with the support of concept definitions from this lesson

7.6.2. Learning Activities

Introduction: Abstracting an App's Data

We will create a polling app that enables students to answer a yes/no question then display the poll results in real time. When your code is completed, you will have a clicker app that stores all of its data on the Web using a cloud database for a high-level data abstraction.

Database Concepts: TinyDB vs. CloudDBs

Before working on the app itself, it is important to understand what CloudDB is and how it differs from TinyDB. As you know from a previous lesson, we can use a TinyDB component to persist data. TinyDB stores its data on the device itself—the phone or tablet—and access to the data is synchronous, which means that access to the data is immediate. It's good for sharing data between uses of the app on the same device, but it is not good for sharing data among users on different devices.

For example, consider a diary app which enables a user to record entries that contain personal information. The synchronous storage of a TinyDB would be effective for storing entries in this app that a user does not want to share with anyone on a different device. Next, consider a messaging app intended to allow users to communicate with other users of the app. If a TinyDB was used to store the messages, users of the app on different devices would not be able to access the messages and the app would not work as intended. For this app, a CloudDB would be a better choice.

CloudDB is a web-based database service. It is a non-visible App Inventor component that can be used to store and retrieve data values in a database located on the Web. It can be found in the palette’s Storage drawer. Whereas TinyDB stores data only on the device running the app, a CloudDB is shared among users on multiple devices running the same app because it stores data online, in the cloud. Access to the web data is asynchronous, which means storing and retrieving data may not happen immediately. Your program must request the data operation, and the CloudDB will signal the program when it is completed. The app can continue running other commands at the same time as the web database is doing the data operation, until it is interrupted by the event that the data operation is complete.

Note that App Inventor also has TinyWebDB and FirebaseDB which are also web databases that can be used the same way as CloudDB with slight differences in the blocks. TinyWebDB does not have a when data changed block to push updates to all the shared devices. FirebaseDB is a Google product and charges for some services. CloudDB is based on FirebaseDB with all the same blocks but it is hosted at MIT.

CloudDB is currently having connection problems due to server overload. If you get a socket connection error, switch to using the Experimental/FirebaseDB and its associated blocks for this tutorial!

The following video explains the basic concepts of using a web-based database like CloudDB.

(TeacherTube Version)

CloudDB stores two types of records, individual data items in variables or lists. In this app, we will only be using it to store individual data items. Note that the tags are case sensitive in a CloudDB.

Getting Ready

Start App Inventor with Clicker App Template. Once the project opens use Save As to rename your project ClickerCloudDB.

Follow the video tutorial below or the text version or the short handout to complete this app.

CloudDB is currently having connection problems due to server overload. If you get a socket connection error, switch to using the Experimental/FirebaseDB and its associated blocks for this tutorial!

Testing the App

This app is best tested by forming a group of students where everyone in the group loads one student's app using Build/App (provide QR code for apk). Make sure that as each person's app loads, that the most recent data stored in the database shows up on their device. When one of student in your group votes, the latest data should update on everyone’s screen. Because this app is more easily tested using .apk files, we recommend it be built (and tested) on Android devices until iOS .apk files become available in App Inventor.

Exercises and Enhancements

To appreciate the increased flexibility and generality that we get from centralizing data on the web, here are some exercises to try. 

1. Create a Percentage Display Using the Thumb Switches
   
   • Read the documentation on Thumb Sliders before proceeding.
   • The sliders or thumb switches are most frequently used to allow the user to set the value of some property by moving their thumb on a sliding scale. For our Clicker app, we will be using this component in reverse - to create a percentage display based on the ratio of “Agree” and “Disagree” votes recorded by the app.
   • This video provides additional details on how to program the sliders to display percentages.
2. Allow Users to Vote Only Once
   
   • Modify the app so that the app only allows the user to vote once (hint: there is an Enabled property for buttons). Votes will still be updated by the DataChanged procedure which is called automatically when the data in the database is updated.
   • Add re-enabling the voting buttons when the user hits reset. Note: For testing purposes, it might be easier to disable the "vote only once" feature while testing other enhancements.
3. Build a Teacher Version
   This special version of the app, the “Teacher” version, will update the question displayed on the screen in real time. First in the student app.
   • Change the student version of the app to accept new questions while the app is running. This will involve adding code to the CloudDB.DataChanged event handler to see if the question was changed in the database and changing the question label accordingly and re-enabling the voting buttons. Use the tag name "question". Note that the question data will consist of a string, whereas the agree and disagree data were numbers.
   • Remove the RESET button from the UI of the student side so that only the teacher can reset the counters.

   Build a separate version of the app called "ClickerTeacher" (use Projects/Save As). Allow only this version to change the questions. Note that when you use Projects/Save As, the CloudDB token and ProjectID will both stay the same, so the student app and the teacher app can share the same database. Also, when testing the app, it may be easier to use QR codes to load the two versions of the app instead of trying to use the Companion.

   Note: If using Projects/Save As does not copy the CloudDB token, you may need to copy and paste the token from the student version into a text editor (e.g. a Google doc) and then copy and paste the token from the text editor into the teacher version.

   • Replace the question label in the teacher version of the app with a TextBox to allow the teacher to update the question field in real time.
   • Add an “Update Question” button to the teacher app that will store the new question into the CloudDB from where it will get pushed to all the users. Remember the tag name you used (question)! Also, reset the counters and store them in the database too.
   • Test with your group with one student using the teacher app and the rest using the corresponding student apps.

7.6.3. Summary

In this lesson, you learned how to:

7.6.4. Self-Check

Q-2:

To say that the operation of requesting data from a CloudDB is asynchronous means

• that it can be completed immediately.
• OK, so you didn’t get it right this time. Let’s look at this as an opportunity to learn. Try reviewing this; synchronous means "at the same time". So synchronous operations are performed instantaneously, whereas asynchronous operations are not. Operations over the Internet are asynchronous.
• that the request cannot be completed at the same time as it was made and may take an unpredictable amount of time.
• Right. Synchronous means "at the same time". So synchronous operations are performed instantaneously, whereas asynchronous operations are not. Operations over the Internet are asynchronous.
• that it must be performed on a clock.
• OK, so you didn’t get it right this time. Let’s look at this as an opportunity to learn. Try reviewing this; synchronous means "at the same time". So synchronous operations are performed instantaneously, whereas asynchronous operations are not. Operations over the Internet are asynchronous.
• that it cannot be performed on a clock.
• OK, so you didn’t get it right this time. Let’s look at this as an opportunity to learn. Try reviewing this; synchronous means "at the same time". So synchronous operations are performed instantaneously, whereas asynchronous operations are not. Operations over the Internet are asynchronous.

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

• a. Data stored in a CloudDB can easily be shared with other devices and users.
• That's right! Data stored in a CloudDB is stored on the Web and that's why it can easily be shared with other devices or users.
• b. Data stored in a CloudDB will persist between different uses of the app.
• That's right! Data stored in a CloudDB persists between uses of the app.
• c. Data stored in a CloudDB disappears when you quit the app.
• No, data stored in a CloudDB persists between uses of the app so they do not disappear.
• d. Data stored in a CloudDB are stored on the Internet.
• Right. Unlike TinyDB, which stores data on the mobile device, CloudDB data are stored on the Internet and downloaded into the app at run time.

Q-4:

A TinyDb component does not have an event handler. Why do CloudDB need a GotValue event handler?

• a. Because data stored in a CloudDB is stored on the phone's hard drive.
• We’re in the learning zone today. Mistakes are our friends!
• b. Because data stored in a CloudDB can store bigger chunks of data.
• We’re in the learning zone today. Mistakes are our friends!
• c. Because CloudDB data are stored on the Web and retrieved over the Internet whereas TinyDb data are stored on the device.
• Good. Because CloudDB data are stored on the Web, attempts to retrieve it depend on the availability of the Internet and other factors and may take considerable time. So an event handler is used to tell the app when the requested data has arrived.
• d. Because CloudDB data are stored in a complicated database whereas TinyDb data are stored in a simple database.
• We’re in the learning zone today. Mistakes are our friends!

Q-5:

When should an app's data be stored in a CloudDB as opposed to a TinyDb?

• a. When the data needs to persist between uses of the app.
• Both, CloudDB and TinyDb are able to persist data between different uses of the app. So this is not the best answer.
• b. When the data needs to be shared among different devices running the app.
• Right. CloudDB store data on the Web and retrieve it over the Internet. So it can be shared among many devices. TinyDb stores data on the device. So it can't be shared among different devices.
• c. When you need to retrieve the data quickly.
• It is true that data stored on a TinyDb is retrieved instantaneously, which will always be faster than data retrieved asynchronously from a CloudDB. But we are talking about a difference of a few milliseconds, assuming the app has a reasonable Internet connection. So this is not a main reason to choose between TinyDb and a Web-based database.
• d. When you need to store lists of data.
• Both CloudDB and TinyDB can store lists of data. So this is not a distinguishing feature.

7.6.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.

You have attempted of activities on this page