Recently I had the opportunity to spend some time taking a look at App Inventor for Android (now maintained by MIT, and originally created by Google), in order to give some lessons on how to create android applications using this system.
I admit that my expectations on the system were very low, since it targets people without any programming skill. In fact, it is actively used in learning computer programming. However, I was surprised when I started looking at it, since it allows not only to write rather complex programs, but also a nice level of abstraction.
All the programming is done with jigsaw puzzle blocks. Like in most jigsaw puzzles, the blocks have connections (sockets), although in App Inventor there are just a handful of standard connection shapes to avoid meaningless connections of incompatible pieces. The pieces use color codes to help understand their role and, some times, their type. However, the role is usually better inferred through the connection shapes. It came as a surprise that data types are not enforced through connection shapes. For example, a block that returns a number has the same connector as a block that returns text. Apparently this is so to enable automatic type conversion. For example, we can connect a block that returns a number into the socket of a block that expects a text, and the App Inventor system will automatically convert that for us.
The programming model is event driven, meaning that there is no concept of a “main” entry point. This idea is very similar to the Java SDK for Android. That means that most of the block chains start with a when block, that ignites the chain every time that a matching event occurs. Another chain starter is global variable definitions, that can be accessed from any point in the program.
Although starting all the block chains as a result from some event being fired is already a type of control flow, the system enables the program to make more complex decisions based on the state of the application within those events. For that matter, it includes a set of control flow blocks that allow to make decisions on which block chains to execute depending on conditions other than the event being fired, or also to repeatedly execute sets of blocks until some condition is met. Although I can easily imagine beginners shoot themselves in the feet when trying to use the later ones…
As I said before, the system allows to program with some degree of abstraction. Specifically, it allows to define procedures (without return value) and functions (with return value). The later are called procedureWithResult. The approach is very clean and intuitive. You first add a definition block (let’s say a procedure), including all the chains that you want to be executed, and this creates automatically a new block in your block set that allows to call that procedure from the event blocks or even other procedures. The system allows to define arguments for both functions and procedures, and the approach is very similar. You first connect a special argument block to the procedure declaration, name it, and this automatically generates a new placeholder block in the set that you can connect to the blocks within the procedure implementation.
The abstraction mechanism is so intuitive, that users (OK, at least the user I was teaching) who never programmed applications before, naturally try to create procedures and functions whenever they need to repeat complex block chains.
As a result from the lessons, Silvia Izquierdo created a chronometer application. It was her idea, and a good learning exercise, since it has the right amount of complexity to apply most of the App Inventor concepts while being feasible within hours of work. It is published in the Android Market, and it is actually useful!
If you want to give it a try to check what can be done with App Inventor, or just need a fast and simple chronometer, open this link or scan the following QR code with Google Googles or your favorite QR scanner: