The great thing is that actually, with only a little knowledge, doing this stuff is really easy. The Arduino board designs and software are open source, which is a good thing. However as usual this means the docs can be problematic.

There’s a confusing array of Arduino hardware out there. The boards have the ATmega micro controller chips on them that you program, and lots of digital and analog input/outputs so you can control and measure things. There are boards with Ethernet, Wi-fi, USB and even LED matrix drivers.

Basic Arduino (UNO)

Using this Arduino which has just a USB port and the I/O connectors, plus a bread board and 4-digit 7-segment LED display from an Earthshine starter kit, I managed after digging out the spec sheet on the display, to create a counter from 0001 to 9999. This sounds trivial, but it has a few challenges:

1. The LED display is basically 4 x 8 LEDs (7 segment + decimal point)
2. There are only 12 pins on it. Huh?
3. If you don’t send power to one of the LEDs, it goes off.

The spec sheet showed that 4 pins control which of the 4 digits you are addressing – set them LOW (common cathode) to enable the corresponding digit.

Then you set some of the other 8 pins HIGH to represent the digit or symbol you want to show.

So to set all 4 digits without any shift register chips or other smarts to “remember” the state of segments for each digit, you have program the Arduino to continually loop through the 4 selector pins, set the segment pins HIGH, wait a few milliseconds, then set the selector pin for that digit HIGH (to turn it off), and then repeat the same process for the next digit’s selector pin. What happens is that each digit is illuminated for say 5ms and then it moves to the next one.

They are continually going on and off, but because you constantly loop at high speed over them, it appears to be a continuous display.

Much more fun – the Rainbowduino

The Rainbowduino is a self contained Arduino board and the latest v3.0 one has built in mini-USB. So its just like an Arduino UNO but has a bunch of other controllers to drive an 8×8 RGB LED matrix with constant current (which I think means when lots of LEDs are on, they stay the same brightness). CAUTION: the LEDs are also seemingly as bright as the sun and staring at them is likely to leave you with a disturbing 8×8 grid of dots burnt into your retina.

So I bought the Rainbowduino plus an 8×8 RGB LED Matrix. The Rainbowduino is built to have the matrix directly plugged into the top of it, which is very handy.

Rainbowduino board plus LED matrix mounted on top

There are some tricks to getting this working however:

1. Unlike the Arduino UNO, my Mac would not recognise the Rainbowduino when plugged in to USB. I had to install the “FTDI” drivers from here. Thanks to @andydavies for the tip there
2. The docs on Rainbowduino are sketchy, and seem to be mainly targeted at an LED 3D cube rather than the matrix, and using the Processing language (which is not what the Arduino IDE uses).
3. It turns our there are several options for controlling this matrix. You can flash your own Arduino “sketches” (programs) directly onto the Rainbowduino, or you can use the I2C serial protocol to drive the Rainbowduino from another Arduino – I am guessing this means the Rainbowduino ATMega has a custom boot loader that supports serial comms to drive the display. I may be wrong.

To solve (2) I had to find the driver code that would work with the Arduino IDE. The v3 Rainbowduino driver is here. If you save that to ~/Documents/Arduino/Libraries/Rainbowv3 or similar (for Mac OS X at least that is where it is) and restart Arduino IDE, you will see you can now insert it into your Arduino sketch using the “Import Library…” menu option.

You will then find it does not compile, complaining it cannot find “WProgram.h”. This is I think because the library is built to run with “Wiring” programming language. To fix this you need to edit the Rainbowduino.h file from the driver that you saved, and change the #include <WProgram.h> to <Arduino.h>.

After that you can use the driver, which is incredibly simple:

1. in setup() call Rb.init()
2. in loop() call some Rb methods such as: Rb.blankDisplay() and Rb.setPixelXY(x, y, rgbcolour)

Rainbowduino with diagonal spectrum

Why so dark? LEDs are too bright to photograph without a filter. I put lots of tissue paper over them.

So here’s an example to apply the colour spectrum diagonally to the entire grid in action:

Note that if you find your reds are not working you probably have a C typing problem, and need to explicitly cast your values to uint32_t to avoid the RR of your RRGGBB being lost to 16bit accuracy.

And seeing as most of my life is spent in Grails… this wouldn’t be complete without a video of the Grails cup shining in all its 8×8 glory.

And here’s the code, if you want some Grails glory yourself:

We started off trying to watch it on the tv via AirPlay to the apple tv, from the iPad. That one sentence tells you that apple are certain to raid the tv market. Remove two components from that list.

Anyway it was fail. Every three minutes or so the 4OD app stopped streaming to apple tv. BBC iPlayer in Safari streams fine so it’s either the 4od app not liking AirPlay or a new iOS 5 bug as we did this fine before 5.0.1

We resorted to watching on the MacBook pro as we had done in the past fine.

Harbinger of what was to follow – channel 4 site demanded I upgrade Flash first. Fine

We start watching. Subjected to 3 mandatory viewing ads at the start all is well for a while.

Another ad break, another 3 ads. Some repeated from before. Watch some more.

Oh noes! Pop up message saying there’s an error and the content can’t be played. Video stops. Hmm. Press play again. Starts from beginning.

Watch first three ads I enjoyed so much again. Unmissable, really.

Fast forward to next mandatory ad section to try to get to where we were.

Watch 3 more ads a second time. Its awesome.

Watch some more misfits at last.

Oh noes! Error message again. Video carries on though. Message goes away by itself after many seconds. Hooray! Watch some more.

Error message again! Video stops. Press play again. Yay! Carries on from 2 ad breaks back, but not from the start. We’re blessed! Skip to ad break before last error point. Bonus! Only see 1 repeat ad!

Oh noes! The missing 2 ads are undead and playing in the background somehow – audio is mixed with programme audio. Press space to try to pause to work out what is going on. Pressing space doesn’t pause. It opens a new browser window with an advert for Assassins Creed – one of the ads we were not currently viewing. Soon discover clicking anywhere on the player window launches last ad’s website. Just what I wanted. Especially 5 minutes after avidly watching an ad.

I have no other browser tabs or windows open with the video streams of the ads. Player has simply gone mad. We wait for ads we cannot see but can hear to finish.

Unpause the player, full screen it again, watch more misfits.

Oh noes! Another error message. Video carries on, message obscuring screen for minutes.

Bonus! Audio from ads we cannot see becomes mixed in again! Now I have mastered this streaming tv technology I know to pause the video, mute the audio, wait a few minutes, unmute, resume video. Perfect!

We carry on watching, we’re 38 minutes into a 45 minute programme – but its taken over an hour to get this far. The magic of tv is somewhat eroded. Only in part due to more ads than content.

Oh noes! A few minutes before the end another error message, video stops. Press play… back at the beginning! YES! I had forgotten those original ads at the start that were repeated throughout, and wanted to catch up on those again. Thank you Channel 4.

The final insult, though perhaps merciful: the laptop battery runs out and it all shuts down.

I pick up the iPad, open 4od app, press play on Misfits. Have to watch one short ad, then can instantly jump to the last few minutes and watch it flawlessly while holding the iPad aloft.

This experience speaks volumes about the state of current computing, tv, media, advertising and software development.

If it weren’t for the iOS AirPlay bug none of this would have happened.

Fear the Apple TV chaps.

Oh, and there must be a separate team doing 4OD for iPad, cos the experience is infinitely better than the web one. Far fewer ads. Rapid seeking. No upgrades. No Flash. Great content. Anywhere.

That’s all you need – happy consumers.

And believe it or not that’s what advertisers need.

I’ve been good so far. Here the NSFW summary: OH FOR FUCK’S SAKE WHAT ON EARTH DO THOSE WANKERS THINK THEY ARE DOING?

I’ve been picking mushrooms for about 15 years now, though not that regularly. We were blessed with finding a good amount of Ceps and a lot of Wood Blewit this time, along with some Blushing Wood Mushroom and some small Horse Mushroom. Just before cooking my wife asked me to confirm the young white Horse mushrooms were what I thought and I said yes of course. I’m experienced after all. I know how to identify Agaricus species.

I cooked some ceps, blewits, wood mushroom and the horse mushroom with some spaghetti, garlic and thyme for me, my wife and kids. It was well received by all.

After the meal I started to wonder. My wife’s questioning made me suddenly anxious as to whether my Horse Mushroom identification was correct. I thought: they were a bit small actually for horse mushroom, and the “cog” pattern on the ring wasn’t so well defined. They didn’t stain brightly yellow, I double checked.

I was feeling a bit tense, wondering if I felt truly sick. The abject fear that perhaps I had fed Death Caps or Destroying Angel to my entire family alone started making me feel ill. You simply cannot *feed* your children a mushroom that you cannot identify – this is a potentially lethal mistake. I went over the id of all the really poisonous white/yellow mushrooms again and my memory of how they looked (another foolish mistake – not keeping one back from cooking).

I ended up the evening pretty certain that what we had was indeed an Agaricus, the Wood mushroom Agaricus Silvicola – a fine eating mushroom at that. Not – thankfully due to my in-built “Agaricus identification skills” but sadly not through real conscious identification – a Destroying Angel.

I can only say how genuinely mortifying it is to be in this kind of situation – even if just through a bought of self-doubt – wondering if in 8-12 hours your entire family will start suffering the dreadful symptoms of often fatal Amanita poisoning that begins with diarrhoea and ends with kidney failure.

Moral of the story: even if you’re experienced at picking mushrooms don’t let excitement get the better of you – remember the perils of identifying the “small white mushroom”. In future I’ll be steering clear of them. I never want to feel that fear again.

It was meant to be 1.1 but there was a bug that needed fixing immediately after releasing so 1.1.1 is where we’re at. This version is tested with Grails 1.3.7 and Grails 2.0 RC1 which is set to drop this weekend.

What’s new in this release of Resources?

Well aside from some useful bug fixes there’s a few interesting changes:

1. If you forget to include r:layoutResources tags, you will get an error in the console. The error may or may not display in the browser currently depending on whether you used site mesh layouts or not. We may be able to improve this in future. This means that people who wondered where their JS code was disappearing to after installing Resources into a 2.0 app will now get an error telling them that they need to add r:layoutResources.
2. There is now support for laying out arbitrary dispositions by passing a “disposition” to the r:layoutResources tag. This means you can position sets of resources wherever you like in the output, using multiple dispositions. Currently this is only relevant for JavaScript but in future we should be able to support images so that you can e.g. have a bunch of “preloaded” images that are hidden in the page somewhere.
3. The integration with Grails 2.0 has been “finalized” now. The ResourceService has changed to a “grailsResourceProcessor” bean, and all g:javascript invocations result in called to r:require or r:script as necessary. The default layouts in 2.0 now use layoutResources and a default “application” module exists in new projects.

There are still some outstanding important bugs that I will endeavour to fix soon, as well as improving the error reporting on all fronts.

Enjoy!

The arrogance of Web evangelists is staggering. They take for granted that the Web will always be popular regardless of whether it is technologically competitive with other platforms. They place ideology above relevance. Haven’t they noticed that the world of software is ablaze with new ideas and a growing number of those ideas are flat out impossible to build on the Web? I can easily see a world in which Web usage falls to insignificant levels compared to Android, iOS, and Windows, and becomes a footnote in history. That thing we used to use in the early days of the Internet.

As those of you who read my previous post on the possibility native could eclipse web on the desktop will know, I could not agree more. It’s not something I want, but I believe it may be inevitable. Even if Joe’s mooted guardians/CEOs of “the web” materialised, there’s no guarantee they would produce something compelling enough for the average user to use in preference to native apps.

Joe’s piece is bang on, in that the web geeks of the world are in complete denial of this and the dead weight of design-by-committee that will forever drag the core web technologies down.

Also ties into a tweet that I saw today:

@hnshah: “As far as the customer is concerned, the interface is the product.” Jef Raskin

There are a couple of ways to interpret this, but mine is “customers don’t give a shit how you implemented this or what your constraints are”.

What they see, feel and experience in front of them is what they care about.

Web devs who deny this is the case are just sticking with what they know, and companies sticking to web development are doing this purely for cost reasons that make not one jot of difference to the customer. Seriously, who wants to learn Objective-C, code Android, or Windows or OS X when they can already do HTML + JS? You can see the logic – it’s “cross platform”. It is however self-interest, and this does not drive the software market. The customer does, and the customer is rarely happy in the long term with lowest-common-denominator UX and functionality.

The web offers no gain for the customer whatsoever vs native. The converse is true for native vs web.

Yes I make a living from making web app stuff. For now at least.

The start of this article will go over some of the basics again, as they are a prerequisite for understanding the more advance topics covered later in the piece.

Recap: What is Resources framework for?

It solves the growing problems around application and plugin static resources. Your CSS, JS and other files have dependencies on each other, and must load in the correct order. You also want to optimize these so that your application loads quickly and caches well for your users.

It provides a way to declare your resources, their dependencies, and a processing chain to modify the resources and response headers to perform all manner of tasks such as bundling multiple resource files into one file, zipping the response, applying long-term client-side caching, or compiling Less or Sass files to regular CSS on the fly.

Where do I start?

First you install the “resources” plugin. To actually see some magic happening you probably want to also install the cached-resources and/or zipped-resources plugins also, but this is not a requirement.

Then you declare some resources in your app, or pull some in from a plugin that supports Resources. Let’s start by declaring a resource that exists in your application, say main.css. To do this you create a file in grails-app/conf/ with a name that ends in “Resources.groovy“. So we might create AppResources.groovy and use the DSL to declare the resource:

This is a module declaration. For full details see the Resources documentation, but in essence this declares a resource module called “common” and it has one CSS resource in it, the file supplied by your application in web-app/css/main.css, and on JS file.

So far, so good. Now you need to pull this resource into a page. To do this requires using some Resources tags.

Using resources in your pages

There are two main tags involved in using resources, with some others that provide extra features. The main two are r:require and r:layoutResources.

The r:require tag tells the framework which resource modules the current GSP requires. The framework will make sure that all the resources declared in those modules are pulled in in the correct order.

To achieve this, you need to include r:layoutResources tags in your <head> and <body> sections. Typically you do this in your SiteMesh layout. You use two calls because one will render the resources that you need to link to in the <head> section of your page (all your CSS, and some of your JavaScript, maybe some favico or iPhone icons). The other goes at the end of the <body> of your page, to render any “deferred” resources, which is usually just your JavaScript code.

So here’s an example of a Grails Sitemesh layout using these tags:

Here you see that you still use the normal Grails sitemesh tags to layout the head and body. These provide the route for you GSP page to actually affect the output, including the output of the Resources plugin’s r:layoutResources tags. That’s because your GSP will call r:require and r:script tags something like this:

This GSP is set to use a Sitemesh layout like the example one given earlier. It uses the r:require tag to say that this page needs the “app” resource module. Using this information, the r:layoutResources tags will render links to all the CSS, JS and other resources of that “common” module, in the correct places.

This means that some may end up in head, and some may end up in body. Remember that we invoked r:layoutResources twice, once in each location? Well, that’s why.

What is this “disposition” stuff?

The disposition of a resource tells the framework which part of the page it belongs – its a form of arbitrary grouping. The default dispositions supported are “head” and “defer” but in fact resources can define any disposition they like – and this can be useful for declaring resources that are not rendered by the normal layoutResources calls (more about this later).

The framework applies a default disposition based on the type of the resource – so CSS always defaults to “head” but JavaScript always defaults to “defer”, so that it runs only when the rest of the page has loaded. Images and icons are also supported to represent favicon and iPhone icons, which render in “head”.

Resource modules usually contain multiple resources and the main reason to specify a disposition when declaring a resource is to force JavaScript to load in the <head> section of the page. To achieve that you just update your resource declaration to include a “disposition” attribute:

Now your page will load with jQuery in the head section, with no code changes to your layout or GSP!

Dependencies

So far, so good but how do we control the order of resources when they are pulled into the page? How can I make sure that my application JS or CSS code always loads after the JS and CSS from a plugin that I’m using?

This is where Resources dependencies come in. There are two simple rules

1. Resources from a given module are loaded in the order they are defined in the module
2. Resources from modules are loaded in module dependency order

The first rule ensures that when you declare resources you can intuitively see which CSS or JS loads before another.

The second rule uses the “dependsOn” method in module declarations to list the names of other resource modules on which the module depends. Those will always be loaded before the module that depends on them. Here’s an example declaration that alters our specimen module to depend on the jQuery plugin’s query module instead, and jQuery UI:

Notice that we have specified both jQuery UI and jQuery in the dependsOn. We don’t need to. However notice that they are also declared in the “wrong” order. This is to illustrate that the order you use here is not important – the ‘jquery-ui’ module declared by the Grails jQueryUI plugin depends on on ‘jquery’ (provided by the Grails jQuery plugin) as well – so it will always make sure that is loaded first.

As your application does not define those two modules, you would need to install the Grails jQuery-UI plugin – or define them yourself. Including the jQuery-UI plugin automatically pulls in the jQuery plugin for you, because of Grails’ transitive plugin dependencies. TheResources framework was designed to work hand in hand with the other Grails dependency mechanisms.

So now you have done this, you still have no changes to make to your GSP! It still just requires the “common” module. Notice how this has decoupled your GSPs and layouts from the details of the resources that they need. This is an important feature that gives you great scope to modularise your resources, and even have page-specific modules if you like that contain nothing other than dependencies themselves:

With this, an edit.gsp could just r:require the “editPage” module and never care about the explicit details of what is required.

Dealing with your ugly inline Javascript

You already know that inline Javascript is pretty horrendous, but some things are just plain shameful and yet we can’t help ourselves. Frequently you want to write a Grails taglib that simplifies using a JS library and to do that it must render some code inline when the tag is invoked.

With Resources you can trivially throw this JS code around to wherever you like. You can have the code render in <head> or at the end of the body, and it will automatically do so after loading the resources that the page depends on. To do this you just use the <r:script> tag instead of a normal <script> or <g:javascript> tag:

In this example the script code specified in <head> does not run immediately. The r:script tag also uses “disposition” and the default is “defer” so you will find that the alert only pops up once the rest of the page has loaded, and the HTML source will show the <script> tag at the end of the body, after all other deferred JS code has been pulled in.

All such fragments in the same disposition are concatenated together, so you don’t get a long list of <script> tags.

To force a fragment of inline JS to execute in <head>, just add disposition=”head” to the r:script tag invocation.

To write your own taglibs that generate code in this way, you just output the result of calling the r.script(attrs, Closure) tag from your tag.

Linking to images

Images often need to be optimised or set for long-term caching. However you don’t normally need to declare them in modules. To render images correctly you should use the <r:img> tag anywhere in your pages as you would and HTML <img> tag. All you do differently is supply a uri or dir/file attribute to tell it where to load from. Other attributes are passed through:

That’s all there is to it.

There are however some extra tricks you can pull. Any tag attributes specified in a module resource declaration are honoured when rendering the link. As such this means that you can specify your width & height values if you declare your image – and never have to specify them when rendering links:

Now any r:img links to that logo will automatically include those attributes in the output. Notice that we had to include the disposition “image” which is not a predefined disposition – it is just anything other than “head” or “defer” to prevent the image being rendered by the r:layoutResources tags.

Bundling: combining files to reduce the number of requests

Page load time is a combination of many factors. Those that you can control from your application itself include how many requests are needed to load your page and whether you load resource before or after your HTML content.

To reduce the number of requests made, you need to combine one or more resources into a single file. This is called bundling and what you do is tell Resource which files can be bundled together. This is usually dependent on how your application uses the code, and inevitably requires some compromise.

For example you could bundle all your resources into one file across your entire app – resulting in just one CSS and one JS file for the entire site. With aggressive browser caching this could yield good results, but if you have a few hundred KB of code in these files it could mean it takes a long time for people to see your site the first time they visit or empty their cache.

To specify the bundle that a file belongs to, just add the “bundle” attribute to resource declarations. The Resources framework will not bundle together resources that are incompatible: different content types, or those with differing “attrs”. For example CSS with media=’print’ will not be bundled with screen media.

It does however allow you to bundle resources across module boundaries. This is important as you will see shortly. It also automatically bundles using the module name by default, and maintains separate bundled files for head and defer dispositions automatically.

That is a lot to take in, but it basically means you don’t need to worry about anything.

Just set the bundle attribute:

Here the main.css, which previously might have auto-bundled into bundle “common” if there was more than one resource in the module, will now be bundled into bundle “core”.

The difference has no effect for now, but what you can do is override the module declarations that came from the jQuery plugins and make them go into the same bundle. To do this we use the “overrides” mechanism to change the properties of the resource modules supplied by the plugins. We can call the defaultBundle method to change the default used by them:

Now all the modules will throw their resources together, and you will find your page (again with zero GSP changes) is now pulling in just three files: bundle_core_head.js, bundle_core_head.css and bundle_core_defer.js

Changing how links to resources are rendered

Under the hood, the r:layoutResources tag uses the r:external tag to render links. The r:external tag is a smart tag that writes out the “right kind” of link for a resource. So for JS files it renders <script src=…> tags, for CSS it renders <link href=…>, and so on for favicons and a few other types.

The key thing is that you can pass any other attributes to r:external and they will pass through to the output. It so happens that r:layoutResources pass the “attrs” Map defined in your resource declaration when calling r:external for that resource. This means you can pass any extra attributes you like to the declaration and they make it to the output.

A typical usage for this is to specify media:’print’ on a CSS resource, because the default for this is “screen, projection”:

Note that if you specify these extra properties, those files will not be bundled with others, as by definition this isn’t going to work out well for you.

Wrapping the link in some other code. AKA MS IE workarounds

The resource declaration can also supply some wrapper markup that is used to render the link, with the generated link being passed in as a string. You normally use this to wrap a resource such that it is commented out for all browsers except MS IE:

The wrapper Closure is passed the link text as an argument. You are then free to pre/post-fix it with anything you like.

Linking to specific resources without using the dependency mechanisms

On occasion you may need to link directly to a resource that is handled by the framework, without using r:layoutResources or r:require.

To do this you can use r:resource to get the URL of a resource, or r:external to create a link to it. You can use these to generate absolute links to those resources, for example in an HTML email.

These tags accept the regular uri, url or plugin/file/dir attributes. The r:external tag also supports a “type” attribute to give it a clue what kind of link to render if it is not obvious from the file extension.

Overriding resources from plugins

Plugins that expose modules normally do the right thing, but sometimes you might need to supply different content for a given file, or change some of the tag attributes or the bundle used. To do this you use the overrides mechanism shown earlier in the defaultBundle example.

The “overrides” closure lets you specify new values for some of the module defaults for a given module, but also lets you tweak individual resources if they can be addressed uniquely. Developers must add an “id” attribute to the resource when it is declared for this to work:

This changes the bundle on just the resources with id “js” in the original jquery module. There might be one or more resources with that id in the module. Resources in other modules are unaffected.

For full details of what you can override, please see the Resources plugin documentation.

Using r:require in GSP fragments

Using g:render to render GSP templates to build up your pages is a powerful technique. What you may not have realised is that you can completely modularise these templates now because the enclosing GSP no longer needs to know what libraries they need.

Yes, you can call r:require at any time in GSP rendering – including inside nested GSP templates – and the dependencies of your code will be stored along with your request and the resources all tallied up when the r:layoutResources called in your Sitemesh layout execute.

The only pre-requisite is that your r:require must be invoked before the corresponding r:layoutResources that you’d like to use to render it.

Picture how easy it is now to create portlet-like user interfaces where only the resources needed by UI elements displayed to the user will be loaded, and when they are they will be optimised. The portlets they have not installed or disabled will not load their resources if you do not render their GSP template.

Dynamic requirements

It is important to realise that the r:require tag can support normal GSP EL values in the modules list attribute. This brings great power because you can change the code pulled in by a page at runtime. For example you can make yourself a trivial per-user theme-switching system by storing the name of the theme they want to use in the session, and using a tag like this:

This will locate the theme module and all its dependencies with no further coding.

You could even switch the entire JS library and supporting code used by your plugin’s UI so that, for example, the user could choose between jQuery UI or YUI, or their own implementation.

Including common resources in your layout

Most likely you have some resources that are used in all pages using your Sitemesh layout. This is no problem because you can call r:require inside your Sitemesh layout, with the same proviso as “Using r:require in GSP fragments” – they must be invoked before the r:layoutResources call that would render them.

This means that in practice your individual GSP pages are likely to have only one or two module requirements as the rest is handled by the Sitemesh layout.

Patterns for plugin authors

Here are a few emerging patterns for plugin developers to heed when supporting the resources plugin.

• Specify id attributes on your resources when declaring them, to maximise the user’s opportunity to override specific details
• Avoid monolithic modules, opting were possible to separate out functional areas such as the jQuery UI theme being separate from the jQuery UI code. This gives developers more flexibility. Obviously you must maintain correct dependencies between these
• Put “development” un-minified versions of resources in “<yourmodulename>-dev” modules, so the user can pull in un-minified versions on demand, per-environment if they wish
• Do not specify the bundling of your modules – at most use defaultBundle. No per-resource bundle attributes. Let the developer control this easily by overriding your defaultBundle settings in each module.
• Use module names prefixed with the name of your plugin followed by a hyphen i.e. “jquery-main”, “myplugin-theme”, “acmeplugin-ui-styling”

Summing up

All the things we’ve tackled here are core Resources framework features – no extra plugins are required. The resource mapper that performs bundling is even built into the framework.

The real fun starts when you install some of the other mapper plugins – they may be renamed, re-encoded or even compiled from one form into another. It all happens at startup for declared resources, and at runtime for ad-hoc resources. Once it’s been done it is stored on disk on the server in that state and no more processing is done.

I hope you have fun with the Resources framework!

There are some nice refinements and maybe some new features coming in point releases at the time of writing.

Such an interface is called skeumorphic. No I didn’t know that term until recently either.

I will say for a start that I love the iBooks page curl as you turn pages – because it is so impressively done. The page curl in e.g. Kindle for iPad doesn’t come close. It isn’t as interactive (limited axes of movement) and is much slower. This destroys the illusion.

Apple’s implementation is a prime example of “surprise and delight”. For those that care, at least. It must have been hard work getting such a high frame rate off that dynamic page curl code. These people know what they are doing.

However, the wider issue here is that the “wow” element of the implementation may well just be Apple engineers making the best of what has been asked of them.

What I mean here, is that the book metaphor was likely not chosen so they could show off a page curl. It is there for one reason only. Books have pages.

The entire concept of ebooks needs selling to the rest of the world, not to geeks. Geeks like pressing buttons to advance things. They think “realistic” interfaces are lame. It may well be that many people at Apple think so.

However what is Apple’s goal? It’s to sell e-reading to the masses, not the geeks. MG Siegler has had the similar realisation in terms of the entire iPad offering (hmm, wasn’t it obvious from the start when iPad was announced?).

With this in mind you need a drop-dead intuitive user interface. You are also re-framing something that already exists in the real world. Therefore the sensible thing is to supply the same visual cues to the user (recommended reading: The Design of Everyday Things).

If you present a novice user with a straight rendering of an ebook page with no chrome, unless they have used something like this in the past they cannot know for sure how to turn a page. There are too many options:

• Swipe left or right
• Swipe up or down
• Tap left or right
• Tap and wait to see what pops up
• Try to find a button to press
• Shake the device until something happens [AKA curse the geeks who designed this crap]

This is why there is a single visual cue in iBooks – a simple bitmap added which instantly gives the user an idea of what they can do and how they can expect it to work. The page edges:

Now, think about the implications of this. Once you add this simple image to the edge of your display the user is intuitively shown that page traversal will be horizontal.

The user then has an expectation that they can turn the page with their finger, after all that is what other objects (real books) they have with these page edges showing do.

This means you have to implement a dynamic page curl, whether you think it is cheesy or not. It needs to be a shit-hot one or it feels worse than a real book, not equal or better. Remember the sell here is “ebooks are better than real books, they are the future”. The benefits of ebooks are not that they do not have pages – they do – it is that they are portable, searchable etc. Real books have great navigation built in.

This page turning is a necessary introduction for novice users that becomes a major feature and development effort, because it is commercially very important. You need great visuals for everyday (non-geeks) to be impressed by what is essentially a document viewer.

For advanced users, and those new users who start to become more adept, it supports tapping on the left and right sides anyway which users will discover over time. There is no need to go through the effort of swiping – unless you like playing with the effect, which I certainly do because it is a joy to behold.

Unlike the Kindle app’s one which is laggy and feels like you have pages made out of heavy cardboard.

So what I’m saying here is – though I will not pretend to be able to read the minds of Apple – I am pretty sure that this was part of the thought process, it makes perfect sense.

People think Apple are all about design. Apple are all about the user experience. That means that what you see is not always an expression of the best design taste, or even what they themselves would think is the nicest presentation.

Its about the best presentation for everyday non-geeks, who are the people slapping down dollars hand over fist to buy the iPad – not the Android geeks who are still waiting for a non-iPad tablet that’s actually useful.

Usable design is not about elegant zen-like perfection – it’s about making things that people are comfortable with and can use without learning much, if anything.

The page effect on Address Book in OS X Lion however, is a different matter. It serves no purpose except to stop the app looking quite so dull as it did before. Unless there are touch-capable OS X machines out there we don’t know about…

Further to my contribution to the everlasting mobile web apps vs native debate I was discussing these issues again with good friend Richard (who is truly called a platform ninja), and again cropped up the “why is a tablet different from a desktop then? why is native better for tablets and not desktop?” question.

Here’s my take on this, and I’m going to keep it short:

1. The web is a shit platform for making applications. All this effort we developers are putting into it to is well out of scope.
2. As many others have noted the primary attraction is that it is easy/easier to make cross platform apps with a web browser.
3. My conjecture is that point (2) is the only reason people have accepted desktop “apps” that are web based.  There was no other choice presented to the users, and the developers had no other choice.

The failure of Java as a cross platform UI/desktop consumer app environment is to blame for point (3).

It meant app developers had to begrudgingly support a mass market of Windows devs while actually using Linux or Macs themselves because Windows back in the 3.1 -> XP days was so unutterably shit. If you’re afraid of writing native apps for iOS or Android, you should have tried writing Win32 applications back in the 90s.

So the web came, and these devs had to keep their apps supporting Linux because they used Linux themselves or had Linux guys screaming at them – but largely ignored the MacOS users (hey I should know, I was one of these developers). The only way to do this was with the web.

Desktop apps, even if you could find a cross platform framework that was not total shit (this is impossible, an immutable rule of the cosmos), require lots of support, required per-platform installation scripts and documentation. Oh and nobody really paid for apps after the initial trend of Shareware subsided.

Consumers didn’t want to pay Joe Bloggs $20 for this or that.

So freemium was born, where we all have web apps and only a select few make real money. We don’t care if they actually need to be web apps, we just choose it as a default because it is what we know, and we are scarred by the memories of 1990s native development.

Well here’s the reality check. It’s nearly 20 years later. Expectations of apps are much higher now. Quality and UX is much more important. Making cross platform (including mobile) web apps is now harder than it ever was because there’s so many more layers of stuff we have to schlep into the apps, and reams of JavaScript to do anything half decent. To still fall far short of any meaningful native integration with the desktop O/S’s features.

…and now Apple and others are creating high quality app stores for native desktop software. This means that there is a simple “arms length” route to market. Millions and millions of users who can and will pay you $5 for your native app. Which, when you have made it native, is likely to be quite easy to port to at least 1 mobile platform as well.

As mooted in all the native vs. web mobile app discussions, the classic issue of access to all the raw platform features comes to the fore. This is even more important on desktop if you are making actual apps rather than services.

Ergo, I see a distinct possibility that the stage is set to that native desktop could actually kill the notion of the web “app”. By apps I am talking things that are distinguished from online services. The web is document retrieval and viewing. That’s always what it was designed for.

Photoshop, Keynote, Email, bla bla. These can be much better as native apps – there have  been many impressive attempts at web versions of such e.g. 280Slides, Google Mail etc.

However the cloud is not the place for the hosting these desktop apps. The cloud is just the place where you store the data.

People are used to cheap tangible purchases on mobile. They will expect the same on desktop. Its a massive opportunity for developers again to create really compelling applications. Free of the shackles of the 1990s – both in the sense that native platforms are much nicer to develop for now, and that the constraint of limiting your ideas to what is capable in a browser that 80% of your market uses can now be lifted.

Go and build great native desktop apps, go and build great web services. Don’t mix them up.

[Before you dismiss me as a madman, I've written many native Win32 apps in C, C++, Delphi. I've written many web services from right back when Mosaic was the only browser we had. I've also written and ported many J2ME mobile apps. I've also made my living off selling shareware as well as consulting.]

[Also interesting read here: http://mattgemmell.com/2011/07/22/apps-vs-the-web]

The most interesting figures for me are that almost 50% of respondents do think there is a need for commercial plugin support, and that a lot of respondents’ companies already pay for commercial tools and support.

Also it was interesting to see the breakdown of usage of my existing plugins, as well as the spread of Grails versions in use. This survey happened just after the release of Grails 1.3.7.

View the survey results here.

I’m very squarely on the “Native is best” side. Obviously if you don’t have the funds/expertise to make a native app then you’ll choose web – but I would wager this is only viable if you don’t actually want to make money out of the app. Unless you have some amazingly compelling content (like pictures of naked people) that can not be got at by native means.

The thing is, I’m not really interested in arguing this any more as its a classic polarized debate like the Mac/PC or Linux/Windows ceaseless arguments. However most people in web development seem to be very anti-native, and as I’m often the outsider in such things, but also sometimes right, I need to set out my stall so that I can try to keep my mouth shut in any more such discussions!

Let’s get this straight. Web is the perfect platform for presenting documents. It is what it was designed for. Everything else has been a hack. We have many very clever and useful libraries such as jQuery to make web application development half-passable. However anybody who seriously thinks these are anything close to a great development platform is chugging on a crack pipe.

Or not an actual developer, but a web site designer who wants to cash in on making mobile apps.

Before you stop reading – I’m a web app dev of many years, and also did more than my fair share of mobile development.

The Web is no cure-all, it is an ugly hack of document rendering turned into interactive UI paradigm. The only selling point for it is that it is cross platform. But your experience – even on powerful desktops – varies widely based on CPU, RAM, and browser – it is simply impossible to make great cross platform apps because to do so is to ignore the native OS paradigms, or poorly mimick them.

Why is it that we are still amazed when someone creates some “fast” game in JS and CSS, or creates some amazing new visual trick like… and animated background or … 3D!

I means seriously, WTF people? We were doing this stuff on ATARI ST when I was a teenager (> 20 years ago), and this still gets a “wow” when somebody manages to make the godawful browser tech stack do the same using CSS and JS? That’s not progress, that’s a SHITTY PLATFORM FOR APPS. Its like we all became stupid and forgot everything that goes on in the rest of the tech world once the web hit.

We’re amazed when stuff like this is done because its so damned hard to do anything good in a web browser. That’s why designers and animators used Flash so much and cursed us for a decade. It is nothing more than triumph against adversity.

The native OS paradigms (visual or otherwise) issue is borne out in the great many “Cross platform” frameworks that have existed over the decades. If you don’t know the awfulness of J2ME, or Java desktop UIs (Swing), or Tcl/Tk and all the old C++ cross platform toolkits, you have no idea how bad things get. This is in part a reason why Java never took off even when delivered via the web and is also part of why Android and iOS are eating the lunch of all the other phone O/Ses whose only realistic entry point was J2ME.

Anybody reading this remember WAP? The mobile Internet that was, right on your phone, back in the early 2000s. What a crock of shit. Why? The UI had no personality, and no styling. It was slow and clunky, and admittedly ran on shitty phones with tiny screens.

WAP lost out to J2ME – a lesser of two evils – which you could consider a “native” app vs. WAP’s “web” approach. J2ME won that battle, even though people (like me) had to write sometimes 30+ different ports of the same application to handle different handsets. And we’re not talking just different graphics/screen size here, different data/game levels, different media, different code workarounds to handle bugs and resource limitations.

But still it was better than WAP. You had complete control (if you ignored all the J2ME horrible UI libraries) and could draw pixels. WAP… you could show stuff on screen badly, and maybe submit some forms.

Web on mobile is today’s WAP, in the same way that Native (Android/iOS/Windows Mobile/WebOS) is today’s J2ME. For compelling apps you need to use native stuff. What language you use to write that is less important. i.e. PhoneGap apps that use JS to glue together web UI and native features like location, camera etc are native apps. They are just slower, clunkier, non-native UI and feature-limited compared to true native apps.

The pace of development in mobile devices is now unlike anything we have seen before. 6-12 month refresh cycles of hardware and OS releases means the web will never catch up, not even close.

The ease of development used to be a USP of web sites, but this is most definitely not true for non-trivial web apps. For a start, for anything non-trivial you need a back-end server app and all that entails.

Web developers who think web apps can replace native apps ignore another major issue aside from native capabilities and integration – resources. When was the last time you, as a web developer, cared about how much memory visitors to your site had, or how fast their CPU was?

As a result performance of web applications varies immensely across clients and this matters even for simple forms or content display (layout complexity, images etc). On mobile this is a critical issue. You have to test your web app on every target device your users may be using.

Think about that.

You’re doing that right now for maybe 3-4 browsers across maybe 2-3 OSes (you are, aren’t you?).

Now extrapolate that level of work to every mobile device out there (especially the large number of Androids), as they all have difference browsers and vastly constrained resources, and different pixels-per-inch which affects usability of touch UIs.

Native development doesn’t skip this problem completely, but it gives you a feel for the size of the challenge that awaits you. Using native UI widgets you are at least nearly guaranteed some reasonable behaviour out of the box.

The point is that web development might get you somewhere, but it is unlikely to get you compelling revenue-generating apps unless your product is incredibly trivial and unique – unless you focus, like J2ME developers had to – on the devices that make up the largest market share – so iPhones and hopefully just a few of the Android handsets. Oh and maybe a HP device too, eh? Oh and Windows Phone.

If you are selling an “app” commercially you better be sure you can deliver it in working order to your end user. Make that a “paying” user. Not so many of those on the real web are there.

Many web developers fail to understand that mobile devices are “embedded systems”, it is not just your desktop web available in your hand. The user expectations are entirely different from desktops. Its so frustrating that people don’t seem to get that this is consumer electronics: where you push an ON button and stuff happens right there and then.

You pick up a phone to do something, it has to do it quickly, cleanly and reliably. The user does not see a mobile device as a mobile desktop (though more powerful than PCs we used not too long ago) where its OK to spend 15s loading, bombard them with some pointless screens, download a ton of crap off the web.

Even a great deal of native apps fail horribly at this. They take too long to load, the UX is poor due to excessive navigation etc. I have some laughably bad iOS apps installed on my devices – which occurs because there is no try before you buy / returns policy, a major flaw that needs to be rectified. And if it does get rectified, you better fear for your app-store hosted web apps.

The fact is mobile devices are now so desirable as a platform precisely because of Apple’s iPhone and the native iOS. Web developers may see these as sexy devices they’d like to do stuff on, but everybody else sees these as great things that work better and faster than their old computer, with less fuss and (so far) no viruses – and nobody thinks of these as being like web apps but packaged up. Web applications pull it back to the sluggish land of the desktop. Response time is everything in touch interfaces.

As for native OS integration, whether using HTML5 features (still not fully standardized) or custom JS APIs á la PhoneGap, the features available will always lag behind native apps, and will usually lag behind in performance. HTML standards processes are inordinately slow and protracted. Never, ever expect and quick turnaround innovation from HTML. Just forget it.

“But my app is not performance dependent”. Yes it bloody is. If the user taps or drags stuff and it doesn’t happen in smooth realtime like native apps, you stick out like a shit on the arctic tundra. Remember that your app is competing UX wise with all the great default apps shipped on the device (well at least as far as iOS goes).

“But I don’t need native integration or true native UI”. Yes you do – as soon as you have any form of native competition. And if you are pursuing a market that actually generates decent income, you can bet people will come with native equivalents.

Some people point to WebOS – it’s web based technology. However it is effectively native, another proprietary platform. Its yet another OS to port to. Are people seriously saying that, even if performance issues don’t emerge from this, that they’d like to use all this hacked together HTML/CSS/JS crud we’ve amassed over the last 10-15 years to write apps for a tiny device that can have a perfectly good, fast, tightly integrated app written using the well-documented libraries provided in a native language? It’s a little like writing scalable web app back ends using BASIC. You could do it but… its the wrong tool for the job.

An interesting blip here is Symbian. This was a native OS platform on all the big Nokia devices. However it failed – the crown went to the UX-inferior J2ME platform present on the same handsets. Why? Presumably because there was no commercial marketplace of any worth for the apps (the handsets always featured low in app sales, a very small % of total market), and the devices it ran on were the horrible Nokia bricks that cursed us for the last 10 years, cost a fortune and had bad battery life.

In a nutshell the Web is a pile of cobbled together crap – from an application development point of view.

We can put up with this for true web applications/services as we can’t face writing native Windows, Linux and Mac OS X clients for our apps – it makes us gush when a tool like jQuery reduces the pain level by another 10%. Our users are accustomed to this paradigm, and for many of our apps we don’t need any whizzbangs that require really obscene hacks like Flash for camera access etc. Because their PCs/Macs are a bit of a hassle to maintain they appreciate not having to install apps. They also don’t expect always-on connectivity so settle for “just while I’m sitting at the computer”.

Even with tablets, there is no point making a web-based app for them. Just make your normal site work well on tablets. Desktop users will likely appreciate the improvements too. I can see the attraction of making a tablet-optimized “app” because its reasonably quick and cheap, but really, put that work into your regular web UI. For a Rolls Royce experience for your tablet users, give them a native app if it is commercially sound to do so.

The User expectations of mobile, including tablets are completely different. The device is a tool to get stuff done. In contrast to “I’m now sitting at my computer doing a bunch of stuff”.

Let’s not even talk about battery usage…

Bottom line: Mobile development is really hard work, involves lots of time and testing, the likes of which desktop web app developers have little idea about. Browser wars are nothing compared to real cross platform dev where the end product is high quality.

If you’re going to do it properly, do it native.