• 500 Internal Server Error – 500 Internal Server Error
• 500 Internal Server Error – 500 Internal Server Error
• 500 Internal Server Error – 500 Internal Server Error
• vvvv: a multipurpose toolkit : How To Project On 3D Geometry –
• XAML Guidelines for Creating a Composite UI –

* The most-asked question was “how do we make sure the interactions we’re using—such as long presses—are discoverable?” The only answer you CAN give to that is “by showing people how they can interact with their Android phones.” Apple did as much with their iPhone television commercials, and it seems that the Android team’s started doing likewise. But I’m getting waaaay offtopic here.

The answer was always no. Which is why it was a bit surprising to hear about App Inventor for Android, a new tool that was very quietly announced on the Google Research blog.

App Inventor for Android lets people assemble Android applications by arranging “components” using a graphical drag-and-drop-interface.

“Graphical drag-and-drop interface”? As more information surfaced (hat tip to Nat Torkington), I figured that this was too good to be true; the drag-and-drop had to be referring to the visual programming interface, which lets students write Scheme code in a UI similar to the programming environment Scratch.

Now, two months later, the help files for App Inventor are publicly available. Even if the web-based platform is only available to participating university students, you can read about it, and see what it is for yourself.

Is there a WYSIWYG designer?

Yes.

The Application Designer bears a bit of a resemblence to both Interface Builder (for the drawer of assets) and Expression Blend (in the use of properties panes).

Of course, there’s also a separate screen for visual programming. When you’re done making a UI (with components), naming the components, and then writing code (with blocks) that references the named components, your Android app is compiled on the Google servers, and you’re given a barcode to download the app to your phone. There is a barcode on the App Inventor site to test this out, and it works pretty seamlessly.

It’s large, though. Compiling Scheme into Java for the phone adds a bit of an overhead, but Google apparently plans to optimize the compiled code in future versions of App Inventor.

So, how does this help universities?

This platform was designed as a teaching tool, and a handful of universities are testing it out this year. With App Inventor, schools can easily build a curriculum with easy wins up front—students can dive in and start making things, applying what they learn to a context (mobile phones) with which they can identify.

With a visual programming environment, it’s focusing on the computer science thinking rather than the syntax, so students aren’t discouraged just out of the gate by missing semicolons and parentheses. Since App Inventor lets students download their source code, I’m guessing the visual programming environment also acts as training wheels to get into the written code later.

It’s also using Scheme, a language with a lot of love from “old school” computer scientist types for teaching functional programming skills that students often miss out on when they only program in Java.

How does this help Google?

Providing a schools with the keystone of a Freshman curriculum fits with Google’s outreach of scholarships and Summers of Code to help make better computer science graduates (who might be future Google interns, Google employees, or work on open-source software that Google uses).

The fact that it’s a platform built around, and generating interest in, their mobile phone OS certainly doesn’t hurt. As App Inventor matures, and the code optimization evolves, it could possibly be a viable development platform for commercial apps, feeding the Android market.

In complete speculation, the fact that all of the students’ code is hosted on the cloud, and the curricula at the universities might be very similar, it gives Google lots of data on the “freshman mistakes” that beginning programmers make, which Google could then theoretically analyze to improve the educational nature of the platform. (I know: pure speculation. But it’s been interesting to see what Google has done—spell checking, trend analysis, etc.—just by processing search queries.)

How does this help YOU?

App inventor isn’t ready for mass consumption yet, obviously. It’s not even open to the public. However, it does offer an interesting glimpse into web-based Android app development that novices can get into quickly without needing to download Eclipse and the Android Dev Tools. (With web-based development environments starting to crop-up—see Bespin or Coderun, for example—, and netbooks getting more popular, this may be a trend to watch.)

It also may inspire a third party to develop a solid WYSIWYG UI editor sooner than App Inventor sees wide release. (Typing that sentence, I see that the long-defunct DroidDraw has finally been updated, which is a step in the right direction.)

Overall, however, it just seems like a great tool not only for learning programming, but for sketching in hardware—getting an idea, and being able to prototype it quickly, without the usual code-writing overhead of Android programming in Java.

If you’re interested, sign up at the App Inventor site to keep in the loop.

What do you think about App Inventor?

I’m Jason Alderman, a partner-in-crime of Matthias on Android hacking projects, and I’ll be guest-blogging here every now and then. (Thanks much, Matthias.)

Google hosted I/O in San Francisco last week, an intense (see post title!) developer-centric two-day conference on hacking with Google technologies. As was the case last year, there were a lot of sessions on Android, and Google will be posting videos of those sessions to YouTube Thursday. I was lucky enough to make it out to I/O, score one of the new Ion dev phones, and sit in on nearly all of the Android sessions.

Most of the sessions were VERY engineering and dev centric… as one might expect from a Google conference. Here’s a run-down of the Android keynote and sessions, before the videos are all live on the I/O site….

The end of the Day 1 Keynote

introduced some of the new features of the forthcoming release after 1.5 (Cupcake), nicknamed “Donut.”

• The web search widget becomes a system-wide search, a la OS X or Vista’s searchbars. All that’s necessary is a “couple of lines of XML” in your app.
• The new text-to-speech (TTS) API will be multilingual, with proper accents (more on this later in the post). TTS voices aren’t perfect yet, but it was pretty darn impressive, and pushes Android devices into “universal translator” territory.
• The Android dev team has been experimenting with gestures on the touchscreen, such as writing letters with your finger to filter a contacts list. Could be handy, especially for hands-free use.

If you want to watch just the Android part of the keynote, skip to 2:34 in.

(Of course, at the end of the keynote, they gave everyone in the room an Android phone, instantly making tons of developers interested in Android development. The sessions were packed until the Google Wave sessions thankfully thinned the ranks the following day.)

Dan Morrill’s How Do I Code Thee

talked about four ways to write Android apps:

• managed code (Java/Dalvik),
• AJAX (web apps hosted inside a WebView),
• native code (C with libc and libm), and
• “Augmented AJAX” (where you provide hooks to Java code in a WebView that can be called by the JavaScript on the page).

Interesting takeaways:

• They’re working on an NDK (Native Development Kit) to complement the SDK.
• Android 1.5′s Browser is WebKit 4 (Safari 4 engine) with SquirrelFish, but the user-agent wasn’t updated (oops) to reflect this.
• The “augmented AJAX” approach uses WebView.addJavascriptInterface(), which lets you call Java or native code from within the javascript methods on a page.

All of the code from this presentation is up at http://code.google.com/p/hdict/.

Chris Nesladek’s Pixel Perfect Code

was a good presentation for people completely new to the platform. For the most part it touched on the new UI Guidelines that Chris and the Android team have posted in the past few days. If you have not yet looked at the UI guidelines, please go read this documentation. One of the things I can’t thank the Android team for enough is the work they’ve poured into cleaning up and updating the Dev Guide for 1.5. There are now detailed design guidelines for icons and widgets (with templates!) and activity and task interaction design guidance.

Interesting takeaways:

• Chris pointed out the new <android:dither=”true”> attribute can help prevent unintended gradient banding in 9-patches, so you no longer need to add noise in Photoshop.
• Toast pop-ups should be used when the user has attention on the screen, while modal dialog boxes should be used if the action is going to “harm the user” (delete e-mail, run out of battery, etc.).
• The 9-patch tool is very handy.
• The “Spare Parts” app (a dev tool that lets you tweak settings) is also very handy.

Jeff Sharkey’s Coding for Life

was helpful to both devs and Android users in general, because it noted what actions eat up your battery life.

Interesting takeaways:

• Waking up in the background is costly, so the new setInexactRepeating() can let the system bin together updates (e.g., checking for mail, news, and twitter posts at the same time) for fewer wake-ups.
• Parsing text from XML or JSON with a tree parser takes longer than using an event/stream parser, so devs should use XmlPullParser for XML or Jackson for JSON, or use something like binary Protocol Buffers.
• If you have an activity that needs to keep the screen awake, using <android:keepScreenOn=”true”> in your layout is safer, and a better practice, than an in-code wakelock.

Jeff Sharkey's battery life takeaways

Dave Sparks’ Noisy Androids: Mastering The Media Framework

was a little bit too in the weeds for me as a designer. I only caught the first half, so I’ll go back and watch it later to make sure I didn’t miss anything (I’m a completist!), but if understanding the way that Android plays video and audio is important for your app, check it out.

Chris Pruett’s Writing Real-Time Games For Android

was essentially an overview of an open-source game framework that he and a few others have been working on. If you’re curious about OpenGL2D drawing vs. Canvas drawing, and what ways you can tweak a game to make it as fast as can be, this session is for you. Look out for the open-source game, a cute side-scroller dubbed “Replica Island,” later this year. (It looked like a lot of fun to play!)

Justin Mattson’s Debugging Arts of the Ninja Masters

was a good overview of the tools in the SDK that can help you debug your app; a detailed look at how to use these tools; and general ways to approach debugging Android code. Admittedly dev-centric, but very much worth watching.

Interesting takeaways:

• logcat, traceview, and hierarchy viewer are your debugging BFF.
• Flat visual-tree hierarchies (those without a lot of nested layout elements) are better and generally draw faster, so the Android team recommends using RelativeLayouts whenever possible, instead of a slew of nested LinearLayouts. Some excessively deep UI hierarchies will actually no longer work in 1.5.

TV Raman and Charles Chen’s Eyes-Free Interaction on Android

was not just about accessibility for blind users, but about ways that accessibility techniques could help any Android user who isn’t able to keep her eyes on the screen at all times. A tremendously entertaining presentation with lots of demos and anecdotes, I especially recommend watching this if you’re interested in novel, experimental approaches to UI. All of their code is available at eyes-free.googlecode.com, and they’ve even got a YouTube channel, if you can’t wait for the session video to be posted to see what I’m talking about.On top of all this, the code methods above for text-to-speech (TTS) will be integrated into Donut’s SDK. You can start playing with TTS now, and not have to relearn new methods, with the guarantee of better-quality voices in Donut.

Romain Guy‘s Turbocharge Your UI

was also one not to miss. It focused on things like Adapters, background images, efficient screen drawing, and lots of tips on Views (pointing out objects like the useful ViewStub)—essentially, walking through, in slides, several of the Android dev team’s recent blog posts on UI. Very helpful stuff.

Finally, Romain and Joe Onarato’s Supporting Multiple Devices With One Binary,

one of the last Android sessions of the conference, is also very much worth watching, because it is not actually about what you’d think from its title! Joe and Romain talk about different device screen sizes, but then they get into a hands-on, elbow-deep-in-code walkthrough of writing your own layout (a custom ViewGroup), then checking it in to the open-source project. The fact that this presentation covered these two Very Useful Things was rather underadvertised in the I/O literature, but the speakers spread the word, and the session was a packed house.

Interesting takeaways:

• Donut will support three screen “densities,” the G1′s HVGA, the smaller QVGA, and the larger WVGA.
• The Android dev team has to use the command line tools instead of the most-excellent Eclipse plug-ins…? Not sure if this is because they’re switching back and forth between future releases and current ones, or because of some other way that the Eclipse ADT doesn’t fit their particular workflow. Will have to rewatch this video to find out.
• repo is something you should learn more about if you intend to commit code to the open-source project.

And that’s about the whole of it.

I met lots of interesting folks, saw some really interesting demos, observed ROBOT CAMERAS from a distance,…

… and overall, got motivated to start hacking my phone(s) again… which was the point of going to the conference in the first place.

• Specialists Versus Generalists: A False Dichotomy? – Pabini Gabriel-Petit posits a counter argument to Jared Spool's discussion on specialists and generalists in UX. Or maybe I like it because Gabriel-Petit pretty much describes me to a tee. (thanks to jalderman)
• MAKE: Blog: Capturing video from Android phones – Make blog post on capturing video… not surprisingly it involves something from Mark Murphy. Is there anything that man can't do? The answer is no. (thanks to jalderman)
• Google I/O – About – Google conference in May. I might should go for the Android events… looks good and pretty cheap. (thanks to jalderman)
• Google axed Android multitouch at Apple’s request – If this is true (and that's a big if), then I'm very disappointed with Apple. That kind of protectionist attitude is bad for innovation.
• Creating Alert Dialogs: Part 1 – Creating Simple Dialogs – Dialogs in Android, another tutorial brought to you by the Learning Android tutorial blog
• mandelbrot – Google Code – Mandelbrot code for Android
• zxing – Google Code – The open source bar code reading code used in such illustrious apps as ShopSavy and CompareEverywhere. Options for iPhone, Android, and Blackberry. I really need to build something that uses this.

• Gallery Tutorial with File Location – Learning Android – A tutorial showing you how to create a Gallery activity that shows all the users pictures on their SD Card. This tutorial also shows you how to fetch the physical location of the file on the card to use in your activity.
• Adding AdMob to your Activity – Learning Android – Great new blog called Learning Android has a tutorial for importing a 3rd party pay-per-click advertising library and show it in your activity
• Use DDMS to capture screen shots from device – I didn't know that I could take screenshots on an android phone using DDMS… (thanks to mgmblog)
• How to have a tiled background (in Android) – More on tiling backgrounds in Android
• Cyrket – Android Market Browser – Pretty cool… this is a web client for the Android Market so those of us without a G1 by our side can keep up with the Android app world.
• java.util.concurrent.CopyOnWriteArrayList – Android – need to look into this for taking a variable size arraylist and converting it into a float[] for the purposes of drawing things in Android
• Code Style Guide ‎(Android Open Source Project‎) – thanks to jalderman… if I'm going to be getting more into Android (and development in general), I guess I need to learn something about code style rules.

Well there is now.

I’ve put together the list, which is viewable here. You can add yourself to the list with this form.

I also cannibalized the ruby script for adding everyone on the list en-mass into your Twitter feed. You can download the script here. For further instructions, check out devinsblog.

Oh… and if you’re interested, my Twitter feed is matthiasshapiro.

And with that out of the way… start a new Android project and put the following into the onCreate method:

setContentView(new MyDrawableView(this));

Near as I can tell, if you want to do any graphics-type drawing in Android, you need to get some level of access to the onDraw method, which resides in the View class. But this means you need to create a new view class. So… create a new class and name it “MyDrawableView”. You should end up with something like this:

public class DrawableView extends View{
Context mContext;

public DrawableView(Context context) {
super(context);
mContext = context;
}
}

Now, lets add an override for our onDraw method:

@Override

protected void onDraw(Canvas canvas){
Paint myPaint = new Paint();
myPaint.setStrokeWidth(3);
myPaint.setColor(0xFF097286);
canvas.drawCircle(200, 200, 50, myPaint);
canvas.drawBitmap(BitmapFactory.decodeResource(mContext.getResources(), R.drawable.icon), 184, 184, null);
invalidate();
}

What we’ve done here is nothing more than draw a circle and place the application icon in it. The Canvas object holds all the drawing calls (read more about it here) and the draw objects are layered one on top of another in the order that they are called. The “invalidate” method at the end forces a draw on the canvas.

I would provide source code, but I really can’t do much more than recommend that you take a look at source code over at anddev.org for a similar tutorial. They also glance at some very simple procedural animation, so it is definately worth your time if you’re looking a little deeper into basic Android drawing.

• Basic and simple 2D drawing / animation :: anddev.org – Android Development Community | Android Tutorials – Simple (and short!) tutorial on 2D drawing in Android
• Getting Started in Android Game Development – Robert Green’s DIY – High level tutorial on game dev for Android
• How to have a tiled background (in an Android app) – Android Blogger has a quick piece on tiling the background in an Android app. A decent blog, but I HATE his blog design.
• G1 browser – now with Zoom Zoom Zoom – RyeBrye continues in his relentless drive to bring multi-touch functionality to the G1
• iPhone, Android Developers Flock to Flurry for Analytics (PRESS RELEASE) | AndroidGuys – An interesting looking analytics program for mobile application developers

• android.hardware.SensorListener – Android – Important for any accelerometer/orientation/magnetic field project
• Android Intent Playground 2.0 (Installation) – Diego Torres Milano has an app that lets us play around with intents right on the G1. Looks really interesting. Must investigate further.
• Android Developers Blog: Can I use this Intent? – Romain Guy talks about using Intents in Android
• Generating keypresses (in Android) programmatically – My Life With Android talks about how to generate keypresses programmatically. Interesting.
• Android Blogger: Sliding drawer, again – Android Blogger has some code that implements the sliding drawer (the widget that creates the basic menu for Android)
• A Computer Programming Blog: How to display a license agreement on your android application. – Tasos Kleisas has a tutorial for displaying a license agreement in Andorid
• Android 3D graphics and SurfaceView – Tasos Kleisas walks through a solution for SurfaceView initialization for 3D in android
• Android Developers Blog: Avoiding memory leaks – Romain Guy talks about avoiding memory leaks. Not the highest thing on my list, but important to know.
• Android Blogging Network » Blog Archive » Actual Multitouch. No Weirdness! – Looks like more basic multi-touch for the G1.

I’ve been working the last couple weeks with a small crew of developers under the name “Math In Pulbic” developing small math related products for Android. With a name like “Math In Public”, one of the first things we wanted to do was make it so that we could have text entry fields that accepted only numbers. Being somewhat new to Java, I was surprised at how easy this was.

Basically, just grab your EditText widget and add a NumberKeyListener as the default key listener:

MyEditText.setKeyListener(new NumberKeyListener(){
   @Override
   protected char[] getAcceptedChars() {
      char[] numberChars = {’1′,’2′,’3′,’4′,’5′,’6′,’7′,’8′,’9′,’0′,‘.’};
      return numberChars;
   }
});

The getAcceptedChars() method allows you to select specifically which characters you want to allow. So you could allow basic mathematical functions (+, =, -, /, *, etc) with this method as well.