Until now.

I made the plunge the other day and upgraded my phone to iOS.  I wasn’t expecting huge improvements as a 3G user.  My phone is slower and isn’t as cool as the 3Gs or the 4G – I get that.  But I figured folders would be worth it, as well as a few other things (naming your own playlists, etc.)

The upgrade took forever, and I began playing around.  Yeah, nothing too exciting – made some folders, noticed the new accounts view in Mail.  Whatever.  I go to switch my desktop (not lock screen) wallpaper.

Nope, can’t do that.  Not on the iPhone 3G at least.  This struck me as odd – I’m not really feeling that having desktop wallpaper would really challenge the performance capabilities of the device, but c’est la vie.  I also noticed that when paired up with my bluetooth car radio that I can now control the volume on the iPhone itself.  You couldn’t do this before.  I didn’t think much of it – it felt like change for change sake to me.

Then things started to go sideways.

I’m listening to my iPod while I’m reading some Mail, and a terrible song comes on.  I double tap the home button to get the iPod controls – the window pops up.  But low and behold – the controls aren’t there.  Nor is the the song information.  My forehead wrinkles a bit, and I move on.

Later, I’m at work and listening to music again.  A coworker comes up and taps my shoulder – so I double tap the home button on the now locked iPhone to get the iPod controls on the lock screen.  They appear – and everything seems fine, save the fact that the Play/Pause button is the Play arrow.  Note, my music is playing.  I touch the play button, and the music indeed pauses – but the iconography doesn’t change.  It’s still the play button.  I touch the play button again, and play resumes.  My eye twitches a bit, and I turn to my coworker with an iPhone 3GS.  He had moved to iOS recently, as well.

Have you had this issue?

Now, the first problem doesn’t exist on the 3GS because they’re privileged enough to get the fancy new iPod controls while not in the iPod app itself.  But the lock screen issue didn’t exist for him.  In fact, his experience seems fantastic.

On the way home, there’s a daily podcast I listen to, and I usually stream it via iTunes because I don’t sync with my PC at work.  So I start it up as I typically do.  At a traffic light, a text message from my wife comes in – and I go in to quickly reply (yeah, I know, shouldn’t do that in the car).  I click reply.

The audio stops.

At first I think it was just some unique glitch.  So I go through the sequence again to see if it’s a reproducible item.  What do you know – it is.  Apparently in iOS, or at least on the iPhone 3G – you can’t stream audio and do anything else at the same time.

It could be a regression, but I’m betting my coworker doesn’t have these problems.

Dear Apple – I like your products.  I have an iMac at home, have had iPhones since the first generation phone, I even own an Apple TV.  It’s a bit disconcerting though that you’ve shown such disregard for current users of your products though in your furor to maximize upgrade revenue.  iPhone 2G users I know have always been patient with the fact that for various reasons, you won’t offer them all of the software upgrades that you offered us in the past.  I can appreciate being in their boat now being two revisions behind in hardware.  But it’s unacceptable that the overall quality of your software would be secondary for users of older devices.  I’ll have to think long and hard before I can convince myself that I can trust you enough to invest additional dollars into your impressive line of mobile products.

That indignation seemed to find an ally in Google.  At Google I/O 2010, there was much ballyhoo about open standards and open platforms.  There was direct mention of Flash being an important part of the internet at large, and Adobe fans seemed to have found a Mao for their Ho Chi Minh.  Outside of sharp words, Adobe had very little ammunition in this battle.  Adding Google as a key ally seemed at least to justify their position – even solidify a dynamic place in the marketplace for media delivery.

The politics of this war are less about openness of platform, however.  Apple’s exclusivity practices in the past few decades have been largely about limiting competition and thus maximizing margins from a niche product.  When the product suffered and competition increased in the early 90′s from Microsoft and others, Apple was only able to recover not by changing their strategy but by executing on the fundamentals that allowed this strategy to succeed in the first place – high quality.  Today, Apple has maximized the potential for the platform itself – whether it be a mobile device, laptop, or media center, to sustain it’s own profitability.  But with the computer and handheld market on lengthy cycles between purchases, maximizing revenue opportunity becomes a challenge of ensuring that customers are purchasing Apple product more frequently.  This is where the iTunes Music Store is so critically important to Apple’s strategy.

Flash as a platform is flawed, says Steve Jobs.  His arguments have some merit, particularly on handheld devices.  But once again, this is a proxy argument.  The problem with Flash isn’t that Jobs can’t control the content developed in the platform.  The problem is that by allowing Flash into the Apple ecosystem, Jobs would be opening a wormhole into an alternative media delivery platform.  Flash is a development tool – but by leaps and bounds it’s greatest claim in the frontier of the internet is multimedia content delivery.  YouTube, Brightcove, and Vimeo are all powered by Flash and all deliver the same content for free that Apple wants to be able to charge for.  This is where Apple dogma and Google dogma meet, and Adobe is simply a place for this war to be fought.

Adobe cannot win and remain sovereign in this battle.  Apple’s desktop platform is the chosen home for many creative’s who use Adobe’s landmark products like Photoshop and Fireworks.  Google owns YouTube, has built it’s own rich internet application framework, and fully backs the HTML5 standard that allows the modern web browser to do all of the things one could only do with the support of Flash in the past.  Google has Adobe smiling with a knife at their back.  For Google, the relationship is convenient to buy time until Android devices overtake Apple devices (likely in 2011).  Apple’s aggression gives Adobe little choice but to ally with the greater but less immediate threat.

Apple’s fatal flaw in this fight is not the control over development for their devices, but how users will get media delivery to those devices.  It’s not that Google is on the opposite side of the debate – they simply don’t care.  Google is a data company that is using mobile platforms as another tool for understanding their users as to maximize the ad revenue that has made them so successful.  Whether or not the user buys their content from Amazon or Apple or Walmart is inconsequential.  If the user clicked an ad for one of those companies to buy an MP3 and Google made $.05 from that click – it’s been a successful day for Google.  The Google approach is open solely because it maximizes revenue potential by maximizing the channels that can generate that revenue – not because of some religious developer fervor.

So Adobe can scream and yell at Apple all they want about openness and freedom.  They have the backing now of a much stronger, much better positioned ally that could turn on them at any minute.  One move for Adobe could be to find a way to exclusively integrate their products with iTMS.  Such a move would at least leverage them against any passive Google aggression.  But ultimately they are but a proxy in the coming Apple/Google apocalypse.  To me, it’s more curious that Apple has decided to bring this battle to such an intermediary first, rather than to try to stunt the emergent competition in Google head on.  It could well be that the cost of such a direct war would be so great to Apple that they’d rather not play offense but instead focus on defense – ensuring exclusivity of content delivery on Apple platforms.  It could also well be that we’ll be watching TV on our Android devices in 2015 and forwarding through the “I’m an Android.  I’m an iPhone.” commercials.  Only John Hodgman will be wearing the Steve Jobs mock turtleneck.

Among the various extra-curriculars that take up my downtime, baseball is up there.  Baseball was a passion for much of my youth.  As I got older and my attention turned towards my career and the world at large, the dawn of Michael Lewis’ “Moneyball” changed my view on baseball entirely.  Baseball became, for better or for worse – less interesting to watch for 180 days a year and more intriguing to capture in the snapshots of statistics and numbers that engulfed baseball in the early 2000′s.  Lewis was demonstrating not a new approach to how baseball was played, but how Oakland A’s manager Billy Beane was simply exploiting an efficiency that none of his contemporaries had (yet) uncovered.

So recently I found myself thinking about the role of the manager in baseball.  As other teams began looking at the Oakland model for constructing successful, cost-conscious rosters, many copied their formula.  Others began to look for other efficiencies.  But the manager role – the ultimate “chicken” contrasted to the players as pigs, has only had cursory evaluation for their affect on the outcome of the game.  These evaluations are subjective by and large, and have all concluded in one way or form that managers tend to have zero net effect on the success or failure of a team.  But baseball managers are perhaps one of the most agile practitioners today.  They must be responsive, they must have enough foresight to plan only enough in that they can mitigate risk, but not so much as to commit themselves to a shortsighted approach.  Their sprints are innings, their releases are games.  They create ample time to adjust and re-plan.  They are agile creatures – perhaps the original agile management style.

Every Game is a Release

Before every game, the manager has a plan to build.  The lineup is first and foremost.  It ultimately has very little affect on the outcome of the game, provided that the manager has planned for his best hitters to be part of the game.  Additionally and potentially irrelevant statistically – the manager will prioritize his lineup which will offer the most potential value for that game.  The catcher amy be different depending on his own starting pitcher.  Lefthanded hitters, statistically vulnerable to left-handed pitching may sit on the bench to start the game while statistically inferior players fill-in for the handicapped lefthander.  Some players may be removed from the roster entirely, optioned to a minor league affiliate to allow for superior options to be available in the case the need arises.

The analogy here, is release planning.  Just like the manager has an assortment of players, we have a backlog.  Each story offers value that may change from one sprint to the next.  Each story may shuffle in priority from one sprint to the next.  But the focus is always on ensuring that during a release we are planning to ensure that we are successful in every area of our sprints during the release while aiming to maximize the success of our teams over the entirety of the release.

Every Inning is a Sprint

Baseball is a strange game in that every inning, the defense controls the ball.  There are 9 innings in a game, and 3 outs per inning.  These are our resources.  As a manager, my job is to allow my team to execute while intervening only when resource mismanagement is certain.  I may pinch hit for a hitter in order to maximize run production while minimizing outs.  Conversely, I may change pitchers frequently to ensure my competition is least able to use their resources to their fullest.

Managing sprints is a task in managing your resources optimally.  Each sprint we start with our planning meeting where we identify what resources are available for the current sprint.  Then, based on various factors – we figure in what we can get done during the sprint.  How we get there may change, but the goal is always part of a theme.  In baseball, this is a touch of a stretch – but it’s hard to think that a manager going into the 9th down by 3 isn’t planning his decisions on maximizing on-base percentage that inning with the prospect of his best power hitter in the dugout.  Often times when a team hasn’t scored the tying or lead run but is threatening to score, the bullpen will warm up, a proactive response to something which may not be certain.  A lot of baseball management is about thinking forward just far enough to be prepared for what you know is next and not focusing too much on the possibilities in September while it’s still May.

Baseball Teams Are Self-Managing

This is more hypothetically true than true in reality.  It’s not unheard of for players to be managers as well.  But unlike professional American football where the level of specialization and differentiation between offensive and defensive roles is stark, or professional basketball where the players can succeed independently of the team, even if the team fails – baseball players are incredibly independent in their affect on any given contest.  While Michael Jordan and Kobe Bryant may have single handedly one NBA titles for their respective teams, Derek Jeter and Curt Schilling would have not won their rings were it not for the complimentary (but not cooperative) talents of the players that surround them.  They exhibit classic examples of game theory where the benefits of the strength of their performance are best realized by them only when realized by all.  That is a key trait of the self-organizing team.

What Baseball Can Tell Us About Software

While these two things are markedly different, baseball managers and players are clear examples of self-sufficient and practical agile applications.  Managers aim to minimize risk and maximize production while only planning for the factors that are at hand or probable rather than trying to account for any possible scenario.  This is not too indifferent from how a Scrum-Master must operate.  If baseball managers went into game 1 concerned about game 60, they would be accused of guesswork and incompetence.  Uncertainty would doom their plan, the pundits would not.  This is not at all indifferent from Agile software teams that learn from recent results and apply the lessons from the most recent experiences immediately.

So when I posted an innocuous message questioning the value of the tool I had just used, I got an immediate response.  To me, this is the type of gratification that people get (or used to get) from setting their Facebook status.  Or Tweeting.  Social media, from the consumer’s perspective – is virtual screaming.  Just without the caps lock key.  It’s everyone’s way of saying look over here, it’s me, I like politics and I love books and I have a cold and does anyone want to grab a drink tonight? What Facebook realizes increasingly (and Twitter, always resistant to changing their innate simplicity, has gave a moment’s thought to) is that eventually you have so many contacts, so many friends, so many followers, so many people who follow you that the signal to noise becomes unbearable without some sort of filter.  All of the conversations, statuses, likes, fandoms, retweets, hashtags, and groups eventually just become an incessant buzz, and we stop paying attention to a lot of it.

The immediate response was a result of having all of 14 people paying attention.  Compare that to the 150 people I’m connected to on Facebook.  Or the paltry 80 or so followers I have on Twitter.  My satisfaction with the experience with Google Buzz at that moment was purely a result of it’s infancy. But the buzz grew immediately louder.  I then noticed that the buzz had gotten into my GMail inbox.  To a guy who likes the mantra of Inbox: 0, this was distressing.  Part of the deal with Twitter which elevates it appeal over Facebook is that it is a pretty passive social media.  Direct messages infect your inbox, but those are fairly rare.  Simple replies to your tweets or even mentions can just fade to noise.  But now that there was a level of replication between ubiquitous social exchange and my more formal communication in email – Buzz had taken the most invasive and distracting part about Facebook and actively decided to emulate it.

At least Google Wave, while useless for my everyday interactions (though potentially useful elsewhere) lived out on an island that I could blissfully ignore.

I think that Wave, Buzz, and GMail eventually need to work out whether or not they’re the same thing or different things.  Facebook is looking to build a “GMail Killer,” and so it seems there is some idea out there that people don’t like email and would rather live in a world where the overwhelming noise of social media permeates everything.  It’s clear that for Google, taking email and putting eyes on the inbox with greater frequency will lead to more exposure to advertisers and inherently, more ad revenue.  But Facebook has ALWAYS had this model and hasn’t been able to consistently demonstrate that users will give advertisers the chance through all of the other noise.

It’s tempting to say that people will ultimately reject this model and the invisible hand of the market will demonstrate that when the inbox becomes too busy, people will just tune it out.  Google has provided options for getting Buzz out of your inbox.  But given the potential upside, particularly in Google’s business model, I’m also unconvinced they won’t try to force this particular feature right down their user’s throats.

This is an unfortunate discovery.  While there is no inherent equals() or hashCode() in the Javascript language itself (unless I’ve missed something) that doesn’t mean GWT couldn’t make one for me.  JavaScriptObject#equals(…) instead calls super.equals().  Which is really Object#equals(…) and that’s really just triple-equality (==).  In object oriented programming, this is what is technically referred to as an absolute pain in the ass. It renders JRE emulation of java.util.Set around JSO’s almost useless.  And it really highlights something that I’ve had in my head a while now:

If you can’t use GWT-RPC, you use JSON at your own peril.  JavaScriptOverlay types, while nifty in concept are simply not first-class objects in GWT.  They’re more akin to a struct or map.

Let’s say you have interface Driveable:

public interface Driveable {
 public void accelerate();
 
 public void brake();
 
 public void tuneRadio();
}

Awesome. Now let’s say you have class AbstractDriveable:

public abstract class AbstractDriveable implements Driveable {
 public void accelerate() {
 Window.alert("Vroom vroom!");
 }
 public void brake() {
 Window.alert("Screeeeeech!");
 }
}

Totally cool.  And then you love your favorite FM station in ConcreteDriveable:

public class ConcreteDriveable extends AbstractDriveable {
 public void tuneRadio() {
 Window.alert("Rockin' the oldies!");
 }
}

Then we launch into development mode with whatever our application is, and…something explodes.

So we debug, and upon looking at the code that cleverly calls tuneRadio polymorphically – we notice that our debugger drops into a catch block for a NoSuchMethodError.

It appears that GWT seems to lose track of this common idiom – use an interface to define behavior, realize that interface on an abstract class to create default behaviors, and then strategize those behaviors in concrete implementations.

The workaround is simple: redeclare your unrealized interface method in the abstract class. But this is a pretty nasty little bug. The GWT guys know this, but it’s rather critical to GWT that it follow the practices of Java as best as possible. Otherwise it’s YAL.

But some of the weary techies I’ve worked with (particularly middle-management types, for some reason) go off the deep end.  I like to say that when you encounter a technical challenge – there’s likely someone else who has also needed to solve a similar problem.  In the instances where that isn’t the case – you’re in a pretty good position to gain something from solving it yourself.  But truth be told, there are very few large problems out there that people aren’t solving.  And yet IT organizations continue to re-invent the wheel – even when economics and time tell them that they should look for an off-the-shelf solution.  This only leaves one real driver for making the build decision when the buy decision is so apparent: politics.  And often it’s the politics of the grudge.

I firmly believe that every shop I’ve walked into that has rolled their own MVC framework, or RIA framework, or rules framework contains an individual who truly believes that the cost of supporting, maintaining, and continuously developing that software is still less than the cost of taking a turnkey solution – either one that is commercial or open source.  I recently had a manager tell me that there was an increasing drive through the IT management structure that the enterprise should own the source and rights to all of the systems that it supports.  This was a crazy notion – are their boundaries to this doctrine?  Will we be writing our own application servers?  RDBMS?  Messaging systems?  Where does this cult draw the line?  And with a little more digging, and without much surprise – I found that this manager had spearheaded a campaign to adopt a particular Javascript framework for client development that ultimately failed and cost the company several millions of dollars.  His dogma seemed crazy, and it was. But it was completely motivated out of fear that technology selection, no matter where the accountability lay – was an avoidable cost of enterprise IT, even if it meant adopting the more extensive cost of building all solutions from the ground up whenever the need arose.

I guess the moral of the story is really that as an IT manager, it’s important to recognize the power of the crowd (the community if you will) and the value it can add at virtually no cost to your organization.  That it’s important to understand why a 3rd party tool has been selected.  That it’s general limitations are known early on.  That your organization is prepared to adopt the tool as if it were it’s very own.  This means hiring experts who have used those technologies.  And above and beyond anything else, that when you fail – the goal must be to marginalize the cost of that failure.  You can hedge your bets, you can reduce risk.  But when the dust settles and a selected technology has failed the organization – be sure to take a good hard look in the mirror and be open about where the selection process has failed.

Sometimes it is the captain, and not the ship.

A bland RPC implementation that was based on past work I’ve done was barfing all over me at GWT compile-time today:

Rebinding com.ryannorris.staffing.client.project.ProjectCreatorService

Invoking com.google.gwt.dev.javac.StandardGeneratorContext@9b32fe

Generating client proxy for remote service interface 'com.ryannorris.staffing.client.project.ProjectCreatorService'

[ERROR] com.ryannorris.staffing.client.Action<T> has no available instantiable subtypes. (reached via com.ryannorris.staffing.client.Action<T>)

[ERROR]    subtype com.ryannorris.staffing.client.Action<T> is not instantiable

[ERROR]    subtype com.ryannorris.staffing.client.project.ProjectCreatorAction is not assignable to 'com.google.gwt.user.client.rpc.IsSerializable' or 'java.io.Serializable' nor does it have a custom field serializer (reached via com.ryannorris.staffing.client.Action<T>)

[ERROR] com.ryannorris.staffing.client.project.ProjectCreatorAction is not assignable to 'com.google.gwt.user.client.rpc.IsSerializable' or 'java.io.Serializable' nor does it have a custom field serializer (reached via com.ryannorris.staffing.client.Action<T>)

I can’t say I ever had the pleasure of dealing with this bit of attention to detail from the GWT Compiler in the past.  And while I will readily admit I haven’t read every change to the underlying architecture that comes with 2.0, this would seem to be a piece that might be worthy of some special mention.

It is, of course, nearly common sense to make sure that your RPC objects can go across the wire in the proper way, and thus simply respecting the semantics of java.io.Serializable the same way we would in EJB per se, is pretty reasonable.  Just a little more heads up would have been nice.

Update 1: There seems to be some mention of fixing compiler feedback around RPC serialization here.  But this defect doesn’t suggest changes that might have actually altered behavior or requirements of the compiler since 1.7.

To get started, let’s break down our validation needs along the standard lines that we see in frameworks today.  Widgets need to be able to be Validatable.  That is to say, Widgets must be able to be externally seen as having the capability to execute logic which validates their current state.  In my approach, I’ve chosen to strategize my widgets rather than visit them in order to validate their data.  This decision is largely to enforce contract-driven development and ensure a high level of testability.

Validatable

package com.ryannorris.gwt.validation.client;
 
public interface Validatable {
	/**
	 * Execute validation on the implementing component
	 *
	 * @return true if validation succeeded, false if validation failed
	 */
	public boolean validate();
}

We also now need an interface that will provide the rules for how validation logic should occur.  Something that is Validatable should be able to validate itself with multiple sets of rules.  Our Validator interface gives us this flexible cardinality, and has a familiar ring to it.

Validator

package com.ryannorris.gwt.validation.client;
 
public interface Validator {
	/**
	 * Execute the implemented validation logic
	 *
	 * @return true if validation succeeded, false otherwise
	 */
	public boolean validate();
}

Yes, these two interfaces are the same besides their name. They are both command interfaces, allowing us to abstract logic behind a single method that we can cope with polymorphically. The idea remember is that Validatable components can re-use many different Validator implementations.

So let’s write a simple Validator and Validatable interface.  In this case, we’ll be validating date input.

DateFormatValidator

package com.ryannorris.gwt.validation.client.validator;
 
import com.google.gwt.i18n.client.DateTimeFormat;
import com.google.gwt.user.client.ui.HasValue;
import com.ryannorris.gwt.validation.client.Validator;
 
public class DateFormatValidator implements Validator {
 
	private HasValue<String> _value;
	private DateTimeFormat _format;
 
	/**
	 * Create a validator that will verify that the given string is compliant
	 * with the pattern
	 *
	 * @param format
	 *            The format to validate against, per the specification in
	 *            {@link DateTimeFormat}
	 * @param value
	 *            The value to validate
	 */
	public DateFormatValidator(String pattern, HasValue<String> value) {
		_format = DateTimeFormat.getFormat(pattern);
	}
 
	/**
	 * Set the value to be validated
	 *
	 * @param value a string, nominally representing a date
	 */
	public void setValue(HasValue<String> value) {
		_value = value;
	}
 
	/*
	 * (non-Javadoc)
	 *
	 * @see com.ryannorris.gwt.validation.client.Validator#validate()
	 */
	@Override
	public boolean validate() {
		try {
			_format.parse(_value.getValue());
		} catch (IllegalArgumentException e) {
			// the value couldn't be parsed by the pattern, return false
			return false;
		}
 
		return true;
	}
}

So, now I have a Validator. How do I now make a widget, let’s say a simple TextBox, Validatable?

Harkon back earlier when I said I was chosing to strategize my Widgets.  That’s only partially true.  Because we’re aiming for good TDD, and hence we want to rely on dependency injection – we will in fact be decorating them as well.  We will strategize around their ability to be validated, while we will decorate them with the Validators that interest us.  This is important, as we wouldn’t want to have 20 different TextBox implementations that handle various Validation permutations.  We would rather one, decoratable TextBox that can be managed by the presenter in our MVP implementation.  So what does our initial stab at a ValidatableTextBox look like?

ValidatableTextBox

package com.ryannorris.gwt.validation.client.widget;
 
import com.google.gwt.user.client.ui.TextBox;
import com.ryannorris.gwt.validation.client.Validatable;
import com.ryannorris.gwt.validation.client.validator.DateFormatValidator;
 
public class ValidatableTextBox extends TextBox implements Validatable {
 
	@Override
	public boolean validate() {
		DateFormatValidator validator = new DateFormatValidator("mm/DD/yyyy",
				getText());
		return validator.validate();
	}
}

Wait, you say.  This isn’t at all what you just described!  This is a text box that will only execute one validator for one date pattern! Well, you’re right.  We need to find a way to enable decoration of our TextBox in a way that can be nicely tested and extensible.  GWT makes extensive use of decorator pattern, and really strives for testability.  We see this in the various Has interfaces, which are added to classes to give them additional behaviors (such as HasText or HasClickHandler).  So, we will follow suit and create our decorator interface HasValidators.

HasValidators

public interface HasValidators {
	/**
	 * Add a validator to the decorated component
	 *
	 * @param validator The validator to be added
	 */
	public void addValidator(Validator validator);
}

And now our updated ValidatableTextBox.

package com.ryannorris.gwt.validation.client.widget;
 
import java.util.Set;
 
import com.google.gwt.user.client.ui.TextBox;
import com.ryannorris.gwt.validation.client.HasValidators;
import com.ryannorris.gwt.validation.client.Validatable;
import com.ryannorris.gwt.validation.client.Validator;
 
public class ValidatableTextBox extends TextBox implements Validatable, HasValidators {
 
	private Set _validators;
 
	@Override
	public void addValidator(Validator validator) {
		_validators.add(validator);
	}
 
	@Override
	public boolean validate() {
		boolean valid = true;
 
		for(Validator validator : _validators) {
			if(! validator.validate()) {
				valid = false;
			}
		}
 
		return valid;
	}
}

So, that’s pretty sweet. I have a collection of Validators as a member of the component – in fact I have a set of them as to ensure no Validator exists more than once on the component.  My validate method now loops through the set of validators and maintains the local state of the validation, allowing the entire validation to fail if any one Validator fails.

A highly testable passive view implementation with this component may look something like:

MySampleValidatableView

/**
 * 
 */
package com.ryannorris.gwt.validation.client;
 
import com.google.gwt.event.dom.client.HasKeyPressHandlers;
import com.google.gwt.user.client.ui.HasValue;
 
/**
 * @author ryan
 * 
 */
public interface MySampleValidatableView {
	/**
	 * Get the {@link HasValidators} behavior of the date box.
	 * 
	 * @return a {@link HasValidators} behavior
	 */
	public HasValidators getDateValidators();
 
	/**
	 * Get the {@link Validatable} behavior of the date box.
	 * 
	 * @return a {@link Validatable} behavior
	 */
	public Validatable getDateValidatable();
 
	/**
	 * Return the {@link HasValue} behavior of the date box. This allows us to
	 * access the value of the control.
	 * 
	 * @return a {@link HasValue} behavior
	 */
	public HasValue<String> getDate();
 
	/**
	 * Return the {@link HasKeyPressHandlers} behavior of the date box. When the
	 * user types a key in the field, we will use this event to validate the
	 * current value;
	 * 
	 * @return
	 */
	public HasKeyPressHandlers getDateKeyUp();
 
	/**
	 * Toggle the visual state of the date box so the user receives feedback
	 * when their date is valid
	 * 
	 * @param valid
	 *            Whether or not the control should reflect a valid date entry
	 *            (true) or an invalid one (false)
	 */
	public void toggleValidDateBox(boolean valid);
 
}

A lot going on here, and it’s seems verbose – but it’s not, it’s just highly testable! We need to be able to access the various behaviors of our text box so that we can test how our presenter collaborates with these behaviors.  We also need to be able to push the passive display functionality back to our view implementation so that our unit tests don’t inadvertently require a hosted environment to run.  So our presenter needs to be built to:

1. Create a DateFormatValidator with the appropriate pattern and a reference to the component holding the text value to validate;
2. Decorate the component in the view through the HasValidators behavior;
3. Execute validation whenever the user changes the value of the widget through the HasKeyPressHandlers interface;
4. Alter the visual display of the component by calling the toggleValidDateBox method.

So last but not least, our presenter:

MySamplePresenter

package com.ryannorris.gwt.validation.client;
 
import com.google.gwt.event.dom.client.KeyPressEvent;
import com.google.gwt.event.dom.client.KeyPressHandler;
import com.ryannorris.gwt.validation.client.validator.DateFormatValidator;
 
public class MySamplePresenter {
 
	public MySamplePresenter(final MySampleValidatableView view) {
 
		DateFormatValidator validator = new DateFormatValidator("mm/DD/yyyy",
				view.getDate());
		view.getDateValidators().addValidator(validator);
 
		view.getDateKeyUp().addKeyPressHandler(new KeyPressHandler() {
 
			@Override
			public void onKeyPress(KeyPressEvent event) {
				view.toggleValidDateBox(view.getDateValidatable().validate());
			}
		});
	}
}

So there you have it – a highly testable base for validation in a GWT application using MVP.

In my next post, I’ll add an event framework to validation, allowing asynchronous validation and abstraction between overall error handling and validation.

For my part, there’s only so much patience I have taking on the burden of supporting multiple browsers and dealing with performance issues.  Particularly if I’m Agile, and I’m focusing on delivering so much value so quickly, it’s very hard to explain to a client that the underlying technology creates significant overhead that adds drag to the project.  This is an even tougher sell – particularly when you’re open with your client, when alternatives that meet the non-functional needs exist.

For your standard web applications that aren’t as client-centric as today’s RIA applications, it’s certainly true that you are barking up the wrong tree with GWT.  Rails, Grails, and Zend can all give you the non-enterprise delivery tools that accelerate development from the server-side and leave the Javascript problem to be solved in a less holistic, more tactical way.

But it’s hard to argue now that anything short of the compilation semantics of GWT is useful in the RIA realm (without the need for a intermediate runtime, of course.)  Javascript is too costly and too brittle in large-scale applications to be subject to human hands.  If you’ve hired a contractor to build you a web-based RIA and they’re not using GWT – it’s well worth your wallet to ask them why.