So this is Getting Started with Safari on iPhone, and my name is Vicki Murley, and I am the Safari Technologies Evangelist at Apple. And as John mentioned this morning, I worked on the Safari engineering team for the first version of Safari on Mac OS X, and then I also worked on the first version of iPhone, which came out last year. But for the last year or so, I've been working as an evangelist on the evangelism team, working with developers, just like you guys, to help them move their web content to iPhone or to develop full-fledged iPhone web applications.

So today's two sessions are going to focus on, you know, getting started with Safari on iPhone. If you're new to the platform and have an existing site, or are thinking about making a full-fledged web app, this is the session to be in. And then later this afternoon, we're going to talk about some advanced topics and new technologies that you can use in your web apps.

So in today's talk, I'm going to cover five major areas. First, we're just gonna talk briefly about kind of the impact and market trends that we've seen with Safari on iPhone. So maybe some of you are a one-man shop or two-man operation, and you're kind of wondering just how many people are using Safari on iPhone. Why is it compelling for me to develop for this platform? After that, we're going to talk about Safari on iPhone fundamentals-- kind of how Safari on iPhone works, how it does what it does.

After that, we're going to talk about optimizing for Safari on iPhone. This is a great section if you have an existing website or existing web content, and you just kind of want to make a couple tweaks that will make your site look great on the device without breaking your existing site. That is the section for you.

After that, we're going to get into full-fledged web apps, and specifically, creating them through Dash Code, which is an IDE on Mac OS X, also used for developing dashboard widgets. And after that, we're going to talk briefly about using web content in native applications. If you have a web app, but you've decided that you want to add a feature that is SDK-only right now, such as location-based services, you would need to make a native application.

But there's ways that you can leverage your existing web code in that native application, and I'm going to tell you how. Okay, so getting started with kind of the impact of Safari on iPhone and some market trends. So iPhone was released on June 29th of 2007. That's when it got into users' hands for the first time. And later that year, it was named the "Invention of the Year" by Time Magazine. So this was very exciting for lots of people at Apple, including myself.

And really, you know, this is pretty exciting because iPhone really changed the way that people interact with all different types of media on mobile devices. So it changed the way we look at photos, changed the way we watch YouTube videos on mobile devices. I don't think I had ever done that before, prior to having an iPhone. I probably haven't used a paper map since I started using iPhone, so it's changed the way we use maps on the go. It's changed the way we listen to music. But more than anything, it's really changed the way that people browse the web on mobile devices.

And this is because Safari on iPhone is the first browser on a mobile device to really render desktop-quality web content on a handheld handset. So we're flipping through a few now. We saw eBay, I think we saw the New York Times in there as well, and this had a pretty amazing impact, specifically that more people were browsing the web using Safari on iPhone, using the iPhone OS, than any other mobile operating system in a very short period of time.

So if we look at the top three mobile operating systems in November of '07, and we look at-- we divide up the market share that the top three currently had at that time, we can see that iPhone operating system accounts for more than half of that pool of people.

So more than all devices running Windows CE, and more than all people running a device that has the Hip Top OS on it combined. More people were using iPhone OS to browse the web on mobile devices. Over the next eight or nine months or so, you know, that number just continued to grow, whereas the market share for other mobile operating systems-- in this case, we're looking at Windows CE-- just kind of stayed the same.

No new adopters, really. So if all these facts and figures aren't enough to make a compelling argument to develop for iPhone, there's one more great reason, and that's because it's extremely easy. The tips that we're going to go over today are maybe one or two lines of HTML, one or two lines of CSS, and you're going to see it's very easy to integrate some of these features and technologies into your web content.

So when we talk about web content on iPhone, we kind of have three levels of adherence. The first is what we call "compatible" with iPhone. So this is looks as expected, works as expected, and many sites fall into this category. eBay is a great example here. The next level is optimized for iPhone.

These are people who have taken advantage of some of the features on iPhone, but still have a website. They haven't made a full-blown web app yet. And then the last level of adherence is full-blown iPhone web applications. So these are web applications that have a UI that is specifically designed for iPhone. They have a discrete purpose. They're not, you know, the full-fledged site.

And the Facebook web app is a great example of an iPhone web application. Okay, so talking about those, you know, kind of three levels of adherence, we're going to go through Safari on iPhone fundamentals, that kind of compatible category, optimizing for Safari on iPhone, and creating web apps in Dashcode.

So getting started with fundamentals, the first thing we're going to do is just take a look at a case study. So this is the website KEXP.org. It's a public radio website in Seattle. Great radio station and great website, but I noticed that there were a few things that they could have done differently to look really great on iPhone. So we're gonna use them as our case study today.

So if we look at this page, we can see that things look pretty good. I see images, I see content. It's laid out pretty much like I would see it on a desktop browser. So things are looking pretty good. And that is because Safari on iPhone is using the same rendering engine to take care of all of the kind of core web technologies that is used in Safari on all other platforms. So Safari is now shipping on Windows, on Mac OS X, and on iPhone and iPod Touch devices, and all of those versions of Safari are using the same underlying engine, which is WebKit.

So as I mentioned, WebKit is responsible for kind of core web technologies, so things like parsing and rendering HTML, rendering CSS styles, executing JavaScript. WebKit takes care of all of that. And that's why you're able to see this kind of desktop-caliber web content on a mobile device because of WebKit.

WebKit is also the name of an open-source project, besides being the name of this engine that supports Safari on all platforms. And this is great for you guys. So WebKit was originally based off of another open-source project named KHTML, and then eventually, WebKit branched far enough that Apple-- the folks who were working on WebKit at Apple decided to make their own open-source project in 2005.

And this is great for anyone developing for WebKit or a WebKit-based browser, because we have many eyes on the engine, you know, many bugs getting fixed, many bugs being reported. But also, by virtue of being an open-source project and by being a kind of small and highly portable code base, WebKit is showing up in all different kinds of applications and on all different kinds of platforms. So for example, you may not know that WebKit is the basis for the OmniWeb browser, and it's also the basis for the new Google Chrome browser. Both of these web browsers use WebKit.

As I mentioned, WebKit is highly portable to other platforms. It's small and compact. So WebKit was used as the basis for the web browser on Nokia E60 series phones, and it's also used by the Open Handset Alliance. So this is great for you guys, because for web developers, compatibility is king, you know? So if you're working with the same engine in many different browsers, that's great for you.

Another thing that is great for you guys is that one of the tenets of WebKit is really standards-based compatibility. So when the folks at Apple who are working at WebKit and the folks across the world who are working at WebKit look for new features to implement, instead of kind of reinventing the wheel every time we have a newfangled idea, we look to the developing web standards for what's there, what's going to be implemented in every browser in the future. That's what we look to first.

We're going to talk later this afternoon about some really exciting stuff that's in upcoming web standards like offline web applications, database storage, stuff like that. Those are the things that we choose to implement in Safari. And as I think I mentioned, that's great for you guys because even if it's only implemented in Safari right now, by virtue of being part of a standard, it's going to be implemented in many other browsers in the future. So you're going to be kind of ahead of the curve by adopting early. Thank you.

Okay, so going back to our case study here, kexp.org, we mentioned this site is looking pretty good because it's using this very powerful rendering engine that's also used on the desktop to render this content. But if I zoom in on the upper left-hand corner, I see that there are two broken plug-in icons here. So plug-ins are not supported in Safari on iPhone at all. So you have to come up with some way to work around this. And the best thing to do is really to provide a fallback content.

So in order to do that, the first thing I did in my exercise here was I took a look at what the appearance was in a desktop browser-- a browser that supported plug-ins. So there was this kind of animated icon at the top, and then there was some text scrolling across that "Now Playing" area that was showing me the name of the artist and the current song that the radio station's playing.

So I'm really looking to provide fallback behavior here. You know, maybe I don't have exactly the same thing, but the key word here, as I said, is "fallback." So for that kind of animated image at the top, you know, the easiest thing for me to do, is to probably just take a still image of that logo and specify that image inside my object tag here. So then, browsers that don't support plug-ins, instead of having the broken plug-in icon, they will just render this image instead. So that is a super simple way to provide fallback content.

For the text that is scrolling down here in the "Now Playing" area, we could have really used just straight web technology to do the same thing. So a combination of set interval, XMLHTP request, and either JavaScript or CSS animation to kind of move that text across that area there would have achieved the same effect, and we wouldn't have had to resort to using a plugin. So use straight web technologies wherever possible.

Okay, so that covers Safari on iPhone fundamentals. Now, we're going to talk about optimizing for Safari on iPhone. So this is kind of if you have an existing website, you're new to the platform, you want to make a couple tweaks so that your site looks great on iPhone, but still displays well in desktop browsers.

So back again to our case study here, if I look at the right-hand side of the screen here, I see this large area of white space. And that is not great because the iPhone screen, while large for a mobile device, is still relatively small. So we want to be kind of utilizing all of the available screen real estate. What's happening here, we're going from a desktop-based browser, very large screen, down to the smaller screen. We have to find a way to render the content that we would be able to make very large on a very compact device.

So the way that we do that behind the scenes is we take the window size of the browser, and we assume a width of 980 pixels, okay? And then we scale that down and we assume a width of 980 pixels, okay? And then we scale that down to the width that is appropriate for iPhone, which is 320 pixels.

So in the case of kexp.org, this website, the web content is actually only 720 pixels wide. So you can see the content is 720 pixels wide. We're assuming 980. That's what's making that white space on the right-hand side for us. And then we're scaling it down to 320, and the white space remains.

So luckily, there's a very easy way to deal with this, and that is by customizing what's called the viewport. So it's easy to do. You just specify a meta tag, and for web sites, we recommend that you specify the page content width. So I mentioned that the width of the content here, these columns of text and images, is really only 720 pixels.

So I could add this tag to my web content-- meta name equals "viewport." The content equals "width" is 720. And that's going to take us from a layout that looks like this with this empty white space to one that looks like this. No white space at all on the right-hand side.

And that's what we want. This meta tag is gonna be ignored in browsers that don't understand it. So any desktop browser that doesn't have this tag implemented-- I don't know of one that does-- will just ignore it, and your content will be unaltered in any other browser. So if you have an iPhone or iPod Touch web application, we recommend that you use a constant here for the width value, and that constant is width equals device width.

Okay, so we mentioned, you know, one of the most useful values for a viewport here, the width, you know, but there are a couple other ones as well. So they are width, height, initial scale. You know, we mentioned we're scaling down from 980 pixels to 320. You can set all of these values in the viewport tag besides being able to set the width. The important thing to remember here is that if you set one of these values, the other values are calculated for you. So we set the width to be 720, and the height was calculated for us, and the initial scale was calculated for us.

Other values that you can set in the Viewport tag include the minimum and maximum scale-- how far a user can zoom in or zoom out on your webpage. And also, you can disable scaling altogether on a webpage by setting this value "user scalable" to "no." And that's very useful if you have a full-fledged web application. Like, most web apps that you see on iPhone don't allow scaling, they just want you to be in this one view. So that's how you would disable that.

So we've talked a little bit about how things look on iPhone right now, and now we're going to talk about how people interact with web content on iPhone. So the first thing I wanna mention is interacting with input fields. I notice this all the time. When I am logging into a website or updating my Facebook status, for instance, I actually don't want my text to be automatically capitalized and if I'm entering a password, I don't want my text to be auto-corrected. I don't want that pop-up bubble to show up and then I have to dismiss it and I've lost my place and I'm just totally confused. So luckily, there's an easy way to disable the default sort of keyboard behavior in text areas in your web pages.

And that's through two attributes here-- auto-correct and auto-capitalize. Of course, auto-correct-- it handles whether or not words are automatically corrected for you and auto-capitalize deals with capitalization. And if you set both of those to "off," both of those features are disabled. So as I mentioned, very useful for username and password fields in your web applications and web content in general. And of course, if a web browser doesn't understand these attributes, it will just ignore them and your content will continue to look great in a desktop browser that doesn't implement these attributes.

Okay, talking some more about how people interact with content on iPhone. Another thing to think about is double tap. We have this desktop caliber web content on this very small screen. So a way that people interact with it, I'm sure you all have done this, is to double tap on a given area of the screen to zoom in.

So what's actually happening here is iPhone is detecting where the touch has happened and finding the closest logical block of web content and then zooming into that block. So by a block, I mean like a paragraph or a div or what's called a replaced element, like an image or a video, where the dimensions of that media define the dimensions of the block.

So here, I've highlighted a couple blocks on this page. If I double tap in on this image here, it looks pretty good. I see, you know, the text and the image looks good. Here's this menu that was on the upper left-hand part of the screen. And here, I've double-tapped on the center area of the page.

So this is arguably, you know, the most important part of the webpage. It's kind of telling me what's new, what's next. And I can barely read this text. I can barely make it out. So that's not good. There's a way-- lucky for you-- there's a way that you can customize this for iPhone, and that is just through this CSS property, "Webkit Text Size Adjust." So here, on the left, we have set it to "Auto"-- or it's set to "Auto," which is the default. And we see the view that we saw on the previous slide. And on the right, we've scaled the text up by 220%. So now, I can, you know, read this text with no problem at all. And it looks great.

One thing to keep in mind when you are using "Webkit Text Size Adjust" is to make sure that it kind of jives with the rest of the CSS on your site, particularly line height. You want to use a relative line height, a multiplier like 1.2 or 1.5 or something like that, as opposed to using kind of an absolute line height, because the line height is going to be calculated off of the adjusted text size if you're using a relative line height.

So if I have adjusted the text up by 220%, but my line height is, you know, 20 pixels or something, you could end up with a scenario where you have text overlapping vertically, and that's not what you want. So make sure to use a relative line height if you're using the CSS property.

More about tap behavior. So, if anyone has ever touched and held on a link, you have seen this little bubble pop up, and this is what we call the "callout bubble." And this is really designed to provide users with additional information when they are on your site. You know, in this case, we can read the text, but you know, in many cases, the text might be too small to read, even after they've double-tapped in. So the call out bubble provides additional info.

The point here is to actually provide useful information in this callout, like the info. "Click here," I already know that this is a link, it's colored like a link. This bubble has popped up. "Click here" is not the most useful phrase to have in the bubble here. So the title is actually defined-- the title meaning the first line of the callout bubble is actually defined by the text that's inside the anchor tag, and then the subtitle on this bubble is defined by the href attribute within that tag.

So we can't really allow customization on this bubble because that would be kind of a security risk for users. Imagine I tell you I am paypal.com, but then you touch the link and I direct you to my malicious site and take all of your username and password info and then take all your money. That would be bad.

So we don't allow customization on this bubble, but we do allow you to disable it. If it's getting in the way, especially if you have a web application, you might want to disable it if it's not doing the behavior that you think your users would expect to see.

So you can disable this callout with just one line of CSS, and that's "webkit touch callout = none." thing that you can do with the tap behavior, which is kind of neat to do in your existing web content, and also very useful if you're doing a web app, is to customize the highlight color on links.

So the default highlight color is just this ugly gray color, but here I've customized it to be this kind of orange color that fits in with the rest of the color scheme of my app. And I've done that with just a line of CSS. There's a theme here. It's WebKit Tap Highlight Color, and you specify an RGBA value here. I have this orange color, and I also have an opacity that's about 40-- that is 40%.

The last thing I want to talk about in terms of optimization is optimizing the page load time for your application, optimizing performance. So the main thing that you're going to run into a mobile device is network latency on cellular networks. So by latency, I mean the time it takes for a packet to go from your device to the server and back again, as opposed to bandwidth, which is kind of throughput. You know, of the pipe-- the size of the pipe. So latency is round-trip time, and on Wi-Fi networks, latency is relatively low. It's about 100 milliseconds.

So pretty low. But on cellular networks, cell networks have inherently high latency, about 500 milliseconds. So you can see that, you know, if you have a lot of resources that you're requesting, and if they are loaded, not in parallel-- if you're waiting for one to finish loading before you can load another one, you can see that those, you know, 500 milliseconds are going to add up really quickly, and your page is going to load very slowly.

So we actually did a real-world test of two websites. We happened to choose apple.com versus microsoft.com. And you can see the total amount of resources on apple.com is greater than that number on microsoft.com. So we're looking at 610K versus 494K. So we have a larger amount of resources on apple.com.

If we look at the number of resources, though, you know, apple.com has almost half the number that Microsoft.com has. We are looking at 31 versus 55. And what that really means is we have fewer large resources-- fewer larger resources on apple.com, and more smaller resources on microsoft.com. So the average bytes per resource on apple.com are 20K, and on Microsoft.com, much smaller, 9K.

So when we loaded these two pages, both over Edge and 3G, the result was that Apple.com loaded two to three times faster than Microsoft.com. You know, even though the site was bigger, you know, in terms of total size, that fewer number of resources, minimizing the number of resources, really caused this site to load much faster.

So there are a couple suggestions that I can give you for minimizing the number of resources. The first is to use this technique called image spriting. Many of you have probably heard of it before, but for those of you who haven't, this is a technique where you use CSS background images, CSS positioning, and the element size to use really a single image for multiple items on the page.

So let's take a look at an example here. I went to this page, apple.com/iphone/softwareupdate, and there was this menu bar at the top that's divided into eight sections, and the iPhone section is this darker gray because I'm on an iPhone page, so that's like the primary highlight. And then, I moved my mouse over the Store button, and that turned kind of a medium gray color when I moused over. So you may think, "Okay, we have these eight images here. "And then, you know, six of those, "maybe we have to duplicate for the medium gray "and the primary dark gray highlight color." So that's adding up pretty quickly. We're about at 20 images by now.

But really, if we take a look at the resources for this page-- I looked at it in the Web Inspector-- I noticed that this was really one image on this page that was accounting for all of these menu items, both the very lightest gray color, the dark gray highlight color, and there were actually two highlight colors in between. One of them I didn't run across. But we're using one image for all of these menu items on the page, just positioning it in different ways using CSS. So we've gone down from 26 resources here, maybe more, down to one. So that's how image sprites work.

The next thing you can do is really combine and compress your resource files, like JavaScript and CSS. So it's really not practical during your development to work with, like, one large JavaScript file. I don't know anyone who would do that. Or one large CSS file. But you can kind of make a script that concatenates those files and then, you know, modifies the files that link to them on the fly when you're ready to kind of deploy your site.

There are also some compressors out there that do a great job of, you know, not only compressing your files and making them smaller, but some of them also will do that concatenation for you. So... Another thing that you can do to optimize for cellular network page load time is to improve your loading parallelism.

I mentioned earlier, latency on cell networks is 500 milliseconds, and if you're waiting on one resource to load before you start loading another one, before you start loading another one, those little hunks of 500 milliseconds are going to add up quickly. So you're better off making sure that you have as many resources floating at one time as possible.

So one way to kind of examine the behavior of your page load is in this view in Safari and WebKit Nightly builds. In the Web Inspector, if I click on the Resources tab, I'm taken to this Network Timeline view. And not only does it show me how much the amount of space I'm using for things like documents, stylesheets, images, scripts, et cetera, I can also sort by start time here by using this little menu at the bottom, and that's showing me the order in which all of my resources are loading, which ones are loading at the same time, et cetera.

So very valuable. One thing to mention here is that the bars that you see-- the light part of the bar is-- the beginning is you have requested the resource, and the end of that light bar is the resource has actually started loading. So the dark area of the bar is actual resource load time, and the light part is the request for the resource to the start of load, that amount of time. So as I mentioned, this tool is available in Safari, and it's also part of WebKit, so you can get the latest version of this tool by downloading a Knightly WebKit build at knightly.webkit.org.

So you may be thinking, "Well, that tool looks great, "but, you know, it's only available on the desktop, "and I care about cellular networks." Well, luckily, there's a way that you can simulate network latency on the desktop. And it's just a command line tool, IPFW, make yourself the pseudo user in terminal, IPFW, add pipe 1, the source port is HTTP, configure the delay in the second command there. And that's gonna give you a pretty good approximation of cellular network latency on a desktop machine. So you can use that for testing when you're ready to go back to your super-fast Wi-Fi connection.

Just execute this command, ipfw flush, to clear those settings. So we have optimized our KEXP site and we have gone from this layout that you see here to one that looks like this one on the right. So some of the changes are subtle, but now this site doesn't have broken plug-in icons. It's using all the available screen real estate. I can see the primary text that's telling me the main info about the page.

And it looks great. So just to kind of recap the things that we did, we defined a viewport to maximize the screen real estate. We customized for the touch interface. We optimized performance, primarily by minimizing the number of resources. And one more thing I just want to mention again, even though it falls more under compatibility than optimization, we provided fallback content for plug-ins. Plug-ins are not supported in Safari on iPhone. Okay, so that covers optimization, and now we're going to move on to full-fledged web applications in Safari on iPhone.

So iPhone web applications are different from, you know, just websites in that they have a few key characteristics. The first is that they often look like a native application. Lots of times, you'll see web apps kind of emulating that sliding browser view or the flip transition that you see in native apps. So they often look native, or at least have UI that is customized for iPhone.

Secondly, the best ones feel built-in. You know, when you touch on a menu item, you don't see the whole page reload, and it's a cue to the user that you're definitely in a web browser. The best iPhone web applications feel built-in. They've built-in, like, a sliding transition or something else to avoid that page reload kind of effect.

Links don't feel like links, they feel like menu items. And lastly, they often provide discrete functionality. So, you know, you may have a huge website, but it's up to you to decide, you know, what the most important things are for users on the go. You know, the typical way that people use iPhones, with the exception of games, of course, is, you know, they pull them out, do a couple things, they want the key information right there at their fingertips. It's true of native apps, and it's also true of web applications.

Okay, so one example of a web app on iPhone is Fandango. They actually have two versions available to their users. They have their full-blown website here, which looks good, and I'm able to interact with it. You know, I double-- I tap in on that text field near the top, and I can enter my zip code, and see some movies, and it's great.

But they also have an iPhone web application, and that looks like this. So this web app, it looks pretty good right now. You know, it has this set of menu items that we're used to seeing in lots of iPhone applications, but when I touch on one of these items in the list, the experience kind of starts to degrade a bit. Like, the whole page reloads. It's obvious to me that I'm using, you know, a web application at that point.

So if you're looking to develop an app like this one that kind of emulates the look and feel of some of the built-in apps, there's a great tool that's available to you, and that tool is DashCode. DashCode has a bunch of advantages. We're gonna go through a little demo walk-through here, but first, I wanna just give you a quick overview.

So one of the biggest advantages are these prepackaged interface elements. So you can basically drag and drop these elements onto your UI, and the CSS and HTML is generated for you behind the scenes. So this is extremely valuable. You know, a year ago, we were doing these Tech Talks, and there was no SDK, so we were talking all about web apps. There was also no DashCode for iPhone web apps at that time. This came out along with the SDK earlier this year.

So we were having to describe to people exactly, you know, "Okay, well, if you want a back button "that looks like one of the built-in back buttons, "it has to have this font, "and the font should be this size, and this color, "and the background should be this color, "and here's how you do the gradient, "and here's the JavaScript that you should attach to it." You know, that's really a lot of code to write for your user interface. So with DashCode, all of that is done for you. So it takes a huge step, right out of the box, right out of the process, and lets you kind of focus, you know, on your web app, on the functionality.

So besides just looking great, you know, the functionality is also built in to these prepackaged elements. So here we have a list part. Another very popular one is this browser part. And the functionality here kind of, you know, you touch one of these menu items and detail view slides in, and that functionality is built in. So the point is, you know, these elements look great, but they also function just as you would expect as well.

Another advantage of Dash code is that when you're building a web app in Dash code, you're building an Ajax-based application. So we all probably know what Ajax is, but I will mention it anyway. It allows you to fetch content asynchronously and then modify your page-- the DOM of your page-- dynamically. So you're pulling less data across the wire because you're just pulling little pieces that you need to update on the page.

So your app is going to be more responsive. Also since you're just updating parts of the page, you can avoid those kind of ugly and obvious page reloads that you see in a web browser all the time. You're making a web app, not a website. So you want to kind of avoid those page reloads, and by using Ajax, you can build in some great transitions between views instead of having your whole view wiped out when a user is using touches the menu item.

I think this is the last advantage that I want to mention, and that's that Dashcode also builds applications that follow the model-view-controller paradigm. And that really just means that you have, kind of, three layers to your application. So this is a very common paradigm in native desktop programming. In Dashcode, the view is basically your HTML and CSS. That's kind of your UI.

The model is your JavaScript objects, handles all of your data. And the layer between those two layers, the-- you know, how they talk to each other, the controller, that's really just JavaScript in a web application. So the big advantage here is, you know, I may have a web app, I've put it out, I've released it, everyone loves it.

Six months later, I decide I want to revise the way it looks. You know, same functionality, but I want it to look different. Well, I can just rewrite that view layer, rewrite my HTML and CSS, but reuse the controller and model layers, which saves me, you know, two-thirds of my development time, which is great.

So I'm going to go through a little quick tutorial here to kind of show you around Dash Code. But while I'm doing that, I want to give you an overview of the workflow. So the first thing that people do when they use Dash Code is they use those prepackaged elements to make up their interface.

The next thing they do is they kind of modify that interface via these different inspectors that I'm going to show you. And lastly, people edit code directly. You know, because you're working with a GUI tool to lay out your UI, you're dealing with code generation on the backend. And while that code generation is extremely clean, you know, in some cases, it can overwrite manual changes that you might make to those files. So it's best to really just leave that step till the end. Okay. I'm just going to start by launching Dashcode from the dock here.

And when I do that, I am presented with this panel of templates. And I mentioned earlier that Dash Code was originally created for dashboard widgets, so there's a bunch of templates there for widgets on Mac OS X. But the functionality that was added back when the SDK was released were these templates for iPhone web applications. So this one, custom, it's pretty much just like a blank slate. You can drag whatever UI elements you want onto it. It's just your kind of GUI interface to get started.

These last two, RSS and podcast, all that these strictly require are like a data URL, either for the RSS feed or the podcast. Of course, you can customize the UI as you like, but most of the functionality is already built in for you for these two templates. And then the middle two templates are browser and utility.

So browser is the one that we saw on a slide earlier that has the kind of sliding panels that we're used to seeing on iPhone built-in applications. And utility allows you to create the type of app, like weather or stocks, that has a front side with information and then you flip to the back side and you have your settings. So I'm going to choose utility.

And when I do that, here's what I get in Dashcode. So, this main area here is what's called the canvas, and this is where you kind of build your UI, where the UI is shown. If I go over here in the upper left corner, this is what is called the Navigator.

And this Navigator really reflects the DOM structure of your HTML. So I can click through, And as I select different items in this navigator list, you can see that the corresponding item is selected in my Canvas view, the GUI area here. Here's the backside setting, there's my header, this group, the reset button, etc.

On the bottom left-hand corner is this set of steps that every template comes with. So they're not strictly required, but they're a great way to kind of get started with a template and kind of learn, you know, how to approach things. So that's great. There is also at the bottom here an integrated code view.

If you've ever used, you know, Xcode or other text editors on Mac OS X, you're used to seeing this file switcher. And here we have, you know, all of the code for our project. So here's a look at the CSS. You can see it looks really good, very clean. And that's where you're going to edit code directly.

There is also an Inspector panel, similar to, you know, every inspector that you've ever seen for every application on Mac OS X. And this is what you use to kind of customize the elements in your Canvas view here. So I have, you know, this sticky note selected, and if I wanna change the background color, I can do that right here in the Inspector, and that generates the CSS for me behind the scenes to change that background color. Of course, you can customize other things like the size, position, the font of the text, the color of the text, et cetera. We won't walk through all of them right now, but it's all there for you to explore.

There is also a library, and this is where you find those pre-packaged interface elements that I've mentioned a few times. What's also nice is if-- I probably would not want to add a back button to this application, because it's a utility app that's gonna flip to the other side, but if I did want to add it, these guides would show up to tell me exactly where, you know, the right place is to drop that button. So, I know-- you know, I don't have to guess on how to make this look and feel like a built-in app.

Also in the library view are some code snippets for just commonly used operations that you might need to interact with the prepackaged parts. So get this indicator value, get this gauge value, etc. All of these code snippets are here for you to use. So now, you know, that's a brief overview of the UI and how it works, and now I'm just going to go ahead, and I'm gonna click "Run" to see what happens.

And the iPhone simulator is going to launch, and it's going to load my app. The last time I loaded it, I set the color to green, so I'm going to reset it to black. And click done. And so this is looking a lot like a built-in iPhone application.

I can also click pause here in the main view and you see this message come up, pausing at the next opportunity. So I'll have to do something over here. And now we've paused and this canvas area has been replaced by all of my local variables and down here in the code view the current line of code that's being executed is highlighted.

So this is great not only to debug the functionality of your app, but also to kind of get a closer look at how the default templates are doing what they do, so maybe you wanna build a flip transition into your existing web app. Working with the debugger and the default templates is a great way to get insight into how that functionality works. Okay, so I'm going to click continue. And then another thing I wanted to show you today, oh, I'll have to click run again, sorry.

Uh, is that there's a new feature in iPhone OS, uh, 2.1, actually. Some people haven't quite discovered it yet, so I'm gonna mention it here. Um, I can add this to my home screen. and then, whenever I launch it from the home screen, it's running in what we call full screen mode.

So the Safari UI elements, you know, it's still a web app, but you no longer see the URL field or the Safari buttons at the bottom that are like back and forward, and you know, the bookmarks or whatever. And now, this looks, you know, even more like a built-in application.

So this is a feature that's new in 2.1, and we're going to go over all the specifics of the code later this afternoon, how to achieve this effect. But right now, I just wanted to mention, you know, it's also just a checkbox to enable this feature here in Dashcode.

Under "Application Attributes" on the left-hand column, if we look under "Web Clip," we see a checkbox for full screen mode. So just check that, and then, every time a user launches your web application from the home screen icon, they'll be running in this full screen mode, and your web app is going to, you know, look and feel even more like a built-in app.

The last thing about dashcode that I want to mention is that they are easy to deploy. You know, you can add a web server to deploy to. You can also deploy, you know, directly to your mobile me account. And I've actually deployed just the browser template and this utility template to my mobile me account. And I'll have those URLs up at the end of this session so that you can see, you know, how these templates behave on a real device. You know, we're looking on a laptop right now. So I'll have those up at the end of the session. Okay.

So that's it for Dashcode. I think you can see it's a way to get up and running, you know, with a web app that's really, really quickly, especially if you want it to kind of, you know, emulate the look and feel of some of the built-in apps on iPhone.

So the last thing we're going to talk about today is web content in native applications. So I mentioned this in the beginning. If you have an app, a web app, and you decide that you want to have or utilize a feature that's SDK only right now. So some of those include location-based services, accelerometer data, accessing built-in contacts. Those are all features that you can only utilize from the SDK right now. So you would have to build a native application. But it's easy to kind of leverage your existing web code in the interface for that application by using this view called UI WebView.

So all of the technologies that you would expect to be supported in a web view are, of course, supported-- so HTML, CSS, and JavaScript. These other document types that you can view from within Safari on iPhone, like PDF, Iwork, and Office documents, and also SVG and Style Text, just to name a few of the supported technologies.

Also worth mentioning-- you can load-- of course, load content from an HTTP URL over the wire, but you can also load content locally from your application bundle. So maybe, you know, you have an index.html file, it's not gonna change for a while, or maybe some CSS. You don't have to load that over the wire. You can put it in your application bundle and load it, you know, on the fly when your application launches.

One thing I want to mention here, you know, iPhone SDK has been out for six months now or so, and we have a full-fledged SDK on the desktop, WebKit SDK, that is, you know, has a wealth of functionality. You could use it to make a full-fledged web browser, if you like. This is not exactly equivalent to UI WebView on iPhone. You know, UI WebView, for now, is primarily... its primary purpose is to display web content.

So these two are not designed to be equal right now, but that said, there's a lot that you can do with UI WebView, especially in terms of kind of bridging your web code to the native code of your application. So there's two directions on that bridge. The first is executing JavaScript from native code, and the second is the other direction, calling native code from JavaScript. And we're going to go over how to do both of these things.

So starting off, executing JavaScript from native code. This part is really straightforward. You create a string-- this is in your native code. You make a string of JavaScript. Here, I've made one with using a string with string. And I've created a string of JavaScript that is "window.alert wow." Next, I'm going to just pass this to the method "string by evaluating JavaScript from string," and that will execute my JavaScript.

One thing to mention, you should wait until the content of your UI WebView has fully loaded. So there's a callback available that you can listen for, and when you get that callback, WebView did finish load, you'll know that, you know, content has fully loaded, and it's now safe to execute JavaScript.

Another direction on that bridge between your web code and the native code is executing native code from JavaScript. So, there are kind of three pieces of the puzzle here that you need to be aware of to make this work. The first is-- the first piece that you need to know about is that you can define a custom URL scheme for your application. So URL schemes that we're all used to seeing are things like HTTP, Tel Links, FTP. Those are all URL schemes that we're used to seeing. But you can create your own URL scheme for your application. So here, I've created my URL scheme. It's my app.

The second piece of the puzzle is to know that every time a load is initiated, there's a callback, and that is "Should start load with request." Okay? And in that callback, you can look at the scheme of the URL for my application. Is it equal to my app? Okay, so that's the second piece of the puzzle.

The last piece is your HTML. So we mentioned that "shouldStartLoadWithRequest," that's a callback that fires every time a load is initiated. Well, you can initiate a load by setting "window.location" to a URL that is equal to the URL scheme for your application. So what's going to happen here is a user clicks on whatever element has this onclick attached to it.

So they click on this element. A load request is initiated, so this callback fires. And then, in that method, you look to see if the URL scheme is equal to the scheme for your application. If it is, maybe you want to do something interesting, take a picture, get the location, whatever, and then return "no" so that the load is abandoned. And if it's not your URL scheme, you just return "yes," and if it's an HTTP request or whatever, that request goes through, the content loads, and everything is great. So this is, you know, kind of the three pieces of the puzzle, executing native code from JavaScript.

Okay, so that really covers all that I wanted to talk about today. We talked a little bit about how Safari on iPhone has changed the way people browse the web on mobile devices. We went over how Safari on iPhone does what it does, and how you can utilize that in your web content.

We talked about optimizing for Safari on iPhone, how to-- you know, if you have an existing site, and you wanna make just a couple tweaks, and, you know, have those-- have that degrade gracefully in desktop browsers, we went over some tips that you could follow. We took a look at creating web apps in Dash code, how to get up and running quickly with a web app that looks and feels like a built-in application.

And the last piece that we covered was integrating web content into native applications. So if you wanna integrate with a feature that's SDK-only right now, you'd have to make a native app, and we talked about how to do that and how to bridge your web code with your native code.

So coming up this afternoon, we're going to go in-depth on some of the latest and greatest web technologies available. So we're going to talk about CSS transforms and animations. This is a way to add hardware accelerated animations to your web applications-- very exciting. We're also going to talk about what we call DOM touch and gesture events. This is like multi-touch through JavaScript.

So in native apps, you can define your own gesture, detector rotation, et cetera. You can also do that through JavaScript now. We're gonna go over that. We're going to talk, lastly, about local data storage. So storing structured data in SQLite databases and also creating a version of your web application that fully functions offline. We're gonna cover both of those topics in terms of local data storage.

So here's my name and contact info, [email protected]. And then, I have a couple titles of documents that I think would be useful for you guys. And they're all linked from developer.apple.com/webapps. So the URLs here are really long. The best thing to do is just go to developer.apple.com/webapps and look for these titles.

So we have the iPhone Web Content Guide, and also the Dash Code User Guide, which provides a tutorial of creating an iPhone web application. It goes more in-depth than what we had time for here today. And also, the iPhone Developer site, which has all your information about native apps, including that class I mentioned, UI WebView, that's at developer.apple.com/iphone.