Event-based Languages (and phones) are the key to learning

When the user clicks the button,…

Computers were first designed to compute, to allow men with oversized glasses to write “recipes”, to take a large set of numbers and compute some formulaic result. Computers still crank through formulas, of course, but their purpose has expanded far beyond computing things. It is doubtful that Alan Turing and his generation envisioned Facebook, Google glass, or even people carrying around their computers tweeting camera-shots and using GPS to find where they’re going.

Though the reason we use computers has changed dramatically, our coding languages have not. Popular languages like Python and Java are still based on the “recipe” model with a “main” program of sequential instructions. This recipe model makes sense for computing things, but is a poor fit for modern software, which is much more like an event-response machine, reacting to the user touching a button, location information coming in from a GPS satellite, or a text arriving from a friend.

For experienced programmers, the dissonance between the language they use and the software they’re trying to build isn’t that big a deal. But for beginners it makes learning to code really difficult. Want to program an app in which clicking a button causes the button to turn red? Should be simple right? It’s not. In Java, for instance, you first create an object called a Listener, then register that listener with the user interface object (the button), then program the handler to…you get the picture! Its not a first hour or even first day exercise, and you have to understand many things before you can do it. This difficulty is the reason why most people’s initial engagement with coding is to display “hello world” on the screen or at most to add up a list of numbers. Couple these less than motivating initial results  with the fact the computer is barking error messages at them, and it is no wonder most don’t stick with the field very long.

The problem is that events, like the user clicking a button or dragging the mouse, are not first-class objects in our popular programming languages. The events must be constructed by the programmer, and its not easy to do.

Event-handling languages like App Inventor are different– “when event do” is a first-class construct in the language. Here’s how you program the”click a button to turn it red” example in App Inventor:

Such a program takes about 30 seconds to learn. You just look in a drawer of button events and function blocks, drag them into your app, and plug them together. Here’s another sample:

Can you tell what it does? It’s basically an answering machine for texts. You turn the app on when you get in your car, or enter a meeting, and it auto-responds to any incoming texts. Pretty powerful, but easy to specify, almost as easy as telling Siri, “when someone texts me send an auto response”.

Now this texting code is a bit more complicated than the Button.Click sample. You have to understand that “number” is the phone number of the person who sent the text and know how to refer to it to set the “PhoneNumber” of the out-going message. But it is still a first day or even first hour exercise.

Here’s one last example, for you game lovers out there. Let’s say you want to animate a flying saucer and have it move horizontally across the screen? Coding animation is really hard, right? Well, here’s the App Inventor code:

Screen Shot 2013-12-11 at 6.58.24 AM

The code is, again, a little more complex than a Button.Click. You need to understand that the Clock.Timer is like an alarm clock, and that there is another value somewhere specifying how often the timer should go off.  And you need to understand that the “X” coordinate of the flying saucer is its horizontal location, and that you can change it by setting it to “itself”+ 5.

The beauty of an event-handling language like App Inventor is that the events– the things that your app can respond to, are pre-defined. They’re organized into little drawer. You just click on a drawer, find what you’re looking for, and drag it into your app. Then you drag response (function call) blocks in to specify what should happen when the event occurs. The fundamental software behavior– event-response– is the fundamental construct in the language.

Now you’re probably asking, “why aren’t all language like this?” Well, they should be. Part of the problem is just the incredible inertia that exists in software engineering. People teach what they know, and programming language design became passee sometime in the 1990s. But it is also about control. Programming languages are designed for maximum flexibility– so you can build anything and make as general-purpose a program as possible. To enable reuse of code, abstraction is worshiped; concrete simplicity is disdained.

App Inventor was designed by a group of really smart Googlers whose target audience was  beginners, so they favored concreteness over abstraction. The language provides you with a fixed set of concrete event and response blocks. You can program just about anything that can occur on a phone or tablet, but not everything. And you cannot define a new component, you are at the mercy of the engineers who develop App Inventor. Such inflexibility drives programmers crazy, they want total control of the machine, and are wary of “toy” systems that don’t give them that. Unfortunately, the cost of this total flexibility– of having an abstract Listener object that you can program– is that learning to code is a horror story!

If you are new to coding and want to give it a try, go to ai2.appinventor.mit.edu. You can also try the App Inventor Hour of Code intro lessons or the I Have a Dream video tutorial at appinventor.org. You can be programming your Android phone in 10 minutes!

Obama says, “Don’t just play with your phone, program it!”


As part of code.org‘s terrific “Hour of Code” week, Barrack Obama has called out youngsters to learn how to code. There are some great learning tools at code.org, including Blockly, Scratch, and App Inventor. The initial “Angry Birds” code challenges involving programming character’s movement through a maze is a great beginning to programming. My twelve-year-old son Tomas had a blast and learned a lot of programming (if, loops, complex logic, etc.).

App Inventor Answers the President’s Call

Learning to program a maze is great, but App Inventor stands out as a tool that actually lets you program your phone and build all kinds of apps. You can build apps that auto-respond to text messages or an app that with a single click sends “thinking of you” to a list of phone numbers; You can build apps that remember where you parked your car, or how far you’ve run. And you can build meaningful, media-rich apps such as an “I Have a Dream” app that plays the speeches of MLK and Malcolm X. Most importantly, you can share your apps with your family and friends because App Inventor works on the open Android platform.

The “I Have a Dream” screencast tutorial is below. If you have an Android, click on the link and follow along, and you can have a cool app downloaded within minutes. And you’ll learn enough programming to build your own apps of various types– the sky is the limit!

For more, see appinventor.org and  MIT’s Hour of Code lesson.

AppInventor.org updates

AppInventor.org has been updated with the following:

1. Conceptual roadmap — find what you want to learn! This page should be helpful to students and teachers designing courses.

2. App Inventor 2  tutorials and video screencasts.
The first batch is ready, many more to come…

  • “I Have a Dream” soundboard app tutorial for beginners. video text
  • Paintpot, the classic tutorial now in App Inventor 2  video text
  • Math Blaster, an app that generates and checks arithmetic, lots of iteration! text

3. Course-in-a-box updatesDesigning an App Inventor course? Make use of the materials here, including these additions:

In the next few weeks we’ll be rolling out more new content, especially for App Inventor 2, and we’ll have a new design!
Dave

National Science Foundation Grant for Teaching App Inventor

The National Science Foundation has awarded a $565,836 grant in support of mobile programming education with App Inventor. Its
a TUES Grant, which stands for Transforming Undergraduate Education in Science, Technology, Engineering, and Mathematics.

The project involves Wellesley College, MIT, Trinity, U. Mass, Lowell, and the University of San Francisco (my school). We’ll be building on-line, Khan-academy-like tools for App Inventor, with the goal of teaching computational thinking to beginners, especially non-CS-students. Many thanks to Franklyn Turbak of Wellesley, who led the proposal process, and Hal Abelson of MIT who leads the App Inventor project. Here are all the Project leads:

Hal Abelson, MIT

Lyn Turbak, Wellesley

Ralph Morelli, Trinity

Fred Martin, UMass-Lowell

David Wolber, USF

 

Learn App Inventor with Video Tutorials

App Inventor Book available at Amazon

Check out appinventor.org/projects. I’ve added video screencast lessons and other teaching materials to complement the original App Inventor tutorials.  These are the tutorials  originally written for the App Inventor site and then refined for the book App Inventor: Create your own Android Apps (which I co-authored with App Inventor creators Hal Abelson, Ellen Spertus, and Liz Looney). I’ve also added some new video tutorials not found in the book, one for an arcade shooting game (see above) and one for a note-taking app.

The video is best watched full screen HD, and each tutorial is split into 5 minute portions.

 

Testing SMS Texting apps with app inventor

Image

two emulators used to test an app inventor app

I stumbled upon a solution to a long-standing issue I’ve had with App Inventor which is how to test, without a phone, apps that process SMS texts in some way. The issue is important because not all schools and developers have phones, but texting apps are fun and important so you’d like to be able to develop and test them even if you don’t have an Android.

So I was trying to build a screencast for the No Texting While Driving tutorial, and I  wanted to be able to test/show the app on-screen. So I googled (go figure) and found out that the emulator id# serves as a phone number (go figure again, and why didn’t I try this before). So the solution is to open multiple emulators (click new emulator in app inventor twice). Connect one of them to app inventor and run the app on it, then use the normal texting app on the other to text the emulator running the app (with phone number something like 5554)

So now you can build/test SMS texting apps without owning an Android phone. I’m happy!

 

Computing Distance from GPS points in App Inventor

With App Inventor, you can create apps that use the LocationSensor to get the phone’s GPS coordinates. Some of my students have been writing apps to perform such public services as finding the closest pub from their current location. To compute this, they need to convert to GPS lat/long coordinates into a distance in miles.

To help them, I created these quick and dirty screencasts demonstrating how to find a formula on the web then convert it into an app inventor program:

PART II

Why App Inventor Works

Sharon Michaels wrote a great review of App Inventor and like many lauds its visual, drag-and-drop interface.  In teaching App Inventor for a year, I’ve seen that it does work for non-programmers and I’ve thought a great deal about why. Here are the key features of the language:

No syntax — The blocks language eliminates the need to remember and type code. When I teach beginners textual languages, their biggest pain is syntax, the blank page, and the cryptic error messages that Python/Java/etc. provides for them. Most beginners quit because of the frustrating experience of syntax errors.

Events at the top level — Traditional programming languages  were designed when the best metaphor for a program was “a program is like a recipe– a set of instructions”.

Since the advent of the graphical user interface, programs have not been recipes, but sets of event-handlers. “When this happens, the app does this. ” is the correct conceptual model.

With App Inventor, an app is a set of event-handlers. I know this is amazing, but you can say, “when a user clicks this button, ” by dragging out a block. Compare this with Java, which requires you to understand classes, objects, and listeners in order to express an event-handler. Even if App Inventor were a textual language, its 1st order events would dramatically ease the development task.

Choose from a set of options — The components and functions are organized into drawers. You program by finding a block and dragging it into the program. You don’t have to remember how to enter an instruction or refer to a programming manual.

Only some blocks plug-in — Instead of chastising the programmer with cryptic error messages, App Inventor’s blocks language restricts the programmer from making mistakes in the first place. For instance, if a function block expects a certain type of parameter, you aren’t allowed to plug in a different type. This doesn’t eliminate all errors, but it sure helps.

Concreteness — You program components, not abstractions. When you drag out a component, an object is created and function blocks created for it. This is a problem in terms of code reuse and program size, but the concreteness is a boon for beginners and is pretty nice for experts as well.

High-level components — The app inventor team has built a great library with simplicity the main goal. There are months of programming expertise embedded in the components.


The Programmers are coming!

Google has targeted education with App Inventor, but its clear that the tool will attract major interest from programmers and web designer/developers. Programmers see the potential because of the the TinyWebDB component which allows an App Inventor apps to communicate with web services.

Early adopter Dean Sanvitale has already built an RSS reader app and a Flickr explorer app. He did this by modifying a sample “tinywebdb-compliant” web service to create http://tinywebdbplus.appspot.com/ then writing an App Inventor client that talks to it. The pic on the right is his RSS reader app running in an emulator.

For more on how to build App Inventor (tinywebdb-) compliant web services, as well as sample source code, see http://appinventor.org/talking-to-an-api and http://appinventor.googlelabs.com/learn/reference/other/tinywebdb.html (The sample is written in Python/App Engine)

Good work Dean and, programmers, rev your engines!

App Inventor at Community Colleges

I just finished teaching a 5-day App Inventor workshop at MPICT, a conference for computer science and IT community college teachers in the Northwest US. App Inventor was a hit– many of the instructors plan to incorporate App Inventor in their courses.

What I learned is our community colleges are in good hands: what a fantastic group of teachers! I learned a great deal about teaching in general and teaching beginning CS courses specifically.

Follow

Get every new post delivered to your Inbox.

Join 63 other followers