Face to Face

Face to Face, a photo by diathesis on Flickr.

Back in December, we lured a black squirrel onto our porch by putting a line of nuts onto the railing so that Christophe could watch him eat.

GWT 2.0 and 2.1 at I/O 2010

The release of GWT 2.1 M2 reminded me that I hadn't yet watched the GWT presentations from Google I/O 2010, so I queued them up and have been watching them while doing some incredibly dull (but unfortunately necessary) data mapping.

GWT Testing Best Practices was of immediate interest to me, as this is something that I've put a fair amount of mental effort into as well. This is a good introduction to testing in GWT and makes several of the points that I would have as well.

In a nutshell, GWTTestCase is comprehensive, but terribly slow, so emphasize junit tests. In order to emphasize unit tests, you must be able to isolate your code from the GWT framework, in particular widget classes that use JSNI and rely on the DOM. When attempting to isolate code for testability, dependency injection is important.

In addition to that, the presentation shows some useful examples of writing testable views, talks about testing asynchronous logic, and suggests a different mode of integrating with handlers than Ray Ryan did a year ago (setClickHandler() vs. getButton()).

Architecting GWT Applications for Production is another Ray Ryan presentation which is almost a sequel to his presentation from I/O 2009. It's mostly a rough-and-ready tour of some of the changes coming up in GWT 2.1 with respect to an application framework, as well as the benefits you should expect to get from that. There are some parts of the presentation that apply to changes in GWT 2.0 as well, so even if you're not ready to get into GWT 2.1, you may learn something useful from this.

GWT's UI Overhaul talks about a bunch of the UI changes in GWT 2.0 and 2.1, from high-level layout to cell rendering. Useful to get in touch with the changes already present in 2.0 and coming in 2.1.

Measure in Milliseconds: Meet Speed Tracer is another presentation that ties in heavily to a presentation from I/O 2009. This time around, it's mostly a quick intro to why performance matters (primarily to usability), what Speed Tracer is and how it works, and then delves into specific examples.

Happily, it's these examples that are the most interesting to me, so I think the emphasis of the presentation is just right. 'The Mysterious Case of Too Much Layout' is a good example of the dangers of premature optimization, and why it's important to use a profiling tool that works with the client-side of web application development as well.

It's interesting to see they've extended this from being a primarily client-side profiler to supporting integration with AppEngine and SpringSource TC for integration on the server-side.

Faster Apps Faster talks about how the GWT compiler makes your applications faster, and how to speed up the compilation process. I've read a fair bit about the GWT compiler, but this kind of detail is interesting for people who aren't aware of how much GWT optimizes Javascript, and why that might be faster than hand-written code.

The suggestions for speeding up the GWT compilation process are good: reducing permutations, draft compilation (GWT 2.0), RAID/SSD, 64-bit JVM, etc. Apparently GWT can do a distributed build as well, although it looks like setting it up will be a little work.

Architecting for Performance with GWT has two presenters, Joel Webber and Adam Schuck. Joel's on the GWT team, and has the builder-of-framework perspective, while Adam works on Wave, and approaches it from a user-of-framework perspective.

There are some interesting examples of enhancements the Wave Team has done, like skipping the selection script during initial startup and loading data in parallel with the Javascript, as well as generalized suggestions such as batching requests to avoid sending a series of serialized data requests, or structuring your RPC interface to deliver all the data you need in a single call.

There's also more talk about measuring performance on a continuous manner, which dovetails nicely with speed tracer's new headless capabilities.

GWT + HTML5 Can Do What?! didn't really teach me anything that I expect to use anytime soon, but it was nice to see the GWT Quake port in action, and hear a little more about it. I am interested to see what comes of GWT + HTML5, and the capabilities that adds.

GWT Linkers is fairly low-level for some of you. In essence, it's targeting building something other than a classical web application using GWT, like Chrome Extensions, HTML5 Web Workers, etc. If you want to build something like this, you'll want to learn about GWT linkers, how they work, what they do, and how to write your own.

Canadian iPad Data Plans Compared

I was curious about how the iPad plans that were announced by Bell, Rogers and Telus compared, where the break points were, and so forth. So I threw together a Google Spreadsheet to do some quick math on the plans. Assuming I read the plan rules correctly, I think the lessons are as follows:

• Bell and Rogers have eerily similar plans, like one copied the other, or both took a suggestion from Apple.
• The $15 plan offered by Bell and Rogers saves $5 over the $20 plan from Telus until you use more than 250MB.
• Telus' one-price plus overage model is cheaper than Bell and Rogers' $35 plan from 250MB-800MB.
• From 800MB to 5GB, Bell and Rogers $35 plan seems to be the way to go, because you'll be paying more than $35 by the time you pay Telus for your overage.
• After 5GB, it seems like Telus' plan, which maxes out at $50, would be cheaper than paying Rogers or Bell for another $35/5GB, assuming Telus doesn't cut you off.

None of the plans spell out the edge cases:

• Telus does have fine print saying "Subject to a monthly data limit of 5GB", but they're not very clear what happens if you hit that limit.
• Neither Rogers nor Bell explains what happens when you reach your cutoff. If you run out of data on the $15 plan, can you upgrade to the $35 plan for $20, keeping the original timeframe? Can you buy a new 30-day window of $15?

Based on my iPhone data usage, if I were to acquire and use an iPad regularly, I think I could probably live within 250MB, although if I went over occasionally, it might be simpler to have Telus' plan. I suspect I wouldn't go over 800MB.

The Future of iPhone Multi-Tasking

Marco Arment on iPhone Multitasking:

One of my most common feature requests is for Instapaper to periodically download articles in the background. A lot of people forget to launch the app to let it download content before going underground or boarding a plane.

I’ve already received multiple emails from people who are excited for iOS 4’s multitasking because they can’t wait for this to finally stop being an issue, because they think Instapaper will be able to download articles periodically in the background.

It’s painful to respond, crushing their hopes, to tell them that the iOS multitasking system doesn’t allow me to do that.

The solution he proposes:

• The application gives the system an NSURLRequest and an ideal refresh interval, such as every 30 minutes, every few hours, or every day.
• iOS executes that request, whenever it deems that it should, and saves the response to a local file.
• Next time the application launches, iOS hands it an NSData of the most recent response.

It's an improvement, although it doesn't go far enough for me. There's a couple of enhancements I'd love to see.

Idle Processing

If the user isn't actively using the phone when the data is retrieved, it would be great if the application were given a chance to process that information, and possibly notify the user (even if this requires user opt-in).

For instance, if you've got a stock application and it periodically retrieves the prices of the equities within your portfolio, it would be nice if it could be set to notify you when prices cross certain thresholds, or change dramatically, rather than having to launch the application before it's given a chance to process the data.

Server Push

The polling model will do, but since the iPhone already supports push notifications, it seems like supporting push notifications whose target is an application rather than the user would also be handy. Instead of having your stock application download regular price updates, the server-side element could watch stock prices, looking for price changes of enough difference to matter, then push those prices to your application.

No Guarantees

As with the rest of Marco's solution, I think it's reasonable to give iOS some decision-making authority with respect to when and how these things are processed. I don't expect the phone to run out making regular requests to the server or sending lots of push notifications and firing up applications when the battery's already low.

The Future of iPhone Multitasking

I suspect Apple has already considered approaches like what Marco has proposed and the enhancements I'm suggesting here. I also suspect that they've decided explicitly not to take these approaches for the time being.

I can live with that. They're expanding on multitasking for iOS4, and applications will take some time to catch up. Once developers, consumers and Apple have had the chance to take iOS 4 multitasking in hand, there will be a chance to expand upon that further, and I think the proposal offered by Marco and the enhancements I'm suggesting here are good examples of the directions they can take while still taking a cautious approach to multi-tasking in iOS.