A few weeks ago I received a review copy of Ralph Roberts’ “Google App Inventor” from the ebook publisher Packt Publishing. I took a quick look at it, was favorably impressed by the sections I read, and was left with the thought that AI had great potential as an app creator for SMBs.
I got busy with other assignments, the leaves fell, and then finally I was able to spend more quality time with this guide over the Thanksgiving week. I discovered to my Googley delight that Packt’s book is a very readable overview to this newly open sourced tool.
My mock up of a field rep screen done in AI.
It is really more than just an overview. Subtitled “Learn By Doing: less theory, more results”, this AI guide more than lives up to this promise. Developers and other tech-minded individuals will immediately grok the basics of this visual environment, which implements programming concepts codelessly, using virtual computing blocks.
They can probably skip ahead to the meat of the book, chapters 5 through 8. But even the Googlescenti as well as, of course, newcomers will want to study the basics of the AI design and development environments–there’s lots of useful pointers in the first few chapters.
Google App Inventor has roots in MIT’s Open Blocks, which had the goal of lowering the threshold to programming, and going back even further, AI borrows from Seymour Papert’s Logo system. With its philosophy of treating software almost as a puzzle or game exercise, AI would be an excellent system for teaching software concepts at the secondary school level and into college, perhaps in a “programming for poets and poetesses’ course
Similar to other lightweight IDEs in this genre, AI has a web-based screen design tool that lets you rapidly draw a basic interface—buttons, text boxes, labels, canvasses, etc. The actual programming involves a separate Java-based “block builder”. I’ve seen this type of drag-and-drop tool before, but unlike others I’ve played with over the years there’s no need to code in a formal sense.
Instead you select and fit together jigsaw-shaped pieces or blocks from all the usual programming suspects–variables, if-then-else, do-while, logic, text manipulation, math–along with some useful components for accessing the web, which occasionally involves experimental but highly useful not-ready-for-prime-time gear (more on that later).
I thought I knew the AI blocks from my last dip into AI’s puzzle-piece assembly process, but I learned of a few that had been slipped in before AI was pushed into open source seas. In the Advanced Component chapter, I unearthed a list building block and a hook that allows it to pull in fields from databases.
FusionTable component makes AI useful to SMBs.
And I hit paydirt when I uncovered an experimental Google FusionTables component, which worked with the aforementioned list block, allowing AI apps to gather remote data. Also new to me was a separate Twitter component, explained in chapter 5, for building social-media aware apps.There’s also componentized access to texting on an Android phone.
What about old-fashioned communication involving email? The book shows how to tweak the ActivityStarter component to run external Android services (like email) within an AI app. Think of ActivityStarter as a cousin to perhaps the more familiar ActiveXObject, which accesses Mr. Softie’s goodies from JavaScript apps.
As I was reading, I was trying to decide whether AI was ready for small businesses. Google FusionTable support along with a component that pulls in web pages would seem to makes AI a good choice for punching out standard biz apps–say, accessing customer accounts and updating records.
Using the App Inventor emulator for testing.
Somewhere around the middle of Chapter 5, “Apps That Surf the Web”, my programming fingers got itchy, and I decided to take on a small prototype, something that perhaps a small business with field reps might actually want.
I had nothing very complicated in mind. I just wanted to see whether I could rapidly sketch out a simple cloud-based ticketing app, for a home improvement estimator or repair person. The rep logs in, sees what work tickets are available, and then updates information and perhaps takes a picture of the proposed job. Emailing the work order with a picture would be nice.
I got pretty far into wrangling these blocks to achieve my goal. I used GoogleFusion Tables as my data source, into which I added a few rows of job tasks (task number, customer contact, job description, and assigned worker). With a little help from the Fusion component and the powerful “list from CSV table” block, I was able to display this information. My work was tested on the AI emulator, which Roberts explains how to use.
So is AppInventor an SMB class product? Considering that even this modest app I was quickly hammering together would have cost major bucks from a vendor not too long ago, I’d say yes. But with some qualifications.
In my own little project, I stumbled around a bit before I realized there’s no “listbox”-like design element or a table element that can be addressed programatically. By the way, FusionTable is considered an experimental feature–it worked for me, but still. Thankfully, Roberts nicely explains the subtleties of the non-experimental, but somewhat deficient TinyWebDB component for pulling in data from web services.
In short: App Inventor is suitable for some small businesses with tech minded owners, and perhaps modest deployments in mid-size companies. AI is still evolving, so it will be interesting to check back again in another few months.
However, I would have no hesitation in recommending Packt’s Google App Inventor for anyone who wants to get the most out of Android gadgets with minimal programming effort.