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?

iUI on Google App Engine Using Gaelyk

Since Google Code project hosting doesn't provide web hosting other than wiki pages, iUI has been using SVN to host the sample applications, like the music sample.  The problem is that neither of these solutions allows PHP or any other server-side solution to run properly (e.g. Search or Stats in the music sample)

I wanted a free hosting solution for the project and also am a big fan of the Groovy programming language (my Java background showing)  So, I thought I'd try using Gaelyk on Google App Engine.  I first pushed a test version several months ago, but I've just pushed a new version to iui-js.appspot.com and also checked in my work-in-progress to revision control.

I've also created a wiki page called iUI on Google App Engine.  The wiki page has (hastily-written) draft instructions on "How I Did It" -- as well as a to do list.  Please let me know if you have any suggestions on the to  do list.

iUI Design Philosophy

The forthcoming release of iUI (version 0.40) is going to be the first release of iUI that add significant architectural changes.  iUI today is not that different from the original release of iUI over 2 years ago.  The major reason for lack of change has been simple: lack of human resources on the iUI team.

There have been many great contributions from the community, from simple bug fixes to beautifully crafted patches that add multiple features and almost double the size of the codebase.  I have also read and heard many opinions on the value of iUI, both positive and negative.  I'd like to write a formal statement defining the design philosophy of iUI so that users, developers, and even critics can better understand what iUI is and what it wants to be when it grows up.  This philosophy comes from three sources:

1. Joe Hewitt's original vision and source code
2. The experience and feedback of the community as it has developed applications with iUI
3. My understanding of the above sources and desire to move the project forward while staying true to its roots and to the loyal community.

Here are some of the key points in outline form:

1. iUI is a micro-framework (small, no underlying framework)
2. iUI is standards-based, but Safari focused (no IE)
3. iUI is lightweight.
4. iUI is a great starting point for any iPhone-optimized mobile site
5. iUI is a great starting point for those who want to learn modern mobile Web Dev.
6. iUI provides a functional core that is extensible through plugins
7. iUI is independent of server side technology.

I'd like to add a little more detail on these points (and was holding off on blogging this until I did) but I'm going to publish it now as it may answer some questions I've received recently.  Comments are very welcome.  This should eventually end up on the iUI project site.

Goal: I Wanna Be a JavaScript Ninja

I've wanted to create a blog that focuses specifically on software development, with a focus on JavaScript development for some time now.  Since Apple's introduction of the iPhone and initial announcement that all iPhone applications would be Web Applications, I've been interested in improving my knowledge of JavaScript and have made solid progress, but still have much to  learn.  Someday I hope to be a JavaScript Ninja (I bought the early access edition of the book, last week.)


I became involved in the iUI project over two years ago, and offered my skills as in the areas of revision control,  release management, and documentation.  I had hoped to learn more about JavaScript by assisting other experts on the project where I could.  Joe Hewitt, who created iUI had moved on to Facebook and was working insane hours on the initial Facebook iPhone Web Application.  A handful of other developers made contributions to the project but it didn't turn out to be the apprenticeship opportunity that I had hoped.  I used iUI on several consulting projects and over time learned much more about JavaScript and came to understand the iUI code base quite well.  Recently, I've decided that I have the expertise and can make the time to begin moving iUI forward and have made a few releases, fixed a few bugs, and added some minor features.  I'm hoping to get more developers involved with iUI and I'm also hoping to interact with and learn from the wider JavaScript community.


I've also had an interest in teaching JavaScript programming.  JavaScript is the de facto language of the Internet and is (at least indirectly) a part of everyone's daily online life.  In some ways it is well suited for beginners, in others it isn't.  I would like to write some posts for beginners or new developers as well.


I've debated whether I should use Apache Roller, Wordpress, or Blogger to do it.  Apache Roller is a great piece of software, I have a server side Java background, and there is a great team of helpful developers working on the project.  But ultimately, I didn't want to commit to maintaining a blog on an instance of Tomcat or on a hosted Java Servlet environment.  I may revisit this in the future, as I'd love to be able to be able to get under the hood of the blogging software I am using.


Blogger is overall the quickest and cheapest way to get started and now is the time as I have several subjects I want to discuss.

New Blog

I've wanted to start a blog about some of the JavaScript, iPhone, and AJAX work I've been doing