The Problem

It is impossible to have an element fixed in CSS on the page in the mobile Webkit browser. When you are surfing the web on your phone, webkit opens the page completely and acts as a viewport.

“Imagine a book in front of you. Take a piece of paper, cut a 320*416 square in it, and lay it over the book. To read the book, move the paper around and position the hole over the words you want to see.” -Richard Herrera

Why it is important

To create better mobile applications and websites, we need fixed positionning to give the user better tools to browse the web on handled devices. Like a real mobile app, we could have a fixed toolbar when scrolling on a site, it is critical to not take the user in hostage in very long list or on long content pages. This is something we can’t really emulate in javascript as mobile devices are not really powerful.

The solution

The Webkit team could give us a proprietary CSS property that would overwrite the viewport behavior, and this is the proposition here. Give us a CSS property like position: -webkit-viewport-fixed that we can apply on a div so it can be fixed to the viewport.

That is one feature request, but surely there we can add to that? The broad domain of “abettermobileweb.com” deserves more!

What would you like to see for mobile specifically that isn’t covered in the current Web and device API standard work?

As you move to a new platform, it is interesting to watch your brain morph over time. I remember switching from Windows to Mac. At first the fonts looked blurry and weird. The mouse pointer didn’t weight right. The constant app menu was strange. There were things I liked about it right away, but they were mostly the fact that I had a command line, and the fact that apps were minimal, pretty, and useful.

Over time though, I grew to like the Mac more and more. A few months in and it was the Windows fonts that looked too sharp and weird.

I am going through the same experience with webOS and the iPhone. It took me awhile to get used to the back gesture on webOS and not look for a back button. Now I know how to organize my multiple windows, and use universal search as my quicksilver, and so much more. When I open up my iPhone now I am at the point where I try to do a back gesture by mistake. webOS is a touchier, needier device, and as I develop apps and play with the platform, I start to grok that more and more.

Embrace the touch

I discussed touching and horizontal scrolling awhile back, but the more I play with touch devices, the more I find myself wanting to build features for the touch. I have a ton of learning, but here are some of the lessons so far:

Native UI or Immersive UI

One decision that you have to make when you start building your application is the style of UI. Do you want a native looking UI for the given platform?

Everyone jumped on native off the bat. We quickly saw libraries such as iUI come out that let you mimic the iPhone UI. Having a native UI can be important. You want to fit in. However, we have also seen the growth of immersive UIs. Convertbot is the example above on the right. It is task based and you feel like you are really interacting with the app. It is almost tactile.

It is interesting to compare the Gmail and native Mail client UI in webOS. The Gmail version is deployed via a website, whereas the native version is of course an application, but they are very similar. Both use HTML/JS/CSS. Both have their look and feels. Do you try to look like your website (e.g. Google look and feel), or do you try to go fully native. The blending of the two gets interesting. Your brand has to live in another native world.

Haptics and touch feedback

It is usability 101 to make sure that you are always giving users feedback on their actions.

First, how do we signal to users that there are particular touch areas? This one is a bit of an art. We don’t really have :hover and the like. I actually like the idea of having a long press show helpful information, but users aren’t used to using that ability yet (see: need more gestures!).

Where we do have touch areas, we need to make sure to have various depress states for the touch.

Users will touch all over the app, so think about what you can do where.

We are going to see haptics in the future. For now it feels like haptics are used like this:

But the science is coming along. Sony Ericcson has a device (Satio) with haptic support for example:

Using the Keyboard: Software or hardware

This brings us to keyboards. What is the optimal input for your application use cases.

Feathers by Aral Balkan is a good example of both the task based nature of mobile apps, and custom software input. I like how Aral thought to create an app that solely creates Twitter messages. He didn’t create a full Twitter client that would do it all.

And if you have the pleasure of a hardware keyboard, how can you use that beyond the obvious inputting of text fields. The beauty of a keyboard that come out is that it doesn’t take away space from the screen. Could you offer short cut keys in the app? Different navigation? There is a lot more to explore here.

Gestures. Time to catalog and create new standards

We are seeing more and more gestures in applications. It feels like we are building out the standards right now. What will be the Ctrl-C’s of mobile? We get to build out invisible ways to navigate.

Tweetie 2 did something interesting when it threw away the refresh button and replaced it with the pull down. Isn’t it more work? Some people don’t like it (Jimmy Fallon for one!) but a lot of people find it more gratifying because it is more natural. We have buttons in the real world, but the apes in us are more used to touching the world around us in very different ways? This is one example of going back to our roots.

Speaking of reload, we are seeing another common gesture here too. Using “shake” to reload, or relayout.

Orientation: Try to accept them, and be more creative

Have you ever turned your device on its side and not seen anything happen? That frustrates me. At the least, we need to rotate the UI and let it continue. But, can we go beyond that? I have been playing with this. What if landscape brings a more immersive experience?

Take an app that loads a stream (e.g. Facebook, FriendFeed, Twitter, whatever). In landscape, you can view one entry at a time. If the type of entry contains a photo album say, take over the full screen to show the photos and let you flick through.

It really is fun to play with touch apps these days, and I get the feeling that we are still in the dark ages wrt our interaction models.

What patterns have you enjoyed in using and building mobile apps?

John Gruber has spotted a library for iPhone web apps, from none other than Apple. This mysterious library, called PastryKit, seems to have flown under the radar as a Google search reveals precious little on it. In similar vein to other efforts, Apple's library provides support for native-feel websites - websites that run in Mobile Safari, but feel like native apps. (That's the objective anyway; some look-and-feel emulators are "good enough", while others get stuck in the uncanny valley).

To get hands-on with PastryKit:

• Visit http://help.apple.com/iphone/3/mobile/ from your iPhone or iPod Touch. This is an official Apple site using PastryKit. If you're feeling lazy/iPhone-challenged, watch Gruber's screencasts.
• Now with the same site in regular Safari (on your Mac/PC), open up the Develop Menu (if it's not there, enable it in Preference|Advanced). Choose User Agent > Mobile Safari 3.0 (or probably any other version number). And now you can see it in your browser. From Develop Menu, Web Inspector will let you view the script.

The HTML includes PastryKit as follows:

PastryKit Javascript and PastryKit CSS are available. Unfortunately, they're a bit unclear due to compression, but Gruber nonetheless pored into the source:

PastryKit accomplishes all three of the aforementioned things — hiding the MobileSafari address bar, providing fixed-position toolbars, and providing scrolling with momentum — by disabling regular scrolling and setting up its own view hierarchy and implementing its own scrolling.

The whole question of native iPhone apps was a hot topic last month after PPK whipped up a storm on the question of web apps replacing iPhone apps. The really interesting thing here is Apple's stance. They launched the iPhone with web intended to be the platform for 3rd party apps, then switched over to native apps and haven't done much to facilitate native-style web apps since then. Is a change coming? As Gruber puts it:

The $64,000 question, though, is whether PastryKit is something Apple intends (or that a team within Apple hopes) to ship publicly. It seems like a lot of effort to build a framework this rich just for this iPhone User Guide, so I’m hopeful the answer is yes. Perhaps something integrated with the next major release of Dashcode? And, perhaps with integrated UI layout tools, along the lines of Interface Builder?

As well as apperaring in the user guide website, Chris Messina noted PastryKit apparently appears in the iTunes LP files.

PhoneGap API’s available to Palm devices include geolocation, accelerometer, notification, orientation, sms, telephony, network, file (read only), and a limited selection of device properties (see the PhoneGap Mobile Spec running on the Palm Emulator to the left).

Essentially a JavaScript shim that maps to the various mobile APIs, the PhoneGap API & suite of tools makes it much easier to build mobile apps for the iPhone, Google Android and various versions of Blackberry by leveraging standard web-based technologies. You can now add Palm to the list of mobile devices being supported by the PhoneGap project.

Mobile CSS Quirks

So many platforms. Take just WebKit; there's iPhone Safari, Android WebKit, Bolt, Iris, different versions, etc. "If someone says my 'app should work in WebKit', laugh in their face. There are just too many versions of WebKit, so as PPK says it, there really is no "WebKit for mobile".

That said, it's good that things are starting to converge towards WebKit. As for the others: Blackberry browser "is dead" as they'll be switching to WebKit; Mozilla is very late to the game; NetFront "is not very good". Windows Mobile 6.5 is a big improvement on 6.1, and with an improved browser, but it's still IE6 based. ('Nuff said.)

There's also a large legacy share, and if users are used to it already, that may be what they want to keep using.

Landscape versus profile mode is an interesting one for those of us desktop developers whose users don't flip their heads around on a regular basis. NetFront has some very surprising and idiosyncratic ways of dealing with it.

The modes don't stop there. There is also mobile versus desktop mode in some browsers; sometimes users can switch these in some obscure corner of their mobile browser preferences. Again, some surprising things happen in Opera and Android. Perhaps of more concern is the difficulty he had diagnosing the situation at first, when Android was showing three divs of the same width in one mode, and not in the other.

@media to the Rescue

Okay, what can we do about all this? Media queries are extremely useful and fairly well supported in modern mobile browsers.

max-width and min-width have subtle issues which PPK is currently researching, but max-device-width and min-device-width give more reliable results. orientation, aspect-ratio, and dpi (also needs research).

Mobile Javascript

Performance-wise, IE Mobile and Blackberry extremely slow. iPhone is middle ground. The really fast browsers are Opera on Samsung and N97, and S60 on Nokia E71 and N97. The bottom line is take your time with mobile Javascript development; you generally can't expect it to "just work"; you'll have to optimise. Also, don't use iframes - they're major performance hogs.

Mobile Connections

Tempting fate, PPK informs us that if someone in the room starts downloading movies, the network gets slower for the rest of us.

Fortunately, browsers give us events to determine when user is going online and offline. Unfortunately, they're doing it wrong. Only Firefox automatically detects offline; all the others require the user to explicitly say "I'm offline now"!

W3C Widgets

In general mobile development, best practice is to put all the core files on the moble phone, and only download the data. But how can we do that with web apps, where the code comes down with the data? W3C widgets offer a solution. You just create a single HTML page with the CSS, Javascript, and images you need; add an icon and config; zip it up; and deploy. PPK reports it works in practice, and works in a "write once, run many" fashion. There are still problems to be sure, but he says it's the best interoperable solution we have today. But still many outstanding platforms: Blackberry (already talking about it), Nokia Maemo, Palm Pre, Android, and of course, iPhone.

Device APIs

Security risks mean critical device APIs will generally remain off limits to general websites for a while. Widgets have a better model, because they're more self-contained and can be verified, although not perfect either.

Ben and Dion have just wrapped up a WebOS talk in London, in conjunction with O2 Litmus. They explained why Palm is using the web as an application platform (might be preaching to the converted on this website!) and covered some of the development issues.

Embracing The Web

Ben and Dion open by discussing a panel Ben was on some years ago with Dave Thomas. Ben answered rich UIs as the most important trend, but Dave held up his mobile and said this is the future of software. And (according to Ben) Dave has been vindicated. Today, we have many, many, devices, and it's tricky for us to target them as both developers (technically) and businesses (commercially).

But what's interesting is the web browsers that have snuck into many of these platforms. The Ajax revolution changed the game for the first time, where you could build real-world web apps. (screenshots: GMail, GMaps, GOffice, Bespin, 280slides.) It's only happening just now, and pretty soon, the web will be a great place not just from portability of the code, but portability of the distribution mechanism.

Tools like Fluid, Mozilla Prism, give us a specialised browser for a web app. On the other end of the spectrum, we have tools like Adobe Air and Appcelerator Titanium that let developers build full-fledged desktop applications.

But why the web? How about other technologies like Silverlight and Flash? Well, the browser really hasn't changed that much (Netscape screenshot). But underneath, the engine has changed dramatically. We're going from the hacky world of the first browsers to one where developers will benefit greatly from the Javascript engines, renderers, and APIs available to us.

For example, with canvas, the ability to do dynamic graphics (nice demos). Likewise, SVGs. Custom typography; Firefox is rolling out support for even obscure features of fonts. Later in the presentation, Ben demonstrates further capabilities: OpenGL and 3D CSS transformations (more nice demos); what Ben calls "the final frontier" of visual interfaces.

Faster Javascript engines are more than just increased performance. As Steven Levy points out, when you increase something's performance by an order of magnitude, you haven't just increased the performance; you've created something new. So we have generational garbage collection, for example, which is a sign of the virtual machines maturing and becoming much faster.

Related to JavaScript speed is threading. We don't have threads and given opinions of the creator of JavaScript, probably never will. But "browsers now have something that's even better than threads": web workers. It's used in different ways; for example, Chrome extensions can run in their own process this way. Another example is running a database server like SQLite in a separate process.

So does the web have the capabilities for today's and tomorrow's applicatons? There's a huge user base and a huge developer based - more developers than any other platform. Some people still think of JavaScript as a toy, but when they get into it, they often realize it's actually quite good, and it's not JavaScript they don't like, but things like browser incompatibilities that are troublesome.

Development Details

Web developers can use the Mojo framework, which provides simple Prototype based APIs. Notifications are HTML controls themselves, so you can put whatever HTML you want inside it. Security-wise, applications can get different powers

Palm wants to sell phones, not proprietary APIs, so it's involved with BONDI and W3C widgets standardisation efforts. One of the things they need to know from us (the developer community) "Palm pays us, but they didn't pay us enough to sell out"; Ben and Dion are developers and they're not going to tell other developers use "our funny proprietary API, you'll love it". However, they can't say when all this will happen, as they're evolving the platform pragmatically and they feel other things might have more immediate impact, e.g. OpenGL support.

The web distribution model is simple - user surfs to a URL! But many people actually want a catalogue, and in fact some app catalogues are becoming spam catalogues. Some even boast about how many apps there are in the catalogue, Ben notes with a wink at the big I. With Palm, developers pay $50 and it helps to avoid the problem. There will be one catalogue, but developers can control which markets they're selling in, and get useful analytics and feeds about its usage. Wanting to reduce the friction for people to buy an app, so would consider (although nothing definite) carrier billing and affiliate links.

Q&A

The developer portal is currently being overhauled. Under consideration are ways to make things more transparent, e.g. bug tracking and planned features.

Ben and Dion anticipate that developers will probably be able to opt in to JavaScript obfuscation (or some other form of obfuscation). As Dion explains, View Source has been really important on the web, so there's a tension and it's likely multiple options will be available.

On ease of use, multitasking has been great; UI latency is still an issue even though the hardware is comparable to 3GS. The problem is the path to the GPU didn't exist, but now with CSS transforms, that will be solved in the future. As far as screen size, where Pixi broke the mold 4 months after the Pre, this happy world of coding to the same screen size on mobiles is going. Ben says it would have been easier for Palm if it wasn't the first phone to break the mould, but reality is the mobile space will break out to big screens, phones, etc etc, so it won't be one fixed resolution or even aspect ratio.

There will be lots of new tools for developing with and they'll be able to work with WebKit. Ben and Dion (not speaking for Palm, they're sure to add) are open to the thought of embracing Flash for native apps and keen to hear people's thoughts on it.

The open source question ... will Palm open source WebOS. Ben says "we (Ben and Dion) would love to do it", but it's not Android working to thousands of phones and it still has to be considered.

Update: Turned out attendees scored free Pre's after the event. Thanks fellas :).

Announcement from O2 Litmus guys.

Developer mail to devrel@palm.com.

Event hashtag: #o2palm

I compare 19 WebKits in order to prove that there is no “WebKit on Mobile” and to figure out which one is the best. My hope is that eventually I’m going to gain some insight in the “family tree” of all WebKits.

This page only contains tests of CSS and JavaScript items that work in some WebKits but not in all. Adding more items, all of which are either supported by all or by none of the WebKits, makes no sense — it’s in the items in the table below that the differences between the 19 tested WebKits lie.

I will probably add some HTML5 items to this list later on, provided they’re supported by at least one WebKit (probably Safari or Chrome).

These tests focus solely on compatibility. I say nothing about performance or user interface, and especially on mobile these factors may, in the short run, be more important than compatibility.

Alex Russell responded to the concern that we are in a world of hurt with multiple browsers on mobile just like we are on the desktop. Alex thinks that the core notion of timeliness matters here:

I’m not convinced that the situation is nearly that bad.

The data doesn’t reflect how fast the mobile market changes. The traditional difference between mobile and desktop, after all, has been that mobile is moving at all. If you figure a conservative 24 month average replacement cycle for smartphones, then the entire market for browsers turns over every two years. And that’s the historical view. An increasing percentage of smartphone owners now receive regular software updates that provide new browsers even faster. What matters then is how old the WebKit version in a particular firmware is and how prevalant that firmware is in the real world. As usual, distribution and market share are what matters in determining real-world compatibility, and if that’s a constantly changing secnario, the data should at least reflect how things are changing.

He uses his own charts to make the comparison :)

What have you found?

It starts off by talking about lazily loading code via the old favorites of adding a <script> to the DOM, or XHR+eval, but then it gets beyond the typical and discusses the nuance of mobile + offline caching. The hack that is used, is another oldie.... which is to hide the script and eval it later:

For an HTML 5 application that takes advantage of the application cache to reduce startup latency and to serve the application offline, there are a few caveats one should be aware of. Mobile networks have decent bandwidth, but poor round trip latency, so listing each module as a separate resource in the manifest incurs quite a bit of extra startup latency when the application cache is empty. Also, if one of the module resources fails to be downloaded by the application cache (e.g. disconnected from network), additional error handling code needs to be written to handle such a case. Finally, applications today have no control when the application cache decides to download the resources in the manifest (such a feature is not defined in the current specification of the draft standard). Typically, resources are downloaded once the main page is loaded, but that's not an ideal time since that's when the application requests user data.

To work-around these caveats, we found a trick that allows you to bundle all of your modules into a single resource without having to parse any of the JavaScript. Of course, with this strategy, there is greater latency with the initial download of the single resource (since it has all your JavaScript modules), but once the resource is stored in the browser's application cache, this issue becomes much less of a factor.

To combine all modules into a single resource, we wrote each module into a separate script tag and hid the code inside a comment block (/* */). When the resource first loads, none of the code is parsed since it is commented out. To load a module, find the DOM element for the corresponding script tag, strip out the comment block, and eval() the code. If the web app supports XHTML, this trick is even more elegant as the modules can be hidden inside a CDATA tag instead of a script tag. An added bonus is the ability to lazy load your modules synchronously since there's no longer a need to fetch the modules asynchronously over the network.

On an iPhone 2.2 device, 200k of JavaScript held within a block comment adds 240ms during page load, whereas 200k of JavaScript that is parsed during page load added 2600 ms. That's more than a 10x reduction in startup latency by eliminating 200k of unneeded JavaScript during page load! Take a look at the code sample below to see how this is done.

PLAIN TEXT

HTML:

1.  
2. <script id="lazy">
3. // Make sure you strip out (or replace) comment blocks in your JavaScript first.
4. /*
5. JavaScript of lazy module
6. */
7. </script>
8.  
9. <script>
10.   function lazyLoad() {
11.     var lazyElement = document.getElementById('lazy');
12.     var lazyElementBody = lazyElement.innerHTML;
13.     var jsCode = stripOutCommentBlock(lazyElementBody);
14.     eval(jsCode);
15.   }
16. </script>
17.  

In the future, we hope that the HTML5 standard will allow more control over when the application cache should download resources in the manifest, since using comments to pass along code is not elegant but worked nicely for us.

Today they have released a new version which improves on their extensible system with:

• Improved 3D flip transition
• Callback events throughout for page transitions, swipe events, and orientation changes
• Included demos: Clock, To-do, Main functional demo
• Theming: Currently has Apple and jQTouch theme (gray)

Read more about getting started and the callback API.

The WebKit Open Source Project provides a JavaScript test Suite dubbed SunSpider. According to the description on the SunSpider home page, “this benchmark tests the core JavaScript language only, not the DOM or other browser APIs. It is designed to compare different versions of the same browser, and different browsers to each other.” We at Medialets have found it to be one of the best attempts to measure real world JavaScript performance in a balanced and statistically sound way.

Medialets ran the SunSpider test suite in the following environments:

1. Safari 4.0.1 on a 2.0 GHz Intel Core 2 Duo White MacBook.
2. The MacBook results were used as a baseline for relative comparisons.
3. Mobile Safari on the iPhone 3G with iPhone OS v2.2.1
4. Mobile Safari on the iPhone 3G with iPhone OS v3.0
5. Mobile Safari on the iPhone 3GS with iPhone OS v3.0
6. The “Browser” app on the T-Mobile G1 with Android OS v1.5 (Cupcake)
7. The “Web” app on the Palm Pre with Web OS v1.0.2

Each device was fully restored and rebooted immediately before running the test suite. Every attempt was made to assure that no atypical background tasks were executing while the tests were running. The SunSpider tests automatically run five times sequentially and the mean average from all five tests are reported. Network speed and latency have no effect on the results of the test.

We all know to beware of benchmarks, but it does show off how powerful these devices are getting!

You can take a look at what it takes to develop for desktop and mobile in this screencast from Kevin Whinnery:

I instantly thought of PhoneGap and asked Jeff Haynie about the differences. It appears that Titanium Mobile handles the device mapping in a different way. Instead of focusing just on device APIs and giving developers access to those APIs via JavaScript, it goes a little further. The Titanium tool will compile down your code and you will see that native widgets will be used in places. As the mobile version moves forward, they expect to do more of that kind of work, so instead of a WebView + APIs, you have native where you can, and WebView where you can't.

From watching the Titanium Developer tool at work, you can quickly see that it is nicely taking care of you, the Web developer, as you go through the process of dealing with phones. Dealing with the SDKs from Apple and Android can be messy business and the tool really tries to make it much more seamless. The same can be said for the packaging and deployment process.

It is great to see yet another product that comes along to help Web developers take their existing skills and have them work on mobile platforms. Personally, the thought of going to Objective-C land isn't a pleasant one for me, so this and PhoneGap make total sense. If other platforms such as Android and hopefully webOS catch on, then it will make even more sense to go cross platform. Who better to write code on difference devices that Web devs since we have to deal with it every day ;)

Need a visual builder? You could take the upcoming 280 Atlas, use Interface Builder or Atlas itself, and deploy your app to the phone. Great times for the Web platform.

On the developer side of the house we get to see a little teaser of what the team will be sharing with us:

Of course we didn't get there without a few hard knocks. As an evolving standard, HTML5 has been fast-changing target and we've skinned our knees and bruised ourselves along the way. So rather than just deliver the fruit of all those bumps and scratches to end users in our own products, we decided we wanted to write a few blog posts to share what we've learned so that others can take advantage of HTML5 as well.

Great to see the mobile Web continue to merge as just One Web, and I look forward to hearing from the trenches on issues the team ran into, so we can learn from them.

Today, Palm expanded the Mojo SDK program for webOS, announcing that a broad group of developers will be provided with the software development kit to create applications for the Palm Pre phone (as well as other future devices running webOS).

Speaking at the Web 2.0 Expo, Palm’s senior vice president of Applications Software and Services Michael Abbott also highlighted some of the most exciting aspects of webOS -- including a new branded service that lets developers create apps that push live content across the Internet -- and invited the audience to apply for the early access program at the Palm Developer Network website.

The power of webOS lets developers rethink how they develop for mobile devices -- and creates opportunities for new kinds of apps. Abbott highlighted several key features of webOS that open up new avenues for the creative ingenuity of the developer community:

• a cards metaphor that simplifies multi-tasking
• Palm Synergy to unify information from sources like Google, Facebook, and Exchange
• a user-friendly approach to notifications that ensures the user is up to date without distracting them from the task at hand. 

An often-overlooked aspect of webOS is that Web applications run natively on the phone. They don’t depend on access to a server, and can run even when there is no access to the Internet. But the full power of webOS is unleashed when the device works together with “the cloud” – the combination of all of the Web sites and services that a user interacts with.

We also got to see a new walk through of the Pre:

Come on HTML5 Phone :)

David Kaneda has created jQTouch a "jQuery plugin with native animations, auto list navigation, and default application styles for Mobile WebKit browsers like iPhone, G1, and Pre."

Features

Setup

jQTouch can now be initialized with one function:

PLAIN TEXT

JAVASCRIPT:

1.  
2. $(document).jQTouch({
3.    icon: 'jqtouch.png',
4.    statusBar: 'black-translucent'
5. });
6.  

This function writes all of the meta tags needed for an iPhone web app. Here are the default settings:

PLAIN TEXT

JAVASCRIPT:

1.  
2.  fullScreen: true,
3.  slideInSelector: 'ul li a',
4.  backSelector: '.back',
5.  flipSelector: '.flip',
6.  slideUpSelector: '.slideup',
7.  statusBar: 'default', // options: black-translucent, black
8.  icon: null,
9.  iconIsGlossy: false,
10.  fixedViewport: true
11.  

Animations

There are now functions for sliding a page up, and "flipping" to a page, using WebKit's built-in 3D capabilities. Both can be seen in the new preview

These new animations are integrated into the page history, and can be navigated by using the back button.

Image Preloading

I've added a quick-and-dirty function for preloading images, which you just send as an array. For example:

PLAIN TEXT

JAVASCRIPT:

1.  
2.  $.preloadImages([
3.      'themes/jqt/img/chevron_white.png',
4.      'themes/jqt/img/bg_row_select.gif',
5.      'themes/jqt/img/back_button.png'
6.      ]);
7.  });
8.  

Minor Improvements

• New HTML structure to ease toolbar button variations and improve animations.
• Various performance improvements
• Added minified code
• Started a custom theme, which will be offered alongside the standard Apple theme
• Created a new Home Screen icon
• Removed some iPhone-dependent code

David also answered some questions for us:

How does it compare to iUI?

It is similar in the way it can load views via built-in HTML or dynamic GET/POST requests, but it uses hardware-accelerated animations, and also includes transitions like slide up and 3D page flip. It also includes code for image preloading, a custom theme, and a much easier setup function which eliminates the need to write META tags for the app icon, viewport settings, etc.

What kind of extended functionality are you looking into

Ultimately, I plan on testing extensively on the G1 and, eventually, the Palm Pre. Other plans include a more robust theming system, and various callback methods to make extending jQTouch even easier.

With PhoneGap, would it just be a script that you can get built in?

I am currently in talks with the PhoneGap crew, and we are planning on including it stock with the kit. We're currently unsure if the script should be ported to XUI or remain based on jQuery.

The new showed this:

Compared to the old version:

With his focus shifting to the mobile space, PPK continues to serve the community by providing similar data for mobile browsers.

Right now I’m doing basic tests while also figuring out what “basic tests” means in the mobile space. It turns out that I even have to test basic CSS stuff like font-style. Many of my already-existing tests use such typographic CSS to denote whether a browser supports a certain selector or effect; but if a mobile phone doesn’t support the CSS in the first place, my tests will misfire horribly.

His Mobile Compatibility Tables, while still very new and a work in progress, will surely be of tremendous help to the many developers who are now looking to mobile web development as the next big wave.

He's already collected a large amount of information on the following mobile browsers:

• Opera Mobile
• Opera Mini
• WebKit
• NetFront
• Blackberry

and for the following browser capabilities:

• Events including key & click
• Basic DOM & Ajax support
• Basic font CSS
• CSS Media
• Focus, blur, scroll
• Screen orientation support
• Font sizes

If you're a mobile web application developer, I urge you to go visit this great resource and even offer PPK feedback to expand his data.

Ben and I have been promoting PhoneGap as a great solution for Web developers to create applications with the technology they know and love, without having to jump off of the cliff to other proprietary worlds. PhoneGap is still new, but gets more impressive every day.

The team is getting more interested, and put together a video on What is PhoneGap?.

You can see a budding list of existing applications that use PhoneGap already and note that PhoneGap isn't just about the iPhone anymore.... Android and RIM are in the house.

He showed off the Palm Pre device running a Web application on their platform:

Video courtesy of PreCommunity.com

Gmail Demo on iPhone and HTC Magic

Then he showed Gmail Offline running on iPhone and HTC using HTML 5 Storage API

Video courtesy of AndroidCommunity.com

Once again we get to see HTML pushing hard in the mobile space.

Fancy writting a Web application on the architecture above? Since announcing the Palm Pre we have seen a lot of people wondering about the goods under the hood. We now have an online reference to check out.

Once you get past the high level stuff, you get to the meat:

Stages and Scenes

Palm's user experience architecture provides for a greater degree of application scope than is normally considered in a web application. To support this and specific functions of the framework, Palm has introduced a structure for webOS applications built around stages and scenes.

A stage is a declarative HTML structure similar to a conventional HTML window or browser tab. Palm webOS applications can have one or more stages, but typically the primary stage will correspond to the application's card. Other stages might include a dashboard, or other cards associated with different activities within the application. You should refer back to the earlier example of the Email application where the main card held the Email inbox and another card held a draft Email. Each email card is a separate stage, but part of the same application.

Scenes are mutually exclusive views of the application within a Stage. Most applications will provide a number of different kinds of scenes within the same stage, but some very simple applications (such as Calculator) will have just a single scene. An application must have at least one scene, supported by a controller, a JavaScript object referred to as a scene assistant, and a scene view, a segment of HTML representing the layout of the scene.

Application Lifecycle

Palm webOS applications are required to use directory and file structure conventions to enable the framework to run the applications without complex configuration files. At the top level the application must have an appinfo.json object, providing the framework with the essential information needed to install and load the app. In addition, all applications will have an index.html file, an icon.png for application's Launcher icon, and an app folder, which provides a directory structure for assistants and views.

By convention, if the app has images, other javascript or application-specific CSS, then these should be contained in folders named images, javascripts, and stylesheets respectively. This is not required but makes it simpler to understand the application's structure.

Launching a webOS application starts with loading the index.html file and any referenced stylesheets and javascript files, as would be done with any web application or web page. However, the framework intervenes after the loading operations and invokes the stage and scene assistants to perform the application's setup functions and to activate the first scene. From this point, the application would be driven either by user actions or dynamic data.

Features

• Storage: HTML5 storage is natively accessible
• Widgets: Can look like this:
  PLAIN TEXT
  HTML:

  1.  
  2.   <div x-mojo-element="ToggleButton" id="my-toggle"></div>
  3.  
• Services: The architecture looks like this:
  
• Developer Tools: SDK comes with emulator and command line tools

Still looking forward to more details, examples, and such.... but exciting to see the data coming out!

Safari JavaScript Database Programming

The HTML 5 specification provides a new mechanism for client-side data storage: JavaScript database support. HTML 5 is currently in development by the Web Hypertext Application Technology Working Group (WHATWG).

JavaScript database support is available in Safari 3.1 and later, and in iPhone OS 2.0 and later.

You should read this documentation if you are a web developer who wants to store data locally on a user’s computer in amounts beyond what can reasonably be stored in an HTTP cookie.

HTML5 Application Cache

Michael Nordman of Google asked "Is this stuff built into shipping Safari or iPhone browsers yet?"

David Kilzer replied "This feature shipped with iPhone OS 2.1. When you use "Add to Home Screen" from the "+" button on Safari for iPhone, a web application with a manifest defined (per the HTML5 spec) will be saved with any cached resources. Note that the manifest file *must* be served with the correct MIME type for this to work.

There is no shipping version of Safari for Mac OS X or Windows that supports this feature yet."

Fantastic to see!