In the last two installments I’ve been talking about App Inventor – Google’s rapid development environment for applications. I’ve been thinking about the potential of such tools not just for general development but also for embedded software. Although Inventor has some tie ins to Lego Mindstorms, it is anemic generally on embedded functions right now. But since Android has the potential to be an important player in the embedded space – and even if it isn’t – its interesting to see if tools like this really have a place in the toolbox or if they are mostly toys.
In the last blog, I showed you a simple program a ***a***nd although it had some quirks due to limitation in App Inventor, it was manageable with the tools provided. This time I want to look at something more substantial and see how App Inventor scales up.
Again, I’ve implemented a game (named Pushy), and again you can install it free from the Android Market. You can also see an example of it running on YouTube. The game is like a common kid’s toy where music plays and the player has to take certain actions (pressing a button or shaking the device or spinning it around) to stay in the game and earn points.
This requires reading some embedded sensors in the device and the implementation of a state machine, among other things. A much more substantial program than the last example. To make it work, the program has to implement a state machine. The device can be completely idle, waiting for an event to occur, waiting for the user to respond to an event, or terminating the game. A timer will keep the beat (and go faster as the game progresses) and the program has to handle sensor events appropriate to the current state and option settings.
Since I showed you excerpts of how programs look last time, I’ll spare you more screen shots, except for one:[Click image to view at full size]
Wow! Granted that’s zoomed out so you can see all of it. But on the other hand, almost all the blocks are collapsed. If you opened them all up it would be an even bigger mess. Although you’ve probably detected I am a bit biased on graphical development, I will be fair. A better tool would let you organize things hierarchically. Of course, that’s also harder for the neophyte to grasp, and one of the supposed advantages of App Inventor is that it enables the beginner to build applications. You can download the entire source here.
Just as before, I also ran into little glitches that would likely trip up a beginner. For example, the system has an orientation sensor that is supposed to read how the device is oriented. I’m not sure if my device lacks what the component is looking for if it is just a bug, but even though my screen will rotate, the sensor never reported any changes in orientation. If it was lacking a sensor, it should have said so. I finally settled on sensing the screen dimensions (which, of course, assumes you don’t have your screen locked to one particular orientation).
Another problem – again, especially for a tool aimed at beginners – is that you can sometimes get mysterious errors that don’t really tell you what happened. You have to read the Android log – something I’d assume the neophyte doesn’t know how to do.
There are other things that are likely to be more tool deficiencies, than inherent problems with the strategy itself. For example, it is hard to find components in the palettes when you have this many things in one program. There’s no search function, but there could be. What’s worse is variables are listed in some apparently random order (maybe the order you defined them in, I’m not sure), not alphabetically. When you have 4 or 5, that’s easy. When you have a few dozen, it is a pain. Not to mention the global variable problem I mentioned previously – everything is global, even what looks like formal parameters. Pushy was the most complex application I’d want to attempt with App Inventor. In fact, maybe it was just over the line.
So, what’s my verdict? I think the tool is interesting and fun. But other than as a toy, I’m not impressed yet. Even if Google adds to the tool to correct its deficiencies, I think that billing this as a way for non-programmers to build apps is misleading. I would hope they would focus more on its use as a rapid development tool with hooks to extend it and build more professional applications. To think that using graphical blocks means you don’t have to understand programming would be like thinking that COBOL programmers don’t need to understand programming since COBOL uses English words. Nice idea, but programmers still have to know how to program – be it in assembly, C++, Java, COBOL, or with little boxes.
That’s my opinion. What’s yours? Is this the wave of the future? Can my accountant now write Android apps? Or are our jobs safe for a few more years?