This is iPhone Web Applications From Start to Finish. I'm Greg Bolsinga. I am an iPhone Web Kit engineer. And today we're here to talk about iPhone web applications. You may be asking yourself why? The great thing about iPhone web applications is you can leverage your existing knowledge. You already have your data, you already have your HTML, CSS, and JavaScript, you already have your servers set up so you can serve this data to your web sites, and you have all the tools you use to create this data.

So there's a lot of existing knowledge that you can leverage. In addition, you can leverage advanced iPhone and Web Kit technologies to make your iPhone web application an app that your users will love. Another great feature of iPhone, web applications is instant deployment. By this I mean as soon as you're ready to publish your application for iPhone, you publish the URL, then your users can access it.

Another wonderful thing about this is that you can protect it behind your FireWall. You can have selected users use it, say only when you're on your own local network or VPN. In addition, you can distribute it only to selected users that way. No ad hoc distribution necessary. Another great thing is when you need to update your application all you do is publish some more data on your server. Up load that -- have that JavaScript and that HTML ready, and that data is available to your web application.

So what are we going to learn today? First thing we're going to learn, actually, is how to optimize your web site for iPhone. This is important, because in the end a web application is a web page. So we'll learn certain optimizations. Safari for iPhone has optimal browsing experience behaviors that you may not want in your web application.

How do you turn those off, and other things like this. Then we'll get into creating an iPhone web application. We'll get it into full screen mode where you and your users will be able to use the whole iPhone screen for your web application. I'll show you how to use off line data, because there are times that your iPhone may not be online, strangely enough, or you may be an iPod Touch, where there's not a Wi-Fi network available.

People like iPhone applications because they're really fun to use, they're really interactive. And I'm going to show you how you can get sophisticated graphics using CSS Visual Effects on the iPhone. And lastly, great performance. Both those CSS Visual Effects and off line data in fact also make your web application perform really wonderfully. And then we'll talk about adding advanced features, orientation events, how you can determine if your device has turned and gone from landscape to portrait, or back. We'll also cover DOM touch events.

IPhone, as you know, supports multiple fingers, you'll want to be able to have more than one finger, as well as all the rich gestures that you can do with iPhone. And lastly, new in iPhone 3.0 we have Geolocation. This way your users can share their location with your application, and you can give them a great experience. So the basics.

Optimizing your web site for iPhone. We're going to cover custom interaction behavior. There's lots of behaviors in web sites that are designed for optimal browsing experiences that may not be optimal for your web application. Text sizing. How do you get your text to look great on a screen the size of something like the iPhone. We'll show you how to optimize those things.

Screen size best practices. Web sites can have any variable width, variable height. How do you get that to look great on a screen the size of an iPhone, and lastly, how do you get your own icon onto the iPhone home screen for your web page. So to show you some of these concepts we're going have Paul Knight here show you a demo.

Thanks Greg.

I'm going to switch over here to one of the demo machines, and I've got a web page, you know, this first part of the presentation is all about taking your existing web content and optimizing it for an iPhone experience. So you may have seen this web page already, it's on the WWDC attendee web site.

And it actually looks better than this if you go to the real one, I had to break it a little bit for purposes of this demonstration. So I've got the site loaded, and it looks great already. IPhone -- Safari for iPhone does a really nice job of rendering it, but there are a few things we can do to improve it. First thing I notice is the content kind of squishes up against the side here. Now one of the things that Safari for iPhone does is it assumes your web page was designed for 980 pixels wide. That's the default width we set.

And you can change that if your site was designed for something different. And you know, now that I look at this, the text is a little too small in a few places, like this paragraph in here, the main paragraph. I can't really read that, double-tap to zoom doesn't really work so well. Maybe we can fix the text size there.

Now one of the things that Safari for iPhone does is when you tap a link you get this nice color -- this colored overlay over the link, and that lets the user know that they clicked the link and something's going to happen. But up here there's this navigation, which is kind of small, hard to see. And even if we double-tap to zoom in, we don't really see that gray, the gray kind of gets lost against the black.

So maybe we can improve the feed back there, and maybe you want to customize the color of your web site, make it fit with the rest of your branding, something like that. We can improve that. And you know, new in 3.0, there's the cut, copy and paste and the selection UI.

So that comes up here. And if you tap and hold on an image, for example, you'll get this action sheet, you know, which let's you save the image or copy. Maybe you want to disable these for whatever reason, we're doing a lot of custom touch events, interaction in this area.

We just want to turn those off. We can do that. And one of the things that your users can do is not only can they bookmark your site, but they can add your site to the home screen. This is great, the bookmark lives along with all of the other applications on their phone.

To do that, they tap +, tap Add to Home Screen. Now by default what we do is we take a snapshot of your site, scale it down to that size icon, and that's what's going to show up with all the other applications. We can do better, we can put -- you can put your own branding, your own logo, your own icon, make it really stand out. So Greg, we're talking about a few issues that we have with our existing page.

Maybe we can go over how to make these changes and then --

Yeah, I'll go over them now. Thanks a lot, Paul. So first thing you're going want to customize is the interaction behavior. You saw the great new iPhone 3.0 feature Copy, with the selection UI come up.

You may have copyrighted data, you may have displayed some data which you may want to be interacting with, and you don't want the selection UI to get in the way. The Tap Highlight indicates to users what they're interacting with on the web page. You may want to customize that to match your design of your site, as well as turn it off completely. I will show you how to do both. And lastly, the alert sheets that come up and enhance the browsing experience. They may get in the way of your interaction experience, how can you modify their behavior. So first up is the selection behavior.

This will prevent the selection UI from displaying. And this is a key feature of iPhone 3.0. So these will not be able to be copied. This is desirable, say if the image is copyright protected. So you should use this selectively. Your users are going to be expecting to be able to copy and paste.

So some portions of your screen may want to be copied. That's what that slide's for. It's a CSS property, and you can use it selectively. By this I mean instead of turning it off for an entire page, you turn it off for the elements you're interested in. It's called Web Kit user select and returning off, in this case, so its value is none.

This comes in desktop Web Kit as well. The Tap Highlight behavior. What this does is it gives users feed back about their interaction. So if it's important that the user knows that they're interacting with, if you don't have another way of displaying it, this is very useful. By default it's gray, but it's a CSS property that you can customize per element or per the page. It's a CSS color, you should make sure that it has alpha so that the content behind the Tap Highlight is visible.

So in this case, the color that I'm using is the light blue color. You can also hide it completely with the clear color. Because again, these are CSS colors, so I'm using transparent here. Web Kit Tap Highlight color. So you can see if you're interacting and the Tap Highlight isn't there. iPhone screen size, it's not terribly clear what you're interacting with.

So be very -- use this wisely. So navigation and sharing. How do you customize this behavior. You tap and hold on a link while browsing. This sheet will come up, it will allow you to open the link in a new page or copy that link to a paste board so you can share it. You may not want that UI to come up while people are interacting with your web site.

Also, images. If you tap and hold on an image, you can save it to the photo library, as well as copy it so it can be shared. Again, you can apply this selectively. It's a CSS property, and it's called Web Kit Touch Call Out, and in this case we're turning it off, so its value is none.

Text sizing. So you can see here that we have a web page where all the text is displayed, but it's rather small. You'll have to zoom in to read it. How do you get it to look great so in that first display it's legible. Well, we have a CSS property for that. It's called Web Kit Text Size Adjust.

So in order to override the default behavior, which is to scale as the iPhone developers have found best, you use Web Kit text size adjust none. This way you will get actual size text with the rest of your web page. By default it's auto, where iPhone for OS is picking the best size for the text. You can also specify it by percentage. You want it to be 200% bigger than normally displayed.

That's text scaling customization. Okay, screen size best practices. How do we get the initial display of a big web site like this to look great on a screen this size? If it was actual size you wouldn't see too much. So how do we scale this down to look great.

Let me introduce to you how we're doing that. First of all, iPhone assumes or uses 980 pixels as the default width of a web site. So we render your web page as if it was 980 pixels and then scale it down to fit. From that to that. How do we do this? Well, we're using two concepts here.

On desktop, the window and the Viewport are the same value, they're the same rectangle. And what they are is the visible area of the page. As you can see, there's a scroll bar. There's more web content that isn't yet visible. Those -- that content is not in the Viewport nor in the window.

On iPhone, the window is the size of the visible area on the screen. However, the Viewport, it might be a little hard to see, but the Viewport is as big as the entire rendered size of your web page at that width that we specified, so 980. So that content that's down below on the window, on desktop, is contained in the fully rendered web page. So it's contained in the Viewport. In essence, what we do is we -- when you're panning and scrolling is moving the window around on that fully rendered Viewport. Again, I'm going to emphasize.

On desktop, the window and the Viewport are equivalent. In this, now that I've explained a little bit more, fixed positioning is relative to the Viewport. So you can see when you pan and zoom around fixed positioning isn't relative to the window, it's relative to the Viewport. Again, on iPhone, the window is the size of the visible area on the screen.

So when we're zooming, pinching and zooming, what happens is we're scaling the Viewport. That's how that works. So how do you customize that initial width. That's what we're going to take and scale to the device width of the iPhone. You use the width that your web page designer used while designing the site.

In this case for Paul's demo, it was 1024 pixels. It's a meta tag on that page, it has a name of View Port, and its content is width equals 1024 in this case. Going to step a little ahead here. For web apps we want the web content to be actual size and match the device. So you use Viewport width equals device width. We use a constant here because when the user rotates the device, the width of the page we're scaling to will change.

This handles rotation nicely. So atypical usage with the Viewport is the height. Typically in web pages there's a fixed width and all the content just flows down and you scroll to it. You can set it to a fixed height with device width, but that's not typical behavior. Lastly, the home screen icon.

Paul showed you this. You tap on the + button, you tap on the Add to Home Screen button. You see your custom icon right there. This is the way when you have a web app, this is the way your users will get to your web app. They must go through these steps to get it on the home screen. How do you do that? So you get from scaled images of the web sites to your icon on the iPhone home screen.

So how do you specify that. It's a 57 by 57 pixel PNG file. There's two ways you can specify it, and two types that you can specify. So that's what this table is. You can set your Apple touch icon for the entire web site. Install it at the root of your web server.

Alternately, you can specify it per page. The first way will automatically round where we get the rounded rec and glass your icon. Will get that neat little glare that you'll see on many of the iPhone icons. So for the entire site, put a file at the root of your web server called apple-touch-icon .png. This may seem very similar to favicon to you, PNG file is a richer format.

Looks great on the iPhone screen. If you want to specify it per page, it's a link tag who has a route property of apple-touch-icon, and the href points of the URI where you have your PNG file. If you don't want the glass look but were still going to automatically round it for you, it's very similar. You add - precompose to both of those. So at the root of your web server apple-touch-icon-precomposed. And then the link tag, same thing, Apple touch icon precomposed.

So here's Paul to show you how he customized that web site.

So this is the web page as it was before. Remember, this was just the existing web content loaded up into the Simulator, and this is our new version with just a few of those modifications. it's a subtle change. I'm going to flip back and forth a couple of times and we're going to take a look at what changed. So before, and after. Back to before. And after.

So the first thing we did is we added that Viewport meta tag. That gave the content a little more room on the site, the site was designed for a slightly larger screen, and so now the content has room to breathe, looks a lot nicer. But probably the most noticeable thing is the text size. So this paragraph here just under the events header got a lot bigger.

Now you can read it without having to zoom in at all. As soon as you go to the page you can read the entire paragraph, it's great. The navigation up here, we also increased the text size there. So now you can see there's navigation, first of all, and you can move around the site.

And I also increased the text size of these headers here. Now one of the great things about Safari for iPhone is that double-tap to zoom behavior. But in order to know where you want to zoom in, you want to make sure that you can read those headings. So now, instead of not knowing where to double tap, it's very clear. Top of the design awards. Double-tap. There you go. The content -- this content here, these paragraphs, they were already optimized for double-taps.

So I didn't change those text sizes at all. The other issue we had is the link color when you click on a link. Didn't really show up in here. We changed that to blue. Now it's really visible. You can see when you've tapped on a link, when you're going to change navigation. But we didn't apply that across the entire site.

So down here, still in grays. Still the default gray. It's CSS, you can choose whatever elements using regular CSS selectors. Really nice way just to change some areas of the site. And the same way, we can still copy down here, bring up the selection UI, all that sort of stuff.

But we disabled it up here. So no matter how many times I double tap or tap and hold, neither that action sheet nor the cut, copy, and paste UI come up. And is finally, the last thing we talked about. That home screen icon, where you add the web site to the home screen, tap +, tap Add to Home Screen. Now I've got a great logo there. I decide to use the automatic grounding and glassing.

So that's applied for me automatically. And when I add it to the home screen it looks like a great app sitting there, ready for the user to use.

Awesome, Paul. Thank you very much. So what did we just cover? We covered the basics. Getting started with those iPhone web technologies. I showed you how to get custom interaction behavior, custom text sizing, screen size best practices with the Viewport.

And how to get your icon on the iPhone home screen. So now creating an iPhone web application. We're going to build an iPhone application using web technologies. We're going to make that transition from a web site to a web app. We're going to become full screen. We're going to customize how the users can scale your web site.

We're going show you how to use high performance graphics so that your iPhone application built using web technologies has that same great, immersive feeling as all iPhone applications do. Lastly, we'll show you how to work off line, because sometimes your iPhone isn't connected to the Internet. So Paul's going to come right back up -- actually, he never even left -- and he's going to do a demo of a great iPhone web application.

Okay, so I've got to show you this on a device, because it looks and feels great. I've already installed and application to my home screen, I've got a nice icon, this time I decided I didn't want the rounded and glassed look, so I'm using that precomposed icon, so that's the 2009 WWDC badge. And we thought for an interesting demo it would be kind of a fun thing to take the WWDC conference schedule and turn it into a web app. Now I say web app. But some of you are noticing the airplane out in the corner.

We'll talk about that in a minute. This is a web app. And it looks and feels great. So let's take a look at this. The first thing is the Viewport that we've been talking about. What we've done is we set the Viewport to be the width of the device's screen so we get 1 to 1 ratio of web content to the screen. It's actual size. We don't have to worry about scaling or anything like that. Part of the thing -- one of the things you can do with a Viewport is you can disable viewer scaling too.

So even if I pinch or anything like that, it doesn't scale. The status bar is custom. It's a black translucent color, and the content will scroll underneath it. And well, there's no Safari chrome. The address bar is gone, the navigation, the Forward and Back buttons are all gone.

This is a full screen web app, you have full control of the screen. So I want to show off this app a little bit. We can choose different days here. It's kind of like the native application if you downloaded it and installed that. And what I like to do when I go to conferences, I go through the whole schedule and I say, oh, that sounds interesting. Like, deploying -- Displaying Web Content in iPhone Applications. That's a pretty awesome session, we want to go to that one. So I just tap it, mark it with a star, and that's saved to my favorites list.

And we can go through. And when I tap them, there's this nice little bounce. And I'm not doing any of that animation in JavaScript. I'm triggering the animation in JavaScript, but that's a CSS animation. There's a session on this later. It's a CSS advanced visual effects. So you can transform and animate your elements using only CSS.

So I'm going to go back to the top, and our favorites are saved in that tab over there. Now I said this is running in airplane mode. There's no internet connection, but this is still a web app. I went to Safari, I tap +, I added to the home screen. It's running fully off line, and there are three APIs we're using to do this.

First to save all of the HTML, CSS, and JavaScript, there's something called the off line application cache. You specify manifest file, list all of the resources you want saved into it, and they're downloaded and saved on the device Now this is also awesome in case you're using an online application, because it means you don't have to hit the network when you want HTML or CSS.

You don't have to go around to the web server, it's already stored locally on the device, it's cached, and that cache will persist across reboots. Now all the session data is actually being stored in the structured storage database. It's a database that's on the device and I can use SQL commands to get to it. So when I'm doing all of this filtering and I'm saying show me the things in the Mac track on Thursday, actually all I'm doing is writing SQL queries.

I'm saying select star from sessions where track is equal to Mac and day is equal to Wednesday, or day is equal to Thursday. It made developing this really easy. I didn't have to write any custom JavaScript objects or iterate through arrays. I just let the database do all the indexing and querying for me. Turned out really fast. Lastly, the favorites. They are using a much simpler API.

It's called local storage and session storage. It's a persistent object. You set strings on it, identified by keys. And later you can get those strings back out of those objects. Local storage will persist across reboots. So if I go back to this app later all of my sessions, all of my favorites, they'll still be there. We can use it totally off line without any network connectivity at all. So that's a lot of things we just talked about.

Greg, maybe you can go over --

What an awesome looking app. All with web technology. So the first thing that Paul did is he went full screen. We went from this in Safari for iPhone, to that. Full screen. How do you do that? What this means is you're more than just a bookmark on the home screen, like we were for web pages. You'll have no Address bar. No Tab bar.

Web apps always launch in portrait. Here's one important thing to note about web apps. Any links will open in Safari on iPhone. This -- this is because Safari on iPhone is great for browsing the web. It has history and all the browsing behavior. So if you go off of your web page that's in your web application, it will go to Mobile Safari.

Even if they're in the same domain. That's something I didn't even realize the first time I heard about this. So what you should do is use XMLHttpRequest to get more data. You could do all of this with JavaScript links rather than anchor links. As Paul showed you, you could get a custom status bar style.

The status bar is this area at the top of the screen. You can customize it. And new in iPhone 3.0. Paul didn't quite get to it, but when the iPhone launches a full screen web app what you'll see is what was visible the last time the user used your app. You can set a custom start up image as a splash screen for, say, like with native applications. New in iPhone 3.0. So how do you make your app full screen? It's a one liner.

So you add it to your web application's HTML. It's a meta tag whose name is apple -mobile-web-app capable. And of course the content is yes for this case. And you can query this at runtime. That's how Paul's knew from Safari on iPhone to say, hey, tap on this to add me to the home screen.

And then when we were running from full screen mode, he knew right to go -- to go right to the schedule. So it's a property on the navigator. It's called stand alone. Clearly, it's true when you're a full screen web app. And it's false when you're in Safari for iPhone. How do you set a custom status bar style. There are three styles of status bars. The default. This is what appears in Safari on iPhone.

It's a gray background. You're all used to it. You could set it to solid black. Here I have drawn a little line around it, so it was clear against the black background as to what it was. So you set this with a meta tag, again. The name of this one is mobile-web-app-status-bar-style.

The content for this is black. And as Paul showed you in his demo, there's also black translucent. Not the greatest screen shot for this, but the web content is visible underneath the status bar. It's also the same meta tag. Here the content is black- translucent. So one thing to note with black translucent. Any web content that shows up under that status bar is not useable.

The user can't click in it when it's under the status bar. So one thing to note here, all these three screen shots are the same size. And you can see because the web content is displaying up and underneath the status bar you can actually see more of those tabs on the web page. So you get a little bit more room and it's nice when scrolling. But that top part -- not accessible. Custom start up image.

New in iPhone 3.0. As I said earlier, it always launches in portrait. So your start up image is a 320 by 460 pixel PNG file. That accounts for the status bar. And you specify it for your web application page with a link tag. It has a rel property of Apple touch startup image, and has an href property of the URI, rather, the URI, where your startup PNG file is. Okay, screen scaling best practices. Users can scale your web content. How do you optimize that scaling behavior. Well, it's the Viewport tag. Remember, I talked about that earlier, saying what the initial width was of the Viewport.

Now we're going to be customizing the scaling behavior. Initial scale, minimum scale, and maximum scale. These will specify once you have the width, then the initial scale we're doing upon that Viewport size. In addition, you can set the minimum scale and the maximum scale that the user can scale your content to.

Let's just say that you only want them to do it initially at one and no bigger than two times bigger. So they could zoom out but not in, more than twice. You'd use this right here. It's the Viewport tag. There are more properties on the Viewport tag, they're separated by commas.

In this case, initial scale is 1, and the maximum scale is 2. You can turn off scaleability completely with the user scaleable property. It's on by default. So typically I would imagine that you're only going to turn it off when you use this in the Viewport tag. So you would add it to the list of items in the Viewport tag, user scaleable equals no. So when you're making a web app, what I imagine you're going to want is 1 to 1 actual size, like Paul's demo there.

So what I suggest you have in your Viewport tag for these items, user scaleable, no. So there's no pinching and zooming of the content. And width equals device width. It will layout one for one with the width of the iPhone, and when you rotate. High performance graphics. So Paul had that great little pop that occurred when we selected his favorite sessions. Looks great, people love that interaction in iPhone applications. And I'm going to do a quick overview, because there's a whole session after this session in another room that I'm going to go over this. This is that animation, by the way.

So it's CSS. This is CSS code that you see here. So on the first selector, New Favorites. When you select that, it becomes a new favorite. We have an animation. Here it's called Favorite. And it refers up ahead to which WebKit keyframes favorite. The duration of the animation is 0.3 seconds, and it happens once.

So the animation's going from a scale of 1 here at the beginning of the favorite animation, and here at the bottom it's going back to a scale of 1. Now along the way the other key frames in this animation 20% of the way through, the scale goes down to 90%. So it looks like it's pulling back. And then halfway through, the scale goes back out to 120%.

So you get this -- rather you get this. And it goes back to 1. So quick overview of the types of things you can do with CSS visual effects, because in this next session you'll see all about it. I think it just animated where those items moved around.

More animations you could do. There's also -- you could get your DIVsto slide, like UIKit, UITableViews. You could get this awesome 3D effects. That's like the weather settings. Those are DIVson either side, and they flip around in 3D space. Here's another great 3D demo. These are all demos from last year's CSS visual effects. All of those are DIVsthat are on a big circle, and as you tap and roll them, it rolls it. It's beautiful stuff you can do. All with CSS, HTML, and JavaScript. I've really pumped it up.

Working off line. Because the iPhone, believe it or not, may not always be online. It's always so disappointing. What do you do? HTML 5 has a standard way of having off line storage. It's a w3 standard. You can read about it here at this URL. There's three types and three characteristics. I'm going to go into each.

Again, this is an overview because there's a session later this week. There's session storage. This is a property on the window object called session storage, and it's like key value pairs. It's terribly simple. It's JavaScript programming in my mind. Session storage.my key =my string value. Key value pairs. The persistence of how long this object lasts is pretty much the life of the lab. So I would think about this is good usage in ecommerce sights, where you may be putting things into a checkout cart for a while. One of its advantages is really fast data access.

Once that data is in there, it's really quick to get out. Next up is local storage. It's so similar to session storage, but the persistence is different. It's keys and values, just like session storage. It's an object on the window called local storage. This is like a supercookie, if I haven't already said that.

It persists across reboots. So this is how Paul stored his favorite sessions in his web application. Again, this is great because it has fast data access, and who doesn't like to use supercookies. Next up is structured data storage. You use the Internet, download your data, put it into a structured database, and you can get SQL access to your data. What's great about this is it persists across reboots.

Then your web application doesn't need to be connected to the Internet to get this data later. The session data, for example, is fairly static. Download all that at the beginning, you don't need to get it again. And what's great is Paul used that SQL select statements to pick each track day of Mac, iPhone, IT, and the days of the week.

So you get fast queries. Great stuff. There's also the off line application cache. It's an HTML 5 API. It comes from the w3 organization. You can read all about it right here. So it is a file called the manifest file. And the contents of this file are the list of resources that you would like the web technology on iPhone to cache for you. I'm doing an overview because there's a whole session about this.

There's an attribute on the HTML tag called manifest. And it points to a URI where your manifest file is. One thing to know about manifest files is you have to configure Apache or your web server to serve up the correct mine type for your manifest file. And the great thing about it as well, is you can determine whether or not you have online access. So whether or not you should go try to poll more data from the Internet. It's a property on the navigator whose name is online. And if you're on line, it's true.

So to summarize. iPhone applications created with web technologies. Getting from our web site to a web app. I showed you how to get full screen, how to handle the user scaling behavior, how to get high performance graphics, so you can get that immersive, great iPhone application feel using only HTML, CSS, and JavaScript, and how to work off line. Not only is it great when you're not connected to the Internet, but it's fast. So now we're going to add advanced features.

We're going to put the iPhone in your iPhone web app. We have JavaScript APIs for the iPhone. You can determine when the device orientation changes, say from portrait to landscape and back. Multi-Touch support. How can you get access to all those fingers, the domino is about a mouse. It only has one. But we have five.

How do you get that Multi-Touch support in your web application. And new in iPhone 3.0, location awareness. Your user can share their location with your application. You can give them an awesome experience. We're going to start with a demo. Paul has some great enhancements to that attendee web site.

Thanks, Greg. Okay, so I'm back here on the home screen, I'm going to launch our web app again, and there's that start up image.

So you know, I've got this great list of favorites, and the favorites are still there. You know, they're saved across launches of the web app. I've got this list of favorites, and I have the title of the session, the time, and the room it's in. But you know, this is my first year at WWDC actually, and I'm not really sure where all of these rooms are, and a couple things got moved around a little bit. So what we really need is a map. So I'm going to take my device and I'm going to rotate it on its side there. And there we go. We listen for the device orientation change.

When the orientation changes you can relayout your web app, or put up new content as I'm doing here. And we've got a map, and here's the first floor and we can tap between the different floors. And when we change between the different floors there's a really nice quick fade that happens. This is actually, again, those CSS visual effects.

I'm using a CSS transition on the opacity property to cross fade between the different floors. And you know on the first floor is the iPhone lab, you really should stop by, you could talk to us, we could tell you all about the things we're doing here, show you a demo if you have any questions. But you know, WWDC is more than just what's happening inside the walls of Moscone.

There's all the meet-ups and the parties and you have a hotel, you're not sleeping in Moscone, right? And so that's why we've got this last tap here, local. So I'm going to go ahead and tap that and bring that up. And it's just a map of the area.

And I'm dropping down some pins again, more CSS visual effects. And so I've got some pins marking -- well the green is us, Moscone. And let's see, that red pin there is one of my favorite coffee shops in the area, Blue Bottle, and there's a -- Union Square up there.

And we can -- we can take this and we can put our finger down, and we can pan. It pans really nicely. And this is because we're using those DOM Touch events. We're getting information about what fingers are being placed down on the screen, when they're being moved, it's a really fast API, and you can use it for direct manipulation of your content elements.

Now the map you can see is actually scrolling behind. The navigation at the top, it's scrolling behind the menu bar, behind the logo in the corner. I'm positioning the map using CSS transforms. If you do it right it can be really fast. You really don't have to relayout the page. So you can get really nice scrolling effects like that.

And of course we can use two fingers to zoom in or rotate. That's a really nice effect. But you know, I'm looking at this map -- does it both anyone else that Market Street is crooked? I lived here for a little while, but let's -- let's do this.

Yeah, that's a lot better.

But, sometimes you're walking around, and you don't really know where you are. You're not really too familiar with the streets, the city, that's why I've got this button in the corner. And well hopefully, it will eventually get its head together. If all things go well. There we go. That's a live Geolocation reading. This is core location, no fakery. It's figuring out using cell triangulation, GPS, we're there.

We're there at that green dot. So this is a new API in 3.0, Geolocation in your web apps. Now normally you're going to get two privacy alerts. You're going to get one if you're running in Safari, for example, for Safari letting the user know Safari wants to know the user's location, and you're going to get one for the actual web site itself. Each web site is going to pop up a privacy alert to the user. And if they accept, Geolocation is going to pinpoint you and you're going to get, as we saw, more and more accurate information the longer you wait.

So maybe this is like not the sort of room of people I need to tell this, but this is a web app. This is HTML, CSS, JavaScript, no Objective-C, no Cocoa Touch was written at all for this. We used for the most part up and coming standards, some specs that are in development, HTML 5, Geolocation is an up and coming spec, some of the new CSS visual effects that are in draft form -- proposed draft form -- and just a couple of iPhone specific extensions. And we wrote a web app that looks and feels great, like a native app. Like if I told you this was written in Cocoa Touch, would you believe me?

Awesome app, Paul.

Few things we covered there, Greg.

Give us the details.

One thing I want to point out is Paul didn't get the may I share your location with this application alert. It's just like the one in core location. He used it within the last 24 hours. Every 24 hours it will ask you can we use your location again. I just wanted to point that out.

What a great app. I wish Market Street was straight. Okay, device orientation changes. We went from the schedule in portrait to these great maps while in landscape. How did we do that. It's actually really simple. We're listening for orientation changes. You attach them to the body, because we don't want -- you want the whole page to rotate.

And you can even do different things, but the event is sent to the body. It's called on orientation change. It's handled like any JavaScript event. In this case, I'm calling some JavaScript called update orientation. And what you'll do in this case when you get an orientation change event is look at the orientation property on the window. This is what we've added for iPhone.

If it's zero, you're in portrait. If you rotated the phone counter clockwise to landscape, its value is 90. And if you rotate it clockwise, its value is minus 90. So those are attached to the body. What Paul did when we got these events was swap out the sessions DIV, the HTML element, and put in the maps DIV.

So he hid one and showed the other. You could do something like that in your orientation code. So we have Multi-Touch. That's how Paul was panning that content directly, while keeping the rest of the items fixed on the screen. As well as how he got the pinches and the rotates.

Typically with the web you have one pointer. There's -- it's the mouse. On -- and you could move it around, drag things around. But on iPhone, you could have another pointer, put down another finger, and once you do that, you could get gestures, like zooming in and zooming back out, around with the DOM Touch APIs, you can even invent your own gestures. So what are the details of touch events.

For each finger the event order is this. You'll get a touch start. This is when the finger first touches the screen. Should the user move that finger, you'll get a touch move event. And when they lift their finger, touch end. You can also go directly from touch start to touch end.

That's a quick tap with any number of fingers. One important thing to note is touch cancel. Once the event cycle has started, started and then touch started and then touch move, a touch cancel event can occur. This will happen, say, when the user touches the lock button, or a JavaScript dialogue occurs. Technically, the user is still touching the screen, but those events, you're not going to get the touch end.

You're in a different mode now, if you will. So be aware of touch cancel, and I can't emphasize enough, touch cancel is very important to listen for. And these are just like regular JavaScript event handling. There's the on touch property -- I'm sorry -- there's the on touch attribute on any DIV, and you give it a JavaScript function to call. And you could also use it all via JavaScript with add event listener.

Standard JavaScript event handling. So I'm going to do -- show you what are the features of a touch event. So when touch is started here what we get is a touch event. If you want to know all the current touches that are occurring for all fingers that may be touching the iPhone, there is a property on the touch event called touches.

It's an array of all the touches. Now when you add the event handler to an element you may be interested in what fingers are touching that particular element. That property is called target touches. It is again an array of all of the touches that are touching that target. While you're on -- using Multi-Touch on iPhone the user may be keeping one finger still and only moving one. You may only want to know in this new event cycle what touches have changed. So on the touch event, there's a property called change touches.

So I have explained that these are arrays. To get the first touch that goes down, you get touch -- you get the target touch zero. And then that touch -- so let me explain, a touch event has lists of touches. So -- because multiple things can be occurring at one time. Those will occur as touch events, but there's a lot of touches in there. So that you could get the touch and you could get the touches target.

What element is it current touching. In case you need to track the touch from event to event, it has a property called identifier. This way you can watch where a particular finger is moving from event to event. And of course because these are user interface event and they're happening to your web app, they have locations, client X and client Y are defined as relative to the Viewport, which I explained earlier. There's also properties for screen -- location relative to the screen. And also location relative to the page. Just like mouse events.

Okay, we also have gestures. This is when two or more fingers is down on the screen. There's two gestures that we support. Scaling, as you're used to with iPhone, and rotation. That's when you have two fingers down and you basically rotate your hand. For each of those gestures, once the second finger goes down, you'll get a gesture start event. And it is of course followed by the gesture change event. What is the user doing.

And then when there are no longer two fingers on the screen, you'll get a gestureend. I also need to point out gesture events and touch events come in the same event stream. So you'll get a touch -- and you don't have to listen for them all either. But if you listen for touch events and gesture events, you'll get touches, and as soon as that second finger goes down you're going to start getting gesture events interspersed. These are just like JavaScript events, so you could add them to your HTML elements, much like touch events, and much like mouse events.

So let me explain gesture events. When you get -- in this case I implemented gesturechange, and it's going to get an event -- it's called a gesture event. And you could see what HTML element is being targeted by this gesture event. And just like touch events, event has a property called target that gives you that information. Okay, for scaling. You put your fingers down, the scale property of the event is 1. And then when you make them smaller, you pinch in, you're going to be scaling it smaller. It's less than 1. When you open, it's greater than 1.

That's the scale. Next up is the rotation. So this is the gesture that isn't used very often in iPhone, and it is the rotation of your finger in degrees. And it's the delta. So if I go here, the delta is 0, and if I move that much, it's 30. What did I just do -- I went counterclockwise, so it's -30, and clockwise would be +30. So you can do little rotation gestures, much like dials, if you think about it.

It's a probability on the gesture event called rotation. One awesome thing about Multi-Touch and CSS visual effects is they go along great together. Because users love to directly manipulate things on iPhone. It's fun to play with web apps that do that. So you can quickly transform your HTML content with CSS visual effects, and when you have the touch events involved with that, that's direct manipulation. So in this little code sample, I call it a code snippet, I'm getting the first touch out of my target touches.

And I use the location, the client X and the client Y, and I pass it to a function both get translated X, and get translated Y. This is because in Paul's app, as he picked up his finger and moved it along, the map was transformed. And we need to keep track of where it was transformed to, so the next transform adds to that. And what you do is you get that new translation location, and you pass that to the CSS property Web Kit transform. And you set the translate.

It's in pixels there. Notice the px added to each. Same thing goes with gestures. When you get those gestures in, the user has scaled and or rotated, you can listen for one or both. And again, I'm using get current scale and get current rotation, because as you pick up your fingers and scale in you're going to want to track where the current scale is, as well as the current rotation to get great UI. You set the WebKit transform both to scale and the rotation. Note with rotation you have to add the DEG there for degrees. Okay. Brand new in iPhone 3.0 is web location -- pardon me -- location awareness in web pages. What we use is the Geolocation JavaScript API.

So this is a W3C editor's draft. It's also implemented by other browsers. So it's a draft standard that looks pretty good right now. So you can read all about this spec at this URL here, at the W3 web site. Basically, it's an asynchronous location API. You make a request to Geolocation for the user's location, and at some point in the future your callback will be called, and you will be told their location and if available, their speed and heading. When you define here that speed is of course where you're going. Heading is where you're going and not where you're looking.

So it's not a compass. How do you access Geolocation? Well, it's an object attached to the navigator object, and being a good programmer, you always want to make sure it's there before you proceed. But on iPhone, it's always there. I should say on iPhone 3.0 it's always there. And you could get a one-shot position.

You could ask where am I? It's a function called get current position. And when you pass is a position callback, because this API Geolocation API is asynchronous. You need to pass a function to be called once it knows a location. You can also observe the position. You could see how in Paul's demo the location kind of popped around as we determined where we were. He was watching -- that code watches the position, because it can change over time. So it's a function called watch position.

It too takes a position callback. And it returns a watch ID. The watch ID is important because at some point in the future you're going to want to stop watching the user's location. And with that, you use clear watch. And you pass it that watch ID, which you got returned from the watch position API. So I said I'd get back to these position callbacks. When you get a position, you get an object called position.

And it has several properties on it. First property that we'll talk about is the time stamp. When was this position obtained. And this is because, which I'll get to in a little bit, you may get older positions if you so desire. We're in a position callback. Obviously, the Geolocation API knows where you are, so location is specified with latitude and longitude, which I'm sure you're familiar with.

They're specified in decimal degrees. And they have an accuracy in meters, so you know about how close that location is. If it's available, the -- oh, I forget to mention something. The -- all these positions are on the coords object, which are in the position. You can see that I have position. coords. This is how the API is specified. So the coords property contains the location. The position contains the time stamp and the coordinates.

It's a little confusing. So if it's available, the coords will also contain the altitude, which is in meters. And has an accuracy. The altitude may not be available because of the iPhone you're using may not be able to support that feature, or it may not be able to tell you at the time the position is known. And so you should program knowing that these may be undefined.

They're JavaScript objects, so undefined could mean different things. But they're basically not defined. Same goes with speed and heading. Speed is in meters per second and your heading is in degrees from true north. And again, heading is where you're going, not where you're looking. That's a compass. So these may also not be available. You should program being aware of that.

For example, I found in my iPhone 3.0 tests that the speed and heading aren't known the first few times. This is why watch position is a great API. As it -- as the location services on iPhone learn more about where you are, things become more accurate, as well as knowing your speed and heading.

So we have the position. Something can go wrong, so of course there's also an error callback. It's optional, but I highly suggest you implement it. It will give you a way to give better user feed back for your web app users. Here's an error callback. It receives an error object.

The error object has a property called code, which is obviously specifying the error. Permission denied. This is that dialogue, because Paul had already given permission to the app where the user is -- can deny or allow or don't allow, approve, I'm not sure the wording right at this moment.

Giving the user sharing his location, his or her location with your app. If the user says no, you'll get a permission denied error. And you could give -- you could change your UI to indicate to them what great features they're missing out on by denying that -- denying location services.

Position unavailable. Paul showed it running under airplane mode. The way location services work is aggregating the cell data if available, the Wi-Fi data if available, and the GPS data if available. If all the radios are off in airplane mode, none of that data is available, but Geolocation can work.

In those cases, you'll get a position unavailable error. This I'll explain the details of in a moment. But there's an option you could tell Geolocation, please give me a location within this amount of time. So should that time expire before you have a location you'll get a time out error. And everyone's favorite, unknown error.

Something happened that isn't one of the above three Errors. For those cases, there's a property on the error object called message. That's great for development debugging. The strings shouldn't be shown to users according to the Geolocation spec, but it's really useful in debugging. So I just alluded to it. We have the position callback, the error callback, and of course some options. How do you specify some more details on how Geolocation should work. It is of course a JavaScript object, which is properties and values. So here's one way you could specify it.

The first property I'll go to -- go into -- is enable high accuracy. This is a hint to Geolocation how it should try to obtain data. Basically, on discussion on the specification list, it implies that you're interested in using GPS. It also implies that you know you are going to try to use more power on the device. So if you say false, you're saying -- you're indicating that you're not so interested in high accuracy. You say true, you are. The time out. This is the error.

You specify the time out in milliseconds. This is the time you're willing to wait to get a position callback. So should that time exceed, you'll get the error callback of time out. So if you specify a time out option, you should have an error callback. Lastly, there's a property called maximum age. Again, it's in milliseconds.

It's very useful with the get current position callback. You could say I'm interested in a location, but I don't care, it's fine with me if it's an hour old. This way you're going to use very low power, and you may only be interested in something that specific. So here are my best practice slides for Geolocation. Number one.

We have a big battery there. Because you should mind battery life. It could fire up all three radios, location services can use more battery than just browsing a regular web page. So be very aware of that. When you use get current position, basically what you're saying is I'm interested in my opinion, you're interested in getting a quick position. And maybe the last position known, which may not be your current location, is sufficient. So you could use something like position options maximum age there. However, there may be other cases where you want more accuracy. And I'm going to reiterate.

You should mind the battery life, especially with this API. Watch position. This one you could watch yourself move around on a map. This little pulsing blue circle, it could get smaller as its more accurate. Things that you can do with watch position is give great user feed back in your web application as to what the user's location is doing with respect to your app. As well as -- as each part of the location services on iPhone gets a fix on your position, it generally gets more accurate.

You have cell phone range, you have Wi-Fi range, then you have GPS range. And you now, again, that only works if you're outside. So there's all sorts of variance of accuracy that will change over time. I like that feed back for user interface. I think you should use standard Java -- pardon me -- I think you should use standard JavaScript timers rather than the timer in the position options. You're all used to JavaScript timers, why not use them.

And in that case, what you're going to need to do is when that timer is exceeded, you should stop watching position. You should always be aware when you're watching position so you can stop it at some point. You may want to stop it when the desired accuracy that's applicable to your application has been reached, when the time out has been exceeded, when an error has occurred, or in Paul's case, with the session app, we go from landscape back to portrait. When we're in portrait, we're just looking at schedules.

We're not interested in where the user is. I just talked about a lot. Adding advanced features using the JavaScript APIs on iPhone, device orientation changes, how do you learn the device changed orientation. Multi-Touch support. Location awareness. Brand new in iPhone 3.0. So today what did you learn? You learned first of all how to optimize your web site for an iPhone.

Because in the end a web application is a single web page. And for that iPhone web application, you made it full screen. You have offline data, so it works when you may be in airplane mode or in the Bart Tunnel. And you have sophisticated graphics with CSS visual effects. So you could get that great interactive experience with iPhone that you and your users love. Both of which give you great performance.

And as I just went through, you get advanced features, like orientation changes, DOM Touch events, and again, Geolocation. In summary, it's really easy to build iPhone applications with web technology. Because you already have a web site, and it already works on iPhone. Then you could just customize it and make a great iPhone web application with just a few more lines of JavaScript, CSS, and HTML. We already have a bunch of great web applications for iPhone, and we look forward to seeing yours on apple.com/webapps. So for more information you can contact Vicki, Mark Malone, and of course all this is documented at developer.apple.com/Safari.