Table of ContentsVariables: Giving Your App a Memory

Defining a variableSetting and Getting a VariableIncrementing a VariableDisplaying a VariableComputational ExpressionsSummary

Variables: Giving Your App a MemoryJust as people need to remember things, so do apps. This chapter examines how you can program an app to remember information.

When you buy a computer, one thing you’ll be asked is how much memory you want the computer to have. Consider this ad:

The description is in a foreign language to many; some of us have learned to decipher the terminology, at least partially. On the first line we learn that the speed of the computer is 3.0 Ghz. (Gigahertz). A computer’s speed is how fast it can perform calculations such as 1+1 or adding up a million numbers. The second line has information about the computer’s memory: 750 GB Hard Drive, 4GB RAM. You can think of the hard drive as the computer’s long-term memory, or at least part of it. When you save information in a word processing file, it is stored on the hard drive. If you have a directly on your computer, it would be stored on the hard drive. 750 GB means 750 gigabytes. A gigabyte is a million megabytes. A megabyte is a million bytes. A byte is 8 electronic currents. If you were storing yes/no votes, you could store 750x1,000,000x1,000,000x8 votes. The “4GB RAM” is the computer’s short-term memory. RAM stands for random access memory. The “random” means that you can ask for the information in any memory slot and it can be accessed in a timely fashion. Long-term memory is slower and better for batch jobs like storing or retrieving an entire file of information. Long-term memory, in the context of a computer, means information that lives even after an app is closed. So if you are using your favorite word processor and haven’t saved your file, your modified document is in short-term memory only. If the power went out, that information would be lost. When you save a file, it moves information from the computer’s short-term memory to its long-term memory. Short-term memory is used by an app as it executes and performs calculations. It is something like a person’s short-term memory. When someone tells you the phone number of a pizza place for a one-time immediate call, you store it in your brain’s short-term memory. If someone calls out some numbers for you to add, those numbers and the running total are stored in your short-term memory. The computer (or smart-phone) has the same kind of short-term memory. You can think of the app’s short-term memory as a huge set of memory cells, with each cell holding a number, some text, or some other type of data. An app can put things in these short-term memory cells, check the data values in them, and perform computations on that data.

There are two types of memory cells in an App Inventor app: component properties and variables. You are already familiar with component properties—these are stored in short-term memory cells. For instance, the width of each component is stored in a memory cell Button.Width50

The end-user who uses the app never sees the memory cell or the number 50—the app’s short-term memory is hidden from the user. You as a programmer can view and set these properties in the Component Designer. You can also change and view them in the Blocks Editor, but more on that later. Besides component properties, you can also define memory cells which are not associated with a particular component-- these are called variables. You might define a variable to keep track of the score in a game app, or to keep track of the question number in a quiz app. Both component properties and variables are short-term in that, when you close the app, the data stored in the memory cells is lost. If you re-open the app, that data will not be in the memory cells unless your app re-sets the property or variable. So if somebody plays your game app and gets the score up to 200, then closes the app, the score will not be 200 when he re-opens the app.

Defining a variableWith App Inventor, you define a new variable in the Blocks Editor by clicking on Definitions and dragging out a def variable block. When you define the variable, you can name it and specify an initial value. Here are the steps you’d follow to create a variable “score”: 1. Drag the def variable block from Definitions:

2. Click on the triangle in the red box to specify the type of variable, e.g., a number or text:

3. Choose a number (123) for this example:

4. Change the initial value to 0:

5. Change the name of the variable to “score” for this example:

When you define a variable you tell the app to set up a named memory cell, a slot in which you can remember something. When the app begins, the slot is allocated and in this sample named “score” with an initial value of 0. score0

Because score has been defined, the app will be able to store values in it (set it), and see what value is in it (get it). So if the app is a game and the player does something good, the value in score can be set to a larger number. If the app needs to determine a winner, it can look at (get) the value of score and compare it to some other number. Note that the blocks for a variable definition are not placed in an event-handler: instead they float by themselves in the blocks editor. All such floating definition blocks are executed when the app begins.

Setting and Getting a VariableWhen you define a variable as demonstrated above, App Inventor immediately creates two blocks for using it, both of which appear in the My Definitions drawer:

The set global to block lets you modify what is in the memory cell. For instance, these blocks:

place a 5 in the variable score: score

5 The block labeled “global score” gets (retrieves) the value of a variable. For instance, if you wanted to check if the score was 100 or greater, you’d plug the “global score” block into an if-then test:

Incrementing a VariableOften, a variable is set based on another variable or even its own current value. For instance, in the game MoleMash, when the player touches the mole, the score should be incremented by one. Here are the blocks to increment a variable.

To understand these blocks, first realize that blocks on the right-- the + and its two “argument” slots -- are performed first, and then the result is “set” into the variable score. Specifically, the blocks say to get the value in the memory cell named score and add 1 to it. If the value of score was 5, adding 1 to it gives 6 as the result of the + operation. The 6 is then plugged into the set global score to operation, resulting in 6 being placed in the variable: score6 So like Chinese, App Inventor blocks are interpreted, in some sense, right-to-left.

Displaying a VariableWhen your app defines a variable, it allocates a memory cell in the app’s short-term memory. This variable and all of the cells in the short-term memory are not visible to the end-user of the app. If you defined and modified a variable score in a game app, but never used score to modify the user interface, the user would never know the score and the app’s work keeping track of it would be wasted. For something like a score, you can define a label component, ScoreLabel to display the score. When the user does something to get points, the app first modifies the variable score then transfers the new value of the variable into the label:

You may ask, “why have both a score and a ScoreLabel?” and its a good question. One could just define another label component displaying the “Current Score:” and place it just to the left of ScoreLabel. Then when the user did something to get points (e.g., ImageSprite.Touched), the ScoreLabel could be incremented (+1) directly and you wouldn’t need to define the variable “score” at all. In software engineering it is considered good practice, however, to keep your “calculation” (model) variables separate from your interface (“view”) variables. The reason is flexibility as the specifications for your app change. For instance, if your client tried the app and decided it would be beneficial to show the score as a sliding bar, you’d only have to change the display blocks, and not the calculations. For our example, you’d leave the score increment blocks as they are, and just replace the “set ScoreLabel.Text to” blocks with something that modified the width of the slider bar (probably a label). For this simple example, the difference might not be significant. But for software with many calculations and views of the data, it is particular important to define variables for the calculations separately from the user interface objects. It becomes even more significant when one attempts to port an app from one device with a particular user interface (e.g., the web) to a different device (a phone). The concept itself has been coined Model-View-Controller, with the Model being the calculations (and database) part, the View being the user interface, and the Controller being the glue (e.g., event-handlers). Understanding a concept like Model-View-Controller, or MVC for short, can add significantly to your ability to working on a software

team.

Computational ExpressionsAn expression is the computer science term for a formula. A common place you’ll find expressions is on the right-hand side of a set global to block. When we add one to the score:

the blocks to the right of the set global score to block (the score + 1) are an experession.

In general, an expression can be any mathematical formula and can contain any mathematical operator, function, or value, including those you’ve defined.

Most of the building blocks for creating expressions are in the Math drawer:

You can combine these with Component properties and variables to calculate just about anything. For instance, if you wanted to move an image sprite to a random column within the bounds of a canvas, you’d configure an expression consisting of a multiply block, the Canvas.Width and a random fraction function:

SummaryAn app is launched. It begins executing its operations and responding to events that occur. In responding to events, the app sometimes needs to remember things. For a game, this might be each player’s score, or even something like the direction an object is moving. If you know your app needs to remember things, you define variables. Variables, like component properties, are really named memory cells in the app’s short-term memory. You can set a variable (modify the value in its cell) and get a variable (look at the contents within the cell). You can perform calculations and then put the result in a variable. Variables are not visible to the end-user of the app. If you want the end-user to view the information stored in a variable, you add blocks that display that information in a label or other user interface component. In software engineering, it is good practice to use variables for calculations and use user interface components just for display—so you wouldn’t directly add to a ScoreLabel, you’d modify a score variable and then place the updated score in the ScoreLabel. This separation of concerns is called the Model-View-Controller paradigm.