AppInventor Test Drive
I’ve always been sort of fascinated by drag and drop programming schemes – the sort of thing where you use little graphical blocks to represent code structures. The simplicity of it appeals to me as a teacher of programming for one thing. And I’m not alone – this idea is used in languages/environments like Scratch, which is gaining popularity in the school world right now. The problem with languages like those is that they always seem to be limited – they’re too cumbersome to write much of a program. And for teaching languages, sometimes that’s OK.
Recently, I decided to try a drag and drop language with at least somewhat higher expectations – Google AppInventor. I’d written a few little test apps using AppInventor – a clock, some tests of location, buttons and colors, and one where I could “roll” a ball around the screen by tilting the phone, and it looked like it had some real potential.
A Real Test – Life
That led me to try writing Conway’s Life. I like Life because it’s fairly easy to write (I make my AP Comp Sci students write it every year), it’s fun to look at, and yet it asks a certain amount from a language – 2 dimension arrays, a fair amount of processing, some screen redrawing, etc. I know that following a discussion of Alice, our tech support specialist, Simón, wrote a version of Life in Alice, which was painful – it required huge contortions to create a 2 dimension array of cells, and was painfully slow with even a 10 by 10 world.
So New Year’s day (yeah, I don’t really follow bowl games 😉 ) I started on it and made a fair amount of progress. Some things were actually easier than I expected. Creating a 2 dimension array as a list of lists was obvious for a Pythonista like me, and drawing the cells on the canvas was also dead easy.
Other things were not quite so straightforward, but still no real problem. For example, AppInventor doesn’t have a “counting” for loop, but only a “for each item in a list” loop. That meant to get the indexes I needed to check surrounding cells I had to use while loops and manual increment counters, but that was no big deal.
So after an evening of messing with it and looking at the documentation, I was in pretty good shape – I had a 20 by 20 “world” or cells which I could randomly set as alive or dead and I could iterate through that world and draw dots on the screen for the live cells.
Frustrations
At that point frustrations started to set in. The first frustration wasn’t really AppInventor’s fault entirely, but rather just the nature of the coding by blocks interface. I soon found the process of coding by blocks very irritating. Switch to the right block pallet, drag out the block you want, set initial values, then drag into place, rinse and repeat. It doesn’t seem so bad when you first start out, but keep in mind that everything is a block. For an if statement comparing two items, you need four blocks – the if, the comparison, and each item. When you know what you want to do, repeating that process gets very tedious very fast. In fact, I started wishing I could just open a window and type in the code. Of course, a little tedium never stopped me, so I pushed forward.
The second frustration ended up being a bit more of dealbreaker. In its current incarnation, AppInventor allots a fixed size panel for assembling blocks. As my logic got more complex, my stacks of blocks grew until they spilled off of the panel. That could have been survivable, but then I found I couldn’t edit the parts off the panel, and I couldn’t move the stack so that the bottom end would stay on the panel. You can zoom in and out, but that doesn’t change the relative size of the blocks compared to the panel.
At that point, just short of getting the rule processing finished, I gave up. I suppose I could have gone back and tried to break things down into smaller functions or pulled my stacks apart for editing and the stuck them back together, but I had simply had enough. And I had already broken things down so that the functions would have been under 30 lines of Java or so. It’s not an intrinsic limitation, of course, but for the moment it does limit the code you can write. That was the issue that made me give up, although I might have struggled on a bit if there hadn’t been one other issue.
And speed…
I also ran into a issue with processing speed. There isn’t any. Running on a Droid Incredible, it took 2-4 seconds to process and draw a 20 by 20 world. That’s pretty shocking. After I gave up on the AppInventor, I wrote a similar implementation of Life in Java and doing the same processing and drawing seemed to be nearly instantaneous, to the point that I needed a 200 ms. delay in the processing loop. (For the record, I never got to the point where the AppInventor version was looping to update, instead I was starting each generation with a button press.)
Conclusions
In spite of the fact that it failed my Life test, I find AppInventor an interesting tool. As a teacher, I can see it being useful for introducing programming to non-programmers. The blocks should make things easier to manage and understand, and the coolness factor of writing an app for your phone would boost motivation. It also is good as GUI-based “glue” for the OS, which I’m sure was one its primary purposes – you can tie several different bits of the phone’s functionality together pretty quickly. Building on this I can see a use as almost as an interface generator – whipping up a quick UI that then calls other code (maybe written in Python for the ASE?) and grabs the results. As I get time, I’m going to experiment with this.
Posted by Naomi Ceder 
Learn Python 