These are my links for February 20th through August 10th:
At the Android sessions at Google I/O this year, the second most-asked question* was whether or not Google would be making a WYSIWYG tool for creating user interfaces (UIs). Android does use XML to specify its UIs, after all; other frameworks with similar declarative UI languages (say, Silverlight’s XAML) have rather awesome design tools (e.g., Expression Blend). Could we expect a WYSIWYG design tool from the Goog?
![[spoiler: the answer was no]](http://huah.net/jason/imgs/theuitoolquestion.png)
* 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.
Yes.
![[Application Designer]](http://huah.net/jason/imgs/design-window-RC4.png)
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.
![[Size of the HelloPurr app is 3.47MB.]](http://huah.net/jason/imgs/hellopurrislarge.jpg)
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.
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.
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.)
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?
Hi, everyone,
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…. Continue reading ‘Google I/O was a firehose of learning.’ »
These are my links for February 3rd through February 10th:
(thanks to jalderman)These are my links for January 26th through February 3rd:
In addition to Android, I also do work in WPF and Silverlight. In that capacity, I discovered that there is a Twitter list for WPF and Silverlight developers. That list was based on a Twitter list of iPhone developers. A quick search revealed that there is no similar list for Android developers.
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.
This is a really basic, super dumbed down tutorial for 2D drawing in Android. If you’ve never done it before, this might help. If you’ve ever done it before… you already know this stuff.
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.
These are my links for January 26th:
These are my links for January 24th:
This one is really easy.
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.
