If you are writing a typical GWT application, which is monolithic and controls the entire viewport of the browser, you probably don’t want to read this post.\u00a0 Go on, read something else interesting–you probably have emails or tweets or something better to do with your time.<\/p>\n
OK, now we just have the people left who are using GWT to build widgets; that is small encapsulated pieces of functionality that integrate into an existing web based application (case #2 outlined here<\/a>).\u00a0 If you’re doing this, and you use the “span to enable”<\/a> gwt mini pattern, you want to upgrade to GWT 2.0 simply to get the new code splitting functionality<\/a>.\u00a0 If you don’t want to read that previous link, the synopsis is that code splitting lets you define a number of pieces of distinct code, using Previous to this feature, if you had a number of widgets, you ended up with a large chunk of code to download on every page (this is an issue with GWT that the monolithic applications simply don’t have to deal with).\u00a0 Some of that code will be run.\u00a0 Some will not, but you’re still paying for download and parsing of that code.\u00a0 You had some unsavory options to deal with this–let all the code be downloaded, or manually split up code into separate modules that you managed (either by hand or with deferred binding).\u00a0 The second solution led to smaller downloads, but meant a lot more management–if you wanted to add a widget to a page, you not only had to add the enabling span, you had to recompile the entire GWT module–and much longer compilation when you deployed your entire web application.\u00a0 However, if your widgets were static, this path might have been an option.<\/p>\n My client used the former solution (entire code download on every page), and was very excited about the code splitting, since that essentially automates the second choice above.\u00a0 In the space of about one half hour, I was able to reduce the initial download size of the GWT javascript by 10%, and there’s scope for much more, since the code is pretty naturally split up into separate chunks for each widget.<\/p>\n It’s not perfect, however. The two concerns I’ve had so far:<\/p>\n you need to replace it with:<\/p>\nGWT.runAsync<\/code>.\u00a0 Then, that code won’t be downloaded until it is reached.<\/p>\n\n
GWT.runAsync<\/code> from an event handler, like onClick, you will not have a valid event on the first call (when the module is loaded) but will on all subsequent calls.\u00a0 This is easy to fix, but was a bit mystifying to me.\u00a0 Basically, if you have code like this:<\/li>\n<\/ol>\n<\/p>\nonClick(ClickEvent event) {\r\nif (event.getSource() instanceof Image) {\r\n\/\/ do something with image\r\n}\r\n}<\/pre>\n<\/p>\nonClick(ClickEvent event) {\r\nif (event.getSource() instanceof Image) {\r\n\/\/ save event.getSource into an instance variable\r\nGWT.runAsync(new RunAsyncCallback() {\r\n\/\/ do something with image in instance variable\r\n}\r\n}\r\n}<\/pre>\n