The Brief: user stories before blocks
Professional developers do not open the code editor first. They decide who the user is and what the user needs to be able to do. That list is what you build against — and what you test against.
App description
You talk to a friend, Nalini, about your plan to make an app and ask her whether she has any ideas. While she's not exactly sure, she suggests that starting by learning how to use some capabilities of mobile devices might provide inspiration.
“Hey, we could take pictures with the device camera and use the touch screen to mark them up first. It'll just be a digital doodle at first, but I could see it being used for…”
In this activity you will create an app that allows the user to take a picture and then draw on the picture in the user interface. For replay value, the screen clears whenever the user shakes the device. Each of these items is an app feature — a specific thing the app may do.
User stories
Three user interactions define this app:
- An app event that allows a user to take a picture when they touch a button.
- Another event that allows a user to touch the screen (swipe gesture as input) to draw on the picture.
- A final app event that allows shaking the device to clear all the outputs.
Initial backlog breakdown
The user needs to be able to:
- Push a button to take a picture
- Draw on the picture
- Clear the picture
- Change the color they draw with (if time permits)
- Change the line width (if time permits)
Design terminology. Start a TEMP chart (Term, Example, Meaning, Picture) in your notebook. Add every bolded vocabulary word from this activity as you meet it. Begin with user story, user centered, and user interface.
Match the design terminology
Drag is not needed — pick the term each definition describes.
Reflection
Record three ideas for apps that could leverage the device's camera or the ability to draw on images. These ideas can be original or existing apps. Share as directed by your teacher.
Designer View: build what the user sees
App Inventor has two views. The Designer is where you add components — tidy packages of functionality for an input or an output. The Blocks view is where you program how they behave.
Which view?
| If I am making adjustments to what the user sees, I should use the… | Designer View |
| If I am changing what will happen in the app, I should use the… | Blocks View |
Anatomy of the Designer
- Palette — drawers of components by category (User Interface, Media, Sensors…).
- Viewer — the phone screen you drag components onto.
- Components — the list of everything you added; select, rename, or delete here.
- Properties — options for whichever component is selected.
Throughout this course, images of App Inventor are shown in the Classic theme. If your
App Inventor looks different, open Settings › User Interface Settings and choose
Classic style. Newer themes do not label the panels.
Practice studio — Designer
Drag components out of the drawers and onto the phone. Everything you add here becomes available in the Blocks view later — exactly like the real thing.
Palette
Viewer
Components
Properties
Checkpoint
- Button added from the User Interface drawer
- Canvas added from the Drawing and Animation drawer
- Camera added from the Media drawer (non-visible)
- Button
Textproperty changed toTake a Picture!
Blocks View: program the behavior
An event is something that happens — a button click, a finger drag, a shake. An event handler is a block of code that listens for that event and then responds to, or “handles,” it.
Events and outputs
Inputs or events cause the program to take action. Events usually produce outputs the user can experience — a picture, a new screen. Sometimes the program produces no noticeable output but changes something internally.
Most components listen to more than one event, so most components have more than one event handler block. Grab the right one.
Event handlers and abstraction
Abstraction hides the complexity of a task by concealing the details, making it easier to focus on the relevant steps.
App Inventor hands you a Camera component with all of its properties and behaviors already defined. You never write the code for how to take a picture. Each block is doing a lot of work for you behind the scenes.
The four blocks you need first
| Block | Location | Description |
|---|---|---|
call Camera1.TakePicture | Camera drawer | A block that calls a procedure that lets the user take a picture. |
set Canvas1.BackgroundImage to | Canvas drawer | Sets the background image of the canvas whenever the event handler the block is placed in is activated. |
when Camera1.AfterPicture | Camera drawer | Handles the event after the user takes the picture. |
when Button1.Click | Button drawer | An event handler that executes the blocks within it whenever Button1 is clicked. Be sure to grab the when Click handler and not one of the others. |
If you cannot find a block described in the procedures:
- Verify that the component is in the Designer Components panel.
- If the component is not in the Designer view, add it there, then return to the Blocks view.
- Find that same component in the Blocks view to grab the blocks associated with it.
Practice studio — Blocks
Open a drawer, drag blocks into the workspace,
and snap them together. The phone on the right runs your blocks — if you wire it wrong, it behaves
wrong, just like the real companion app. Hover an orange argument
to grab its get block.
Blocks
Viewer
Blocks snap together like puzzle pieces.
Blocks you create from an event handler may only be used inside the handler you pulled them
from. The image block is a variable connected to when Camera1.AfterPicture. Other
event handlers do not have access to the camera's image, so this variable works only with the camera's
specific event handler.
Debugging & version control
Debugging means looking at your code piece by piece to determine why the program is doing something different from what you intended it to do. Be patient with yourself, and seek help from those around you.
Connect and test
- Connect › AI Companion in the App Inventor browser window.
- Launch the companion app on the mobile device. The browser displays a six-character code.
- Enter the six-character code and select Connect with code, or scan the QR code.
- Touch the button as input, and
- Receive the output of an image on the screen after you take the picture.
Steps for debugging code
- Describe what you expected versus what actually happened.
- Isolate the smallest piece that misbehaves — one event handler at a time.
- Read the blocks out loud, in order, as the device would run them.
- Check the Designer: does every block's component actually exist?
- Check for empty sockets and blocks sitting outside a handler.
- Change one thing, retest, and note the result.
Save this list — you will use it all year.
Debugging. Title a page “Debugging.” Use it all year to record information and tips about debugging your code — including every bug you fix below.
Bug hunt
Each app below is broken. Read the blocks, decide what the device would actually do, and pick the fix.
Iteration and version control
After testing and debugging, you have a functioning app — and you want to keep it that way while you add
features. Saving your project as a new version with a new name minimizes how much you have to fix later.
Use Projects › Save project as…
Naming matters, because it helps you review previous versions of your code as you develop toward the final app. Discuss naming conventions with your teacher.
Procedures and arguments
You already wrote procedures. Every event handler you built is a procedure — a group of statements that performs some task. Now look at how information gets into one.
Procedures, methods, and functions
Through built-in procedures you see abstraction — the removal of smaller details to focus on the bigger details. The terms are often used interchangeably depending on the language you are writing in. A function returns a value; a procedure does not necessarily have to.
| Term | Definition |
|---|---|
| Function | Something that takes a bunch of inputs and returns one or more values. |
| Procedure | A small component of a computer program that may contain one or several specific algorithms to accomplish a certain task. |
| Method | Similar to functions in text-based languages like Python. Some languages use function, method, and procedure interchangeably; block-based programming does not differentiate between them. |
Arguments are local variables
The orange blocks known as arguments are specific to a particular event handler and are stored in that event handler. They are local variables that can only be used within that handler.
The details of how that information is accessed and stored are abstracted, so all you do is drag in the value the argument is holding. You do not need to know how they work — just that they hold information you need. In future activities you will define your own variables.
Canvas1.Dragged gives you four numbersTo draw a line, the procedure needs the x and y coordinates on the screen. The app needs to
know where the user first touched (prevX, prevY) and
where they touch next (currentX, currentY). Plugging those
get blocks into call Canvas1.DrawLine passes the information to the procedure as arguments.
Check your understanding
Optional extension — three challenges
Your teacher will direct you about which additional features to add. Use iterative saves and the naming convention outlined by your teacher so you never lose a working app.
Challenge A — Pen size
Add a slider to adjust the width of the line that draws as you drag.
Needs: a HorizontalArrangement
(drag it in first), a Label, and a Slider. Set the arrangement's Width to
Fill parent. Watch the argument the Slider.PositionChanged handler offers.
Save with an A on the end of the name.
Challenge B — Color change
Add buttons that change the color of the pen.
Needs: a HorizontalArrangement and
three Buttons inside it. Set each button's Shape and BackgroundColor, and
rename each one (e.g. ButtonBlue) so you can keep track. Save with a B.
Challenge C — A fourth button
Add a fourth button with a custom color.
Instead of a color block, build the color from a make color list of three numbers: red, green, blue. Change the values to see what colors you can make. Save with a C.
Keep exploring
Explore the other components and choose one feature to try in this app. See the App Inventor Component Reference for the full list.
Back up and share your work
- Show your MIT App Inventor screen and demonstrate the app on a mobile device.
- Android or iOS:
Projects › Export selected project (.AIA) to my computer. - Android only:
Build › App (save .APK to my computer). - Quick reference image: in the Blocks view, right-click a blank area and choose
Download Blocks as Images. Share the image with your teacher.
Wrap-up: exit ticket, ethics, and conclusion
Answer the exit ticket first, then capture your conclusion responses. Everything you type here can be copied into your Computer Science Notebook at the end.
Exit ticket
Ten questions. You get one retry on anything you miss.
Ethical scenario
Imagine an app designed to help people share information about ride-share drivers or passengers that have made them feel unsafe. The benefits are clear from the description, but this app could also have negative societal impacts.
Conclusion questions
Take your work with you
Copy everything you typed into one block of text for your notebook or your class LMS, or print this page as a PDF.