Ron's Techie Blog

I’ve been working with Grails again lately after not using it for a while. Last time I was using Grails was a pre-1.0 release about a year ago. Even then it was an extremely productive framework, but it was rough around the edges.

The main obstacle I saw was that exception messages and stack traces were not descriptive of the root problem. It wasn’t that the error messages were poorly written, but the error that was reported wasn’t near the root cause of the problem. The reported error was a far-removed side effect of the actual problem. If you had messed up the definition of your GORM domain class, the application may start up fine and complain that some dynamic save method was undefined for the domain class when you tried to use it. You then had to do a good deal of trial and error until you isolated what change caused the problem. Having a robust set of unit tests for your application helped, but it still took a while to diagnose the problem.

I’ve been using Grails 1.1 betas lately, and it looks like the error reporting has gotten much better. When I’ve gotten errors, it was usually pretty clear what the cause was.

Officially, IDEA only supports Grails 1.0, but it’s working fine for me with some tweaks. Here’s what I did:

• Created the Grails 1.1 project outside of IDEA, using the grails command (not MVN plugin)
• Redefine GROOVY and GRAILS global libraries in IDEA to point to the latest versions of each
• Imported the existing Grails project into IDEA
• After installing some Grails plugins (specifically, the google-chart plugin), I found that they weren’t on the classpath and the grails launcher no longer worked. Apparently Grails 1.1 moved where the plugins are stored and IDEA hasn’t been updated for this yet. To get around it, I added <home dir>/.grails/1.1/projects/<my project> to the module’s content root for my project, and added the plugin’s source directory (plugins/google-chart-0.4.8/src/groovy in my case) as a source folder within the added content root.

The grails app launcher is working for me, and I’m not getting the compile problems I was getting before.

Well, it looks like hackers have been hard at work on the iPhone since it came out and have managed to hack the iPhone to gain access to the filesystem, alter the iPhone’s internals, and to launch custom programs. This has in turn been used to enable people to install custom ring tones and sounds, use the EDGE network from a laptop, and install and run a simple program on the iPhone. It’s unclear whether Apple can/will disable some of these hacks in the future. These hacks are still really only for techies and you may be voiding your warranty. Also, it looks like some of these hacks break visual voicemail and EDGE network access.

Meanwhile, there are already hundreds of web-based iPhone applications using the web-based development model Apple supports. I’m still hoping Apple will open up the SDK for custom applications.

Apple has posted guidelines for developing web applications for the iPhone. Apple has not provided an SDK for developing applications, so for now this is the only way to create applications for the iPhone.

The guidelines tell us how to best construct web pages for Safari on the iPhone, how to optimize media served up to the iPhone, what technologies are in (JavaScript, AJAX, most rich media formats), and what technologies are out (Flash, Java applets, plugins). They also tell us how to create links in web pages to the phone, mail, and Google maps applications so that phone numbers in applications can automatically dial a phone number, etc.

I actually think this is a pretty good development model for many types of applications. Since everything is using standard web technologies (XHTML, JavaScript, DHTML, AJAX), there’s an army of developers that already have the necessary skills, and adapting an existing web application to work well on the iPhone will be much less work than rebuilding it for a custom SDK. Due to AJAX and frameworks such as GWT, the usability gap between desktop UIs and web application UIs has narrowed considerably.

To me, the one big missing piece in this model is the ability to store data offline, along the lines of Google Gears. Google Gears is a browser plugin and includes SQLite, a very capable embedded RDBMS. This would allow applications to be delivered to the iPhone that can work online or offline, storing their data locally on the iPhone, and syncing up with servers when connected. I want my applications to work when there isn’t good EDGE nor WiFI network coverage. I would think twice about choosing the iPhone as the platform for that new sales team application if I knew it would only work if the sales guy was in an EDGE-covered area. I would like to be able to use Google reader to catch up on my RSS feeds even if I’m on the train and I keep losing my net connection. The only downside that comes to mind is storing application data in this manner will tend to use up the iPhone’s flash memory (4 GB or 8 GB).

Although I like the idea of developing applications for the iPhone using standard web technologies, I hope Apple will make an iPhone SDK available soon so developers can create applications that can take fuller advantage of the iPhone’s resources. I can’t create a voice memo application as a webapp.