So this session is going to be Designing and Developing Hybrid-Web/Cocoa Applications and it's being brought to us by the Barbarian Group who flew out from New York and Los Angeles to give us this fine presentation. At this time I would like to bring up Keith Butters, one of the partners of the Barbarian Group.

Is this working? Hey everybody. George stole my show of hands so I don't have that little bit of the intro to this. Hybrid-Web/Cocoa Applications, when George called us I had no idea what this means and part of that is because I am primarily a graphic designer and I brought Toby and Chandler with me so they can get into all the technical stuff.

Toby is our CTO and Chandler is a Senior Developer with us, but what do we mean by Hybrid-Web/Cocoa Applications? Basically we are talking about using WebKit which is really awesome in every demo I've seen so far this week and I am sure you guys to have be dazzled by it.

And what we really don't mean though is just tossing a browser into your app for the sake of throwing a browser into your app because a lot of apps that I have been seeing lately come out, I mean there is no point in having a browser, I'd rather click a link and just go to my browser. I have a browser, I like my browser, it's setup the way I want it to be so, I like it that way.

So basically we are talking about making your application more awesome and part of that has to do with the appearance, a lot of that has to do with making it skinnable and so users can you know add their own skins and such and it's also real easy to consume web services and to use the power of the web in other ways then just browsing.

So why design hybrid apps? Part of it is that we can make much more interesting user interfaces with you know AJAX and all that stuff. I saw the Dojo talk yesterday which was super cool and if you didn't see it you should definitely watch the video when they come out. And their doing all kinds of really interesting stuff that's not just sort of AppKit.

You know, I mean, I'm sorry there doing really interesting stuff but you can put it in your app and it's not just AppKit based you know user interface controls you can be very custom about it. And then another reason to do it is that the human interface guidelines are fairly out of date. I mean most things like CoverFlow aren't even in them right now.

If you look at iTunes, the iTunes Store in particular is very much just a web view sitting in the middle of your application. Then there are apps like Disco and Cha-Ching which are, they use WebKits somewhat but its also just good examples of people doing more interesting graphic design with their application.

And another reason is that you can still use your data when you are off the grid, when you're on an airplane or when you are in a tunnel , Amtrak which we do far too often in our line of work. I know that Dojo 0.9 once again in their session was saying that they sort of solved this for their release that is coming out, but it's still you know its still 0.9 and I don't necessarily know how it works yet and I know it's not coming out for a couple weeks so it will be interesting to test.

But for now to develop a be able to save your data locally and use your app on an airplane is a pretty compelling reason to stick around. And back up your data locally and remotely and plus of course all the fantastic features of WebKit that you get for free.

Now design wise like our shop is primarly a web shop and we have you know people who design really beautiful websites all the time and then we also do some software, this is an iTunes plug-in we've been working on which you need to check out if you haven't yet. It's called Magnetosphere and then we also actually built a hybrid application and I didn't realize that's what it was called when they built it.

But if you may have seen this in Best Buy or some of those other places where Apple has a store within a store and this is basically a one window giant full screen web view and everything else inside it is all just basically a website. I mean you probably wouldn't know it by looking at it and users have no idea that they are looking at web pages but that's indeed what it is. So I'm going to talk a little bit about what these guys are going to teach you, hopefully teach anyway.

How building hybrid apps affect the user interface design process. It's a very different work flow using AppKit and using WebKit to design your application. And in turn effects the development cycle substantially. And then Toby is going to talk about all the technologies that you can leverage now that there's an actual WebKit instance in your application.

And then Chandler is going to go into real detail later on about dealing with bindings and Core Data and how to make that all work with JavaScript etc and then these are a bunch of the technologies that we're talking about over the course of the day Core Data and bindings of course which makes your web view a real sort of it feels like a piece of your AppKit application, XHTML, CSS, SVG for design Canvas for drawing and JavaScript XML and all the plug-ins you sort of just get for free because you got WebKit in your application.

This is sort of a common problem for me as a graphic designer, I'll open up a interface builder, lay out my application and I think it's gorgeous, I'm like okay this is perfect and then immediately I'll open up you know iChat and you know Aperture and whatever else and all of a sudden I'm looking at the screen and thinking like oh wow my UI kind of sucks and it's not that AppKit is bad, there's plenty of great places for AppKit but its just that some many apps now are so much more beautiful then the off the rack AppKit look.

And once again Leopard is quite a bit better, there's some heads up display stuff in there if any of you have checked out the IB the newest IB. But it's still not as beautiful as a lot of things. So I brought this in here for two reason, one because you know working in a Simpsons quote is always a good thing, but it also, thank you, one person liked that. But it also seems, it's the way I think about graphic design and a lot of us are sort of self hating narcissists.

It's true and we work and we work and we work until we reach the point of something that we don't hate instead of something that we fall in love with. So what we've been doing now is developing in parallel where you have an AppKit view this is a Core Data inspector and it presents all the information in a fairly clear way.

It doesn't, it's not nearly as usable as what you like to have but it's a quick way for developers to put everything together and deliver it to a designer such that the designer can build a UI based around what they see and change to look of the application.

So here's the same information laying it out in WebKit with CSS is actually just a Photoshop comp that they later can cut up and style and all that sort of stuff. And so we did this one and I said no that's not too great and we moved on and did this one, it's a little stock application as you can see but I could design a hundred of these things and they can modify the CSS and do all that stuff really, really quickly. And this is another sort of designer pet peeve that I'd like to bring up with everybody. I get this phone call weekly maybe monthly you know fairly often and there usually really, really wrong.

It's so important to have somebody who has a semblance of graphic design knowledge working with you from the beginning so that your app is not you know, we've all downloaded those apps where they've just got, they just said oh I am going to use the brush metal and oh I am going to use this kind of button and all of a sudden it looks just like a big mishmash.

You should start with a designer so that then when you do need your icon you already got one and they can do it and it's not going to cost you an arm and a leg and they are not going to complain about your app the whole time while your doing it.

Now custom view design it's really hard and I have yet to find anyone and I am sure pretty sure there are people here but we live in, we work in sort of a smallish bubble and our experience and the people we are networked with. It's really hard to find somebody who can do great custom views and that shouldn't be a limitation to making your application look beautiful. And it also means that you developers can be working on, you developers can be working on the hard stuff and let a kid from San Francisco who can throw a rock in San Francisco and hit a web designer.

Let them deal with your visuals and of course consult with them and all of that. Their easy to find and they all know most of the technologies that you'll need to make your site beautiful including really nice CSS and CSS 3 which is going to work really nicely with resolution independence and all that.

And it also changes the development cycle quite a bit. As I showed you those two quick comps of this little stock viewer demo, they don't have to recompile, my developers don't have to recompile and I can change everything about the way my application looks using WebKit and I think its really worth noting to that by using CSS and WebKit and all of this for your app design, you can give power to your users and users really like to sort of rally around your product and you know help with it and they want to contribute.

And by it including skins that other people viewed you can probably you know at some point, when your app design is solid enough you can let your user do it and not even worrying about managing a whole team and all that. It will make your application a hell of a lot better and it's only going to enhance the community that lives around your application.

And now I am going to bring up Toby who is going to teach you or try to teach you, ha ha, a bunch of the nuts and bolts about all this stuff and after that Chandler is going to come up and do some demos and show you that app that we were working on and a few other things So thanks.

Thanks Keith. So how many people here are now or have been a career web developer? And how many are Cocoa developers? And both? Okay so my talk is going to be for the people who especially that are both, maybe too much of an overview. But I am going to go thru and introduce some of the tech that you use both on the WebKit side and on the Cocoa side. And talk a little about the overlaps and show kind of how easy it is to get those concepts and start working toward making hybrid apps yourself.

So everything I just said is right there. I am going to give some uses for WebKit that may be kind of standard and will be a little bit different, sort of what Keith's talk on using it for design. One of the most obvious uses for WebKit is to consume resources and a resource is basically anything with a URI.

It can be local or remote using the file protocol or HTTP. If you can access it through your browser, you'll be able to access it with WebKit so that obviously includes things like XHTML pages, all of your objects, images and SVG and swifts. You can invoke web services obviously and then you can consume RESTful resources.

The benefits of consuming resources in your Cocoa app are obvious if you want to build a browser or do what Keith said not to do and just throw a browser into your app. You can publish data online and pull it back down for reading it obviously. And then you can support skinning, Keith talked a bit about that. There's modifying resources too which is useful for things like an app that publishes to your blog or something.

You can also use it in some interesting ways, one of the talks I saw earlier in the week had used it for the CS3 installers for the Adobe Suite which was a really cool use. You can active serials if you want to you know roll your own and then if you are kind of a masochist you can let users submit bug reports directly from your app.

You can update app resources, pull down things, you know like skins from users, you can let users push skins live and you know icons, the app we're going to use later uses some custom icons for different stock symbols and you can pull that sort of thing down as new people are added to the important part of the market anyway.

Using HTTP is good for this, there's kind of a resurgence in looking at the protocol itself lately and using refs the verbs that HTTP provides let you do pretty much everything you'll want to do remotely. So WebKit is one of the few browsers that gives you all the power of HTTP. So the benefits of modifying resources in general are just that it's really easy. So if you can think of a way that you might benefit from that, it's super easy you may as well use it. And then at the protocol level you don't have to rewrite anything.

And then there's sharing data. You can have an app that's just a local stand alone app that you know does terribly important things but then a lot of other apps can benefit form pushing data you know to .mac or just to your own web server or across to other users in case of like an IRC client.

So once the data is in a centralized location and you can access it from all sorts of different clients so Dashboard Widgets we all use to access all kinds of online information and a lot of apps come bundled with widgets so that the widgets are part of the suite. You know suddenly have a suite, other users of your app just of the single client you write can share data with each other.

If you are publishing everything to a server you can obviously have pages that show the data. We could have had a scheduling app if we wanted to, to download you know the attendees schedule and also see it online cause the data centralized and then there are some new mobile devices that benefit from web development these days. You can also purchase data for offline consumption, which you can do without WebKit.

You can go out and pull data and you can use all sorts of protocols, a full network stack but most of the time the data seems to be the buzz anyway and definitely the stuff that we work with the most being primarily a web shop is stuff that's on the web so you can open NetNewsWire and pull down your RSS feeds all 900 of them and then you get on Jet Blue and you can read them. So by, you pull them down with WebKit and then use other tech to store them for now anyway but it's a good use.

And if you add services, even really light weight services to your business model, your app then you get some maybe a little strong armed loyalty there once users are sinking everything through your app and through your server, even if a competitor comes out and writes a client, their still using your service so if you make your app a little richer and kind of move it you know off the desktop a little bit you have the ability to attract more clients cause they can use lots of different client applications to access it.

So I'm going to go through that sort of pedantic overview that I was talking about. For the people that are just web developers and not Cocoa developers I thought I would introduce some of the Cocoa tech that you will be using. I'll do this the inverse for the Cocoa people and then I'll talk about the overlaps a little bit.

So Cocoa uses MVC, all of the better web frameworks do from back in my J2EE days using Struts thru Rails and in Jango now. Everybody is using MVC cause it's a good model, it's been around for a long time. The pattern is a classic and Cocoa has had it and you know since the inception you know since the small talk days. Core Data for web developers is like a local really strong database, it uses SQLite and you get you know all the benefits of having a local data base inside your app basically.

Including not having to worry to much about multiple users messing with the data at the same time. You get familiar resource consumption and the familiarity is both on resources web pages, everything that we consume on a daily basis and you also get the familiarity of the rendering engine. So you can have form controls that you know move a little bit away from the AppKit style and are something that anyone who has used the web will be used to which is good and there quick to build.

AppKit and WebKit together provide for a really flexible presentation later because you can do you can use a lot of the cool stuff that you'd other wise have to script yourself like the NSCollection view which is like my favorite thing right now. And then you can also use WebKit for things as flippant as just making like a gradiant bar with SVG that you just didn't want to do for some reason with a custom drawing you know up to building a browser and throwing that up in there.

With bindings, bindings are really cool for web developers I think as a web developer because you are use to having to kick all you bars up to whatever your presentation layer is and you kick up everything to ERV for instance and Rails and you have to do that yourself I mean is kind of easy but you still have to do that yourself.

With bindings you get sort of two directional sync, you can sync your models with your views and if someone changes something in the views, it reflects it in the model. It's really cool and probably along with core data one of the most attractive parts of Cocoa for web people I think, well with WebKit of course. So the web tech for Cocoa folks, this will be really quick because everyone knows this stuff I think.

XHTML, XML its how everything should be done out there and so you're used to that, CSS you know in the past few years for those who may have done some web dev back in the day and have only been doing Cocoa stuff for a while. Everyone is moving toward web standards and it has moved toward web standards and is doing nice semantic markup and keeping all of the presentation in CSS so you can break out all of that presentational logic and make it available to users you know like Keith was talking about.

And it also fits really well in a sort of multi disciplinary shop like ours, so you are going to have people working in parallel that may or may not care that it's a Cocoa app, they just need to be able to develop something. SVG is getting more and more awesome by the day gives you a great sort of stateful way to draw and it's based on web standards and it doesn't really get any better then that. You script with JavaScript for animation and interactivity so its tech that you already know. You don't require any proprietary apps that you have to buy for everyone.

Canvas is sort of a faster non stateful way to draw in WebKit. I used a lot in Dashboard Widgets and gives you the power to sort of do a lot of complex drawings really fast without taking up a lot of memory. JavaScript is sort of the lingual frank of client side scripting.

And then you get all the plug-ins that you know are available for your web browser. Then there's just resource consumption in general and as I said earlier, I think of a resource as anything that has a URI and that doesn't just include files and images and things but also RESTful services so you can you know you can have actions as resources. And so you get that with WebKit and web tech in general.

So some of the overlaps there are some common concepts between the two NDC, the way that some web frameworks have bindings like abilities, if you are into you know just Cocoa dev or just web development and you're here, you're obviously smart and into a lot of things and so there's not really a high barrier to entry.

You don't necessarily have to become the best web developer in the world or the best Cocoa developer in the world, you can kind of take baby steps towards pulling AppKit pieces into your you know light weight sort of WebKit wrapper apps if you're a web developer or you can start tossing in little things for just UI if you're a Cocoa developer that hasn't really done this type of apps before.

As I said earlier the model layer is overlapped if you use Core Data and you should I think? It users SQLite, it gives you your ORM and it gives you persistence for free, you don't have to think about serializing things and writing them out. You can do that obviously, you can write your own anything in Cocoa but you don't have to, it's awesome. You also get a really great modeling tool that I wish existed for more web frameworks. So it's in a lot of cases especially in the simpler apps, it will be your web tier, I mean your model tier.

You get implicit relationships in a query syntax where you don't have to write SQL. A lot of the same, you know like you go and watch like the Rails web cast and if your sold on that then you will be sold on this as well. Web developers are already use to design you know databases and normalizing databases, you really do get to just take that one to one and take it over into your Core Data experience. There are some weird things you have to learn as times goes on but you can start right away just with some ideas of a few entities and start modeling and kick out an app without writing any code at all.

NSManagedObject could be thought of for the Rails people as ActiveRecord::Base, it's sort of your super class for all of your, for all of your model objects. With controllers you know web controllers are support to be stateless, they, a controller is you know conceptually may be one thing but on a given request it's sort of the action that's invoked. It could even just be Apache, just handling the request in general. You kick variables up often manually sometimes there's somethings to help it out, but you know you still have to do that.

Cocoa gives you statefullness so if you're a web developer you can and you've never built a desktop app you get to sort of keep local state which is great. The different like object controllers like NSArray controller manage all of your collections of objects and give you really great ways to bind them and access them and bind the contents of those arrays straight to your views without having to push anything, it's really great. Bindings you can also link sort of manually just in your custom objects.

In that's, that binding is part of a sort of a controller functionality and you know this state is there. They do work well together, its not really that one is better then the other and you know a lot of people over the years have stepped into try to make HTTP stateful you know faking it basically and you can do that but you can also use that the way it's intended, which is to keep it stateless and you can do that side by side in you Cocoa app. So you can pull things down and keep them around and you know form the next request to go invoke something restfully.

The views, this is pretty obvious on each side, in a AppKit you get all the windows , MS table views and the trees, the collection view which is the new cool grid and then you get WebViews. You also get all your customs stuff but these are the ones that are sort of, if you're transitioning in you'll probably look at right away and use right away.

On the web side you get obviously pages. That's the most popular view probably. You can consume feeds. Those are part of the view layer if you're a web developer. All of your objects, I consider part of the view because there sort of the payload of a response and to that end the same thing with RESTful responses. The response from Apache or Engine X is to me part of the view, its part of the end result.

Some of the cooler hybrid apps that you guys probably use already, MarsEdit you can you know publish, blog post, you can write them ahead of time, publish them later. You can sit on a flight tomorrow morning and write about how your nerves are made of silk instead of steal and how painful it can be to speak.

MarsEdit uses WebKit in a cool way, you can just sort of type in content and it'll make it like sort of cookie cutter you know HTML render for you. Or you can link against your actual style sheet from you site and see how things are going to look ahead of time.

For doing stuff like this you guys as coders, if you're bloggers as well, you know that it takes 50 times to like publish a block of code before it looks right and before you know over flow doesn't kick in and everything. You can preview it all locally and do it when you have nothing else to do like when you are on Amtrak or the plane.

NetNewsWire, we've all been using it probably forever and it obviously transforms RSS and Atom and gives you a view of it that your use to like you have those pages just sort of saved, they don't look the same that they would but you can skin them and make them look however you want. It's just another instance. Colloquy, you know everyone's probably tried to hack around and make nice skins for this and iChat, the new iChat is going to do the same thing. It uses it for the conversation window.

So I am going to summarize this a little bit cause Chandler has a lot to talk about and show you guys. But I mostly wanted to point out that these two disciplines do have a lot in common, those of you who are sort of hybrid developers know that weather or not you are making hybrid apps.

There's a very low barrier to entry on both sides so if you're a web developer and you never touched Cocoa, like crack open Xcode on your flight back and play just, IB especially you'll be able to play with a lot and make this terrible interfaces that Keith was talking about.

You should consider, this is unsolicited business advice consider linking your software somehow to the web, not you know just for the sake of doing it, but there probably is a way that you could benefit from it. Or that your users could benefit from it. Be it to have you know widgets and iPhone pages that can use the same data that your local you know OS X client uses, there's a lot of appeal to a user, to me at least in knowing whatever phone I am buying next month, I'm probably going to be able to use the same data that I mess with all the time. We live in a multiclient world and the web you know if you follow good security practices and everything provides a nice share point for all of that data.

You know single user, multiple clients, multiple users, multiple clients, multiple user, single client. It really doesn't matter. You get to just sort of treat that stuff as part of a bigger picture. And like Keith opened with, WebKit isn't really a substitute for everything. We are guilty of throwing a web view and a window and writing a big flash app you know and making that our app or a demo or you know using for it prototyping.

We wouldn't release that you know, it's just there because we're a web shop that makes it very easy to not burn something on a CD-ROM and require your clients to open a browser and wonder if their IE chrome is six feet tall you know you can use it in weird quick little one off ways. But it does do a lot of stuff and all of it is for free.

And it's all based on standards that are supported and developed by really smart people. The protocols have been around forever so with everyone moving back to the roots of actually figuring out what the HTTP spec was all about. You get to use tech that you know you can rely on. So I am going to bring Chandler McWilliams, one of our senior developers up to give you guys a demo and to talk a little bit about a little lower level about implementing WebKit inside your app.

Hello everyone could we get the demo machine please? So here's the application that Keith showed earlier. This is a running application in leopard. We've got some charting going on here, all, we kind of walk you through the application. You can see a few different views of the data, looks like whatever tower stream was it's not happy today. So what we have going on here is there's actually a number of WebKits used here. This isn't one of the applications that Toby had mentioned where the whole thing is one gigantic web view. There's actually seven, eight, nine web views going on here.

The first one is this bar along the top. So you recognize the familiar search bar here which those of you that know HTML will know that you can use with the imput type search. So this kind of comes for free on WebKit. So this whole top bar is used for searching for new quotes and it uses prototype to make the AJAX request to actually pull the data from a web service.

And then pull it back to the application. That data is then piped up into Core Data and saved to the user's machine so I can unplug this from the web. As Toby's saying I can be on an airplane any where else and the data will still be there and then instead of the other view that Keith had shown, which we started with, which is kind of difficult to see trends in. We decided to bring in this web and now we are using Dojo charting here to draw the graph for us.

So as I said there are a number of web views and the whole app is skinnable just using CSS and HTML. So this top web view actually extends down the whole back of the application and what that gives us is that we can change the whole background color of the app just by changing the CSS.

The other places the web view can be seen is obviously in the graph here. This is a separate view that's connected via bindings to the Core Data store so when you select one of these buckets over here it kind of pumps up to the application controller what the active one is and then that gets sent back down into this graph view so that you can see the data and the particular context. Now this view over here as Toby said, were somewhat enamored of the NS collection view because you get all theses cool sorting animations for free.

So this is an NS collection view and each of the cells is actually another WebKit view. So it's a grid of WebKit views and what we get there is that we can do little core animation tricks and get all this nice sorting. But you can completely change the way this looks.

So what I want to do now, now that you guys kind of have an overview of what's going on here. I want to see if I can tweak this application just a little bit to kind of change the colors. So I tried to whip up a little style sheet last night, so lets see how this goes. So here's the application, I can just double click it to launch it like a normal Cocoa application.

But what I could do in this case is, say there's a few of the images that we don't like, something's that we want to tweak, I can pass this onto a designer like Keith or some other web developer and they can just go in here with package content and everything that they need is right here in this HTML directory in the resources. So these are all the resources necessary for the application, for all the different web views.

You can see that there's a style sheet here for the company web view, which is each of the little buckets in the NS grid. There is a few other style sheets for the graph and another one for the stock services as a whole. So as I said I kinds put something together ahead of time, so let's see if I do a little renaming here.

So I'm just going to, I'm basically, what I'm doing here is that any of your users could make there own style sheets and just inject this into your application. And one of the great things that you get when you do something like that is that you get basically get an instant community. As soon as you get a few people kind of linked around your application.

So here's, now you can see all the top is green, there's less images involved here, you still get all the sorting and all that just using text links. So as I said I just kind of threw this style sheet together very quickly here. But the idea is that you can go out to your users and you can say here's kind of a default design, now you guys do my work for me and make all these other designs because people love to just share their own interpretations of things and by using WebKit in your application you really, really get to do that. So lets go back to slides.

So what do we have going on under the hood here? I'm going to do yet another list of all the technologies. One of the great things about building applications using WebKit is that since the web views alone use a number of technologies, you can make these incredibly impressive lists of all the things you know.

So this application is using AJAX, we got XHTML for the view, CSS to make things look pretty, some JavaScript. In this particular case the JavaScript is being used to make the call using AJAX to get the data, its being used to draw the graph along side the Dojo charting.

library, which is fantastic, its also being used for some of the little widgets, so when you click on one of those buckets in the NS collection view, its JavaScripted pumping that up into the application and then bringing it back into Core Data. Lets see what else? We also have as I mentioned, using SVG and Dojo.fx, all of the graph there is all done in SVG.

And then again XML making AJAX request pulls up an XML format off of any server on the web and then that's parsed and that data is pushed into Core Data. Core Data as Toby mentioned is basically a database that you have running on your machine all the time.

And its fairly straight forward especially for those of you that know SQL or SQLite, you can just stick your data in there and it will go around with you and then finally the NSCollectionView, which is just fantastic because you get all those great little animations right out of the box.

And then we have bindings. Bindings are used to connect some of the NS ray controllers into NSCollectionView so that we just get the layout just kind of comes out so it's really great when you add a new company everything just kind of sorts and falls into place. So again here is what we started with, this is jut kind of AppKit out of the box.

One of the great things about using Core Data is that there's a prototyping tool where you can just drag your models in to Interface Builder and it will just pump out a simple interface. So when I was developing this I used that and just kind of moved things around a bit so that I could get this column view, it's a little bit easier to look at.

And then here's the application without any CSS at all, so as you can see it's not much to look at. Kind of difficult to see what's going on, you can, those of you are web developers might notice that there's some unordered list because all the mark up is symantec even though no one will ever see it. And then what we wanted to do is we wanted to go ahead and try to make this pretty with CSS. So here's just a little snippet of some of the vary straight forward CSS that we used to start to kind of massage things into place.

And then here is an older view of the same application. Again all designed just using XHTML and CSS. So what I am going to do right now is give a little WebKit 101 for those of you that have used WebKit, this will be a little bit of a review. But hopefully there's a lot of you out there who haven't made the leap quite yet, you've seen some of the applications this week and you're really wondering how you can kind of bring this into your own application.

And what I am going to do is go over some of the technologies here in slides and then do another demo to kind of do it live so you can see how it really works out. So the great thing about WebKit is as many of you might know, you can make a web browser using one line of code.

So here's the one line that you need. Every web view has a mainframe element and you just load a request using the NSURLRequest and in this particular case I'm just loading apple.com. This can also be a local file on the file system which we, what we've done for the application.

Well this is all you need to load a particular request so with this single line of code and just a few minutes in Interface Builder and Xcode you could make an application that a user could launch and it will only load a single web page. I've seen a couple of these for Google mail, so you can just double click and it goes right to Google mail and you have Google mail on your own window so you don't accidentally close it or anything like that.

There very basic applications but there actually really, really fantastic. So here is a little bit of an expansion with the famous one line of code browser. After adding an NSTextField to your window you can see I've replaced the URLWithString, which is getting the string value from an NSTextField, which again is just a simple message there.

So one thing to keep in mind when you are building these applications is if you have your own HTML, you want to bring along with the app, it's very simple if you need to connect to an external resource. But in this case we have our HTML, we have our CSS, we have the whole Dojo library, all of the images and SVG that we are using.

So something you have to do is kind of wrestle with Xcode to get it to bring those things along. Some of you might have noticed that in Xcode it's not difficult but it's non trivial to get a directory structure of assets to be preserved inside of your resources folder. Normally that is not such a big deal for application development but when you're using a website, Since many of us web developers, cause I also sit on both sides of that fence, we use very, very strict directory structures.

You know, we will have a JavaScript library and everything has to be in its place and you know we like to put our images in one folder and the CSS in another and everyone has a different way of doing it but we're all fairly, fairly strict about it. And so one nice thing that you can do is use the Run Script build phase in Xcode to just copy your whole HTML directory into the resources and then just refer to that from then on out.

And the nice thing there is that you can actually have another developer, develop the site using just that directory, they can get everything working while you're working on the application and then just swap out the assets and everything just works. So here a little sample code as well.

This is just a simple bash script at the top that uses some of the built in constants to find out where you project is and to first remove the HTML directory and then just copy the new on in. It's kind of a scorched earth approach but its fairly fast and does the job.

Next we have how to load a file from the bundle so as I said, since you , in this case are outing everything into and HTML directory, when you load something from the bundle what you need to do is just use the NSbundle mainBundle to get a fix on the applications bundle and then get the resourcePath on that bundle to get the directory back. And here I am using pathWithComponents to concatenate the HTML directory on to the end of the resource path of the bundle.

And then finally I am going to use NSbundles pathForResource oftype inDirectory method to get the index HTML file for that. Now you might see that I could of just used NSStrings pathWithComponents, I could of just added another member to the array there and out index.html on the end and it would of just slammed it all together. But the nice thing about using the pathForResource method is that it makes sure that it's valid.

So in this particular case I have taken out the error checking for the sake of brevity. But you might get the full path back as null if the resource isn't there, and so that gives you just a little bit more error checking especially if you intend your application to be something that's skinnable.

If you send it out into the world and some of your users maybe misnames the index HTML or accidentally deletes it or something like that, this would be the point in your application where you can rescue from such a thing and either auto generate a new index HTML or give the user some sort of indication that something gone terribly wrong. And then finally just how to load the file there. So let me see if I can make a web browser here in just a couple of minutes.

So I've already got my web code project here, this is just an application here called oneliner. And I am going to go through the motions of just making a one line web browser. So I am going to go into frameworks, so the first thing that's important to do is you need to add the framework. So I am going to go to project, add to project, and we need to add the WebKit framework to this project. So, let me see if I can find this here.

Alright, so I got my WebKit framework in there and then in my classes directory, I need to make a new file here, so I am just going to make a new objective C class and this is going to be the controller for the application. So now I've got my controller here, so then just for sake of making sure I am just going to go ahead and put WebKit in here. I think I need the (inaudible) case.

So now I am importing WebKit into my controller so I've got that part settled. And let's open the nib here in interface builder, if we can. Alright, so here is my window, let me get this out of the way. So here's my window and I am just going to use the new library to look for the web view. Pull this out a little. And then I'm going to want in this text field here for the URL field.

Now let's get this size inspector here so he can get some springs involved with everything. For those of you that are web developers, this might seem like magic, I hope. Alright, and then let's, get an NS object here so in IB3 the way to get a particular instance of one of your objects is to drag out an NS object and then change the class, so it should auto fill.

Its syncing with Xcode to find the class so now I've got my controller and I am going to go ahead and add an action here, lets call it load URL and I am going to add a couple of outlets. One is going to be for the web view, and one is going to be for the location.

So now I've got these in place and I want to add those again to my header here, so I am going to see if this will work. I'm lazy, so I am just going to try to drag these over here, it's a very sexy new feature of Interface Builder and it should work just fine for that as well. And so now I can switch back.

Into my class here, so I am back into the M file and I got this load URL action, so now that everything is kind of in place, let's do the final steps in Interface Builder. I'm going to control drag connect to that to load URL connect this to the web view and just for fun connect that to the location. So now let's do the one line web browser. So I am going to get the web views mainframe. I haven't said that in a while. And I am going to get the NSURL request. Lets see request with URL.

So let's go to, actually let's go ahead and do this. So now I just grab the value coming directly out of the sender in this case I got all those paired. Well let's see what happens. Nope I think I have an extra bracket. Sorry everyone.

Far left. Well that's not working out. Oh there we go. Thank you. Sorry about that.

And there we have a web browser. So now this is just a normal web browser, any URL that you type here up at the top, as soon as you hit enter is going to take you there. So we can see you don't get any of the bells and whistles like loaders but things like Flash and all of your plug-ins work. So as you can see it fairly simple to make a very quick web browser. So can I go back to slides please?

Okay so now that we have the web browser out of the way, let's talk a little bit about how to get JavaScript and Cocoa to communicate with one another. So in an application like the stock viewer you need to be able to have some kind of connection between the two When you bring an event in through AJAX or something like that in a web view you need to be able to throw that up to your application to go into another view, could be a table view or to go into something like core date.

So first I am going to talk about going from JavaScript in Cocoa so once you have the web view in place you need to do a few things just to make sure you've got a hold of the right bits you need. So right here I'm just creating inside of a controller class in this instance. In my init method I am just making a new web view, just from code without using an Interface Builder. And then in the awakeFromNib I'm going to set the frame load delegate to self.

Now what that's going to mean is that when ever a new document loads that this controller is set up as the delegate so it will receive all the events. And then I am going to just go ahead and use the loadHTMLString with baseURL method and I am just going to load in an empty stream.

So one great thing here is that if you could put any HTML you want, you can actually hard code some of the HTML into your application and keep that out of the prying hands of your users. So you can kind of split the difference here if you want to make sure that some of the things here are pristine.

And then finally you need to be prepared to answer when the WebScriptObject is available. So when a page is loaded the WebScriptObject which is the way you can communicate to the JavaScript engine isn't immediately available. So once the page is loaded this delegate method is called and you can make an ivar in this case the WSO ivar, to hold onto reference to this window script.

Now once you have that object you can start making your calls, so there are three main ways that you can make JavaScript calls from Cocoa to make JavaScript do what you want. So the first tier is just using callWebScriptMethod with arguments, so the WebScript method here is called the helloJS, so this would just be a normal JavaScript function in the document that you loaded and then you can pass in a number of arguments in an NSArray, so in this case I am passing a single argument which is Cocoa calling JavaScript. So once this is called that method, the helloJS function inside JavaScript is called and passed this argument.

Another thing you can do is just directly set values using KVO inside of your JavaScript. So here I am just setting a variable called jsVariable and giving it a value of new value inside of my WebKit. So you can very simply pass variable values back and forth between Cocoa and JavaScript.

And then here we have a way that you can evaluate JavaScript and return the result. So since I come from the web world and I like, I'm used to things like math random and these quick JavaScript ways to do certain things. Right here I am just using evaluateWebScript to just call math.random to get a random number between zero and 100 just one line and it will stick the result into my variable there and I am ready to go.

Now of course this uses an eval similar to the JavaScript eval and whenever you do that you have to be careful to keep your quotes straight and all your commas in the right place because it's a little bit less rigid way to do things. So now we know how to go from Cocoa to JavaScript and going back the other way is fairly simple as well.

Again, there's some things you need to set up first. The first thing is you can see I'm using my script object here and I'm going to set a value, in this case called controller, which will make a variable in JavaScript that references your controller. So again, similar is grabbing this WSO object in the first place to give you a hook into the JavaScript engine, this is the inverse move. So this way you could go from JavaScript and you could call out to the Cocoa class.

The next thing you need to do is allow access to some or all of the selectors in the Cocoa class. Out of the box all of your selectors are protected so you can't call them from JavaScript. So if some of you have poked around with this but not too much and just got frustrated because nothing wasn't working, this was probably the culprit. If this is, again, a scorched earth approach that will allow JavaScript to access any selector in your class, but you can tweak this and you can have some conditionals in here that only allow certain selectors.

Again, make notice that this method is selector excluded from WebScript and if you return NO it's not excluded. That always seemed a little bit backwards to me. So you have to return NO to mean that it's okay to call these methods. And then finally we have allow access to some or all properties in the Cocoa class using the isKeyExcludedFromWebScript. This is basically the cousin of isSelectorExcludedFromWebScript which allows the JavaScript engine access to certain keys in your class.

Now there's a few things to keep in mind when you're going to call from JavaScript to Cocoa. Since Cocoa is obviously, or object C is a severely different language than JavaScript, there's a few naming conventions you have to keep in mind. Most importantly is any colons in a method in objective C in Cocoa need to be replaced with underscores. And this is incredibly important when you're using a method that only has a single argument you need to make sure to have that trailing underscore on the end. And then you also just use the reference to the Cocoa object that we made a moment ago.

So what I'm going to do here is you can see a simple Cocoa method that I just pulled out of the stock here the didLoadValue forSymbol and company and I'll show you how to translate that into the JavaScript equivalent. So when this is moved into JavaScript you see the first thing I have there is the controller, that variable I set up using KDO that refers to my class.

And then the .operator and then the didLoadValue_for Symbol_andCompany using underscores in place of the colons. Now again, here is a Cocoa method that takes a single argument, just a setName method, which in the JavaScript becomes setName_ to replace every colon with an underscore. And then finally just a simple instance where there are no arguments, it's just the method name itself.

So here's kind of an overview of all of that. Let's keep going. So you can make better method names. So, this is especially important when you're actually working with a JavaScript or an HTML developer to do more sophisticated things. You know, this gives you kind of an easy way to make a light protocol, to make some contracts with this developer that you're working with.

Some number of JavaScript developers have never seen Cocoa, have no idea what objective C is, and so when you say yeah, you have to have a trailing underscore on the method, sorry about that, they'll get a little bit upset with you, or just be kind of confused. So what you can do is you can use the webScriptName ForSelector method to set up some conditionals, testing against the selector, and then return a more JavaScript friendly name. so in this particular case, I'm testing for the didLoadValueForSymbolAndCompany selector. And I'm just going to return a more JavaScript friendly camel case sort of format without the underscores.

And then again, the same thing for the setName selector. I'm just going to return it without the trailing underscore. So the JavaScript becomes a little bit cleaner. So another thing to keep in mind is how things are serialized as you move between it. The engine is pretty phenomenal in the way that things get mixed up. So JavaScript numbers are converted to NSNumber objects, or basic data types, like int and float, strings are converted to NSString, and all this is just for free. And this is all from the documentation. The JavaScript arrays are mapped to NSArray objects.

Kind of. So more often than not your JavaScript arrays are actually going to show up as WebScript objects in Cocoa, which means that you need to use KVC methods to get out values from that. This is particularly true, in my experience, when you use a JavaScript library such as Prototype, which messes around quite a bit with the built in JavaScript array prototypes.

It adds other methods and things, and I think in those particular cases, you're more often than not going to come up with a WebScript object. You can use the simple KVC methods, WebScriptValueAtIndex, which will treat it like an array. And there's really no difference otherwise. Other JavaScript objects are actually wrapped as WebScriptObject instances, which you can use KDO to access.

Going the other way, from Cocoa to JavaScript, again, NSNumbers are turned into JavaScript numbers. NSStrings become JavaScript strings. NSArray objects are mapped to special read-only arrays in JavaScript, you need to make a copy of the array if you want to play with it inside the JavaScript. And nulls converted to JavaScript nulls The Cocoa web undefined type is converted to undefined. And all WebScriptObject instances are unwrapped for the scripting environment.

Also, the NSDictionary is not serialized in a usable format. It comes in as a type that is very difficult to access. So I typically suggest using NSArray instead and making some nice JavaScript helper methods so that you can know the index of the property that you want to access. So just to kind of start an overview, some different options for Using webView as Toby and Keith have mentioned we've made an entire application that's just a web view.

We can take a website that we've built, throw it inside of this application and you get something you can kind of carry around on your laptop and show to your clients. This is also great for use of things Dojo Offline and Google Gears, so that you can do a pure JavaScript technique for storing things on the user's computer.

You can also use a web view alongside of other AppKit views. In the example I showed, there is an NSCollection view, but it uses WebKit views inside of it, which is somewhat confusing, but you can have your WebKit view right up there with an NSTable or any of the other AppKit views.

Another option, as I showed with the NSCollection view, is to use it inside. So any time that there is a cell you can just throw a web view in there and get a little bit finer control. And finally you can also use multiple WebViews, one for service consumption and status, one for displaying things, or just using them in different ways to kind of leverage the power of your users.

And also, it gives you an alternative to drawing inside of custom NSViews, by using WebView and Canvas. So you can throw a web view in there just to use JavaScript so that you can draw inside of it. A lot of developers are familiar with drawing inside of Canvas, but not so much how to draw using the NSView methods.

So again, the most obvious reasons to use WebKit are to consume resources, to get cheaper designers, which is always good, use XHTML web services, images, videos, rich media, easy drawing using Canvas and SVG, and you can also, as Toby mentioned, modify resources with user registration, activating serials, support requests, updating resources internally in the app, and also, of course, templates and skinning. So that does it for me. There's one more thing. George is going to come back up here and kind of take you through a few more points. So, thank you very much.

George: Okay. Given the time frame right now, we're about twelve minutes left, show of hands, how many of you have been to the iPhone developing websites for iPhones session or seen the rebroadcast? Practically the entire room. Great. So let me just get quick through these. I'm going to talk about this, I want to open up the floor for Q and A, and then we have a lab later on where you'll be able to meet the Barbarian Group and talk to the WebKit development team, as well as the QuickTime Development Team.

So as you've seen in the previous sessions, live or prerecorded, good design practices. Be sure to ensure you're using column layouts. Using divs. If you haven't read up on the Swiss Grid system, I highly encourage you to pick up some of those graphics design novels, it'll help influence a lot of your web design. Size does matter in terms of the assets.

Media queries. Be sure you're reading up on the latest CSS3 implementation as it relates to both WebKit as well as the W3C in handling media queries for resolution independence, optimizing for iPhone. Key things you want to remember. Dealing with the view port. How large is the actual view port of your content on any given page. That will help the rendering time as the iPhone sort of designates how to zoom in and zoom out of content. Dealing with the double tap. Dealing with the two fingers and how you actually interact with the actual device.

Text size adjustment. That also is based on how big your viewport is. Remember, keeping things somewhat contained and not having things flow across the width of the page. Events. Reading up on what the exact JavaScript DOM events are that the iPhone does support. Again we'll be releasing more information probably sometime at the end of this day around the information that you saw previously in your previous sessions. And in media.

Being sure that you encode your media properly using H.264 baseline profile and have it properly optimized for both the Edge network as well as the WiFi network user reference movies. So with that, I'm just going to you click through the more information. If you have specific questions either relating to the hybrid session you just saw, to iPhone development or anything related to web development here at Apple, in general, please contact Mark Malone. He's a World Wide Developer relations manager and evangelist. Anything related to media as it relates to iPhone or it might be integrated media within a hybrid WebKit Cocoa implementation of your application, please contact Allan Shaffer.

And then lastly, today we have some interesting sessions. Please be sure to check them out if you have time. We've got a Developing a Rich Media WebKit Based Application in Presidio. That's going to cover in-depth, the rich media uses of SVG, QuickTime, which are all applicable to the hybrid app session you just saw. As well as later on this evening we're going to have the founder of, one of the key founders of 37 Signals, 7 as well as the development lead and creator of Prototype, Sam Stevenson will be on Russian Hill talking about the Prototype Framework.

We also have a lab dealing specifically for Hybrid-WebKit/Cocoa Applications. If your question was not able to be answerer in the last 90 minutes, please take all your questions out to the hallway, because do have to clear out the room to make room for the next session that's coming in. but also, please come to the lab. The lab starts at 2 p.m. in the graphics and media lab, downstairs on the first floor.