TurboManage

David Chandler's Journal of Java Web and Mobile Development

  • David M. Chandler


    Web app developer since 1994 now working for Google and residing in Atlanta with the wife of my youth and our five children. My current side project is a not-for-profit startup using GWT on AppEngine. In my "spare" time, I take pictures, preferably of Rocky Mountain National Park.

  • Subscribe

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 108 other followers

  • Sleepless Nights…

    February 2012
    S M T W T F S
    « Dec    
     1234
    567891011
    12131415161718
    19202122232425
    26272829  
  • Blog Stats

    • 303,664 hits

Getting Started with Android

Posted by David Chandler on February 7, 2012

Fibonacci Series for Android

I’ve recently joined the Android Developer Relations team at Google and am thus renaming this blog David Chandler’s Journal of Java Web and Mobile Development. Some of my favorite Google platforms are intersecting in new ways all the time (witness today’s announcement of Chrome Beta for Android ICS). Having done Web development for 18 years, I now turn my attention to mobile development, where I’m cautiously hopeful that HTML5 will make it easier in the long run to build cross-platform mobile apps.

As I started to ramp up on Android, my first thought was, “Why on earth did I ever wait so long to try this?” There’s something magical about connecting the USB cable to my phone and seeing my own work appear there. Perhaps it’s because I was an iPhone user for a few years and felt out of touch with my phone as a Java developer. At any rate, in no particular order, here are a few notes that I hope will be helpful to Android newbies like myself. If you’re an experienced Android developer, it will no doubt take me a while to catch up with you. Please feel free to post your favorite tips and tricks in the comments as we go along.

Getting Started with Android

To get started, I installed the Android Developer Tools plugin for Eclipse and started working through the tutorials on the Android Developer site. At first, I was trying too hard. To get started, you really don’t need to worry about adb or running “android” from the command line, as you can launch the AVD manager and SDK manager right from Eclipse. The tutorials are written to run apps using the emulator, but it’s easy and faster to use your actual phone:

  1. On your phone under Settings | Applications or Settings | Security, allow “Unknown sources.”
  2. On your phone under Settings | Development, enable “USB debugging.” It’s also useful to enable “Stay awake” so you don’t have to unlock the screen frequently.
  3. Plug in your phone via USB cable and choose the “Mount as disk drive” option if prompted. You should now see it listed when you run “adb devices”.
  4. In Eclipse, click Debug as | Android Application. You will be prompted to choose a device (which should show up automatically) or launch an emulator. Edit the launch configuration for each project to change the default action.
That was easy.

Creating visual appeal

A visually appealing app is a strong indication of quality and is easier than you might think to create. Android Asset Studio is an online tool that will take any image or text, size it appropriately for various screen densities, and package it so you can just drop it into your res folder. Even easier, you can do it within Eclipse: choose File | New | Android icon set and just follow the prompts.

Capturing screen shots

When you upload your app in the Android Market, you’ll need two screen shots of your app. The ADT plugin for Eclipse has a tool that makes this easy. Open the DDMS perspective and click the camera tool to snapshot a running emulator or connected device.

There’s also a third-party utility to project your phone’s screen onto your display. This is really useful when giving Android talks for your local JUG or GTUG.

Packaging your app

When you’re ready to distribute your app, you’ll need to sign the .apk file. In Eclipse, choose File | Export | Android application and it will walk you through the process, including creating a keystore. To test your app on your phone, run “adb -d install path/to/your.apk” on the command line. The -d option selects connected devices. You can also use -e to target the emulator. You may get a warning that you need to uninstall the old version of your app first. If you do, just run “adb -d uninstall package_name,” where package_name is the root Java package associated with your app, like com.turbomanage.

Publishing to the Android Market

Go to the Android Market, sign up for an account, and upload your artifacts. Your app will be scanned for malware and should show up in an hour or two. It took me only a few days to get ramped up enough to create my first app, which I packaged and published in an afternoon. It really couldn’t be easier. When you publish, do pay attention to your application version and SDK version. Note that target SDK version is distinct from minimum SDK version, and both are important for maximum compatibility across devices.

Introducing Fibonacci Series for Android

For my first app, I took a shallow dip into my creativity pool and came up with a Fibonacci Series calculator. There are several Fibonacci apps (mostly involving stock trading) already, but I just needed a simple calculator for when I’m on a dinner date with friends and suddenly can’t remember one of the five-digit Fibonacci numbers, for example. Regular readers of this blog will recognize the related sunflower illustration thrown in for good measure. The app gave me a good opportunity to use simple TextViews, a custom view for the Canvas on which to draw the sunflower, and practice handling orientation changes (go ahead, turn it sideways and see what happens). Oh, and I incorporated a tabbed interface and the menu button also. There are lots of tutorials on these topics online already, so I think for now I’ll just point you to the source code.

As a newcomer from GWT, I found the concept of an Activity very familiar (GWT’s Activities and Places are deliberately modelled after the Android). I ran across only a few gotchas. One that I remember is that overriding onConfigurationChanged() in your Activity does not guarantee you will get notified of all orientation changes because it doesn’t get called if another app is in the foreground when the orientation changes. But no matter, you can check every time in the Activity’s onCreate() method. It also took me longer than it should have to figure out how to hook into the phone’s menu button (just override onCreateOptionsMenu()). The tutorials on the Android Developer site as well as the new Android Training section under Resources cover most of the beginner topics quite well.

For new developers, the single most useful page on the site is this one: Common Tasks.

And don’t forget the android tag on Stack Overflow, which Google officially supports.

Once again, here’s the source.

Enjoy!

Oh, and if you’re wondering about all the status bar icons in the screen shot above, yes, I really did publish the latest version to the Android Market while on the plane, listening to music, with USB cable connected. Android development is pretty addictive…

Posted in Android | 3 Comments »

Dart presentation at AJUG

Posted by David Chandler on December 22, 2011

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!

Posted in Dart | Leave a Comment »

Will it play in App Engine page moved

Posted by David Chandler on December 21, 2011

Just noticed that the old “Will it play in App Engine Java” page has moved to the appengine wiki. This was necessary because Google Groups deprecated groups pages. It’s also very out of date.

Posted in AppEngine | 1 Comment »

$() syntax for Dart

Posted by David Chandler on December 14, 2011

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.

Posted in Dart | 4 Comments »

Dart dev mode cometh

Posted by David Chandler on December 9, 2011

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.”

 

Posted in Dart | 4 Comments »

HTML5 and Dart @ Rich Web Experience

Posted by David Chandler on November 30, 2011

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.

Posted in Dart | 2 Comments »

HTML5 and GWT @ Rich Web Experience

Posted by David Chandler on November 30, 2011

Here are the slides from my HTML5+GWT talk at Rich Web Experience:

Building Mobile and Enterprise Apps with HTML5 and GWT

The talk is very similar to the combined GWT and Dart talk I gave at SenchaCon last month, which you can find at www.dartlang.org/slides/.

Posted in Google Web Toolkit | 5 Comments »

Google Plugin for Eclipse now open source

Posted by David Chandler on November 16, 2011

This is pretty big news for the GWT community and should make it easier for GWT frameworks to build tooling for Eclipse. Witness JBoss, who was working on GWT integration even before the announcement. Congrats to the GPE team!

Posted in Eclipse, Google Web Toolkit | Leave a Comment »

Dart-to-JS compilation with Frog

Posted by David Chandler on November 2, 2011

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.

Posted in Dart | 2 Comments »

DART slides from SenchaCon

Posted by David Chandler on October 28, 2011

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.

 

Posted in Dart, Google Web Toolkit | 2 Comments »

 
Follow

Get every new post delivered to your Inbox.

Join 108 other followers