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.

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]

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.

The interview can be found here.

I often feel like I’m in the wrong job. I love the real world, being outside, being with my family. Staying indoors all the time in front of a computer is a bind, thought it obviously conveys benefits to my family so one can’t complain. I am also incredibly privileged to spend most of my time applying my sometimes hard to constrain creative urges, rather than plodding along doing dull grey work.

Working outside of the corporate office is something that all companies should strive to support. It is challenging, buy we should be driving forward developments to make it less so for more people. There was a recent article about this and increased productivity I read, and it holds true.

I digress.

Yesterday I worked out a change to my routine, a life hack if you will. Every other Tuesday afternoon I get to emerge from the grails shack early to charge up my rock batteries at a drum lesson. I the past this has meant I lose 3 hours of work time due to driving to and from the lesson and lesson time.

I decided to change this by cycling to the train station in future, about 15 min each way, get the train to drum lesson (station is opposite) and work on the train and in any waiting time. Exercise + outdoors + more work done = win. I tried it out yesterday minus the cycling part (bike needs fixing) and it worked great.

Sort of. I got another 2 hours work in, but not connected work.

Opposite the station is a café and a large pub. Neither have wifi free or paid. In a city opposite the major rail station. In 2011. Commercially this is madness for those businesses. Want to be full of commuters buying stuff? GET FREE WIFI. It is like water in a desert.

Today I have to return to another part of the same city to have my car serviced at the official dealer. I don’t have a fancy car (Toyota) but since they paired up with Lexus is means we get a swanky dealership, free coffee brought to you etc. I my shorts and t-shirt I feel like a kid in a grown-up’s world.

So I have to work here for a few hours. You guessed it, no wifi. Plenty of chairs, comfort, free drinks but no wifi. Wtf. There’s nowhere nearby with wifi either… Ok there’s McDonalds and KFC and I will have no choice but to go there shortly. It should come as no surprise that these efficient businesses have grasped what smaller businesses appear to have missed. (notable exception Star Anise café in home town of Stroud has free wifi for patrons yay!).

There is however good 3G and yesterday morning I paid O2 for tethering on my iPhone to remedy this in future, but 24hr later it’s still not up and running, despite “within 24hr” commitment. Here’s another real world fail – telcos like o2 send you automated text messages, but they have no way for you to reply and interact with someone. This is a one way customer mis-service:

The fact you even have to “order” tethering and it can’t be enabled immediately is pretty bizarre in this connected world.

But going back to the wifi… basically I’m complaining about the ineptness of UK businesses to adopt what is actually nearly 10 year old technology now, for their own benefit. This is basic stuff. Make money by going the extra mile.

UPDATE: McDonalds stank, had The Cloud wifi but neither iPhone nor MBP nor MBP with Skype Access could connect. KFC had nothing. Found Starbucks in a Sainsburys supermarket. No wifi at all. And they wonder why the UK is not very competitive or innovative any more.

And while I’m here, I happened to notice something really depressing about our society, probably a global phenomenon. Driving here I passed a junction where, on the corner, sat a beautiful and ornate remnant of our society’s past.

On this corner sits the base of what must have been a cast iron lamp-post. It is ornate like you wouldn’t believe, with swirls and botanical motifs over it.

Next to it, like some kind of poor excuse for a replacement, is a long grey pipe with a traffic light strapped to it.

Where did it all go wrong? Where did pride in our streets and urban environment go? Was it the war and the make-do era? Why has this not returned now that it can be argued there is a biggest passion for design than ever before? It does not have to cost, the material is not as important as the aesthetic detail.

When you look around, our streets (certainly in the UK) are full of ugly “street furniture”. This stuff is the difference between walking through your shitty, dirty, soulless urban environment and a classic European city’s old quarter back streets full of charm and attention to detail. Architecture is part of this (but who said cheap architecture has to be free of beauty?), but the “street furniture” of railings, lamp posts, traffic lights, litter bins, pavements, telco wiring boxes etc are everywhere and detract from our environment in such a pernicious way we cannot have pride in these places.

And that affects how people feel, and how their lives turn out.

Aside from all the basics, they allowed 3rd party applications on the device AND the desktop to talk to each other directly to sync custom data. I’ve bitched about this before.

As an avid Mac, iPhone, MobileMe and soon to be iPad user, I have to wonder what is happening with this at Apple. My real-world gripe is this:

I was just about to open OmniFocus on my iPhone specifically so that it would sync with the latest data on my MacBook Pro, which is set to sync via MobileMe (using a pretty ugly file based solution). Why am I even doing this? Why isn’t this data synced (a) when I dock my iPhone to sync all the other iTunes stuff, and (b) why can’t it automatically sync wirelessly

Well part (b) is easier to answer, although it is a three-fold answer. First, there’s no background app support to allow automatic sync of the OmniFocus app on the phone. That should be addressed by the Push API functionality except that OmniFocus doesn’t support Push API (server cost to them to do so) and even if they did support Push, iPhone SDK Push is not able to automatically pass the data to the application to force it to sync – the user must acknowledge the event and run the app on the phone manually. It’s a pile of suck, surprisingly, with a real feel of “disconnected device”.

Part (a) is more tricky to answer. It must be trivial for Apple to add this kind of support for direct-to-app syncing. They already have/had Sync APIs for OS X for a long time. Lack of support for this apparently makes no sense.

In conclusion I am very surprised that Apple has not updated the OS X Sync APIs so that:

• Third party apps can sync any data they like to/from the iPhone/iPod/iPad with iTunes as the conduit (that was the concept’s name in PalmOS if I recall)
• The transport for sync is completely hidden from the applications such that sync will happen transparently via Dock, Wifi (direct between devices on local Wifi network), and via MobileMe cloud if the device is not on the same Wifi network.

This is not rocket science after all. And yet we still have to know / think about what networks our devices are connected to, manually make sure we run them frequently etc. It is pretty lame, Mr. Jobs.

Many many people have this desire: a single place for all their media: music, videos etc.

A NAS device is the place, backed up suitable. The problem is iTunes / Front Row just does not fit with this strategy if you have more than one computer / Apple device.

The core issue is that iTunes does not automatically rescan the media folder for new files. So you can point as many iTunes as you like to a shared location but they will only see the files they add to their libraries via purchasing or importing media.

So you end up with many devices in your house, all with a different view onto your shared media.

To access that new album you imported, you have to manually Add To Library on that iTunes instance, hoping it isn’t set to duplicate the files on the server. When this happens, as it certainly used to for me, you then end up with many copies of albums as you re-create your library from scratch on the various computers over the years.

Add to this the fact that if for some reason your connection to the NAS goes down when you run iTunes, it will revert the media path to the local folder, and you end up with a total mess – a bunch of machines with files only on some of them, their media split between local and NAS, and only the ones that added those files having them listed in their library.

The experience is so un-Apple it is shocking, and it causes daily pain.

It is important to remember that the iTunes Media folder is where it PUTS files that you buy/import – and that is ALL. (There is a new “Automatically add to iTunes” folder there, which seems half-assed to me). The iTunes Library is specific to each computer and is the list of media and the file path to each. This, unlike the media folder that actually stores the media files, is something you do not want to share between computers in many cases.

Now, iTunes 9 added Home Sharing. But guess what, this sucks and blows! Why? It (a) only shares iTunes-purchased content and (b) it duplicates the files to your local HD. Home sharing, I believe has a lot more to do with the iSlate/tablet and their new datacenter – music in the cloud crap – so you can sync your iSlate content without a cable.

Please Apple, it needs to work like this:

How it should work

This is relatively simple:

1. First, never change the media path in iTunes if the previous path is not reachable. Tell the user what is happening so they can fix it
2. When new files are added, make a bonjour announcement to any other iTunes running (perhaps even wide-area bonjour to make iPhones/Slates pick it up) so that they can instantly add the file to their iTunes library
3. When a file is not located on the local disks, have a local cache for stuff that the user ACTUALLY PLAYS. My wife doesn’t like all that heavy metal I listen to, so let’s not fill her hard disk with a clone of it eh? iSlate and Apple TV / mac mini media hubs etc can pick up just the files that are needed.
4. For the occasion when not all the machines / iTunes are running, have iTunes do daily rescan in the BACKGROUND for any new files in the media folder and AUTOMATICALLY add these to the Library. This is not rocket science.
5. Maintain an “excludes” list on each iTunes library so the user can remove items from their local itunes Library (without deleting it from the NAS) and they will not be offered the file again in a future background sync.

Don’t give me stuff about non-purchased media not having ISRC codes to identify them and de-dupe. You can dedupe on SHA hashes of the media (calculate once and embed in the metadata of the file) and failing that trackdata, and then failing that – USER INTERVENTION eg “There are some new media files added and we don’t know if they are duplicates or not – help me”.

You can even put all these newly discovered files into a special “Newly discovered” place in iTunes where the user can yay or nay them – or have it set to auto-accept (default).

The more and more macs and related devices are sold to households the more shitty this problem becomes and you REALLY REALLY need to fix it Apple. Without the cloud. The cloud is not a solution for terabytes of media being instantly accessible in your living room.

Please. Just do it. iTunes Home Sharing was nearly it, but sadly failed completely to address this.

It is noticeable that Mac OS X and related apps are moving to user interface paradigms that will work much better than conventional UIs on (touch controlled?) TVs and multi-touch tablets.

Some examples of this growing trend:

• Front row started it really
• Several Apple apps with full screen modes. Especially the new quicktime X and its large transport buttons, iTunes/Front row with Coverflow, iPhoto with multitouch trackpad support
• The new exposé screen layout, touchpad gesture and per-app exposé
• Spaces – something that will prove MUCH more useful if every application is full screen, and effectively each Space is a single Application. Then Exposé sort of becomes the current spaces “zoom out”
• Safari “Top sites” is, in my opinion, clearly targetted at touch (tablet) displays.
• iTunes LP media format
• This is the big one – iTunes “Home Sharing”. This is required to solve the problem of your TV/tablet as a media purchase platform. You will typically buy content at home on a TV/tablet and then expect it to be on your laptop and hence iPod.

So I expect, within a few years, for us to see a new paradigm at least for TV and tablets where apps run full screen and you swipe to switch application… and wonderfully simple UIs as a result.

If we can only do away with the keyboard, we might finally be rid of these rather old fashioned apps with lots of menus and shortcuts and yada yada.

What’s happened is that I’ve found a couple of “minor” bugs, which have hit me in different ways and in different combinations in a client projects including the Weceem CMS 0.2 which is coming along nicely although we have had to battle with some of these problems. It seems like once you find something you can’t get away from it.

Anyway these issues have been raised in Jira and are scheduled for fixing soon. Here’s a breakdown of them and any workarounds:

1. Grails will no longer (?) let you bind null “noSelection” values to relationships. If you have noSelection=”['':'None']” or similar on a select box, if you select this on a nullable relationship field you will get a plethora of binding/validation errors. It seems the empty value is enough to have grails believe you are trying to create a new “inline” instance of the referenced class, which typically fails validation but may not depending on your constraints. Eg this could be creating extra instances of classes you don’t know about if you have lax constraints on the related class. Jira issue here.
   Current workaround: for a relationship to a “Template” object field named “template”, your action needs to do this:

   if (params.'template') params.remove('template')
   if (params.'template.id' == '') params.remove('template.id')

2. It is currently impossible to query for null associations on 1:1 relationships using any mechanism – criteria, dynamic finders, HQL all return empty results. This ties into the previous issue – say you want a UI to select the “Author” of a book but you only want to allow Author to be used once in any Book(s). To present a list of Authors that have no “book” associated requires this kind of query. This is actually a Hibernate bug that needs votes + comments to get it fixed. Grails Jira is here.
   Current workaround: the insanely inefficient list and collect (beware of blowing heap):

   Author.list().collect { it -> it.book == null }

3. Invoking tags as methods and passing in bodies is a bit broken. Jira issue here – and a workaround for FCK editor is jira’d here. Basically if you invoke a tag as a method and need to pass in a body… your mileage may vary. The body is output immediately when executed, instead of returned as a String. So if you try to say have your own tag that then calls the FCK editor tag with some canned data it won’t work.
   Current workaround: change the tag you call to not evaluate the body() until it is needed in the output. Another option (untested) is to embed the invocation of the tag into a GSP fragment and render that using g:render instead.
4. The “transients” settings on GORM classes is not currently inherited if you have descendent classes. This might be causing you some embarrassment if you aren’t aware of it. Eg. If you have a domain class with descendents, check your database schema and your data to see if values that should be transient are being persisted – in particular passwords. Jira is here.
   Current workaround: Always declare a transients propert in your descendents even if you don’t need it, assigning the inherited value. Eg something like:

   class HTMLContent extends Content {
       static transients = Content.transients + [ 'summary' ]
       //...
   }

Thanks to Graeme for his help confirming and nailing down these problems. Looking forward to fixes in 1.2

It seems that we really do need Grails users to hassle the maintainers of the components Grails depends on eg Hibernate, to get issues that break functionality in Grails fixed. All users of Grails are indirect users of these underlying technologies. This gives us rapid productivity gains, but can also cause delays getting issues resolved when they can’t be worked around in Grails.

So get the vote out – if you find a Grails issue dependent on another project’s bug, please vote for / comment on issues in those other issue trackers to up the pressure!

Now this is particularly interesting to me as I have a fairly well developed idea for such a service, and had begun implementing this using the iPhone with a custom iPhone application (and of course a Grails application for the back end).

My immediate thought was “phew! Glad I didn’t spend any more time on that. Note to self: check own ideas for ‘behemoth trouncing risk’ in future”. Not to mention some relief that I wouldn’t have to implement the service myself now Google has “done it”.

However, then I started to think a little more and looked at their offering a bit closer – as much as I can with nobody using it and no iPhone support yet.

This made me realise a few things:

1. The behemoth does not always get it right, or rather tends to cater for the very high volume use-case which is not necessarily where the financial gain is to be mad
2. I have not seen their phone app yet, but I am wondering if it will have the right “drop dead simple” UI it requires
3. The behemoth when trying to handle the generic mass-market use cases, can not always create the seamless and simple UI required for users to love (and continue to use) a service
4. Most importantly – this kind of usage is not, in my view, what this technology is best for. I think the money to be made here is on smaller groups of users, and users in specific organisations.

Sure Google will have some plans further down the pipe – I’m sure an API will come (“Show where you are on your blog”, “Get location of friend X” etc). Its also surprising they don’t have an iPhone app (rather than an iphone customized web site) for this already.

However I think there’s a fair bit of money to be made with such a service that focusses on making sure parents know where their kids were when they said they’d check in, and for small-scale logistics for companies. The application UI -has- to be top-notch, and the functions it provides have to relate to the market place. There’s possibly a couple of different client apps that could be made to front the same back end.

So if you’ve got a some spare cash and want to fill what I believe remains a gap in the market, drop me a line and I can flesh out the ideas for you