App Inventor ch1-4

Android Programming
with App Inventor for Android
(draft 1, 1/2010)
David Wolber
Table of Contents
........................................................................................................... 1
Chapter 1: Introduction ...................................................................... 3
Getting Started: Downloading Some Apps.............................................. 5
Chapter 2: Building And Deploying an App with App Inventor............. 6
Introduction....................................................................................... 6
Building the User Interface .................................................................. 6
Programming the App's Behavior .......................................................... 8
Download the App to Your Phone ......................................................... 11
Test the App in the Emulator............................................................... 12
Installing and Running the Emulator ....................................................12
Chapter 3: An App Is......................................................................... 15
A App is a Recipe............................................................................... 15
An App is a Set of Event-Handlers .......................................................15
An App Consists of Event-Handlers That Can Ask Questions and Branch ....17
An App Consists of Event-Handlers That Can Ask Questions, Branch, and
Repeat ............................................................................................. 18
An App Consists of Event-Handlers That Can Ask Questions, Branch, Repeat,
and Talk to Web Services ................................................................... 19
An App Consists of Event-Handlers That Can Ask Questions, Branch, Repeat,
Talk to Web Services, and Remember Things ........................................20
Chapter 4: Components, Properties, Events, and Functions .............. 22
Components ..................................................................................... 22
Properties......................................................................................... 24
Events ............................................................................................. 26
Functions ......................................................................................... 28
Summary ......................................................................................... 29
Problems .......................................................................................... 30
Chapter 1: Introduction
Programming is like magic to most people, and only a small percentage of
humans ever try it. This is unfortunate, as there are many very creative
people that don't even dream of applying their creativity, at least directly, to
building software. Most people consider the apps they use on their
computers and phones as beyond their control-- they are stuck with being
consumers, and not producers, or even "customizers", of software. The
software we now use would certainly be better if the tools for building it
were accessible to more people.
There has been progress. The web started out as read-only-- only web
masters could create web pages and most of us just "consumed" the
information out there. With blogs, wikis, social networks, and Twitter, the
web has now become a read-write web, and most everybody is now "part of
the conversation".
However, there is still a large chasm in terms of producers and consumers:
though many now blog and create web pages, there are still few who know
how to create apps-- software that displays information dynamically and can
respond to user input and other events. Just as there is a digital divide,
there is also a programmer divide that limits people's control over the
devices they use.
Can this divide be breached? Can ordinary people be taught to program their
computers and their phones? There are reasons to believe they can. Young
people today are incredibly computer literate compared to the previous
generations. They don't fear computing-- it is part of their lives from an
early age. And they use computing hours upon hours a day. Thus, they are
extremely motivated to have useful software and to be able to customize it
for their own personal use.
Google is very interested in this question, and to explore it they have
designed a new visual programming language, App Inventor, designed to
allow people to program their phones. Here is Google's vision:
Mobile applications are triggering a fundamental shift in the way people
experience computing and use mobile phones. Ten years ago, people
"went to the computer" to perform tasks and access the Internet, and
they used a cell phone only to make calls. Today, smartphones let us
carry computing with us, have become central to servicing our
communication and information needs, and have made the web part of
all that we do. Ten years ago, people's use of computing was largely
dissociated from real life. With the ubiquity of social networking, online
and offline life are becoming fused. (Our) exploration is motivated by
the vision that open mobile platforms like Android can bring some of
that same change to introductory Computer Science, to make it more
about people and their interactions with others and with the world
around them. It's a vision where young people—and everyone—can
engage the world of mobile services and applications as creators, not
just consumers. Through this work, we hope to do the following:
Make mobile application development accessible to anyone.
Enhance introductory learning experiences in computing through the
vehicle of Android’s open platform.
• Encourage a community of faculty and students to share material and
ideas for teaching and exploring.
•
•
From Google Research Blog:
http://googleresearch.blogspot.com/2009/07/app-inventor-forandroid.html
The App Inventor visual language makes developing Android apps
considerably easier than with a traditional programming language. With App
Inventor, everything you can do is visible, and you program by piecing
together blocks representing phone functionality and data. It is similar to
the Mindstorms blocks language for programming Lego robots, but you
program your phone instead.
The blocks language makes things easier, and Google's target audience was
people without programming experience, so ease-of-use was part of the
design. But programming with App Inventor is still a difficult task and gets
more complex as you build more complicated apps.
The key from a learning perspective is motivation: people are
significantly more motivated to learn programming and computer concepts
because they are building something fun that they can use in their every
day life. In teaching App Inventor, I've been amazed at how hard students
have worked-- they're motivation level has been significantly higher even
compared courses in which I've taught fun programming applications like
robots or graphics. My belief is that they are more motivated because they
are building "real" software-- software that can benefit their everyday lives.
This book steps you through the process of building Android apps using App
Inventor. We'll begin with some simple apps-- an app that speaks what you
type, and an app that moves a ball around the screen. But rather quickly
we'll progress to more complicated apps and you'll be building games,
educational software, Twitter clients, and maybe even the next killer app for
the Android platform!
Getting Started: Downloading Some Apps
The Market
The Android Market has thousands of apps, many of which are free to
download. You can search for specific keywords to find an app, and you can
read a blurb about the app and see reviews of it before downloading. Before
embarking on our journey to learn programming, definitely download some
apps and become acquainted with how Android apps look and behave.
Barcode Scanner
There are two specific apps that we'll use in the programming lessons. The
first is a barcode scanner. This is required because when you build an app,
App Inventor creates a barcode for the app. With an Android barcode scaner,
you can scan the barcode in order to install the new app on your phone.
Very cool!
One popular barcode scanner is from ZXing. If you go to the Market and
search for it, you'll find it. Just step through the installation instructions and
you'll have a barcode scanner. For fun, try scanning the ISBN barcodes of
some books to see what the scanner does with them.
Text To Speech
The first sample app we'll create will speak the words the user types. For this, you need to
have Text to Speech (TTS) library code on your phone. With TTS, your apps can speak
words that have been typed in or sent as a text to your phone. You can
download a TTS app named TTS Service Extended at the Android Market.
Once you've downloaded it, open the app and click on menu to choose a
Default Engine. If you don't choose an engine, the app won't work (there's
no default setting unfortunately). You can also change the default language
and speech rate.
Once you've installed it, test it by clicking on the App to start it, then clicking
menu and choosing "Listen to a preview". Then try changing to a different
language to see what happens.
Chapter 2: Building And Deploying
an App with App Inventor
This chapter describes App Inventor and steps through the task of creating,
testing, and deploying a mobile app.
Introduction
Programming is generally a two-step process:
1.
2.
Design how the application will look.
Design how the application will behave.
With App Inventor, these two tasks are performed in separate windows. The
first window is the Component Designer. You use it to choose and place the
buttons, text boxes, images, and other components that will appear on the
phone when your app is run. The second window is the Blocks Editor. You
use it to define the behavior of your app-- how it should respond to events
such as the user pressing a button.
Building the User Interface
We'll start with a simple example: an application that let's the user enter
some words, then speaks the words when the user clicks a button. Though
simple, this application illustrates the basics of App Inventor and the basic
structure of a mobile app.
To build the application, we first open the component designer:
The left side is a palette with all the components that can be added to an application. The
left-middle panel is the surface representing the way the phone's screen will appear when
the application runs. The programmer drags from the left to the left-middle to specify the
components of a particular application.
For our sample app, we need three components: a TextBox where the user can enter the
words she wants spoken, a button for the user to click, and a TextToSpeech component
that will do the work of actually speaking the words.
The TextBox and the Button are part of the Basic palette, which is open in the snapshot
above. There are a number of other component palettes. The TextToSpeech component
is found in the Not ready for prime time palette.
The TextToSpeech component is a "non-visible" component, meaning it
won't appear on the phone's screen when the app runs. You can think of it
as a little man deep within the phone who will speak out the words the user
types, but will stay hidden from view.
As a component is dragged into an app, it's name appears in the middleright list of components. By default each component is given a name that
includes its type and a number (e.g., 'TextBox1'). You can select a
component to change its name and other properties. The name is important
because when you begin programming the behavior of the app, you'll need
to refer to particular components by name.
The component designer is used only to specify the way the application will
look (it's presentation). If you download the app we've developed thus far, it
will look fine but nothing will happen when the user types text and clicks on
the "Speak It" button.
Programming the App's Behavior
You can click on the Open Blocks Editor button in the Designer menu to
begin programming the behavior of the application. If you were writing a
traditional computer program, you would type code using a programming
language like Python or Java at this point. With App Inventor, you program
the app's behavior by configuring pre-defined blocks.
The Blocks Editor provides you with two palettes from which you can drag
blocks, the Built-in pallete and the "My Blocks" palette. The Built-In palette:
provides general programming blocks you'll need to specify the behavior and
logic of the app. We'll explore these later.
The My Blocks palette:
has blocks representing the components of your particular application, the
ones that were added in the Component Designer. Our example has three
components: TextBox1, SpeakItButton, and TextToSpeech1. Each of these
components has a drawer containing function and property blocks for the
component. As you can see, there is also a My Definitions component for
custom variables and functions you define.
When you click on a component, say the SpeakItButton, you can see all of
the events and operations associated with it:
Each component's drawer contains blocks associated with the component, including events,
properties, and functions that can be applied to it.
The pink blocks at the top represent events that can occur which are related to the
component. As the snapshot shows, a button component like SpeakItButton has four
associated events: when the user clicks it, when the user touches it or in some other
manner gives it focus (Got Focus), when it loses focus (LostFocus) and when it is initialized
(on app startup).
For our simple 'type in some words and click to speak them' example, we'll first choose the
SpeakItButton.Click event and drag it into the program block area:
This event block is a "when do" block and can be read as "when the user clicks on
SpeakItButton, do ..." Until we drag in some operations within this event block, nothing will
happen when the app runs and the user clicks the button.
In this case, the application should respond to the click by getting the text the end-user has
entered and giving it to the TextToSpeech component. So we first click on the
TextToSpeech1 component's drawer to see all of its operations. It has a number of them,
but the one we want is "Speak" as we want to tell the "little man" to say something:
The something we want him to say, the message, is the contents of TextBox1. That is, we
must envision that the user has typed in some words in the text box and then clicked on the
SpeakIt button.
We can get what the user has typed by opening the TextBox1 drawer and finding its "Text"
property. This "Text" property is a memory cell within the TextBox1 component whose job is
to watch what the user types. With this property, we can build our behavior:
TextBox1.Text -- what the user has typed -- is hooked in as the "message" of the function
TextToSpeech1.Speak. Both of these blocks are placed within the SpeakItButton.Click block.
In programming, we call such a when-do block, along with the operations inside it, an
event-handler. In this sample, the event handler has only one operation (block), but it
can have many.
The event-handler reads as "When SpeakItButton is clicked, TextToSpeech1
should speak the message that is the text entered by the end-user in
TextBox1.
Download the App to Your Phone
When you finish programming the blocks of an app, you can test it out on
your phone. One of the coolest features of App Inventor is that you can
download an app to your phone by scanning a barcode.
Back in the Component Designer, select Package For Phone | Show Barcode:
After a minute, a barcode will appear on the screen:
You'll need a barcode scanner on your phone-- you can download one from ZXing if you
don't have one. Once you have it, start it up and place the barcode scanner's window so
that the barcode on your computer appears within it. When the phone reads the barcode, it
will step you through downloading and installing your app to the phone.
When you run the application, it will look like this:
When you, the end-user, enter words and press "Speak It", the words will be
spoken.
Test the App in the Emulator
Android provides an emulator so you can test apps on your computer
without downloading to an actual phone. Copying the app for use on the
emulator is faster than downloading the app to a phone, so using the
emulator can speed the development process. It also allows you to test
when you don't have an Android phone handy.
Of course the emulator doesn't really make calls or texts, nor does it receive
them. It also doesn't move or turn, so it can't be used to test apps that
respond to sensor events. But for most apps, the emulator can help you test
most of its behaviors.
Installing and Running the Emulator
The emulator is part of the Android Software Development Kit (SDK). The
SDK has a bunch of code and tools for developing Android apps with Java.
We won't be programming in Java, but we'll use the same emulator that
Javaites use to test their apps.
You can install the SDK (and the emulator) on your computer using the
instructions below. For additional help, see the documentation at:
http://developer.android.com/guide
1. Download the android SDK on to your computer. If you are on a USF
computer science computer, its already there! If not, get it and make sure
your path is setup correctly.
2. Create an android virtual device (AVD). An AVD is an emulator
instance for a particular version of the phone (e.g., version 1.5).
Enter the commands below in the terminal (the > just represents the
prompt, do not type it):
> android list targets
This will show you a numbered list of the 'targets' phone versions that come
as part of your SDK. When this book "went to press" Android version 1.5
came as target #2.
> android create avd -n basic -t 2
This creates an AVD named 'basic'. The "2" corresponds to the target
number.
You only need to do the above commands once, to create your virtual
device.
3. Start the emulator:
> emulator -avd basic
'basic' refers to the name you gave to the AVD you created.
4. Download an app to the emulator:
a. In the App Inventor Component Designer window, open an app, and
choose Package for Phone | Download to Computer
In the App Inventor environment, there are two ways to create an app
once you've coded its blocks, and both appear under the "Package for
Phone" menu. The first choice is "Show Barcode" which will create the
app and display a barcode for it. You can then use a barcode scanner to
download the app on the phone.
The second choice is "Download to your computer". If you want to test
your app with the emulator, choose this option and download the app to
your computer. This will create a file with the extension .apk (an
android package) on your hard disk.
b. Open a different terminal window than the one that started the emulator
and run the install command. For instance, if your downloaded app is named
Purr.apk and is stored in your "Download" folder, use the following
command:
> adb install -r Download/Purr.apk
c. Be careful the second time you download the same app-- it will be given a
different name such as Purr(2).apk. You'll need to rename it on your
computer to "Purr2.apk" before installing it on the emulator, as the "install"
command doesn't allow parenthesis in the file names.
Chapter 3: An App Is...
This chapter is conceptual: we examine the structure of an app, beginning
with the analogy that an app is like a recipe. You will learn about eventhandlers, conditionals, and repeat loops, and be ready to delve into some
more complicated Android programming.
A App is a Recipe
The simplest apps are like recipes: the app specifies the computer
instructions that should be performed: do A then B then C:
An App is a Set of Event-Handlers
Most apps don't really fit the recipe paradigm, as most have graphical user
interfaces (GUIs) with which the user interacts. Such apps are better
described as a set of event-handlers, with recipes that are only performed in
response to some event.
Events are often user initiated: the user clicking a button or choosing an
item from a drop-down list. The "recipe" performed in response can be one
or more of the functions that the computer or phone is capable of
performing. We call the event and the functions executed in response to it
an event-handler.
Most apps will have many event-handlers: In Chapter 2, we described an
application which could be described with a single event-handler:
The app responded only to the SpeakItbutton.Click event, and it responded
by getting the text from the component TextBox1 (the text the user had
entered) and calling the TextToSpeech.Speak function with that text.
App Inventor is a language based on the event-handler paradigm.
Conceptually, nothing happens except in response to an event. You'll never
drag in function blocks into the app area without hooking them into an
event's "when-do" block. For instance, you wouldn't want blocks like:
floating in the block editor outside of an event-handler.
Okay, you're saying, I get the event-handler paradigm, but aren't there
actions that should be performed when an app runs, without waiting for an
event?
The answer is yes. For instance, a Twitter client for Android might need to
contact the Twitter web service to get the user's information as soon as the
app begins. With App Inventor, these fit into the event-handler paradigm
through the use of Initialization events. Every component has an
Initialization event that is triggered when the component is drawn on the
screen. If you want to do X when an app starts, you can hook X onto some
component's Initialization event. For instance, you could have an app
welcome the user on startup:
There is also a special Timer component that allows you to trigger responses
when a certain amount of time passes. So an app with a moving object is
characterized as an app with a timer event where the response to the event
is to move the object.
Events types include user-initiated events like button clicks, initialization
events, timer events, and external events such as the phone receiving a text
or information from a web service like Twitter arriving to the phone.
The job of the app programmer, then, is to put together blocks that say how
the phone should respond to all pertinent events.
An App Consists of Event-Handlers That Can Ask Questions
and Branch
Many responses to events are not linear recipes, but contain branches and loops. The app is
allowed to ask questions -- to query the data within it-- and determine its course based on
the answers. We say that such apps have conditional branches:
Here, when the event occurs, we perform operation A, then only perform B1
if some condition is true. If the condition is false, we instead perform B2.
Once either of the branches completes, the app proceeds back on the main
branch (C).
Conditions are questions such as "has the score reached 100?" or "did the
text I just received come from Joe". Such examples are simple; in general,
you can code any complex logic with nested conditionals and various
comparative operators.
To check conditions in App Inventor, you'll use "if-then" blocks and "if-thenelse" blocks:
You can insert any type of condition in the test slot. If its true, the blocks within the then-do
are executed (B1 in the previous diagram). If it is false, the blocks within the else-do are
executed (B2 in the previous diagram).
An App Consists of Event-Handlers That Can Ask
Questions, Branch, and Repeat
Besides asking questions and branching based on the answer, you can also
branch up in a app so as to repeat some operations multiple times. Such an
up-branch is called a loop and can be characterized with the following
diagram:
The operation A is executed, then a condition is checked. If it is true, B is
executed. Each time B is executed, the app jumps back up and checks the
condition again. This loop is repeated until the condition becomes false.
App Inventor provides two "repeat" blocks, the while-do and the foreach.
With the while-do, the condition is put into the test slot, and the operations
to repeat are put in the do slot. The foreach is specifically for repeating
operations on a list of data.
An example of an app that uses a repeat is one that texts a list of phone
numbers. The condition in such an app is "am I at the end of the list of
numbers?" and the operation is sending the message to the current person
in the list.
An App Consists of Event-Handlers That Can Ask
Questions, Branch, Repeat, and Talk to Web Services
Some apps use only the information within the device they are running on,
whether that device be a phone or a computer. But many apps communicate
with the outside world by sending requests to web services.
Twitter is an example of a web service that an App Inventor app can talk to
You'll write apps that communicate with Twitter both to gather data to
display on the phone, and to update your Twitter status. Apps that talk to
more than one web service are called mashups, and we'll explore those as
well.
Web services like Twitter provide an application programmer interface (API),
which is the protocol for how a program communicates with the service.
We'll discuss web services and APIs extensively in Chapter 6.
An App Consists of Event-Handlers That Can Ask
Questions, Branch, Repeat, Talk to Web Services, and
Remember Things
When you use apps, you expect them to remember things for you, such as
the contacts you enter into your contact manager app. Such memory that
lives even after an app is closed is called persistent data and is stored in
some type of a database:
App Inventor provides persistent memory through a special web service and
component called tinywebdb. We'll explore its use and build apps such as a
quiz application that lets the teacher maintain the list of questions.
Summary
A programmer must view an app both from an end-user perspective and
from the inside-out. With App Inventor, you'll design how an app looks and
then you'll design its behavior-- the set of event-handlers that lead an app
to behave as you want. You'll build these event-handlers by assembling and
configuring blocks representing events, operations, conditional branches,
repeat loops, web service operations, and database operations, then testing
your constructions by actually running the app on your phone. After writing
a few programs, the mapping between the internal view of an app and its
physical manifestation will become clear. When that happens, you will be a
programmer!
Chapter 4: Components,
Properties, Events, and Functions
In this chapter, you'll learn about components and modifying their
properties, as well as more on programming the event-handlers of an
application. You'll begin with a simple app that just draws a circle when a
button is clicked, then progress to an app for painting pictures on your
phone.
Components
The items that appear on the phone when an app is running-- text, input
boxes, list boxes, graphics, drawing canvases, etc.-- are called components.
There are also non-visible components representing things like motion
sensors and the Twitter web service.
The components that you can add to an App Inventor app are organized into
palettes that run along the left side of the designer:
The "Basic" palette has the most common
components. Button, Label, and TextBox are
probably the most popular: the label component is
for text the user can't modify, the TextBox is used
to get input from the end-user. The Checkbox,
RadioButton, and ListPicker are for allowing the
user to choose between options. The canvas and
image are used for graphical apps like paint
programs and games.
The other palettes have more application specific
components: Media is for playing sounds and
movies; Animation provides an image sprite; Social
provides components for making phone calls, texts,
and accessing Twitter; Sensors provide
components for sensing location and movement of
the phone; Screen arangement components are for
beautifying the user interface.
Properties
All components have properties-- the information needed about a
component. One property all components have is an ID, which is the name
of the component that appears in the Blocks editor when you program an
application's behavior. Visual components also have properties such as their
width, height, and background image.
The snapshot above shows an app with a canvas component and a button
component below it.The left-side of the designer provides a facsimile of what
will actually appear on the phone. In the snapshot, the button component is
selected in the lower left corner, so it's properties appear in the Properties
window.
The right-side of the designer is for editing properties. You can select a
component, and the properties window will switch to the properties for that
component. Be sure and hit return after editing any of the properties, or the
changes won't be recorded.
The Button component is of course very common. A Button component has
some properties common to many components (ID, BackgroundColor,
Width, Height), but it also has properties specific to buttons-- the text that
should appear on it, the font size and typeface of that text, and an optional
image for the face of the button.
Another common component is the Canvas. It defines a screen sub-area on
which the user can draw, paint, and manipulate images. It has its own set of
properties:
The Canvas component has an ID and like most visual components a
BackgroundColor, width, and height. Often, the width of a canvas will be set
to "Fill parent..." which means the canvas should span the width of its
parent, which is the screen itself. A height of 400 pixels will take most of the
phone's screen.
Because canvas components allow users to paint on them, they have a
PaintColor property. This property specifies the color of any end-user
painting that might occur.
It is important to note that component properties can be set in the
Component Designer and in the behavior editor. In the designer, you are
setting the initial value of a property-- when the app starts, the properties
are set with these initial values. In the behavior editor, you can specify
changes to properties that should occur in response to an event. You'll do
this by adding a block to set a property within some event handler. For
example, if you wanted to change the canvas PaintColor when a user clicked
a button, you could have an event-hanlder like the following:
Events
Besides having properties that record its state, each component also has a
set of events that the component can respond to. A component's events only
appear in the Behavior editor. For instance, here is a snapshot of the
component Button1's events:
At the top of the palette are the events associated with a Button. The most
popular event for a Button is, of course, the Click-- you use this block to
specify what should happen when a button is clicked. In the diagram, the
programmer has dragged a Click event block into the app area.
The Button component also has some other events to which it responds.
GotFocus is triggered when the user has touched or somehow selected a
button but hasn't yet clicked. LostFocus is triggered when the user touches
something else on the screen so that the focus is no longer on the button.
The Initialize event is common to all components. It is triggered when the
component is first drawn on the screen as the app loads. You'll use this
event to specify functions that should be executed when the app loads.
User actions like a button click are the most common type of event. But
there are other types as well:
•
•
Timer events-- The passing of time can trigger an event.
Sensor events-- a change in phone location can trigger a location
change event. The phone has an accelerometer which triggers motion
events.
•
•
Phone events-- when a call or text come in it can trigger an event.
Communication events-- when your app requests data from a web
service, an event will be triggered when that data is received.
Functions
Besides having properties and events that it responds to, a component also
has functions that can be applied to it. All components have functions to set
and get the value of each of it's properties. Above, we showed how a set
function could be used to set the value of the PaintColor property of a
canvas.
Most components also have other functions associated with them. For
instance, the Canvas component, besides it property set-get functions, also
has the following: DrawCircle, DrawLine, DrawPoint, and Clear.
If, in response to a button click, you wanted to draw a circle on the canvas,
you'd specify it by dragging in the DrawCircle function and placing it in the
Button.Click event handler:
As you can see from the DrawCircle block, the function has three open slots labeled x, y,
and r. These slots are called parameters (they're also known as arguments). A
parameter is a piece of information that the function needs to do its job. If you told a child
to draw a circle on the paper, the child might ask you: where on the paper and how big?
This is the information that is needed to DrawCircle, and in App Inventor the where of a
circle is specified with x and y coordinates, and the size with the radius r, all measured in
screen pixels (the size of one tiny dot on the screen).
If you left the x, y, and r slots empty, your app would not work-- parameters (slots) must
be filled in. So After dragging the DrawCircle operation onto the program area, the
programmer must specify actual values for the parameters. Above the blocks, there is a
mini-palette of programming components. In this case, you would click on the one labeled
Math and chooses a "123" block that represents a number. The number block can then be
placed into the slot for x with a number, say 20, entered instead of the "123". Similar blocks
can then be added for y and r:
The x and y coordinates are in relation to the top-left of the screen, with x larger as you go
right, and y larger as you go down:
........... x=300,y=0
x=0,y=0
x=1,y=1
.
.
.
x=300,y=300
Now since pixels are very small, there are actually hundreds of pixels running across the
width and the height of the phone. So if you ran this app and clicked on the button, a circle
would be drawn at x=20,y=20, which is near the top-left corner:
Summary
This chapter described the basic-building blocks of an app. Apps consist of
components, both visual and non-visual. Each component has properties
that track of the current state of the component, things such as its width
and height.
Each component also has a set of events and functions associated with its
dynamic behavior. Events are user actions and other actions that the
component responds to, e.g., a button responds to a user clicking it.
Functions are things that can happen to a component and often change its
state. For instance, the DrawCircle function modifies the state of a canvas
component by drawing a circle on it. DrawCircle, like most functions, has
parameters associated with it. When invoking a function on a component,
the programmer must specify these parameters so that the function knows
how to do its job (e.g., how big to draw the circle).
Problems
1. Program an application that draws a circle in the center of a canvas when
a button is clicked.
2. SaveAs your DrawCircle app into another app and name it CanvasFun.
Modify the program so that:
The canvas has an image as a background. You can set this in the
component designer.
• The user can click on a second button to draw a green circle at 40,40.
Note that you'll need to set the PaintColor property of the canvas in
the Click event handlers of both buttons.
• The user can click on a third button to clear the canvas. You'll need to
use the Canvas.clear block.
•
3. Program the PaintPot painting app from Google:
http://sites.google.com/site/appinventorhelp/tutorials/paintpot

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project