WWDC2003 Session 403

Transcript

Kind: captions Language: en well welcome hope you had a good lunch this session is really critical for anybody who's going to be who is thinking of embedding Safari technology within your own application or leveraging any aspect of Safari technology whether using Apple help or these other things just understanding what's going on with the Safari technologies and to talk you through this stuff I want to introduce Don Melton manager of internet technologies at Apple Don thanks John hi there wasn't that a marvelous lunch mmm still feeling that ok like John said this is the Safari overview and I'm Don Melton Lee internet technologies manager and what we're gonna do today if I can get that clicker to work is we're gonna get a high-level overview of Safari technology and we're gonna have a roadmap which hopefully John will remember to read at the end of the session on other useful sessions here at the conference concerning Safari I think this is going to be especially useful to those of you developing applications internet tools web content Apple help content and open source it's also going to probably be fun for those of you who might have ever used a web browser how many of you have ever used a web browser okay it's a my kind of crowd then all right ok here's what we'll cover today like John said Safari technology you can use in your software we're gonna see some demos and I'm gonna talk a little bit about the api's but remember this is high level we're not gonna see that much code and because I'm the manager of Internet technologies I'm going to remind you about other internet technologies that we have available at Apple besides just the cool Safari stuff so let's get started talking about Safari everybody's favorite web browser so Apple released the first public beta of Safari on January 7th at Macworld San Francisco here at Moscone I knew it was gonna be I knew it was gonna be popular because people were trying to download it from the show floor people were going crazy over this thing and I think within four days we set some kind of record for downloads at Apple it was it was pretty big and then a few months later we released public beta to with even more features and the download rush started all over again and now this week as you know we've released 1.0 this is the GM this is the real thing this it's not a dot next to it and the folks at the home office in Cupertino tell me the servers are pretty busy so why is safari such a phenomenal success I mean because people are not just downloading it they're actually using it and some people are already even in beta one making it that their default web browser I can think of three reasons innovative features solid quality and impressive performance ok let's talk about the features Safari is a full-featured web browser it's grown up even for a 1.0 release this is just a partial list of some of the features with things like snapback integrated google search and what I think is the best bookmarks organizer a native web browser it's very very compelling to users plus for all us geeks we've got tabbed browsing who liked that when we added that in beta - ok and now bookmarks synchronization with icing very very popular the other reason is solid quality Safari just works right it works the way you expect it to it renders web pages the way they were meant to be rendered it renders them the way the web designer intended them to be rendered especially if that web designer used current web standards but hey Safari works even if they didn't the other reason is stability I don't know how many times after the first beta came out I heard this is just a beta you should just stick the 1.0 on that ship that thing Thanks we really appreciate that we're glad the crashes were few and far between we'd like to say now that was intentional we like to think we engineered that quality so quality is a big draw and I think this is the other reason a lot of people are already making it their default web browser even back in the beta but the most important reason I think for Safari success is the impressive performance I mean it's it's just the fastest browser on Mac OS 10 not only does it beat the competition in the standard book benchmarks but just in everyday usage loading web pages launch time scrolling and resizing windows did you notice that one point I was actually even faster on launch time than the previous betas worked on that one it also has a small memory footprint for those memory challenged configurations out there so the question that I hear most often even around the office is how do we make Safari so fast and it's actually fairly straightforward for one thing broken clicker we made performance the priority the number-one priority we made it a feature we made it so that engineers and managers would have their own job performance measured on safaris performance I mean we we made sure that everybody realized this is job one you have to take it seriously the other thing is we started with great technology not only Mac OS 10 as a platform but also our great open source engine that I'll be talking more about later my engineers my Safari engineering team would like me to mention that we also started with great engineers so I didn't have that on this slide ok now what I think is really important here is we took regular measurements of the software we measured it weekly daily hourly sometimes more often than that and we measured it across different axes we've measured page load times and launch times and memory footprint and the number of malloc nodes that we had and week we created massive charts and tables and we crack this whole thing and we use the tools that come right on your developers CD you know real simple ones like top and more sophisticated ones like FS usage and sample and more importantly we built our own tools and we built them right into Safari right inside because if you're not looking at performance from the inside you're missing a lot of the picture about what's going on in your app so we took regular measurements and then with all that data we remove the sloth okay we remove those cases of where we were doing work to three times to often get it down to just you know maybe just do that once that's all you need to do and even in some cases maybe not even do that at all and then and only then did we fall into the classical optimizing just get rid of the easy stuff off the top and you'd be surprised at how fast your app can get with that kind of approach but I think most importantly we never made it any slower people always ask me you know how did you make Safari fast we didn't make it slow well the truth is we never made it slower we never regressed if we had some huge feature that was going to land and we tested it and tried it out and if that was gonna slow down the app we didn't land that feature there was a big one that was going to go in last year that would have slowed down Safari by 7% I told the engineer sorry can't land that you got to give me that 7% back and he worked and worked it went a week and a half he got me eight percent back so I let him land it you have to do that you have to have that policy no regressions zero tolerance that's why Safari is faster on every release I really like well I have this bully pulpit where you're all out there you listening to me after that wonderful lunch please please some take some of these techniques back so we can have fast applications on this platform okay so so Don Safari is swell for users it has all these great features the solid quality this impressive performance but what's what's in it for us developers out there your Sam well as you've probably heard we're opening up Safari we're opening up the hood and we're letting you at the engine this week okay because Safari it's not just a browser anymore we're taking the frameworks that we're inside Safari and we're moving them into public locations in the system and we're giving them public api's that you can all call we're also providing you the developer a software development kit so you can use those frameworks and those api's what are these frameworks they're two of them the first probably heard about it already talked about in the conference is the web kit this is the Safari content window it's the big HTML widget it's the framework that provides the embeddable browser views how you can put Safari inside your app but there's another framework our old friend foundation we've upgraded and enhanced it with brand-new URL api's for loading and other things okay so one of these frameworks available they're available now yesterday as a matter of fact okay they're built into Panther and more importantly they're in Jaguar as soon as you install Safari 1.0 if you got Safari one dot oh you know you go in there and it get info in the finder and notice how it's skinnier now hey that's because the engine is out in the system WebKit is over in the system library frameworks alongside a new foundation that gets installed ok so who's using WebKit well in Panther that's going to be male so you can have beautiful HTML mail rendered Sherlock right and to help viewer and I told you this is gonna be nice for people doing Apple help content you've got the power of safari inside of help in Panther but also Xcode will be using it project builder actually I believe does use it on the CD and hopefully your application will be using it one of these days okay so who's using these new foundation URL API is underneath well in Panther software update that's how we download stuff for software updating you know and Java uses it for cookies among other things and hopefully your app can use it too so when is the SDK available it's available now right now yesterday as a matter of fact it went up I believe it was probably a half an hour after Safari went online and if you have one of them free ADC memberships you can just go right over to the developer site and download the SDK install that it's got documentation the whole nine yards total coverage okay so where can you use the SDK where can you use these technologies well you can use them in both cocoa and yes in carbon applications now it's an objective-c API but the WebKit has a convenient C API for initializing the WebKit and creating views and plus the SDK has plenty of examples C and C++ adapter code included that you can just lift and take out using your application we made sure the license was liftable and reusable so I'd like to do now is I'd like to have Richard Williamson Safari engineer extraordinaire is that how you introduced him yesterday Scott yeah thank you come and do a demo of the web kit for us I don't show that info so the first time I'm going to show you is actually a recap of the demo yesterday and so some of you may have seen it already I want to put out one thing the the controller that we use isn't on the seed of the Penta CD so keep that in mind the first demo we're going to build a codeless browser that's what it's come to be called so I'm gonna watch interface builder and start a new application and you'll notice that interface builder has a new palette the WebKit palette I'm going to place an instance of that class the webview into my window and now I'm going to connect a URL to this webview using target action and two buttons quickly go back and forward get these buns a label and connect them again using target action let me set the resize flags on these buttons and then we will test the application without compiling any code without writing any code it really is this easy-to-use web kit so what like what I'd like to show you now is a demonstration of the binder technology which I showed you yesterday but it's worth a second shot so the first thing I'm going to do is disconnect the normal target action mechanism that we use to connect the text field to the webview and instead I'm going to use a controller a web view controller to bind the webview in the text field together to the same underlying property the main flame URL so when the URL changes in the webview it will be reflected in the text field and to do that I'll use the new bindings inspector after selecting the webview can the text field and I'll bind the value of the text field to the main frame URL now I'd also like to enable and disable the back forward buttons as I navigate and as it's appropriate to enable and disable these buttons so I'm gonna bind or associate the enabled property of the back button to whether or not the webview can go back and similarly can go forward now finally what I'd like to do is add a Clovis indicator so I can see when the page loads and when it finishes so let's add a Clovis indicator this size this text field so it fits and we'll make the focus indicator determinate from 0 to 1 and bind it to the estimated progress of the page load set the resize flags that's it again no code the code list browser let's go ahead and run this now you'll notice the back and forward buttons are disabled the focus indicator showed the page load and as I navigate the URL of the text field changes so that's the quick snapshot of how to use WebKit from Koko but I've already had questions about how do we do this from carbon so what I'm gonna do now is show you a couple of applications that already build these applications with their source code in their entirety or available in the SDK as examples so the first example is an application called carbon web and this is a browser written using the Carbon api's just to show you that it is no different than the cocoa version let me load a web page there you see and it's relatively full-featured it has a history it has back and forward buttons and final demo I'd like to show you is another carbon application this uses a combination of WebKit and new foundation api's to download URLs onto your desktop let me go ahead and load a page as simple as that so this sample is also an SDK all the source codes available to you thanks Don thank you Richard well you'd think it was that easy to do a web browser we could have got Safari done sooner huh yes those guys have been sandbagging me all right rich will be back he's here all week and yeah he has a session which is a lot more in-depth on Friday morning at 9 o'clock right okay let's give you an overview of the WebKit right now first off I want you to look at this incredibly simple architectural diagram okay but really the WebKit is that simple I mean Safari sits on top of the WebKit and he uses the WebKit to display web content the WebKit sits on top of the foundation URL API and it uses that API to load web content and it's really not that much more complex and Safari itself is in a way just a wrapper for the WebKit but let's focus on the WebKit for now and let's take a look at what's inside it two special frameworks webcore and javascriptcore our two open-source components our engine I'd like to talk a little bit about those at the core of WebKit what we're doing is we're using open source from the KDE project now the KDE project is a desktop environment available on Linux and other unix-like says and the KDE top has various applications and utilities and libraries in it and one of those applications is the conquerer web browser and the conquerer web browser uses two libraries in KDE called HTML and KJ s and we're using those same libraries web core is basically an adapter built on top of K HTML HTML is the HTML rendering portion and web core not only contains about you know 98% of the KHTML source but it also contains adapter glue code basically to connect it to the app kit and OS services and everything else underneath the other framework is JavaScript core JavaScript core is just basically a thin wrapper around KJ s and JavaScript Corp is a JavaScript interpreter it's the part that gives dynamic content to webpages now we also have some other open-source components in webcore and javascriptcore including the XX pad XML parser the pcre regular expression library and believe it or not we've even got some Mozilla code in there that always surprises people when I tell them that it's not much but we do add Mozilla code in there so why did we choose to do the engine open source well it's all about the technology I mean this open source is a great development model you get lots of people working for you essentially for free you get lots of contributions from the outside and you you get synergy going with a whole community but for us the decision to use HTML and kgs was a technology decision they're that good and I'd like right now just a tip my hat to the KHTML and kgs developers in the KDE project and thank them for their wonderful work and you really appreciate it at Apple because let me let me drill down this a little deeper it's small KHTML and KJ s combined are only about a hundred and forty thousand lines of code that's less than an order of magnitude smaller than some other web browser engines out there that's that's a lot less code and it's fast not only is it fast because less source code makes less object code and if you actually get less object code well you go faster but it's just designed to be fast from the get-go it's a really good design well one of the things I really love about it is it's easy to modify this is a fun code base to hack it's just very straightforward easy to understand C++ code you'd love it so what are we doing with the community the open source community with K HTML and kgs well we're working with the KDE team we've already had one transatlantic telephone conference call with them we're on mailing lists together and Harry Porton who's the lead for kg/s has actually been out to the Cupertino campus and visited us we know these people we know them pretty well they're very nice folks we're also giving back our bug fixes enhancements to the community apple is giving that back if you notice yesterday one of the other downloads you could get is you get the latest version of webcore and javascriptcore because hey it's open-source give that back and we've actually been sending patches along the way back to the KDE team and we're also taking contributions from them just just a 3-4 weeks prior to us releasing 1.0 we actually took a patch for a very small feature in KHTML itself from the KDE trunk we're also sharing ideas and plans for the future with the KDE developers like I said about our previous summit we're going to have another one now that the Safari team has survived Safari one point once we survive WWDC we're planning on getting together again and figuring out what we do next how to split up some work and really take the engine toward the future but you can contribute to to this engine either to our webcore and javascriptcore projects or to Kage to ml and kgs we would love to see your bug fixes and enhancements too so which frameworks should you use though I mean because I've been talking up webcore and javascriptcore here how they're great don't call them directly their internal frameworks they're api's are guaranteed to change in fact David Hyatt must have changed in this afternoon knowing him don't use webcore and javascriptcore use the WebKit the WebKit is the public API for webcore and javascriptcore technology okay so what does WebKit provide let's get back to it as a whole okay basically the WebKit provides core classes to display web content and carbon and cocoa windows it can display by default mime types like HTML text and images but also things like plugins and Java applets it simplifies the complicated loading process it can request content from a server and download that in the background and manage the delivery to your application plus it not only deals with the internet it can deal with local files as well it also has a default behavior just like a web browser yep if user clicks on a link with the default view you saw in Richards demo it just loads another page WebKit will create manage all the views destroying what it needs to cleaning things up behind your back it's got you covered so why use it well many applications need to display HTML content not just web browsers certainly web content editors for preview but even word processors and spreadsheets and apps that I can't even think about yet but more importantly why right code to do this yourself I mean it's a lot of code but we built it in the system we've made sure that it's optimized it's fast it's got a low footprint it's not going to add to your startup time to call it it's right there at your fingertips as developers okay another reason to use WebKit is the fine standard support we are fully buzzword compliant we got your HTML for your XHTML your XML your CSS one two and even some a css3 Dom level zero Dom level one Dom level two I mean even if you don't know what all those means it it does sound impressive I hope we support HTTP cookies javascript net netscape style carbon-based plugins java applets secure connections over ssl and for your text geeks out there we do unicode and bi-directional layout support so we're fully that's a lot of rfcs and w3c specifications they just named off their but more importantly we're we're real world compliant because the WebKit knows how to layout the world weird web okay because you know I don't know if you go to some of those dark corners of the Internet where you know it's just about one two grades above line noise out there the WebKit can handle it it can handle that malformed content as well but because there's so much of that stuff out there we're working with the w3c on new standards we want to make it better for web content developers out there we have team members on w3c committees we're committed to this for the future okay I want to cover some basic WebKit concepts four concepts views frames loading data and delegates okay first off infuse how do you embed web content in your application well you create a web view object you attach it to a window and then you send its main frame a load request message it's that simple webview inherits from in s view just like other coco views and if you're using it from carbon it acts like an H I've you it provides a no code interface you saw that in the interface builder demo and it has plenty of hooks for customization which we'll discuss shortly frames a web frame encapsulate the data displayed and a web view okay every webview has at least one web frame and load requests are sent to this main frame as I mentioned earlier web freight web frame objects are created by the webview it manages them all for you and web frames can be nested in a hierarchy you know sort of like frame sets on the world wide web and web view manages that and the route frame is called the main frame that's where you send your load messages to loading data loading data into frames is handled by two foundation classes new foundation classes and as URL request in nsurlresponse-- a request is just the URL to load and any options on that load options like whether it should use the cache whether it should reload what the user agent string is things like that and a response is everything from the server except the content this is the metadata like the HTTP headers you know times and other tricky little information there delegates now this is where I think the real cool part of web kits is delegates are how you customize the embedded view think of delegates like callbacks if you're a C programmer basically excuse me you create a delegate object that follows an informal protocol or an interface and you pass and you attach that object to the web view to handle things for you there are four delegates for web views the first one the web frame load delegate the chat attracts changes to what page you're on for example when a page starts loading it stops loading it fails to load and it tracks the transitions between pages the next delegate is the resource load delegate and this tracks the loading of sub resources on the page for example images you could create one of these delegates if you wanted to block images or you wanted to load a completely different image than the one the page specified you might implement both of these delegates if you wanted to do progress feedback and if you look at the source code to one of the examples we have on the disk that's actually what's done for progress feedback the third delegate is the policy delegate this handles navigation actions like clicks and form submissions and back and forward and you can basically with the policy delegate either handle a let WebKit handle the content internally or maybe you want to intercept that click and say I don't want to download you at all I'm not going to allow the user to click on that link or maybe instead of loading it within your app you want to download it to the desktop you could say download that instead of displaying it then there's the web UI delegate that manages all window and user interface activity it controls the opening of windows and you can actually use it to control context menus as well like add items to context menus and any application that's going to handle web views and multiple windows is probably going to want to create a web UI delegate and I'd like to call Richard Williamson back up to the stage to show you a demo of that very thing okay so you see the codeless browser now we're gonna make some code you three to get through this presentation without seeing any code we have some code we're gonna write right now and what I'm gonna do is show you in Xcode one of the sample applications that is on the SDK and we'll modify it so we first run it to show you some of the features now you'll notice that this mini browser has a few additional features than the the codeless browser up in the title bar i'm showing the number of resources that were loaded 43 or 43 that was done using the resource load delegate you also notice that in this case as I navigate the uol does update in the text field I didn't use the controller technology I didn't bind the URL to this field I used the delegate to set that with code as glue code to do that and that glue code is visible in the SDK now the let me go to the new york times site and show you some of the built-in context menus that the WebKit has in this case open link in new window download to disk and copy link to clipboard now by default the WebKit will show this context menu but there's no implementation behind it it's your responsibility is a client of WebKit to open a new window with your chrome and your instance of webview and in fact it might not even be a window you could change the title of this context menu and you may open a link in a tab for example but in this case let's go ahead and try and open the link nothing happens that's because the UI delegate isn't set up to handle a new window let me go back to Xcode and if I can get a handle on Xcode let me bring up the editor and open up the source for the document now this document is using the NS document infrastructure and you can see that I'm setting up two delegates the same load delegate and the resource load delegate these are the two delegates that handle showing that progress in the title and changing the URL what I'd like to do is add a UI delegate so I'm going to cut and paste this code that happens to be down here just below and add myself as a UI delegate now the API for these delegates is really rich but I want to emphasize by default you don't have to implement anything it's default behaviors for all of the delegate mechanisms so I'm just going to override one method this is the method that we use to create a new view so WebKit will send this in response to requests either from the context menu or perhaps from JavaScript to open a new window and what I do here simply is to use the NS document infrastructure to create a new document using the standard document controller that will open a new untitled document which in turn will load a nib file that nib file contains the webview that you can see I retrieved from the document down below and then simply I load the request into the mainframe of that webview that's all it takes let's go ahead and compile this yes I'd like to save and once it's compiled in link let's run it so let's try different site how about wired okay now if I bring up a context menu over a link and open the link in a new window I get in your window simple as that that's it so there's a lot more detail that will show you on the session on Friday but this gives you a sense of how to use delegates and the WebKit next time thank you Richard oops okay click on the demo button okay I'd like to give you a little overview of the foundation API and let's go back to one of those simple architecture diagrams once again Safari and WebKit at the top foundation in the middle and I just want to focus on the fact that foundation the URL API sits on top of CF network that's where it gets its implementation and that sits on top of BSD sockets okay let's focus on that API very very simple stack standard stuff okay so what does foundation now provide whatever you added URL loading one thing we've already talked about that a little bit but also content caching so you can get fast access to web pages and other internet data cookies so you can do all the sorts of e-commerce and complicated web application work authentication so you can get into the sites securely and custom protocols you can add your custom protocols now so why use this API well the features I just mentioned before the convenience because it does a lot of work for you flexibility much like the WebKit it's very very flexible and the performance even better than before so let's talk about the convenience first just like the WebKit the foundation URL API has smart default behaviors just does the right thing for you by default it has automatic handling of cache and cookies if you're going to write a little command-line tool to download URLs guess what you got the power and behaviors of an entire web browser behind you if you want it our cache works per application and you can decide where that's stored on the system if you don't decide a nice default spot is picked for you and cookies are per user but their shared I'm sorry they're there per user but they're shared across applications and it also has nearly automatic handling of authentication if you want to get basic and digest auth things like that all you have to do is just implement two callbacks basically two delegates for flexibility it has methods and delegates to control just about everything request options that I mentioned before things for reload and offline modes you can get very clever there you can get direct access to the cache if you want and if you want to get funky with a cookie manager you can make multiple cookie policies just like Safari has you know always accept always reject you can do an ask policy if you want plus we allow you to add custom protocols we provide the standard HTTP HTTP FTP file and the all-important about protocol but you can add your own using the same API that we've used but the performance if you thought it was fast before in Jaguar it's even faster now fast URL loading is essential to fast web browsing and we're going to keep making that better so let me cover some other internet technologies since we've got through the web kit in the foundation URL API is that I want you to know about and before I move on to this I just want to mention one of the session tomorrow when I was talking about web standards I've forgot to mention there'll be a session 10:30 tomorrow morning Safari and technology and web standards I have no idea what room it's in but John Glenn's Eno's okay so the first technology I want to talk about CF networking see if network we like to call it all the networking knobs and buttons it has a nice corefoundation style capi don't forget about that that's what's underneath the foundation API that's what foundation is implemented on top of it has protocol abstractions for sockets for HTTP even for rendezvous and in Panther we're adding DNS host resolution and support for the FTP protocol also we have a web services API this is how you do XML RPC and soap on Mac os10 and in Panther we're adding a server-side API also Sherlock the easy way to deliver platform compelling web services I like to call it web services for the rest of it rest of us excuse me what's new in Panther we've added a channel browser like Safari bookmarks it's a whole organizer not only does it contain the standard Apple channels but it can contain your third-party channels we've created also a new easy channel submission mechanism and we think this will give you a high visibility for your web service in Sherlock we've also improved performance dramatically faster launch and channel switching it's very peppy and we have a new standards compliant xquery engine it's two to three times faster than the one in Jaguar ok let me cover just very quickly some other technologies that maybe you shouldn't use anymore these are no longer under active development HTML rendering lib no use the WebKit that's why we put out the whole Safari SDK nsurl handled well it still works and has been re-implemented on top of the new foundation api's it's not where the future is URL access manager please say no please use CF network for some of the low-level operations and the new foundation URL API is for everything else also internet config you don't really need to use it anymore launch services can can set up those helper applications and system config can be used for just about everything else ok in summary just to make sure everybody got it or they came in late don't forget the WebKit can put a browser view in your application and foundation now has upgraded URL api's at your disposal so please create some great applications using these technologies for Mac OS 10 things nobody has ever seen before that's what will really thrilled the Safari and the Internet technologies teams thank you very much and like to bring John Valenti back for the wrap-up John it's dawn 3 why don't we call the Q&A panel up well we're getting roadmap there ok but while we're going through the Q&A folks all right so for the for the benefit of those who would be watching this session on DVD someday there was a session this morning open source at Apple there's a pile of other sessions that are coming up later this week or later today related to internet technologies at Apple so Safari technologies and advance foundation URL advanced WebKit api's later on this week delivering web services using web using Sherlock channels and then overview of networking API so it's really important in the age of Panther to make the right networking API choices as well as a variety of other API choices there are the right API is to choose in the wrong API is to choose nowadays so a lot of these sessions are going to be great for giving you that kind of guidance and finally if there's any feedback you have on the API is related to you know foundation URLs or WebKit or anything you've heard in this session that you want more information about or you know working with Apple in the Safari technology side of the house feel free to send me an email and we'll I'll get you plugged into the right people you