Marc Palmer

This morning I released a new Grails plugin that lets you manage beta-invites to your app and similar.

More information here.

There have been lots of iPad reviews, so I’ll try not to go over the same old stuff. Suffice to say it is very good, but I’m still learning how to use it – i.e. how it fits into my life. Will I really do diagrams on it, will I read e-books for long periods, will I write code?(?!).

A quick summary after 2 days intermittent use.

• It is a little too heavy at first. I suspect my arms will get used to it, or I will learn to hold it the right way – we never thought people would write essays with their thumbs on mobile phones. This is no doubt related to battery weight. I’d rather have the battery life – but a few 100g less would stop this being something people mention. Hardback books are heavy.
• The photos app is an instant winner. All they need now is selection of which you want to order prints for and ordering prints direct from iPad using iTunes account. Oh, and they do need wireless smart syncing of photos from MobileMe, Flickr etc. So you can publish from your other Mac/PCs and the ipad syncs them over the wire in the background.
• Typing is much much better than I thought it would be. With practice I can be as fast or faster than on a regular Apple keyboard I’m sure. I just need to get used to the slightly differently layout and tactile differences. So much so I could consider writing code on it. There are already some HTML editors for iPad.
• It would be really nice to set an App to be used as the lock screen, not a wallpaper. Eg set Weather HD or Guardian Eyewitness, Calendar month view, or the built in picture frame app – to come up when you press the lock button.
• I actually like some of the iPhone apps at 2x zoom. Most iPad native apps seem to be taking the fonts a little too small, and losing the benefits of larger font clarity / greater distance from the eyes that iPad screen should be affording you.
• Some apps definitely need further optimisation. E.g. Omnigraffle is not a bad first stab but there is no justification I can see for the UI being so laggy when dragging a single rectangle around the screen on a trivial diagram. Calculating the guides cannot be that intensive! Art authority is nice but the image quality of the marble UI backgrounds is really nasty, and the UI is rather sluggish with no indication it is busy at times.
• A little gripping surface around the edges would make you less scared when carrying it without a case. The front surface is very slippery, the back isn’t.
• I find it hard to find apps in home screen – they are too far apart and with an image background, it is hard for icons to stand out visually – I often have to resort to using search to find apps! This is reason enough to not have the option to set custom wallpaper… or at least it should be default reduce the intensity of wallpapers by 50%
• I miss the magazine rack metaphor from NewsRack for iPad. Seems much better fit for iPad than iPhone, I hope it comes back
• The lameness of many apps is more obvious on iPad than on iPhone. You’re more happy to “make do” on iPhone but the bar is being set higher on iPad by very good UIs e.g. Penultimate, Elements, Weather HD, Virtuoso HD piano. Omnigraffle is a good first stab but feels too awkward still.
• iBooks better become like iPod app and allow third party PDFs/ePub files to install easily w/o buying from iBooks store. All other e-book readers I can find seem completely lacking the Apple polish – slow, unintuitive touch interactions etc.
• Smaller text sizes on webpages will be much more readable when they eventually upgrade the display to higher dpi. It might be a year or two though…

I can’t vouch for Pages, Numbers, Keynote or iBooks yet – they aren’t available in the UK app store (which you can only access from iTunes currently anyway).

The Weceem CMS plugin for Grails uses the Blueprint CSS framework, jQuery and jQuery UI Javascript libraries. As the Grails plugin marketplace continues to mature, other plugins will have more polished user interfaces or reusable tags that require certain libraries.

This raises an ugly prospect: a new resource dependency problem. Only unlike java dependency problems this is worse as you end up with multiple copies of resources in your app, even if they are the same version because plugins will typically bundle the resources themselves. Your app may add some of these too and your site becomes slow to load or experiences failures related to clashing library versions.

There is however a staggeringly simple solution to this: lightweight Grails plugins that contain the resources.

Thanks to Grails’ automatic dependency resolution we (the grails community) can just create plugins to wrap up each such library and then we just make any apps or plugins that require them depend on them by installing the library plugin or adding it to the dependsOn clause of other plugins.

An important caveat here is that the library plugins need to use version numbers matching the version of the library they encapsulate. Then if you want jQuery 1.4.2 you depend on/install grails-jquery version 1.4.2 or higher. The grails-jquery plugin authors have already done this.

These plugins should implement a simple tag called “resources” in an appropriate namespace e.g. or .

I strongly believe that such plugins should NOT include other tags or more heavyweight tags wrapping up library features – do that in another plugin e.g. “grails-jquery-tools”.

This approach does provide new challenges for optimizing static content – minifying JS and CSS and including only required modules from a larger library remains awkward as it is today with non-dependency solutions.

Ultimately I think we need smarter solutions than those currently in use to solve this. I have some ideas forming…

I have released Bean-Fields plugin 0.6. This extremely handy plugin for Grails applications makes your data form GSPs DRY by centralizing the rendering and styling of your fields, handling <label> rendering, rendering appropriate HTML field based on property type, application of HTML max length constraints, rendering “required field” indicators, and rendering per-field errors. Rendering a whole bean’s worth of fields can be as simple as:

Version 0.6 fixes a bunch of bugs related to rendering fields for nested property paths e.g. propertyName=”book.author.firstName” and introduces support for list / array properties eg “book.authors[3].firstName” (This was really quite painful to implement!). Radio groups are working properly now, and test coverage much improved – thanks to contribs from Antony Stubbs.

It also adds a user-definable threshold for whether a radio group or select list should be used for a field with an inList constraint.

Full list of resolved issues is here.

I delivered my talk “Yes you CAN use Grails” yesterday at JAX London 2010, and it was well received. Unfortunately nobody was videoing it, and as the slides are “Presentation Zen” style you won’t get much from the official slides from JAX. It talks about Grails basics and how Grails is the perfect fit for existing Java development shops, and the things you need to know to make it possible to use it in your workplace. Well, at least you can try.

So I recorded myself doing the talk here at home and have uploaded a screencast of it all for those of you who are interested. Its not so good the second try – you had to be there for the best version

Click the thumbnail to download the MOV. Its about 47 minutes. Its probably going to cost me a fortune having it on Amazon S3!

Also available as a torrent.

People interested in making the case for Grails may be interested in an older post of mine that I’d completely forgotten about – “10 common misconceptions about Grails”.