<%@ page contentType="text/cache-manifest" %>CACHE MANIFEST
# rev 0
file.html


It's important to keep CACHE MANIFEST on the same line as the contentType property - manifests are discarded if they don't start from the first character with that declaration.

One last thing - this works better cross browser (where some browsers dont respect a manifest not ending in .manifest) by setting grails.mime.file.extensions to false, which will allow your mapping to be directly to cache.manifest, returning the rendered gsp.

Really, killing apps is the only reason to have the multitask bar anyway - since multiple instances of running apps isnt possible in iPhone OS, you could simply return to the running app by re-tapping the app icon on the home screen. The multitask bar exists solely for a shortcut to running apps and to kill them from running.

No more stressing in the blogs about apps being killed only by the OS! You do have control if you want it. Likely what Scott was implying is that you just don't have to monitor it if you don't choose to.

Note: This post has been getting a fair amount of traffic. I originally posted this directly after launch, and subsequently it contained outdated information from what is now known from the final release of OS 3.2. I originally had left the original post info for the sake of blogging/ journalistic integrity, however after three revisions because of newer info, I decided to strip the clutter of invalid content. Having said my disclaimer, below is the revised new post, and here is the release version of the iPad UA string as of 4/6/10, pulled directly from my 32GB wifi model:

Mozilla/5.0 (iPad; U; CPU OS 3_2 like Mac OS X; en-us) AppleWebKit/531.21.10 (KHTML, like Gecko) version/4.0.4 Mobile/7B367 Safari/531.21.10

more after the break.

The iPad represents itself in line with how the iPhone and iPod Touch differentiate themselves by specifying different device strings, but still contains the word 'mobile' - so Apple is currently explicitly classing this device as a mobile browser. But we now have a new class of devices to case for, segmented somewhere between mobile and non-mobile. While Apple has taken the first real swing at a tablet user agent, it's up in the air whether other tablet browsers will fall in line with this or do their own thing. Consistency is critical for proper detection without necessitating device specific casing.

This is intriguing and presents an interesting new issue for web developers. In their marketing materials, Apple has classified the iPad as designed for a full web experience (barring Flash of course), but they themselves are saying to the developers that this is a mobile device, right in the UA string. Moreover, technically the UA string classification is correct - this is a mobile browser. This isn't the desktop version of Safari. While they are both webkit based, it is inevitable that considerations will want to be made for the glorified Safari mobile browser in the iPad, and using the user agent string to identify that and case for it is problematic unless Apple modifies the UA string. My guess is at some point they will, possibly as soon as 4.0 hits.

It's not so much that this matters for development now as much as that it sets a precedent for future slate browsers. Apple has said here that slate browsers, even if they are larger versions of existing mobile browsers, should identify as a mobile browser, but clearly full sites should, and will be ultimately presented to iPad users in many cases. Even if the UA string wasn't an issue, there's still the question of how to architect a full site for both tablets and desktop viewing (primarily casing for browsers that do and don't have Flash). Proper implementation of progressive enhancement techniques is a great solution (see my related post on this topic here).

Maybe this whole UA string mess will all be a moot point when we see the 4.0 beta. As with all things Apple launch related, time will tell. One thing you can count on is that if the iPad succeeds, the precedent will be set. We'll see who follows.