iUI and mobile HTML5 at iPadDevCamp

iPadDevCamp is this weekend. (It is produced by the wonderful iPhoneDevCamp team.)  It is at eBay in San Jose, CA but there are some satellite locations as well.  I went to iPhoneDevCamp in 2008 and 2009 and highly recommend it to both Cocoa and Web developers.  I've been talking to a few folks about adapting iUI for creating iPad (or iPad-like) webapps similar to what Apple is doing in AdLib.  Any takers?

We will be entering 'iuiPad' in the Hackathon.  (Someone will need to volunteer to do the demo, because I will not be there on Sunday.)  Of course, anyone will be welcome to contribute to the project, whether they attend iPadDevCamp or not.

If you're interested in contributing to this project, please do one or more of the following:

1. Register for iPadDevCamp
2. Follow #iuipad on Twitter
3. Join the iui-developers Google Group
4. Check the iUI project site (we've added a wiki page and will be updating it shortly)

Comments welcome...

TXJS: JavaScript conference in Austin, Texas

TXJS is a full-day conference in Austin, Texas, featuring some of the best minds in JavaScript.

They just added more spots, so I signed up.  I'm looking forward to visiting Austin again.

Storing Persistent Data in Hybrid iPhone Webapps

I'm in the process of adding some persistence to a hybrid iPhone webapp. It looks like I'll be using the HTML5 Web Storage capability. I googled around and didn't find any comparisons of the alternatives or suggested best practices. Apple has a document called Safari Client-Side Storage and Offline Applications, which covers Key-Value storage and the JavaScript Database -- but makes no mention of hybrid applications.

It seems there are four possible options:

1. Web Database
2. Key-value storage
3. Cookies
4. Use a JavaScript to Cocoa bridge to access native persistence

I've given a little thought to the advantages and disadvantages of each (enough to decide to give HTML 5 Web storage a try.)  I'll update this document if I get any good feedback.


Web Database

Advantages

• Can be used in hybrid, online and offline webapps.
• Supported in iPhone OS 2.0 and later.
• SQL is familiar and powerful for those who know it and need it.

Disadvantages

• Use of SQL is overkill for simple persistence

Key-value Storage

Advantages

• Simple conceptual model than SQL
• Has both "session"and  "local"  modes

Disadvantages

• Only supported in iPhone 3.0 and later (although Apple isn't very clear on this)

Cookies

Advantages

• Tried and true web technology

Disadvantages

• Either not supported in Hybrid mode or requires extra Cocoa code to support.  (Does anybody have a definitive answer, details, or an example?)
• Extra data is transmitted to the server on each request
• Others?

Custom JavaScript to Cocoa Bridge Option

Advantages

• You can use any iPhone native mechanism for persistence

Disadvantages

• Requires custom Cocoa code
• JavaScript to Cocoa bridge options are fairly clunky
• Will not work for pure online/offline webapp

Issues in Serving iUI Sample Apps using Mercurial

Since Google Code does not provide general-purpose web hosting to projects, iUI has long used the SVN repository as an HTTP server to server the sample webapps. For example the URL http://iui.googlecode.com/svn/tags/REL-0.30/samples/music.html serves the Music Sample from the 0.30 release of iUI. We had been using the tag REL-current to always server the latest stable release. We can't (easily) do this with Mercurial because the tag is passed in the query string. The URL http://iui.googlecode.com/hg/samples/music.html?r=REL-current will serve the HTML for the version tagged 'REL-current, but will then try to pull iui.css and iui.js from the 'tip' (at the time of writing, iui.css and iui.js are in a different directory on the 'tip' then they are in REL-current, so the files are not even found. If they hadn't been moved, then the wrong versions would be pulled.)

I'm not sure there is an easy solution to this problem, but if anyone has any ideas, please let me know.

Since we are now deploying the samples to Google App Engine (at http://iui-js.appspot.com), we'll have to have a 'tip' version and a 'REL-current' version on AppEngine, as well. Google App Engine does support deploying multiple versions of a webapp, but I think this is only intended for fallback purposes and not designed for serving multiple versions simultaneously. The other advantage to using AppEngine, of course, is that the dynamic pages used in the Samples and Tests will actually work.

XSLT Book Recommendations

I learned XSLT using Jeni Tennison's Beginning XSLTas a tutorial and Michael Kay's XSLT bookas a reference.  Tennison has a newer book entitled Beginning XSLT 2.0. I'd take a look at her newer book, but keep in mind most XSLT implementations in use today still do not implement XLST 2.0, so don't reject the older book simply because it doesn't cover XSLT 2.0.  If you're hardcore or plan on becoming hardcore,  I'd recommend XSLT 2.0 and XPath 2.0 (it's up to the 4th Edition now.)






If anyone has any other recommendations for learning XSLT, please post a comment...

iUI Sample WebApp using HTML 5 Offline Cache on Google App Engine

I've pushed a new development build of the iUI sample and test apps to Google App Engine (iui-js.appspot.com)

Among other changes in this build, the Music Sample web application now supports offline operation on the iPhone ('airplane mode'.)  It has been updated to HTML 5 and includes an application cache manifest (music.manifest)  Although the Music Sample is fairly simple it has two dynamic 'pages' (they're actually

elements) that are loaded via Ajax.  The Search Results page simply inserts the search string into three sample list entries.  The Stats page returns static HTML content but is served up via a dynamic URI that delays for two seconds before returning the content.  The purpose of the delay is to demonstrate the loading spinner.  Both of these pages have "fallback" pages that are displayed in offline mode.  The screenshots below show what each page looks like in online and offline mode.

If you have an iPhone and want to try it out, here are the steps:

1. Load the Music Sample in Mobile Safari.
2. Touch the "+" button on the bottom toolbar.
3. Touch the "Add to Home Screen" button on the action sheet that pops up.
4. (Optional) Edit the name that will appear under the icon on your home screen.
5. Touch the "Add" button (top right)
6. Launch the WebApp from your newly created Home Screen button.
7. Browse around
8. Exit the WebApp and load the iPhone "Settings" application
9. Turn on "Airplane Mode"
10. Return to the Music Sample WebApp.
11. Browse around making sure to visit the Stats and Search Results pages
12. Turn off "Airplane Mode"

Wasn't that cool?  There are two 'themes' configured in the application and the resources for both are listed in the manifest, so you can actually change themes while offline (this is a cool demo, but may not be the optimal handling of themes for offline WebApps)

For further details,  please see my previous blog post or the iUI on Google App Engine wiki page.  There's also a nice blog article about the Countdown 2.0 webapp that helped motivate me to do this.   The initial version of Countdown was written at iPhoneDevCamp 3.

Mobile Best Practices in the iPhone Era?

A friend e-mailed me this evening asking about what the current best practices are for mobile web access.  My immediate, flip response is "Make it look good on mobile WebKit and if the others can't read it, that's their problem."

I've been so focused on iPhone (and compatible sites) over the last year, that I have almost no idea what people are doing to support other devices.  Maybe the best practice is (essentially) to make it look good on the iPhone.   Most of the other devices are using Mobile Safari and are pretty close to the iPhone in capabilities.  Those that aren't are moving quickly to catch up.  WebKit is pretty much standards-based and when you look at actual mobile web usage statistics all the other phones don't add up to much.

She asked about a specific client that has an existing site that currently uses Flash navigation and has a limited budget.  The client wants improved mobile support.  Without knowing any details on the implementation of the site, the clients needs or budget, I'd guess there are four possibilities:

1. Remove the Flash navigation and replace with HTML and CSS navigation that is as modern as possible given the structure and complexity of the existing site and the customers budget.  Use the iPhone viewport tag and other techniques to make the site iPhone-compatible.
2. Create an alternative mobile site using XHTML that can be viewed by iPhones and other mobile devices, even older ones with limited web browsers.  Redirect mobile users to the mobile site (giving them an option to return to the main site, of course)
3. Redirect users to an iPhone-optimized site using iUI or another of the iPhone-centric mobile libraries.
4. Create an XHTML and an iPhone-centric site (In other words #2 and #3)  (Optionally remove the Flash navigation on the desktop site, as well.)

I would recommend #1 or #3 depending upon the budget.  But I'm an iPhone bigot (or at least Mobile WebKit bigot.)  Ultimately, it's a matter of return on investment.  For a relatively small site, why make the huge investment of supporting all the older phones with small screens and lousy browsers that no one uses anyway?

Whichever strategy is chosen, testing needs to be performed starting with the most popular devices and extending as far down the "long tail" as the testing budget and ROI calculations can justify.

Am I too much of an Apple fan boy?  Does anyone else have some pragmatic alternative best practices?