App Engine, Dart, and Android at DevNexus

DevNexus keynote

First, a huge thank you to the volunteer organizers and sponsors of DevNexus! The Atlanta JUG‘s annual not-for-profit conference attracted 500 mostly Java developers this year and remains one of the best values of any developer conference in the world.

I gave an update on Google App Engine for Java (see slides) and a pitch for HTML5 + Dart (see slides).

There were a lot of talks on mobile / Web development this year, including:

• JQuery Mobile framework (Raymond Camden, Adobe)
• Intro to PhoneGap (Raymond Camden, Adobe)
• Java-Powered Mobile Cross-Platform Mobile Apps with Phone Gap (Andrew Trice)
• Web vs. Apps keynote (Ben Galbraith)
• Easy Mobile Development: Intro to Appcelerator Titanium (Pratik Patel)
• What’s New in Android (Robert Cooper)
• Spring for Android (Roy Clarkson, Spring)
• Mind-Blowing Apps with HTML5 Canvas (David Geary)

All the mobile / Web talks that I attended were standing room only (70-130 people, depending on room capacity). It seems that mobile in the enterprise is red hot and enterprise apps are good candidates for Web apps vs. native. I was particularly impressed with

• Spring for Android, a nice REST client for native Android apps (video, @springandroid)
• jQuery Mobile, which lets you build simple, nicely-styled mobile Web sites with mostly HTML and CSS. The DevNexus mobile site is built with it. View source to see how easy it is.
• David Geary’s ability to wow an audience with cool Canvas demos

Thanks again to Gunnar, Vince, Sudhir, and the gang for making DevNexus such a high-quality event.

Advertisement

Is the mobile Web ready for business app developers?

Disclaimer: these thoughts are my own, not necessarily those of my employer.

I recently attended A Night with Sencha and Ted Patrick, and it got me thinking more about the mobile web. Mobile developers are clearly hungry for cross-platform solutions like Sencha and Titanium, and HTML5 promises significant cross-platform compatibility. (Action game developers, you can stop reading now because you already know that the high-performance mobile Web is not there yet. In fact, many folks I talked to last week at GDC are not even using the Android SDK, but rather the Android Native Development Kit to port games from iOS in C.)

Having said that, the mobile web for business app developers is arguably the easiest way to develop mobile apps, period, even without the side benefit of cross-platform compatibility. Why?

• Web development frameworks is a rich and mature space. There are dozens of well-established popular frameworks on both client and server for MVC, CSS, JSON, etc. We’ve been doing Web development for almost 20 years now.
• Web design tools abound. Although IDEs for native apps offer design & layout functionality, more designers are familiar with tools like Dreamweaver for HMTL+CSS. Firebug and Chrome DevTools are the ultimate WYSIWYG editors. Who wants to learn another style language when you’ve finally conquered CSS (kicking and screaming)?
• Mobile browsers, like their desktop cousins, offer great tools for design and debugging (such as Safari Web Inspector and remote debugging with Chrome Beta for Android). Tools like the Window Resizer Chrome extension let you quickly test your app in a variety of different resolutions.
• Frameworks like Sencha do a lot of the heavy lifting around RPC, local storage, dynamic UI creation & data binding. These things take a lot of work to do correctly in a native app.
• You don’t have to worry as much about device compatibility. Mobile browsers aren’t perfect and there are still compatibility gaps (see mobilehtml5.org), but most players in the ecosystem are motivated to ensure that the browser runs well on all devices. The ecosystem is probably less concerned with your apartment finder app. Provided you’re using standard browser features, the browser vendor bears much of the testing burden.

So why does anyone write native apps?

• Monetization, of course. But you can wrap your app in a WebView. As far as I know, WebViews aren’t an issue in any of the app markets with the possible exception of Apple, and according to Ted Patrick, Apple has been good about letting WebView apps in “once they get to know you and find that your app is reliable.” YMMV.
• Native look and feel. Sencha / jqTouch does a convincing job with this on iOS. I haven’t seen it on Android.
• Performance. I already mentioned this with respect to fast-moving games, but most business apps don’t use Canvas or a lot of CSS transitions. And with care, even large apps that manage a lot of data (like mobile GMail for the Web) can be snappy.
• Hardware access. With HTML5, you can get the user’s location and even the accelerometer, but not the camera. At least not yet. But for most business apps, location is all you need.
• Integration with the OS. If your app needs a ContentProvider or background Service or handles Intents, then you do indeed need a native app. Several well-known apps are succeeding with a hybrid approach, however, by using WebViews for rendering and native Services for data access. This simplifies the UI design as noted earlier while retaining other advantages of the platform.
• Finally, native apps let you write code in something other than Javascript. Of course, you could try GWT or Dart and compile to JS, too. Ironically, many of the native cross-platform solutions also require you to write your app in Javascript.

Over the next few weeks, I’ll be porting my listwidget app to native Android and mobile Web using a variety of technologies. I’ll keep you posted.

Dart presentation at AJUG

Thanks to the dedicated Atlantans who braved yet another rainy 3rd Tuesday and holiday traffic to learn about HTML5 and Dart at AJUG this week. My presentation slides are available at www.dartlang.org/slides/ along with several other decks by Dart team members. Also, I’ve just posted a 10-min screencast, Getting Started with Dart, which shows lots of goodies from the meeting, including the Dart Editor, frog server, and Dartium (Dart VM in Chrome).

Enjoy!

$() syntax for Dart

Bob Nystrom’s article Improving the DOM introduces a jQuery-like syntax for Dart, but you still have to write out document.query(…). Can anything be done to shorten it? It turns out that $ is a valid function name in Dart, so, as suggested by Jacob Richmann on misc@dartlang.org, you can define a utility function like this:

ElementList $(String query) => document.queryAll(query);

Now in your UI code, you can write simply

$('h2').first.text = 'Heading 2';

This got me thinking. What if you wanted to emulate jQuery even further, like:

$('h1').addClass('blue'); // call methods on matching elements
$('h1').each((Element e) => e.text = "Heading");
$('h1').onClick((Event v) => window.alert('hi'));

Here’s a tiny library that lets you do the above. It’s just a starter, but hopefully shows some of Dart’s potential for convenient DOM manipulation.

#library('dartQuery');

#import("dart:html");

typedef void ElementFunction(Element e);

/**
 * jQuery-like syntax returns an ElementListWrapper on which methods can be called
 */
ElementListWrapper $(String query) => new ElementListWrapper(document.queryAll(query));

/**
 * jQuery-like interface providing convenience methods which
 * operate on multiple Elements returned by document.queryAll()
 * A TODO in dart:html's Element.dart suggests that some methods
 * may eventually make it into Dart's ElementList, possibly eliminating
 * the need for a wrapper.
 */
class ElementListWrapper {

  ElementList _elements;

  ElementListWrapper(ElementList this._elements);

  // invoke a function for each element
  void each(ElementFunction f) => _elements.forEach(f);

  // add a style classname to each element
  void addClass(String className) {
    each((Element e) => e.classes.add(className));
  }

  // add a click handler to each element
  void onClick(EventListener h) {
    each((Element e) => e.on.click.add(h, true));
  }

  // allows $('#id').first
  Element get first() => _elements.first;

}

Warning: this was working earlier in frog and dartc, but something seems to have changed this afternoon. Either I broke it while reformatting for the blog or my Dart build is hosed. YMMV.

Dart dev mode cometh

As of yesterday, you can get “dev mode light” functionality in Dart using the frog compiler. The new frog “tip” will compile your Dart script to JS on the fly, so the workflow is

1. edit your Dart script
2. save
3. refresh in browser
4. see changes in 1 or 2 sec

You can already do this in the Dart Editor, but if you want the latest libs from Dart source, you’ll need to use frog instead. Here’s how to do it:

1. Install node as per the frog README
2. Pull latest from bleeding_edge
3. > cd dart/frog
4. > ./minfrog tip/toss.dart
5. Browse to a Dart sample under the http address you get back (like http://localhost:1337/client/samples/spirodraw/spirodraw.html). Navigation from the home page may not work yet, so you may have to append the path to the URL as shown here.
6. Now open dart/client/samples/spirodraw/Spirodraw.dart in the Dart Editor or your favorite text editor (probably vi).
7. Make a change (say, replace a color) and save it.
8. Hit refresh in the browser.

Note: currently, the server only serves up code under the dart source hierarchy. An option to point to an external location is coming soon.

How it works

Toss.dart is a tiny Dart script that runs an http server. When you request an html page that contains <script type=”application/dart”>, the server invokes the frog JS compiler on the fly and serves up the resulting JS inline.

You can also run frog on the command line. The compiler has been renamed from frogsh to minfrog and is checked into the Dart source repo so you don’t need to build it first. Just add the dart/frog directory to your PATH.

> cd dart/client/samples/spirodraw
> minfrog –compile-only –out=spirodraw.js Spirodraw.dart
Edit the <script> tag in spirodraw.html to point to the compiled JS
> open spirodraw.html (to launch the browser, works on Mac, anyway)

If you run frog directly like this, make sure the <script> tag in your html points to your compiled JS. If you instead run the frog toss server, the <script> tag should point to the Dart script directly with type=”application/dart”.

Coming soon

Running the frog server (toss.dart) is an easy way to see your changes quickly. Even better will be Dartium, a special Chromium build with the Dart VM integrated. With Dartium, no JS compilation is needed at all. Just edit, save, and refresh in the browser to see your changes “instantly.”

 

HTML5 and Dart @ Rich Web Experience

Thanks for all the great Dart questions today at Rich Web Experience! Slides are available at www.dartlang.org/slides/. See the Nov 16 Devoxx presentation as that’s the deck I ran today with just title page tweaks and more demos. I completely forgot to demo frog tip, which allows you to write Dart code that interacts with the DOM right in the browser tab. It’s under dart/frog/tip in the Dart source repo if you want to check it out. See the Getting Started wiki page to check out the source and build.

Dart-to-JS compilation with Frog

I’ve been playing a bit with frog, the new Dart compiler written in Dart. Although it does not yet have all the capabilities of dartc, I’m seeing very nice improvements in compilation speed and the size of the resulting JS. Here’s some data for the sunflower and spirodraw samples:

Sunflower:

• dartc: 109,612 bytes
• frog: 12,131 bytes

Spirodraw:

• dartc: 121,799 bytes
• frog: 24,320 bytes

The dartc results were obtained by running “dartc –optimize sample.dart”. The unoptimized JS is much larger.

Frog optimizes by default. I had previously built dart on my Mac as per the wiki and installed node.js per the frog README. From there, I ran:

> cd dart
> ./tools/build.py --arch=ia32 -m release
> cd frog
> mkdir bin
> ln -s ~/code/bleeding_edge/dart/xcodebuild/Release_ia32/dart_bin bin/dart_bin
> ./frog.py --js_out=frogsh -- frog.dart
> export PATH=$PATH:$PWD

Then I compiled the sunflower sample with frog:

> cd ../client/samples/sunflower
> frogsh --compile-only --out=sunflower.js Sunflower.dart

Because the samples are designed to be compiled with htmlconverter.py, I also had to modify the script tag in sunflower.html to reference sunflower.js instead of Sunflower.dart (and removed type=”application/dart”).

Frog runs about 10x faster than dartc –optimize on the command line! This is comparable to dartc performance in the editor, which has the advantage of a warm JVM (frog, on the other hand, runs in the Dart VM). The dramatic difference in code size is likely because dartc had not yet implemented dead code elimination. And, unlike dartc, frog does not support incremental compilation so was able to take an entirely different approach. Also, frog is not finished, so there may be gotchas that appears as more corner cases are implemented. But for the moment, it looks very promising.

DART slides from SenchaCon

I thoroughly enjoyed SenchaCon this week in Austin, TX, where I presented Building Modern Web Apps with HTML5 and DART. Overall, I was very impressed with the quality of the developers at SenchaCon. It was a special treat to meet Darrell Meyer and Sven Brunken, lead developers for Ext GWT. In the last year, Ext GWT has undergone a huge refactoring to do things more consistently with vanilla GWT (including Cell widgets and the Appearance pattern), and now makes advanced use of these as well as the new AutoBeans framework. I regret not meeting Darrell, Sven, Colin, and team sooner, as they are clearly sophisticated GWT developers who understand the innards of GWT quite well and have taken pains in the last year to make Ext GWT more interoperable with mainline GWT, including throwing away some of their previous work when GWT rolled out with the same functionality unanticipated. I frequently get asked about GWT consulting and am delighted to learn that Sencha has a growing professional services team knowledgeable about GWT as well as all things browser. This is not an official endorsement, but Sencha certainly appears to be one of the few companies capable of handling large GWT projects.

I had lots of fun watching developers interact with the Chromebooks on display in the Chrome booth. Many folks mentioned getting one for their kids or grandmas this Christmas (“and give yourself the gift of no tech support”). I am personally more attracted to the Chromebook than tablets, but that’s mostly because I’m so keyboard-focused (the trackpad on the Samsung Chrombook, by the way, is one of the better I’ve used apart from a Mac–I haven’t tried the Acer Chromebook yet). One place where a tablet would excel is crammed in the back of an airplane, where there’s not really enough room to open my 15″ MacBook Pro. Speaking of which, flights are much more bearable with a laptop and wi-fi. I think I’m addicted to work.

Back to Dart. I regrettably did not leave any time for questions, but was pleasantly surprised at feedback from JS developers after my talk who expressed frustration with Javascript’s lack of typing and scoping and were cautiously optimistic about Dart as a better way to build large-scale apps in the browser. I also met folks who are currently building large apps in JS by compiling from ActionScript. The fact that people are doing this (along with compiling from Java using GWT) definitely points to the need for better languages in the browser.

 

New article on DART

This InfoQ article covers some of DART’s more interesting features like snapshots and isolates.

First thoughts on Dart from a GWT developer

I consider myself more of a tools & frameworks guy than a language geek so I’m more likely to groan than gush over a new language for the Web.

However, as I dug into Dart a bit working on a couple of the samples, I have to say I caught a bit of the same fire that I felt when I first encountered Google App Engine and GWT. Dart is fun. Coming from a GWT / Java background, I found it easy to get started.

Here are a few of my favorite things about Dart so far:

1. Closures. You can register an event handler as simply as
   element.on.click.add((Event e) { window.alert('You clicked'); });
   Already, I don’t miss the clutter of anonymous inner classes.
2. Functions can be passed by reference. You can define
   myClickHandler(Event e) { ... }
   and then just write
   button.on.click.add(myClickHandler);
3. Function type aliases are a compact way to create your own callback types.
4. Optional typing. At first I thought I wouldn’t like this. However, as the Ruby community has long pointed out, Java is full of redundancy. Why write
   String[] values = new String[] {"a","b","c"};
   when
values = ['a','b','c'];
   will do?
5. Getters and setters. If you define methods using the get or set keywords, Dart will invoke them when you reference a field using dot notation. That is, some.property automatically invokes some.getProperty();.
6. Constructor initializers. If an argument has this. before it in a constructor argument list, the field with that name will automatically be initialized with that argument’s value. So a constructor that simply assigns arguments to fields can be written on one line:
   Point(this.x, this.y);
7. The Dart DOM and HTML libraries provide convenient and mostly transparent access to the DOM. Thus, you can easily use static layout in an HTML file and call document.getElementById(). The Canvas code in the Sunflower and Spirodraw samples is almost identical to the corresponding Javascript.
8. document.query(id_or_class) and .queryAll() work very similar to jQuery. These are part of the Dart HTML library, which offers convenient access to the DOM.

Thanks to all the syntactic sugar, Dart code is quite a bit smaller than the corresponding GWT app. My GWT sunflower app required very little modification to run in Dart, and the Dart code for the app went from 96 lines to 58 lines. Better still, I replaced the GWT SliderBar widget (almost 1000 lines of Java) with just a few lines of static HTML (my apologies to Firefox users: FF doesn’t support <input type=”range”> yet). Spirodraw was reduced from ~500 lines to ~300 lines, and the control panel layout is completely static HTML, which makes it easier to read.

Of course, it’s very, very early for Dart. GWT is a mature toolkit with a solid IDE (Google Plugin for Eclipse, among others), mature frameworks for RPC, MVP, etc., and a large open source community. But based on first looks, Dart is a promising new way to write Web apps. If browser vendors implement the Dart VM natively, it will rock! Chrome seems pretty likely to do this, at least. Until then, you can use dartc to produce JS for any modern browser. Hopefully, the editor (demo’d in the GOTO conf keynote this morning) will ship soon and make it easy for everyone to get started with Dart.

See also

• Official Dart language site
• Dart code samples (including ported GWT samples Sunflower and Spirodraw)
• Idiomatic Dart (great intro to Dart features)