Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels ▼

Al Williams

Dr. Dobb's Bloggers

Giant Android (Applications) and App Inventor

April 29, 2011

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 and 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]
Figure 1.

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?

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.