 |
 |
||
|
Currently writing about iPhone Development, GWT, Ajax, Leopard, and Java.
Announcing iDoc: Javadoc for iPhone
Tuesday, January 29, 2008
Got an iPhone? View iDoc demo of the OpenJDK Javadoc
Want to make iPhone Javadoc? Download the iDoc source code
Want to make iPhone Javadoc? Download the iDoc source code
Every Java developer loves Javadoc. Every software developer* loves the iPhone. iDoc brings these two worlds together and generates iPhone-friendly Javadoc for your source code. Now you can browse API documentation when you want it, where you want it - all in the palm of your hand.
The cynical set might question the need for iDoc. After all, isn't Javadoc only useful while programming? And doesn't all programming happen at an eight-core workstation with a high-speed Internet connection and two 30" monitors? Surely Javadoc is best viewed when tethered to a desk.
Sadly, that view (shared by 100% of my coworkers) is mistaken, as evidenced by the following...
Top 10 Uses for iPhone Javadoc
10. Settle an API argument at the Google cafe
9. Give the observer in your pair programming team something to do
8. Study open source on the subway
7. Justify the iPhone's business use to the your IT department
6. Sound smart during an interview (requires hidden iPhone & discreet fingers)
5. Impress Blackberry users
4. View Tomcat docs while flying an F-14 Tomcat (not recommended)
3. Cheat on the Sun Java Certification test
2. Write off your iPhone in next year's taxes
1. You're writing an article about iPhone Web Development and need to create an iPhone application that appeals to developerWorks' readers
That last one happens to be reason for writing iDoc. My article, "Develop iPhone Web Applications with Eclipse", describes the creation of iDoc and covers best practices for iPhone web development. While designing the iDoc user interface, I use two slick open source tools: Aptana's iPhone Development plug-in and Joe Hewitt's iUi framework. If you're looking to create an iPhone-specific web site, I highly recommend you check them out. The article was published today on IBM developerWorks and can be found in the Open Source and Java Technology zones.
I generated iPhone-specific Java 7 Javadoc using OpenJDK and posted it online as the iDoc demo. If my Top 10 list won you over and you want to generate Javadoc for your own code base, download the v0.1 iDoc source code. I'd love to hear any feedback on the project or article. Right now the generator is very simple: it doesn't resolve links within comments or display full signatures for Java 5 generics. (So maybe it won't help you cheat on a Sun Java Certification test after all...)
* every software developer who doesn't work for Microsoft or Nokia
Dr. Dobb's Article: Hands-On Google Web Toolkit
Monday, December 17, 2007
"Hands-On Google Web Toolkit," an article I co-authored with Ed Burnette, is in this month's issue of Dr. Dobb's Journal. The article details the creation of GWTFlow, an Ajax Cover Flow Mash-up. To view your Flickr photos using this application, visit the GWTFlow Project Page.
GWT Conference Wrap-up
Sunday, December 16, 2007
I had a great time at the Voices That Matter: Google Web Toolkit conference. Many thanks to Barbara Gavin at Pearson for organizing the event.
The highlight of the week was moderating Wednesday afternoon's GWT Tools Panel. We had a great group of panelists on stage to discuss widget libraries, components, and IDE plugins (pretty much anything to make a GWT developers' life easier):
Selected quotes from the week's sessions:
The highlight of the week was moderating Wednesday afternoon's GWT Tools Panel. We had a great group of panelists on stage to discuss widget libraries, components, and IDE plugins (pretty much anything to make a GWT developers' life easier):
- Eric Clayberg - Instantiations GWT Designer
- Ray Cromwell - Chronoscope visualization, charting, and vector graphics framework
- Robert Hanson - gwt-widget library & gwt-server library, author of GWT In Action
- Fred Sauer - gwt-dnd (Drag & Drop), gwt-voices (Sound), gwt-log (Logging), gwt-game (Game engine)
Selected quotes from the week's sessions:
- "Fast is better than slow is an understatement when switching costs are low." Bruce Johnson, A Business Case for GWT
- "It's not that the dog talks beautifully, it's that the dog talks!" Josh Bloch on Ajax
- "Techniques you use to build a hut are not the same techniques you use to build a skyscraper. If you try to turn a hut into a skyscraper, it will probably fall down." Josh Bloch on the benefits of static typing and GWT
- "Turn on GZIP compression - gPokr went from 250kb to 70kb." Ryan Dewsbury, Deployment Best Practices
- "HTTP requests are the slowest thing you'll ever do in a browser." Joel Webber, GWT Performance
- "Fastest code is that which never executes." Joel Webber, GWT Performance
- "Graphic design derives from use, not from making things look pretty." Kelly Norton, GWT Usability
- "Keep the user interface stable. If it's moving around, that's bad." Kelly Norton, GWT Usability
- "This is Ajax Baby!" David Geary, GWT Cool & Useful Stuff
- "Deferred Binding allows resources to be baked into crunched-down, streamlined versions." Ray Cromwell, Deferred Binding
- "GWT libraries are value-add, not magic." Bruce Johnson, A Tour of GWT Libraries
- "The optimization is not pre-mature if it's about to affect hundreds of thousands of people." Joel Webber, Best Practices for Building Libraries
- "Design to real use cases, not someone's dreamscape." Kelly Norton, Best Practices for Building Libraries
GWT Leopard Fixed
Wednesday, November 07, 2007
Google Web Toolkit now works on Mac OS 10.5. Google's team posted a link to the unofficial test build of GWT 1.4.61 in the issue tracker (comment #46):
http://code.google.com/p/google-web-toolkit/issues/detail?id=1792#c46
According to the post, this is not an official release and is still under testing, so report any problems to GWT Issue 1792. I've tested the patch on Leopard with the Hello World, Kitchen Sink, and my GWTFlow applications. Everything works great. I had no problems launching GWT applications via shell scripts or debugging them from Eclipse. Other users report similar successes with IntelliJ JetBrains and Cypal Studio.
If you're interested in the gory details of the GWT/Leopard incompatibilities, view the history in the issue notes. The first two problems stemmed from changes in Apple's AWT subsystem initialization and Webkit's Carbon interop. The third problem was a ClassLoader bug in Leopard's 1.5 JVM when starting Java with -XstartOnFirstThread.
Many thanks to Google's Kelly Norton* and members of the GWT community for tracking this issue down.
*If you want to thank Kelly in person and hear some in-depth talks on GWT and Ajax, register for the upcoming Google Web Toolkit Conference (Dec 3-6, 2007 in San Francisco). Take $100 off registration with discount code GW-ADAM.
http://code.google.com/p/google-web-toolkit/issues/detail?id=1792#c46
According to the post, this is not an official release and is still under testing, so report any problems to GWT Issue 1792. I've tested the patch on Leopard with the Hello World, Kitchen Sink, and my GWTFlow applications. Everything works great. I had no problems launching GWT applications via shell scripts or debugging them from Eclipse. Other users report similar successes with IntelliJ JetBrains and Cypal Studio.If you're interested in the gory details of the GWT/Leopard incompatibilities, view the history in the issue notes. The first two problems stemmed from changes in Apple's AWT subsystem initialization and Webkit's Carbon interop. The third problem was a ClassLoader bug in Leopard's 1.5 JVM when starting Java with -XstartOnFirstThread.
Many thanks to Google's Kelly Norton* and members of the GWT community for tracking this issue down.
*If you want to thank Kelly in person and hear some in-depth talks on GWT and Ajax, register for the upcoming Google Web Toolkit Conference (Dec 3-6, 2007 in San Francisco). Take $100 off registration with discount code GW-ADAM.
Google Web Toolkit Conference
Tuesday, November 06, 2007
Pearson's GWT Conference is coming in less than a month! Voices That Matter: Google Web Toolkit will take place December 3-6, 2007 at the Palace Hotel in San Francisco. There's a fantastic collection of speakers:
Discount Code: Save $100!
Pearson was nice enough to provide me with a discount code to share with my readers. If you're interested in attending, please register with the following code to receive $100 off the conference price: GW-ADAM.
I look forward to meeting some of the great members of the GWT Community!
- Bruce Johnson & Joel Webber: creators of GWT
- David Geary: author of the upcoming book Google Web Toolkit Solutions: More Cool & Useful Stuff
- Josh Bloch: Chief Java Architect at Google
- Billy Hoffman: author of Ajax Security
- Kelly Norton: Google engineer & MIT Media Lab alum
- Ryan Dewsbury: creator of GPokr and author of the upcoming Google Web Toolkit Applications book
- ..and many more
Discount Code: Save $100!
Pearson was nice enough to provide me with a discount code to share with my readers. If you're interested in attending, please register with the following code to receive $100 off the conference price: GW-ADAM.
I look forward to meeting some of the great members of the GWT Community!
DTrace: Why Java 6 on Leopard Matters
Saturday, November 03, 2007
In all the hullabaloo and developer discontent about Mac OS 10.5 shipping with Java 1.5, one question has been frequently overlooked: why do we need Java 6? Why is Java 1.6 so much better than Java 1.5?
The standard answer is performance. And it's true, Java 6 smokes Java 5, especially in GUI applications. But I spend most of my time in the server world, so the Java 6 performance improvements don't impact my life that much. There are some other nice-to-haves like XML binding, better exception logging, and improved web service support - but nothing on the scale of the Java 1.4->1.5 changes.
So why does Java 6 on Leopard Matter?
DTrace!
DTrace is a kernel debugging framework created by Sun. Apple built DTrace support into Leopard and created a Garageband-like GUI around it: Instruments, aka Xray. Apple is pretty proud of DTrace (5 of Leopard's 300 new features are DTrace related), and rightfully so. The developer community is also excited about it - in his seminal Mac OS 10.5 review, John Siracusa called it "indistinguishable from magic" and said DTrace "can't help but lead to better, faster, more stable applications."
For an in depth description of DTrace, I highly recommend you read Siracusa's review, Sun's page, or the developers' blogs. If you're short on time, here's the poor man's guide to DTrace:
How developers monitored & debugged applications before DTrace:
How developers monitor & debug applications after DTrace:
DTrace and Java 6
So what does DTrace have to do with Java? DTrace allows developers to get a top-to-bottom view of application activity and see what happens across the entire stack. You can look "beneath the JVM" and understand how your application interacts with the kernel. Very cool stuff.
Unfortunately, DTrace probes are only available in Java 6 - it can't be hooked up to Java 5, which ships with Leopard. So there's this incredibly useful tool that developers are dying to use for debugging Java applications. It's sitting there in the terminal, taunting techies. But everytime they type "dtrace -l", 21,527 probes scroll by without a hotspot in sight.
Performance & parity are all great reasons to want Java 6 on Leopard, but I'm looking forward to DTrace support.
The standard answer is performance. And it's true, Java 6 smokes Java 5, especially in GUI applications. But I spend most of my time in the server world, so the Java 6 performance improvements don't impact my life that much. There are some other nice-to-haves like XML binding, better exception logging, and improved web service support - but nothing on the scale of the Java 1.4->1.5 changes.
So why does Java 6 on Leopard Matter?
DTrace!
DTrace is a kernel debugging framework created by Sun. Apple built DTrace support into Leopard and created a Garageband-like GUI around it: Instruments, aka Xray. Apple is pretty proud of DTrace (5 of Leopard's 300 new features are DTrace related), and rightfully so. The developer community is also excited about it - in his seminal Mac OS 10.5 review, John Siracusa called it "indistinguishable from magic" and said DTrace "can't help but lead to better, faster, more stable applications."
For an in depth description of DTrace, I highly recommend you read Siracusa's review, Sun's page, or the developers' blogs. If you're short on time, here's the poor man's guide to DTrace:
How developers monitored & debugged applications before DTrace:
How developers monitor & debug applications after DTrace:
DTrace and Java 6
So what does DTrace have to do with Java? DTrace allows developers to get a top-to-bottom view of application activity and see what happens across the entire stack. You can look "beneath the JVM" and understand how your application interacts with the kernel. Very cool stuff.
Unfortunately, DTrace probes are only available in Java 6 - it can't be hooked up to Java 5, which ships with Leopard. So there's this incredibly useful tool that developers are dying to use for debugging Java applications. It's sitting there in the terminal, taunting techies. But everytime they type "dtrace -l", 21,527 probes scroll by without a hotspot in sight.
Performance & parity are all great reasons to want Java 6 on Leopard, but I'm looking forward to DTrace support.
Java 6 on Leopard: Developer Discontent
Tuesday, October 30, 2007
In my Leopard First Impressions post, I mentioned that Mac OS X 10.5 ships with Java 5, not Java 6. Sun released Java 6 almost a year ago, so this is generating quite a bit of angst in the Java developer community. Is Apple abandoning Java? Is it time to install Ubuntu? Should Duke sell his iPods?
In short, no. The same thing happened in 2003: Apple shipped OS X Panther with the old version of Java (1.3). A few weeks later, however, Apple released the latest Java (1.4.1) via a software update. I'd expect the same thing to happen in this case. Eric Burke created a nice timeline showing the history of Mac OS X releases, and he agrees: it's not time to panic, Java 1.6 is coming.
From a stroll through the Java developer blogs and mailing lists, there are roughly three areas of contention:
1. Java versions on Mac are always late
2. Steve Jobs said nobody uses Java anymore
3. Apple is too secretive towards developers
All are legitimate and longstanding critiques, but none have stopped me from developing Java on a Mac these past few years (and enjoying it!). Yes, Apple takes some time to release the latest & greatest versions - but coming from the world of application servers & corporate software, I'm used to being a version or two behind. Developing on Windows or Linux would let me use Java 6 right now, but I'm not willing to put up with the trade-offs.
From a consumer standpoint, I still love the fact that a modern version of Java is shipped with every copy of OS X and integrated with the software update system. It might be a version or two behind, but it's still light years ahead of the Windows world - I shudder to think what JRE is on grandma's Acer.
The Steve Jobs comment was in the context of supporting Java applets on the iPhone. Applets have been losing to Flash and Ajax for years. Server-side Java development, however, is alive and thriving - and I'm pretty sure they're aware of that in Cupertino.
The last issue, secrecy, is par for course with Apple. I haven't been following the release of information too closely this time. In general, though, most communication is reserved for ADC members and covered under a strict NDA. Apple & Microsoft take different approaches with developers: Apple gives away XCode and charges for information, while Microsoft gives away information and charges for Visual Studio. (But really, who's keynote would you rather watch?)
Leopard is a great developer's environment right now. When Java 6 is released, it will get even better.
In short, no. The same thing happened in 2003: Apple shipped OS X Panther with the old version of Java (1.3). A few weeks later, however, Apple released the latest Java (1.4.1) via a software update. I'd expect the same thing to happen in this case. Eric Burke created a nice timeline showing the history of Mac OS X releases, and he agrees: it's not time to panic, Java 1.6 is coming.
From a stroll through the Java developer blogs and mailing lists, there are roughly three areas of contention:
1. Java versions on Mac are always late
2. Steve Jobs said nobody uses Java anymore
3. Apple is too secretive towards developers
All are legitimate and longstanding critiques, but none have stopped me from developing Java on a Mac these past few years (and enjoying it!). Yes, Apple takes some time to release the latest & greatest versions - but coming from the world of application servers & corporate software, I'm used to being a version or two behind. Developing on Windows or Linux would let me use Java 6 right now, but I'm not willing to put up with the trade-offs.
From a consumer standpoint, I still love the fact that a modern version of Java is shipped with every copy of OS X and integrated with the software update system. It might be a version or two behind, but it's still light years ahead of the Windows world - I shudder to think what JRE is on grandma's Acer.
The Steve Jobs comment was in the context of supporting Java applets on the iPhone. Applets have been losing to Flash and Ajax for years. Server-side Java development, however, is alive and thriving - and I'm pretty sure they're aware of that in Cupertino.
The last issue, secrecy, is par for course with Apple. I haven't been following the release of information too closely this time. In general, though, most communication is reserved for ADC members and covered under a strict NDA. Apple & Microsoft take different approaches with developers: Apple gives away XCode and charges for information, while Microsoft gives away information and charges for Visual Studio. (But really, who's keynote would you rather watch?)
Leopard is a great developer's environment right now. When Java 6 is released, it will get even better.
Leopard: First Impressions, Java, GWT
Saturday, October 27, 2007
I had the official Leopard release up & running on my laptop by 8:00pm EST. Short of an early FedEx delivery or mugging Walt Mossberg, I don' t think I could have done it much faster. Install was a breeze - click a few buttons, grab some dinner, and come back to a star-covered desktop.
Leopard First Impressions
Three features immediately help my productivity: Quick Look, Spaces, and Tabbed Terminal. I spent half an hour zipping through old files using Quick Look, finding documents and spreadsheets I'd completely forgotten about. Spaces & Tabbed Terminal are a developer's best friend (although I kept tripping the Spaces hot keys when RDCing to a Windows box). I'm still working on my optimal desktop configuration, with 2x2 currently in the lead.
Network sharing is great, except for a slight lag when populating the Shared list. This causes Places to appear in one spot then jump down 40 pixels. This happens in open & save dialogs, resulting in some whack-a-mole mouse action. (Anyone know how to move Places above Shared?)
Other personal highlights: faster Safari, faster Spotlight (hallelujah), unified UI. The animated iChat backgrounds will make for a nice demo to non-Mac friends. The transparent top bar is ridiculous and the tiny blue lights in the dock are hard to see, but I'll gladly put up with them to get all the other improvements.
Java on Leopard
Most of my third party tools worked like a charm: Eclipse, Smultron, Fugu, RDC. I had no problems upgrading XCode/Interface Builder. Unlike previous releases, the developer tool install does not include the Java Developer Documentation - you now have to download it separately. Log in to the ADC Member Site (free memberships work), click Downloads, then select Java for Mac OS X 10.5 Documentation. As reported earlier, Leopard ships with Java 5 (build 1.5.0_13-b05-237); hopefully they'll release Java 6 soon as a software update.
Google Web Toolkit on Leopard
Unfortunately, GWT on Leopard has some issues. If you start hosted mode, it either exits immediately or brings up the window then quickly crashes with this stack trace:
Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
at apple.awt.CGraphicsEnvironment.displayChanged(CGraphicsEnvironment.java:65)
at apple.awt.CToolkit$4.run(CToolkit.java:1259)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)...
Update 11/6/07: GWT now works on Leopard! View my latest post for more information and links to a test build.
Shrook
(Updated 10/28/07: Shrook is now compatible with Leopard!)
Announcing GWTFlow: Ajax Cover Flow photo gallery
Wednesday, October 24, 2007
View GWTFlow version 0.1
GWTFlow is a mashup photo viewer I wrote using the Google Web Toolkit (GWT) for an upcoming Dr. Dobbs article. GWTFlow uses CoverFlow-like effects for navigating through photos. Currently you can view photos from Flickr, but it's designed to support other image services like Picasa Web Albums. The article, which I co-authored with Ed Burnette, gives a hands-on look at GWT development using GWTFlow as our sample application. It is scheduled to be published in the December issue of Dr. Dobbs Journal.
GWTFlow's user interface is inspired by the .Mac Web Gallery, which was redesigned in August 2007 to make extensive use of the Prototype & Script.aclo.us frameworks. Apple's web gallery has three viewing modes: grid, mosaic, and carousel. Grid and mosaic modes are great examples of Ajax applications (if slightly resource intensive). Unfortunately, the Cover Flow-like carousel mode initially used Flash instead of Ajax*. This led to some criticism from Ajaxian readers, wishing that Apple had done the entire application in Ajax. GWTFlow, I'm proud to say, is 100% Flash-free. : )
GWTFlow uses standard GWT widgets for positioning the images and callouts to Script.aculo.us for the effects. All of the photos are just Image objects placed on an AbsolutePanel, with a little math behind the scenes to determine positioning & simulate perspective. Albums & images are retrieved via RPC calls to a Java service, which then calls out to Flickr's public API using flickrj. GWT made development & debugging a breeze, with history & cross-browser support basically coming for free. Not being a JavaScript expert, this would have been a nightmare for me to build by hand and expect it to work on Internet Explorer, Firefox, and Safari.
As a 0.1 release, there are obviously some bugs. Performance is dependent on the client machine; everything runs smoothly on my workstation, but the effects are a little jumpy on my laptop and downright ugly on my iPhone (poor 620mhz ARM processor). Larger photo albums also degrade performance. There's a known bug where some Flickr accounts aren't getting loaded properly, possibly due to spaces in the username. In future versions, I'd like to add Picasa support, more options for navigating through photos (keyboard, slider, etc), and integration with Adam Tacy's gwt-fx effects library. I'd also like to angle the images & add reflections to make it more like Cover Flow, but I'm a little worried about hurting performance.
The latest GWTFlow version should always be available at http://www.adamhoughton.com/GWTFlow. Any feedback is appreciated! Once the Dr. Dobbs article is published, I'll post a link. I should have the complete source code online soon.
* Since I first starting working on GWTFlow, it looks like Apple rolled out a version of Carousel mode that uses Ajax instead of Flash. Good for them.
Book Review: Google Web Toolkit Solutions
Wednesday, August 22, 2007
This book review was originally published on Ed Burnette's ZDNet blog. Ed received a preview copy of the book from Addison-Wesley and was kind enough to let me review it.
I'm not a very good tennis player. Yet when I signed up for tennis lessons a few months ago, for some reason I checked "Intermediate" skill level. Not Beginner or even Advanced Beginner - no, I signed up for Intermediate. So when everyone in class focused on speeding up their top spin or disguising their back spin, I'd be happy just to get the ball over the net. I settled into my role as a ball feeder to the other students, who really were Intermediate.
Which brings us to Google Web Toolkit Solutions: More Cool & Useful Stuff by David Geary & Rob Gordon. This upcoming book is written for an Intermediate audience - developers who have (at least) installed the Google Web Toolkit (GWT), created an ajax-y app, and debugged it via Eclipse. There are great resources for Beginner GWT and Advanced Beginner GWT, such as Google's online developer guide or Ed's excellent e-book and gwtPowered web site. If you are just picking up GWT for the first time, I highly recommend you start there. But when you're ready to add a little spin to your ball, GWT Solutions is a good next step.
Right from the start, this book helps lay the framework for creating production-level applications. The first chapter covers two important topics: browser history and internationalization (i18n). Neither is necessary for creating Hello World, but definitely make a difference in real world applications. Support for browser history has always been tricky in web applications, especially in the Ajax world ("please use my special previous arrow, not the big one you click everywhere else!!!"). Luckily, GWT provides integration with browser history via HistoryListeners. It's pretty painless to implement, but definitely easiest if you build it into your app at the beginning. Ditto with i18n - no developer looks forward to removing hard-coded strings from 20,000 lines of code. This book makes you eat your broccoli from the start: a couple extra minutes of work that you'll be thankful for weeks later when the boss decides it's time to translate the application into Dutch.
In addition to covering the important plumbing, Google Web Toolkit Solutions shows off a few of the framework's flashy possibilities. The fun really starts in Chapters 4 and 5, with examples of dragging viewports, iPhone-like gestures, and Yahoo Map mashups (and this is all before the halfway point of the book). These implementations are chock full of useful GWT tips, and the authors provide source code for using or extending them. But they also help illustrate one of the authors' main themes: that GWT is a feature-rich, world-class environment for developing GUIs. The fact that they could reproduce iPhone gestures with cross-browser compatibility in just a couple days of coding really shows the power of the framework. The authors encourage developers to think beyond traditional web frameworks like Struts and Ruby on Rails, and to treat GWT as a competitor (successor?) to Swing & Eclipse's Rich Client Platform.
The areas of the book I find most helpful are the instructions for real-world deployment and integration of Google Web Toolkit applications. It's easy enough to launch GWT apps from Eclipse in hosted mode, but your local playpen is probably not an ideal server for thousands of users. The last three chapters cover the nuts and bolts of deploying GWT apps to external servers and integrating with ORM frameworks like Hibernate. And as much fun as it would be to rewrite everything in GWT, upper management usually isn't keen to throw away perfectly fine code that took years to develop. GWT Solutions shows how to integrate with Struts-based legacy applications and mix-in external Javascript libraries like Script.aculo.us. (Once your GWT component is sitting on a sidebar of the company web page, it can begin its quest for site-wide domination.)
The format of the book is long code examples with follow-up discussion and tips scattered throughout. This makes for interesting reading and helped me discover quite a few new techniques. The only downside is that the discussion of some features is spread out over different examples and chapters, which made it easy to forget where I found something and difficult to focus in on help with a specific feature. The examples are written using version 1.3.3 of GWT, but the authors note areas where the upcoming 1.4 version fixes bugs and improves on functionality.
Overall, I'd recommend Google Web Toolkit Solutions. The extensive examples and tips go a long way in progressing GWT skills from Intermediate to Advanced.
I'm not a very good tennis player. Yet when I signed up for tennis lessons a few months ago, for some reason I checked "Intermediate" skill level. Not Beginner or even Advanced Beginner - no, I signed up for Intermediate. So when everyone in class focused on speeding up their top spin or disguising their back spin, I'd be happy just to get the ball over the net. I settled into my role as a ball feeder to the other students, who really were Intermediate.
Which brings us to Google Web Toolkit Solutions: More Cool & Useful Stuff by David Geary & Rob Gordon. This upcoming book is written for an Intermediate audience - developers who have (at least) installed the Google Web Toolkit (GWT), created an ajax-y app, and debugged it via Eclipse. There are great resources for Beginner GWT and Advanced Beginner GWT, such as Google's online developer guide or Ed's excellent e-book and gwtPowered web site. If you are just picking up GWT for the first time, I highly recommend you start there. But when you're ready to add a little spin to your ball, GWT Solutions is a good next step.Right from the start, this book helps lay the framework for creating production-level applications. The first chapter covers two important topics: browser history and internationalization (i18n). Neither is necessary for creating Hello World, but definitely make a difference in real world applications. Support for browser history has always been tricky in web applications, especially in the Ajax world ("please use my special previous arrow, not the big one you click everywhere else!!!"). Luckily, GWT provides integration with browser history via HistoryListeners. It's pretty painless to implement, but definitely easiest if you build it into your app at the beginning. Ditto with i18n - no developer looks forward to removing hard-coded strings from 20,000 lines of code. This book makes you eat your broccoli from the start: a couple extra minutes of work that you'll be thankful for weeks later when the boss decides it's time to translate the application into Dutch.
In addition to covering the important plumbing, Google Web Toolkit Solutions shows off a few of the framework's flashy possibilities. The fun really starts in Chapters 4 and 5, with examples of dragging viewports, iPhone-like gestures, and Yahoo Map mashups (and this is all before the halfway point of the book). These implementations are chock full of useful GWT tips, and the authors provide source code for using or extending them. But they also help illustrate one of the authors' main themes: that GWT is a feature-rich, world-class environment for developing GUIs. The fact that they could reproduce iPhone gestures with cross-browser compatibility in just a couple days of coding really shows the power of the framework. The authors encourage developers to think beyond traditional web frameworks like Struts and Ruby on Rails, and to treat GWT as a competitor (successor?) to Swing & Eclipse's Rich Client Platform.
The areas of the book I find most helpful are the instructions for real-world deployment and integration of Google Web Toolkit applications. It's easy enough to launch GWT apps from Eclipse in hosted mode, but your local playpen is probably not an ideal server for thousands of users. The last three chapters cover the nuts and bolts of deploying GWT apps to external servers and integrating with ORM frameworks like Hibernate. And as much fun as it would be to rewrite everything in GWT, upper management usually isn't keen to throw away perfectly fine code that took years to develop. GWT Solutions shows how to integrate with Struts-based legacy applications and mix-in external Javascript libraries like Script.aculo.us. (Once your GWT component is sitting on a sidebar of the company web page, it can begin its quest for site-wide domination.)
The format of the book is long code examples with follow-up discussion and tips scattered throughout. This makes for interesting reading and helped me discover quite a few new techniques. The only downside is that the discussion of some features is spread out over different examples and chapters, which made it easy to forget where I found something and difficult to focus in on help with a specific feature. The examples are written using version 1.3.3 of GWT, but the authors note areas where the upcoming 1.4 version fixes bugs and improves on functionality.
Overall, I'd recommend Google Web Toolkit Solutions. The extensive examples and tips go a long way in progressing GWT skills from Intermediate to Advanced.
