Computing Distance from GPS points in App Inventor

Posted on September 30, 2010 by wolber

With App Inventor, you can create apps that use the LocationSensor to get the phone’s GPS coordinates. Some of my students have been writing apps to perform such public services as finding the closest pub from their current location. To compute this, they need to convert to GPS lat/long coordinates into a distance in miles.

To help them, I created these quick and dirty screencasts demonstrating how to find a formula on the web then convert it into an app inventor program:

PART II

Filed under: screencasts | Tagged: , , , , | 9 Comments »

Setting the Icon and Publishing an App

Posted on September 8, 2010 by wolber

Peter Evers of Amsterdam and  MobileGuru.nl has a great post describing how to change the icon of your App Inventor app. He also provides info for publishing an app on GetJar, an alternative to the Android Market.

His app is an Android version of the on-line magazine “overdose”– you can install it at: http://www.getjar.com/mobile/43526/overdose

Filed under: Uncategorized | Tagged: , , , | 1 Comment »

Idea Transformation, App Inventor, and State Farm Insurance

Posted on August 28, 2010 by wolber

How many great ideas get left as just that, some jotted down notes on a dirty napkin in an even dirtier bar? Especially with software and mobile app ideas, most get dropped with, “if we only knew a programmer.”

App Inventor changes things by lowering the barrier to app development– just about anyone, with little or no training, can take an idea and build a working Android prototype for it. Even if it’s not the most refined, complete, or beautiful app,  an interactive app can convey an app idea better than a power-point presentation or dirty napkin.

USF Student Daniel Finnegan in the App Inventor class. Photo by Shawn Calhoun (http://www.flickr.com/photos/shawncalhoun/4622481338/in/set-72157623971497647/)

Here’s an example. Daniel Finnegan was a student in my App Inventor class last spring. Daniel is a really sharp, creative guy, a creative writing major who I’m sure spends more time thinking about the human condition than cell phone apps. But with a few hours focusing on app development he came up with a great idea. He had read about the dangers of texting while driving– incredibly, something like 28% of accidents involve a phone. For his final project, he came up with an app that tries to help by eliminating your urge to text back. The app, which Daniel coined, “No Text While Driving,”  auto-responds to any arriving text with a response message such as, “I’m driving right now, I’ll text you back later.”  You turn it on when you start your drive and all your friends and colleagues know why you’re not there for them. The app even lets the user change the response for different situations—say if you’re going into a meeting or a movie– and we’ve written versions that speak texts aloud and even send the driver’s current location as part of the auto-response.

Daniel’s idea struck a chord with people and when App Inventor launched in July,  Daniel’s app was cited on the App Inventor About page. Because the app was also a nice example of the powerful Android features you can program with App Inventor,  I also developed it as a tutorial for the App Inventor site, and created a YouTube screencast on how to build it.

A few days ago, we were excited to see that State Farm Insurance had launched “On the Move”, an Android app that is quite similar to  “No Text While Driving”. State Farm distributes it free to anyone as part of State Farm’s updated Pocket Agent® for Android™ application.

Daniel Finnegan's "No Text While Driving" app

“It is our hope that this widget will prevent crashes and save lives,” said Laurette Stiles, Strategic Resources vice president at State Farm. “This new service will help drivers manage the temptation to read or respond to text messages when they are behind the wheel. We wanted to make this widget available free-of-charge as just one of the ways we’re working to keep our roadways safe for drivers.”

I don’t know that the State Farm app was inspired  by “No Text While Driving”, but its quite possible. In pondering this, I realized the incredible nature of it–an app created in an introductory computer science course,  by an English major who had never programmed a computer, possibly being the inspiration for a now mass-produced piece of software! And one that saves lives! As soon as I finish this blog, I have to email USF President Stephen Privett!

If Daniel had written a term paper on his idea,  I wouldn’t be blogging about it possibly being the inspiration for the State Farm app. But because App Inventor made it possible for Daniel to transform his idea into something tangible–well, virtual– an interactive app, it is a distinct possibility.

So cheers to Daniel, and to the App Inventor team– you have built a tool that opens up app development to a huge new pool of creative people!

Filed under: students, success stories, what is app inventor? | Tagged: , , , , , , | 43 Comments »

Success Story from Helsinki

Posted on August 25, 2010 by wolber

You’ve got a real-world problem that could be solved with software, but none of the pre-canned solutions you find quite fits your particular needs. Wouldn’t it be great if you could take something that almost fit and tailor it? And wouldn’t it be great if you could do it within hours and without hiring a programmer. This is the promise of App Inventor, and the promise of an open source where the “source” is actually decipherable.

I recently received a series of emails from a couple who needed an SMS Texting broadcast hub to organize a community event. They tailored one of the App Inventor tutorials I wrote, BroadcastHub, to solve the problem. From Myles Byrne:

My wife and i are respectively a cancer scientist and a bioinformatician who moved from San Francisco to Helsinki last year. We’re working extracurricularly with a local arts organization to try to lift a central neighborhood to a more creative and inclusive plane, especially regarding the growing immigrant population. So there is at least some relatedness to the mission of FrontlineSMS.

So we’re organizing events from now till 2012, when Helsinki is World Design Capital. The first such event is Saturday, and we’re trying to get  broadcastHub working in this way:

– a cell number on an Android (HTC wildfire) receives SMS’s from people who want to be part of the event
– each SMS receives an auto-response reply
– each number that sent in an SMS receives several more messages over the next few days – simple text broadcasts
…

I was planning to learn App Inventor at leisure. But hours of searching for commercial SMS providers doing what broadcastHub does (for Helsinki users) turned up nothing.

A few days later I received this:

Dave,

Our community raising event in Helsinki went off really well. About 1000 people came.

(almost entirely in Finnish)
http://www.facebook.com/#!/profile.php?id=100001436757236

We needed SMS broadcast capabilty for up to a thousand people over a few days. We looked at FrontlineSMS, Clickatell, and others – nothing had the right fit. Then I got my invitation to App Inventor, looked at the broadcasterHub tutorial, and realized with a shock this was the perfect solution. In a few hours I was able to modify the broadcastHub tutorial app to fit exactly our needs:

Any SMS’s sent to my phone number with the app running received an autoreply: “Text ‘beatroot’ to this number to sign up for our message list.” Any numbers sending an SMS to me containing ‘beatroot’ or ‘Beatroot’ were added to the broadcast list. But because our event was in Helsinki, the broadcast messages needed to be in Finnish. So instead of writing them myself, I told the app to take any messages sent to me from Heta and Jon, the Finnish organizers of the event, and automatically re-send it to all the numbers on the broadcast list.

It really was incredibly fast and easy to modify the broadcastHub app to do only what we needed. The app worked perfectly and can be easily re-used, modified, and shared. Having the capabilities of an android phone plugged into a graphical programming environment is an amazing experience. You’re not just learning logic, you’re learning it in the context of the social world connected to your phone.

Thanks David and Google for bringing the next level, again.
We will be using your tools for more ambitious (but still local!) projects in the near future.

Cheers,
– Myles Byrne
Heta Kuchka
Jon Sundell
: Punajuuri (Beatroot)
Helsinki, Finland

Check out their event page at http://www.punajuuri.org/

and you’ll see the invitation for people to join their broadcast list:

Elävä musiikki alkaa viiskulmasta ja jatkuu
Pursimiehenkatua pitkin kankurinkadun kulmaan.

Send “Punajuuri” SMS to +358 50 415 6799 to get live SMS updates

Cheers to Myles and team, and cheers to the App Inventor team!

Filed under: texting, what is app inventor? | Tagged: , , , , , | Leave a comment »

On David Pogue’s Review of App Inventor

Posted on August 16, 2010 by wolber

David Pouge gave a poor review to App Inventor in his New York Times article, D.I.Y. Tool for Android Needs Work . Because of pre-beta glitches, he and his son were unable to complete the tutorials. I think his frustration led to him making some off-base conclusions about App Inventor. The conclusions he came up with after a day certainly don’t mesh at all with the experience I’ve had teaching the tool for the past year.

He says:

“But make no mistake — this is programming. You can’t do it unless you’re a programmer, or have one nearby.”

He is correct in that App Inventor app development is indeed programming. But he is wrong in that you– someone who has never programmed before– can do it! Learning to write apps in App Inventor is significantly easier to learn than a traditional text language (more on this later). It lowers the bar dramatically. There are limitations, and some will be able to do more than others. But all of my students, with no prior programming experienced, got to the point that they could create apps without aid.  David’s sentence is misleading, and I hate to see it dampen people’s enthusiasm for this great tool.

App Inventor programming vs. textual programming

David asks:

“is there really such a huge difference between having to type out ‘AccelerometorSensor1.XAccel,’ as in real programming — and dragging a block bearing that name?”

This is a great and fair question, and to look at it clearly I think it really helps to be a programmer and to have taught beginners. From that vantage point, the answer is emphatically YES! In practice, there is a huge difference between typing commands and choosing from pre-defined blocks. Many of a beginner’s frustrations come from syntax errors– trying to instruct the computer with a textual language and being barked at with indecipherable messages when there’s something wrong. Of course the complex logic they face later is another barrier, but its the “syntax” frustration that turns many, many beginners away from even getting to the more fun logical problem solving. If App Inventor just gets people past that first hump, it is a great tool.

Another key is that App Inventor is an event-handling language, meaning events are first-class objects. You can directly drag out a button.click event block and then place the response to the event inside. Seems logical, and you’d think after all these years it wouldn’t be such a big deal. Unfortunately it is– you can’t even imagine how much conceptual understanding you must have to do the same in Java or Python.

David should ask a programmer who has never programmed the Android to write a Java program that prints out the readings from the Accelerometer. Hell, he could even ask one with some Android experience. See how long it takes the programmer. He’ll find that that single Accelerometer block will be replaced not with a single line of code, but an import statement, an object creation statement, manifest files, etc. The App Inventor team has done a  lot of work to package a bunch of ugly stuff inside those blocks. You have to think of it as a great code library, specially designed for beginners, and transformed into visual blocks language.

For more thoughts on why App Inventor works, check out my previous post.

No Fundamentals Mentioned

David didn’t mention any fundamental issues to back his negative conclusions about App Inventor. In a reply to a comment concerning this, he mentioned only one thing:

“I explicitly let Google off the hook for the aspects that are related to the early stage of the software, and critiqued ONLY the fundamentals. For example, this business of needing two different apps to do your development, switching back and forth. That’s not going to change when the software is final.”

In my experience, the switching back and forth between the component designer and the blocks editor is barely bothersome to most when they begin,  and completely forgotten by all soon thereafter. There are plenty of fundamental issues with learning to program, but this is not one of them.

Summary

David’s article is interesting and provocative, but my guess is that the start-up glitches and his anti-hype feelings had an undue influence on his opinions. Start-up glitches often do this– we all know the importance of first impressions. Google probably should have made sure more phones “worked” with App Inventor out of the box. Its scary to think that if David had been using a Nexus One on a Mac, his critique would have been completely different.

In any case, I’m inviting David and his son to San Francisco– I think given a day I can change his mind!

Filed under: what is app inventor? | Tagged: , , , , , | 2 Comments »

App Inventor and CS0: Strategies for Success

Posted on August 7, 2010 by wolber

Strategies for Success with App Inventor and CS0

Following are the strategies I’ve used in teaching App Inventor. My course is called “Computing, Robots, and the Web”, which qualifies as a Math core course at USF. The students are primarily humanities, science, and business students. I taught the course last Fall and Spring as part of Google’s App Inventor pilot.

Portfolios and student-owned accounts

On the first day of class, students register for Google Sites accounts and create a portfolio site. From that day on they post everything they do– from small lab assignments to large, creative projects– on their portfolio. I tell them that if its not on their portfolio, it doesn’t exist! I also assign students their own App Inventor accounts the first day of class, as opposed to using generic class accounts. These are the advantages of the portfolio approach:

  • The motivation level is higher when students know they are creating something that their classmates and others can view.
  • Students can continue to work on their projects when the course ends.
  • Students can refer back to the samples and projects they’ve done previously.
  • One outcome of the class is a portfolio of their work which they can show their family, friends, and prospective employers.
  • Its a nice way to introduce and encourage “cloud computing”.

Here’s an example of a student portfolio via USF student Mackenzie Lisenbey, and here’s a student page linking to all the portfolios.

Worked-out samples and assigned variations
Even more than with the typical CS major, CS 0 students learn better with concrete examples as opposed to abstract concepts. The students build apps following fully worked-out tutorials that explain the behaviors (blocks) each step of the way. They’re then given assignments that ask them to program variations and additions on those samples. The sample apps become part of the vocabulary for the class. I find that “it’s like the quiz example, when you step through the questions,” works better than, “you know how iteration works, just increment the index variable…”

Interesting apps and student-initiated learning
The assigned sample apps should be interesting in terms of their end-result. Samples that just illustrate an interesting computer science concept don’t work so well with this audience. Whereas CS students are motivated puzzle-solvers, the less technical student is motivated  from creating something cool or useful to the world.

You can still get to the computer science concept, just not in a top-down, concept-first manner. As the students work on interesting samples, they invariably think of ideas for customization and other apps. “Hey, Wolber, how would I do this? What if I wanted to bring in my tweets? This quiz is cool, but how would I make a multiple choice quiz?” When they are motivated to solve a real-world problem you can teach them the concepts.

Creative Projects
Some students take off immediately as soon as they begin building the sample projects. The motivation level rises dramatically, however, when I assign the first creative project, and let the students create whatever they want. For some students, this is when they really buy in.

I’ve assigned two major projects each semester. Groups of two have worked best. People say that its best to group students of similar abilities– I agree. I also require the teams to assign each member individual programming deliverables.

At the beginning of each creative project, the students are given time in class to explore their ideas and build a project page. They develop an “elevator pitch”, perform some market research, and in general build a mini-business plan and specification for the app they’re going to build. I require them to create a prototype early on and perform “user testing” with their friends and other students. This is all informal and fun, but it gives them an idea about how to take an idea from concept to reality. At some point, I’d like to develop some better lessons in this area and include readings such as Kawasaki’s The Art of the Start

Market/Studio for Publishing Apps
I created a USF Android Market for my Spring ’10 course and the students were required to submit their mid-term and final projects there. The market provides another level of motivation for students– they know that many people will visit it. The students post their projects, including a barcode that people can use to install their app, source code that can be uploaded into App Inventor for customization, and a distilled version of their “business plan”

The market is a Google Sites page with all students as “collaborators”  I provided a template for submission so that there would be some uniformity in the site, though this didn’t prove too successful. I think the potential for this is great:  I envision is a well-designed app studio that can be promoted throughout the university.

App Inventor and CS 0 Core Requirements
The requirements for a core-curriculum computer science course vary from school to school. I’ve integrated “Internet and Society” readings (e.g., The Big Switch), web design, and web 2.0 tools as part of my course. App Inventor itself is a great vehicle for teaching programming concepts, web services, GPS, web 2.0, and just about any other computing concept.
Check out my site at appinventor.org for more about teaching App Inventor.

Filed under: teaching | Tagged: , , , | Leave a comment »

Why App Inventor Works

Posted on August 6, 2010 by wolber

Sharon Michaels wrote a great review of App Inventor and like many lauds its visual, drag-and-drop interface.  In teaching App Inventor for a year, I’ve seen that it does work for non-programmers and I’ve thought a great deal about why. Here are the key features of the language:

No syntax — The blocks language eliminates the need to remember and type code. When I teach beginners textual languages, their biggest pain is syntax, the blank page, and the cryptic error messages that Python/Java/etc. provides for them. Most beginners quit because of the frustrating experience of syntax errors.

Events at the top level — Traditional programming languages  were designed when the best metaphor for a program was “a program is like a recipe– a set of instructions”.

Since the advent of the graphical user interface, programs have not been recipes, but sets of event-handlers. “When this happens, the app does this. ” is the correct conceptual model.

With App Inventor, an app is a set of event-handlers. I know this is amazing, but you can say, “when a user clicks this button, ” by dragging out a block. Compare this with Java, which requires you to understand classes, objects, and listeners in order to express an event-handler. Even if App Inventor were a textual language, its 1st order events would dramatically ease the development task.

Choose from a set of options — The components and functions are organized into drawers. You program by finding a block and dragging it into the program. You don’t have to remember how to enter an instruction or refer to a programming manual.

Only some blocks plug-in — Instead of chastising the programmer with cryptic error messages, App Inventor’s blocks language restricts the programmer from making mistakes in the first place. For instance, if a function block expects a certain type of parameter, you aren’t allowed to plug in a different type. This doesn’t eliminate all errors, but it sure helps.

Concreteness — You program components, not abstractions. When you drag out a component, an object is created and function blocks created for it. This is a problem in terms of code reuse and program size, but the concreteness is a boon for beginners and is pretty nice for experts as well.

High-level components — The app inventor team has built a great library with simplicity the main goal. There are months of programming expertise embedded in the components.


Filed under: what is app inventor? | Tagged: , , , | 5 Comments »

App Inventor: the electronic napkin for designing apps

Posted on July 20, 2010 by wolber

What excites me is the prototyping capabilities of App Inventor. Suddenly you have an electronic napkin for sketching out app ideas. Having a semi-working, interactive app is huge in terms of formulating ideas and getting them across to others. Like new terminology and abstractions, it gives people a way to talk and riff on ideas.

In a broader economic sense, it enables a bunch of smart, creative people to get involved in something that they’ve pretty much had to leave to the programmers. Consider two  twenty-somethings sitting around in their kitchen drinking a beer. They start talking and come up with a great idea for an app. One dude says, “We should really do it!”. The other says, “but who would we hire to program it.” The first dude takes a chug of beer, “Oh yeah, forget it.”

Now envision a world with App Inventor. The idea comes up and now the second dude (actually a dudette) says “this is cool. Let me get my laptop and we can build a prototype for it TONIGHT.”  They stay up building the prototype and in the process refining their ideas and getting EXCITED. Their wild idea has manifested itself into something tangible (well, virtually tangible). Not a complete, perfect app, but something that will spur them on, something they can show others and get feedback on, something they can show to angel funders!

They live happily ever after. Dudette even asks Dude to marry him, if he’ll stop working on the computer so much.

Filed under: what is app inventor? | Tagged: , , , , | 2 Comments »

On App Inventor and Lowering the Bar

Posted on July 18, 2010 by wolber

Steve Lohr of the New York Times calls it Do-It-Yourself App Creation Software. Salon’s Dan Gillmor says it is the Hypercard for mobile development. Others have put it in a more recent context by calling it Scratch for App Development. Mike Loukides of O’Reilly wrote:

This is revolutionary; they’re not trying to lower the bar, they’re throwing it away entirely.

I’ve taught App Inventor to non-programmers for a year as part of Google’s pilot program and I can say from experience that these guys are right: App Inventor will change both how apps are created, and who creates them.

Will the bar be thrown away? Not exactly, but a lot more people can get under the bar– and past the syntax barrier that has forever kept them out– to enter the app building world. Once in there are still difficult logical and design mountains to climb, but by then your hooked. Its like the barriers to learning simple conversational French have been eliminated, so that you can immediately chat with that French woman you meet at the bar. To get the girl you have to be smart and speak some poetry at some point, but now you’re motivated, a hell of a lot more motivated than if you had to go back to Cleveland and spend a year learning how to say, “Souhaitez-vous un verre de vin”

I see App Inventor creation at three levels:

Level 0, Anyone: some simple but very useful apps. These apps make use of the high-level components provided by App Inventor (Texting, LocationSensor, TextToSpeech) but require no repeat loops or complex logic. An example is this screencast of No Text While Driving, an app designed by Daniel Finnegan, a Politics major in my class at USF.

Level 1: Anyone who likes French Accents: Apps with some sophisticated logic. This level requires some hard thinking and problem solving. The blocks language has gotten you past the syntax, but now you need to piece together some repeat loops and index variables, and maybe a nested if-else. Examples of apps at this level include the Quiz and Create a Quiz tutorials I wrote for the App Inventor site. Who can do this? Just about anyone, but here you start losing some people that just don’t want to think that hard.

Level 2.0:  Apps that talk to APIs: You can get past the limitations of the visual environment by talking to back-end web services. Here you need to program in another language like Python, or know a programmer real well. App Inventor has provided a bridge with its TinyWebDB component. Basically, a programmer has to write a web service proxy that talks to the service you want and follows the App Inventor protocol. Then App Inventor programmers can create client apps that use TinyWebDB to communicate. I’ve written a few App Inventor web services using Python and App Engine, including proxies for Amazon, Yahoo Finance, and San Francisco’s NextMuniBus API (my students used this service to build their DroidMuni app with App Inventor).

The web service programming is quite simple,  for a programmer. You can download one of my samples and build an App-Inventor compliant service within minutes. But the barrier is back up, big time: most people will never write web services. But I do envision the following:

  • Some App Inventor programmers graduating to Python (or another language) because they are so motivated.
  • Organizations providing App-Inventor-compliant APIs that App Inventor programmers can then mash.
  • Collaborations, on-line or off, of App Inventor client programmers and App Inventor API builders. For instance, one of my CS 1 students worked with some CS 0 (App Inventor) students in this way to build an app using the Eventful API.
  • Yahoo-Pipes-like functionality for App Inventor

Level 2.0, the bridge to “back-end code”,is the key to App Inventor’s success. Without it, App Inventor would have been a nice educational tool. With it, App Inventor will change the world of app development.

Not sure? I’m not either, but they say you should bet on the toolmaker, along with the tool. Dan Gillmor wrote this about Hal Abelson, App Inventor co-director:

a brilliant computer scientist who also understands how app development needs to get into wider distribution, not just the coder community

This statement resonates with my experience working with Hal and the team during the university pilot and this summer. They are money, and they don’t even know it. This is why I’ve thrown my hat in with App Inventor.

Filed under: api communication, what is app inventor? | Tagged: , , , , | 1 Comment »

« Previous Page — Next Page »