Just before I left work yesterday, I got an email with my acceptance to the Google App Inventor Beta. I was pretty excited because I have an idea for a very basic app that I want to release for iOS and Android so I can compare market sizes, downloads, propensity to purchase, etc. I’ve hesitated starting any Android development, because I work enough in Java at my bill paying job, and I saw that UIs are built using XML. App Inventor looked like it might be the ticket. You get to drag UI elements onto a workspace and then add behaviors to them. These behaviors aren’t added with code, but with visual elements. The app I intended to build at its core is a list of audio files and when you click one it plays. I figured this would be in App Inventors sweet spot.
Setup and Installation
The first instructions is make sure you have Java 6 installed and configure to run in the browser on the Mac. I hadn’t looked at the Java Preferences in a while so I didn’t realize some of the configurations existed but this wasn’t problematic. Google nicely has a page that verifies you have things setup properly. Next you have to have Java Web Start setup properly and again they have a nice page to help you verify the setup. Now my Mac is good to go.
Next were the instructions on to how to setup my phone for development. I was a little worried that I might be required to have my phone around for development, but I later came to find that there is an emulator included. I didn’t find this out until after my experiment but it didn’t really affect my judgement positively or negatively.
Web App for App Development
Now I’m off to make my first app and whoa, I am presented with a web app. This makes sense as this is Google, but this makes no sense to me because that means I am now required to be connected to the Internet to do development. I know I am connected to the Internet a large percentage of the time, but I have a productivity trick where I turn off wi-fi so I’m not distracted by email, Facebook, Twitter, et al. App Inventor prevents me from ever using this trick or going anywhere without an Internet connection to development work. Big swinging strike one.
The web app portion of App Inventor allows you to place UI elements like buttons, images, labels, etc. and to import content like audio and image files. Since I need to make a list of items I went looking for a UI element that would display a list. There is no list view element. The closest thing is a “ListPicker” that, when clicked on, displays a list of items that you can select from. The supported UI elements don’t lend themselves to making much more than a form submission app. Strike two.
A Second App for Development
After you’ve “designed” your UI you need to hookup the behaviors. This is done by launching the “Blocks Editor” which uses Java Web Start to start a desktop Java application. This is pretty weird, but Apple does the same thing with the current incarnation of its development tools (XCode 4 fixes this) so I can’t ding Google for it. Things get really weird for your typical developer when you find out that you don’t define behaviors with code but with little graphical widgets. You hook up these little blocks to define what happens when you do something like clicking on a button. There are widgets for conditional logic and for defining and setting variables.
I’ll admit it, I was tempted to dismiss this out of hand. I don’t believe in visual programming for serious development. But I stopped myself. The app I’m writing isn’t complicated and should actually be in the sweet spot for visual programming. Check swing.
Experiment in Visual Programming
Since I couldn’t find a proper list, I decided to first try playing a sound with a button. Things would get ugly if I had to use buttons for the final UI, but for getting my feet wet it would do. So I dragged out a button.click block and connected a sound.play block, fired up the app, click on the button, and voila, the sound plays. Then I clicked on the button and while the audio that was playing kept going, it started playing the same sound again. I kept pushing the button to see if I could crash the app, but I just succeeded in making a bunch of noise. Okay my first bug. My first instinct was to pull out the “if then” block and then check to see if the sound was playing before I started playing it again. Well, the “sound” block has no notion of being played, you can play, stop, pause, and resume, but how are you supposed to know which of those to do unless you know the current state of the sound. I looked at some of the documentation and it seemed that I would need to create a global variable (yeah, I should have stepped away as soon as I saw that was a fundamental programming concept) that kept the state of the sound. While I got this to work and did prevent duplicate sounds from being played, because there is no callback mechanism, I couldn’t tell when the sound had stopped playing so while the global variable might say the sound is playing, it could have already stopped playing. Strike three!
Done with App Inventor not with Android
While it was a short-lived experiment, about an hour and a half, I’m happy that Google made it easy for me to fail fast. If I had invested anymore time before running into these limitations I would have been very unhappy. I don’t think I’ll ever bother with App Inventor as I fully expect it to go the way of “Google Wave.” Google likes to do these experiments and see where they go. It seems like the developer loses interest in short order and enhancements rarely come.
I was holding out hope that App Inventor would allow me to keep from diving fully into Android development. But now that illusion has been shattered and I’ve already moved on and downloaded the SDK. Going forward, I plan to continue documenting development and business differences between iOS and Android.
