App Inventor
Enviado por ylser • 7 de Noviembre de 2014 • 2.185 Palabras (9 Páginas) • 268 Visitas
CHAPTER 14
Understanding an App’s Architecture
This chapter examines the structure of an app from a programmer’s perspective. It begins
with the traditional analogy that an app is like a recipe and then proceeds to reconcep-
tualize an app as a set of components that respond to events. The chapter also examines
how apps can ask questions, repeat, remember, and talk to the Web, all of which will be
described in more detail in later chapters.
Many people can tell you what an app is from a user’s perspective, but understand-
ing what it is from a programmer’s perspective is more complicated. Apps have an
internal structure that we must fully understand in order to create them effectively.
One way to describe an app’s internals is to break it into two parts, its components
and its behaviors . Roughly, these correspond to the two main windows you use in
App Inventor: you use the Component Designer to specify the objects (components)
of the app, and you use the Blocks Editor to program how the app responds to user
and external events (the app’s behavior).
Figure 14-1 provides an overview of this app architecture. In this chapter, we’ll explore
this architecture in detail.
220 Chapter 14: Understanding an App’s Architecture
App
Components
Visible
Button, Textbox,
Label, etc.
Non-visible
Texting,
LocationSensor,
Text To Speech
Button.Click,
Texting.MessageReceived
Event Response
Ball.MoveTo,
Texting.SendMessage,
set Label.Visible to
Variables
Behaviors:
Event Handlers
Procedures
Figure 14-1. The internal architecture of an App Inventor app
Components
There are two main types of components in an app: visible and non-visible. The app’s
visible components are the ones you can see when the app is launched—things like
buttons, text boxes, and labels. These are often referred to as the app’s user interface .
Non-visible components are those you can’t see, so they’re not part of the user in-
terface. Instead, they provide access to the built-in functionality of the device; for ex-
ample, the Texting component sends and processes SMS texts, the LocationSensor
component determines the device’s location, and the TextToSpeech component
talks. The non-visible components are the technology within the device—little
people that do jobs for your app.
Both visible and non-visible components are defined by a set of properties . Properties
are memory slots for storing information about the component. Visible components,
for instance, have properties like Width , Height , and Alignment , which together
define how the component looks. So a button that looks like the Submit button in
Figure 14-2 to the end user is defined in the Component Designer with a set of prop-
erties, including those shown in Table 14-1.
Table 14-1. Button properties
Width Height Alignment Text
50 30 center Submit
Figure 14-2. Submit button
Behavior 221
You can think of properties as something like the cells you see in a spreadsheet. You
modify them in the Component Designer to define the initial appearance of a com-
ponent. If you change the number in the Width slot from 50 to 70, the button will
appear wider, both in the Designer and in the app. Note that the end user of the app
doesn’t see the 70; he just sees the button’s width change.
Behavior
An app’s components are generally straightforward to understand: a text box is for
entering information, a button is for clicking, and so on. An app’s behavior, on the
other hand, is conceptually difficult and often complex. The behavior defines how
the app should respond to events, both user initiated (e.g., a button click) and exter-
nal (e.g., an SMS text arriving to the phone). The difficulty of specifying such interac-
tive behavior is why programming is so challenging.
Fortunately, App Inventor provides a visual “blocks” language perfectly suited for
specifying behaviors. This section provides a model for understanding it.
An App As a Recipe
Traditionally, software has often been compared to a recipe. Like a
recipe, a traditional app follows a linear sequence of instructions,
such as those shown in Figure 14-3, that the computer (chef) should
perform.
A typical app might start a bank transaction (A), perform some
computations and modify a customer’s account (B), and then print
out the new balance on the screen (C).
An App As a Set of Event Handlers
However, most apps today, whether they’re for mobile phones,
the Web, or desktop computers, don’t fit the recipe paradigm anymore. They don’t
perform a bunch of instructions in a predetermined order; instead, they react to
events—most commonly, events initiated by the app’s end user. For example, if the
user clicks a button, the app responds by performing some operation (e.g., sending a
text message). For touchscreen phones and devices, the act of dragging your finger
across the screen is another event. The app might respond to that event by drawing
a line from the point of your original touch to the point where you lifted your finger.
These types of apps are better conceptualized as a set of components that respond
to events. The apps do include “recipes”—sequences of instructions—but each
recipe is only performed in response to some event, as shown in Figure 14-4.
A
B
C
Figure 14-3.
Traditional
software follows a
linear sequence of
instructions
222 Chapter 14: Understanding an App’s Architecture
A
B
C
Event1
D
E
Event2
Figure 14-4. An app as multiple recipes hooked to events
So, as events occur, the app reacts by calling a sequence of functions . Functions are
things you can do to or with a component—operations like sending an SMS text, or
property-changing operations such as changing the text in a label of the user inter-
face. To call a function means to invoke it, to make it happen. We call an event and the
set of functions performed in response to it an event handler .
Many events are initiated by
...