Configure player

Close

WWDC Index does not host video files

If you have access to video files, you can configure a URL pattern to be used in a video player.

URL pattern

preview

Use any of these variables in your URL pattern, the pattern is stored in your browsers' local storage.

$id
ID of session: wwdc2008-100
$eventId
ID of event: wwdc2008
$eventContentId
ID of session without event part: 100
$eventShortId
Shortened ID of event: wwdc08
$year
Year of session: 2008
$extension
Extension of original filename: m4v
$filenameAlmostEvery
Filename from "(Almost) Every..." gist: [2008] [Session 100] Introductio...

WWDC08 • Session 100

Introduction to Mac and iPhone Development

Getting Started • 55:14

This session is designed for experienced developers who are new to Mac OS X and iPhone OS. Learn the fundamentals of the Mac OS X architecture and what makes a great Mac or iPhone application. Benefit from an orientation that will prepare you for further learning in the sessions on frameworks, APIs, and tools. Whether you are interested in creating applications for the growing Mac platform or mobile applications for iPhone and iPod touch, this is a must-attend session.

Speakers: Deric Horn, Larry Coopet

Unlisted on Apple Developer site

Downloads from Apple

SD Video (671.2 MB)

Transcript

This transcript was generated using Whisper, it has known transcription errors. We are working on an improved version.

So welcome to Introduction to Mac and iPhone Development, and welcome to our sold-out event, WWDC. So before I get started, I'd kind of like to get an idea for myself. How many of you are here at WWDC for the first time ever? Oh, awesome. It's fantastic to see so many new developers at the conference.

So one hour really isn't much time to go over all the concepts needed to develop iPhone apps and Mac OS X apps. So this is going to be a bit of a whirlwind technology tour. And hopefully as you see things that you like, you'll be able to remember them and follow up on them later on in the week.

Deric Horn, Larry Coopet So I'm Deric Horn. I'm the application technologies evangelist. And really what that means is I'm responsible for the promotion and adoption of our key technologies, our key application technologies by our developers. And then I'm also a voice for the developers back inside of Apple Engineering so I can help escalate issues and to make sure that we're delivering what you guys are dependent on.

So we released Mac OS X back in 2001, and since then we've had these steady updates. And I think Leopard that we released last October was an amazing release with huge user features and developer features. So everyone's been really busy, but, you know, why stop there? We released an entirely new platform to develop for, and that's the iPhone, of course. So I just wanted to say thank you guys for making the beta SDK such a success. And I also wanted to thank those hundreds of thousands of other people that downloaded the SDK that couldn't get their tickets for the conference.

So, I'm going to start off today by talking a little bit about the architecture of Mac OS X and iPhone, a little bit about the development frameworks to put things in perspective. And then I think any time you develop for a new platform, and I know this when I was brought into the iPhone development program, there are really two fundamental questions that you have.

One, I just really want to know how do I get my code called? You know, how do I put a button on the screen and have it call Hello World? So, we're going to start off by talking a little bit about those development fundamentals, the tools, the language, and the frameworks that you're going to use to write applications.

And then I think that the second fundamental question you have is what are those available technologies and how do I integrate them into my application? I mean, how hard is it to take something like core location and integrate that into my application? So, along the way, we'll have several demos. We've got some sample code associated with this session on the attendees' website. And hopefully, I'll be able to give you a little bit of insight as to which sessions you should follow up on.

So, I'm going to show you a little bit of the standard architecture diagram you've probably already seen a few times today, but at the base we have the Unix and kernel, and this is at the bottom of both the iPhone and Mac OS X, and this really is Unix. An engineer walked into my office, I think, last week and he said, Deric, when you say that Unix is on the iPhone, what do you mean? And it truly is. So, for instance, I wrote a little application about a month ago to test the file system access, you know, what files we have read-write access to on the device itself.

That was all using straight POSIX, Fopen, Fread, Fwrite type calls, so that could run on a Solaris machine, Mac OS X, and runs perfectly on the iPhone. And then above that we have our core frameworks. These are typically our non-GUI frameworks, like core foundation, foundation type frameworks. And above that we've got a rich set of media frameworks.

And then finally, you see where the architecture begins to diverge, and this is the application development frameworks. On Mac OS X you develop for Cocoa, and on the iPhone for Cocoa Touch. And then the glorious part, where your applications get to participate up at the native application layer where you're going to see Safari, mobile Safari, and hopefully your app and your mobile app.

But really, I think what's more important about this diagram is that since the beginning of Mac OS X, we've really tried to keep the operating system very nimble and keep these dependencies in a downward direction so that we can now start to integrate and adopt new technologies quickly and integrate them into the system.

So on other platforms, you may have to untangle a bunch of spaghetti code in order to take one technology out and replace it with another. But this type of architecture, we take very seriously within Apple so we can go ahead and move the operating system and the development frameworks forward very quickly.

Deric Horn, Larry Coopet So I want to touch a little bit about what the application development frameworks are. And basically, if you've come to WWDC to learn about how to do iPhone application development or you've come to WWDC to learn about how to do Mac OS X development, you're going to leave knowing how to develop on both platforms.

And that's because they really share about 90% in common. So for instance, when you develop for Mac OS X, you're going to develop for the foundation, non-GUI portion, and you're going to use AppKit that's going to provide all the user interface, your event system, and all that whole user experience level.

Well, on Cocoa Touch, we have that exact same foundation also available. And then finally, we're introducing UIKit, and that's analogous to AppKit. A lot of the same coding concepts are based on AppKit. It's very similar, but it's designed specifically with the iPhone in mind. So what's the difference between the two? So at this time, I would like to welcome a colleague of mine upstage, and he is probably the person I know that has had his fingers in more code than anybody else I've ever met. I'd like to welcome Larry Coope up here.

Thanks, Deric. Thanks a lot. So, as Deric mentioned, I work in worldwide developer relations, helping other developers bring their applications to the Mac. So, I want to tell a story real quick. Every year a friend of mine comes to WWDC and he complains how Apple makes him learn all these new things. And I tease him every year.

I say, yes, if it wasn't for Apple, you would never learn anything new. So he sent me this email with this quote, and I thought it was appropriate as you guys are bombarded by the amount of information this week, which is, learning is not compulsory, but neither is survival. So keep that in mind this week when you're going through all your content. So as Deric said, we're going to talk briefly about tools, language, and developing for Mac OS X and iPhone.

So tools. As you heard this morning, Xcode is our IDE. And like Deric said, how do I get started? This is it. This is where everything begins and you're going to build all your applications based on this. The cool thing about Xcode and our tools is they're built on industry standard tools. GCC, GDB, LD, including Dtrace for optimization. So these are tools you're already familiar with. You guys already know this stuff.

Next, about Xcode is, Always start from a template. As developers, people say, well, I've got this complicated build system. You really need to start Xcode with a template. I know it's obvious, but believe me, a lot of people won't do it. Drag your code in. And what's interesting about the tools that differ from other platforms, it's tight integration with Interface Builder.

Okay? And why is that interesting? Because Interface Builder is not just a UI editor. As you've seen all day today, right, it's an integral part of your development system. And its tight integration with Xcode lets it know about your code. Why is that important? You're going to let IB do the dirty work and a lot of the heavy lifting. Instantiation of UI objects as well as your class objects, which are tightly coupled. Okay? So, The other thing I want to say about Xcode is that it's very flexible. If you do have a complex enterprise-based build system, and boy, I need to do this.

As Deric said, we've got Unix under the hood, okay? I can script this thing any way I want, whether it's Python, Perl, Ruby, calling Xcode externally. We've got a command line tool, Xcode build. So as simple or as complicated as you want, you can build your build system.

But day-to-day, you as developers will use a really powerful integrated development environment. Next, Objective-C, okay? I have a lot of developers say, I can't throw my code away. You do not do that, okay? Objective-C is a superset of C. And the cool thing about our tools is GCC is a full Objective-C++ compiler.

And people say, what does that mean? Mix and match, okay? There is zero restrictions. Whatever you've got, your C, C++, can be tightly integrated in the same file, the same function, the same line, which you'll see in the demo. So definitely, you're going to be reusing your intellectual property code every day.

So, Objective-C. Let's take a little look, real briefly. I want to point out something here. So what have we got? I want to point out that the semantic differences between the two languages are not big. The learning curve here is small. In this case, I've got some C++ code and the equivalent line of an Objective-C call. I've got an object that I'm talking to, my WND, my window object, and I'm calling a method on that.

Set frame. Okay? The first parameter is the frame or my rectangle that I'm setting. And here's where Objective-C starts to get really interesting. And as being an old C++ guy, I resisted this. But what's really great, I really love Objective-C now. Because what's that? Heck if I know.

Go to your headers. Talk to your other developers. What's this Boolean I'm passing? Well, in Objective-C, the name parameters are named. So, in this case, this method is called set frame colon display colon. And that is the method's signature. And it's hopefully, if you write your own Objective-C functions well, they are self-documenting. In this case, this is a true method on NSWindow. And it tells me I need to display this window now. As you know, Mac OS X is a buffered windowing system. And it delays all updates.

But in this case, I need to tell it, I need you to update right now. So, this is really powerful. And you'll see why later. And again, to point out, I really want to get this through everyone's head. It's truly mix and match. In this case, this is actually from a file of mine, some sample code. There's my C++ object. I'm extracting a value from it. And I'm passing it right to an Objective-C method. Zero limitations. So, Objective-C being the language.

What are the real differences at runtime? Well, Objective-C is loosely typed. As you get into it, you'll see. And it's dynamically name-bound. So I said set frame colon display colon, that's the name of the function. That is found by name. There's no virtual tables. There's no pointers. That is name-bound. And what does that allow me to do? That powerful, simple construct lets me introspect classes and instance of classes to see if that object responds to that message by name. And you'll see how powerful this is as you get more and more into Objective-C and Cocoa.

So we've talked about Objective C a little bit. What is Cocoa? Well, it's clearly our object-oriented environment. It's a full-featured, mature set of frameworks that you're going to build your interface and application on, and if you're bringing your other code across, that you'll build on top of that.

Deric Horn, Larry Coopet It really allows you to build really powerful, really consistent applications. So the important point I like to point out here is one of the really fantastic benefits of Cocoa is the ability to remove that day-to-day tedium, right, for you guys, where you can really focus on your applications and not worry about all the details building your application.

One of the important things about Cocoa as a framework, and that, like Deric says, Apple takes very seriously, is there's very few design patterns used throughout the system that you will see repeated over and over again. Things like the naming patterns. When you see a certain signature in a function, you know that you own that object that it's returning to you, or the system does. And that helps you with your memory management. How do I manage memory? I can just look at the function and I know. And it's used everywhere.

Things like target action. How do I get my code called? How do I reuse off-the-shelf, built-in components, but for my application-specific behaviors? And delegation, which allows me to literally delegate temporarily some functionality to an object that I know little or nothing about. And then, model view controller. This is really important for you guys bringing your, you know, multi-platform, multi-device. device code to the Mac.

So the goal again, more functionality, less code. And the other thing I really love about Cocoa now is, you know, in the days when we used to rapidly prototype things and you'd have to go back and say, okay, I've got a prototype and I have to go back and do it for real. Now my rapid prototype is my production code and it's really, really fantastic. Again, keep focused on your application and not on the details of, you know, the system. So I want to talk briefly about the three important ones here, target action, delegation, and model view controller.

So target action, what is it? It really, a target is an instance of your object and the action is the method that's gonna be tied to that instance. And again, we'll see this later in the demo. Delegation. I love this slide because it's way too complicated. It makes it look a lot harder than it really is.

What's important to take away from this is that Cocoa uses this over and over. When you come to a platform and you want to take override standard system behavior, the first thing you think of is subclassing. How do I take that system object and make it do what I need it to do? Well, in delegation, You don't have to, in Cocoa, we think we have a better way, which allows you to say, okay, I'm gonna temporary turn over functionality to you to a delegate object

[Transcript missing]

Model-view controller.

When I first started learning Cocoa, and everyone talked about this, I was like, what? Model? I'm not a 3D app. What? And so I like to think of it this way. Engine, UI, glue. The engine being your intellectual property, your code, the view, obviously the UI, and the controller really is the glue or the arbiter between the two. And the important thing in this slide to point out is the arrows.

When you have a system where that model and the view start to talk to each other directly, you've got problems. Because the view system is changing so often. Look at, if you're familiar with Cocoa at all, you know that UI kit is slightly different than NS view. And if you've followed this paradigm, you can easily port your code to the iPhone.

So what does this mean for you guys as developers? And this is the number one thing I tell developers. You must take ownership, right? People say, well, my view holds state information. That's just a bad idea architecturally, right? Your model, your engine should hold your state. You know, you really need to factor that code so that it plays nicely everywhere. And like I said, removing view dependencies on state and other information like that so that the controller can be the go-between.

And then as you do that, you automatically will be able to take advantage of all these really, really rich technologies that Deric's going to show you later.

[Transcript missing]

Thank you. So in my slide, I was talking to you how NS Window can delegate its resizing if you choose. So I'm going to open Xcode here, and I'm going to open a new project and pick a Mac OS X application.

And one of the advantages of starting from a template is I'm going to run this application. Build. I know you guys have seen this this morning. So I've got an application up and running. So what I want to do is I'm going to drag in my model code here.

Let me show you what this is going to do. So this is a simple C++ object. This is purposely trivial. You'll notice it includes no Mac code. It's a C++ object that's going to help me constrain my window, right? Very artificial, but it's... And I've got two methods that are important. It's set constraint and set ratio. Okay? Now I'm going to go right to my controller class. So I'm going to create a new file. And I'm going to say I want Cocoa and I want to Objective C class and I'll call it MyController.

And here's a little trick. If you're going to use C++, there's many ways to tell GCC that I want to integrate Objective-C and C++, but just like a .c file that tells the compiler what it is, .m is a Cocoa file, .mm is an Objective-C++ file. So I'm going to rename that there. Then I want to... I'm going to open my little helper script app here so you guys don't have to see me type. So I'm going to add my little constrainor object. Then I'm going to add my instance, which is a straight C++ instance.

And then I'm going to add-- Two wrapper functions, right? You notice the IB action on there. That's so Interface Builder recognizes that. And so these are kind of going to wrap my C++ object. Let's go back to the, now here's my, let me open that in a bigger window for you.

So now here's the implementation of that. And I need to do a little bit more dirty work because I'm instantiating a C++ object. So my constructors and destructors. Then, here's the important part. Those action methods I declare, I just want to point out that all I'm doing is passing this message down directly to my C++ object. That's it.

And you're going to see a lot of Cocoa code like that that trivially wraps your C++. And then... I'm going to implement my delegate methods. Another interesting point, I, you can search this project, I never call this code. The cool thing is, it's funny, some people say sometimes with Cocoa, I feel like I'm not always in control.

that's sometimes true. So the window object's going to be calling me, not me. So I build that. So I've got my code, my engine code, which is my model. I've got my controller code. I need a view. So now I'm going to close that. And again, I've started from a nice template.

So I've got my interface builder file here. And I'm going to go and first I'm going to grab an object, put that in there, which is my instance of my controller object. And what's cool about interface builder, remember I said the tight coupling between the two, I go in here and I can just start typing M.

It already knows about my controller. And indeed, when I hit my tab, it shows my methods there, right there. So I can start hooking things up to that. Okay? And the last thing I need to do... The second for the last thing is now drag and tell that window that my object, which is just a generic object, is the delegate of the window and that it should receive delegate messages. Now I want to hook up my interface to... Put in, for now, I need to wait to set the ratio for my width to height ratio, and I want to tell it, and I need a little checkbox. Again, this is very trivial to say, hey, start.

Start constraining the window. And then let's hook those up too. So I want to say when this guy changes, I want to call set constraint ratio. And when this guy changes, I want to say toggle the constraint. So hopefully, if I haven't done anything wrong here, I can go back to Xcode and build this. It already knows, because of the tight integration, that the interface builder file is dirty. So you save all.

[Transcript missing]

Run it. And now I can type in 1.5. Nothing should happen until I click my Constrain button. And now you can see I'm constraining the window. And if, real quick, if you want to see something quick and dirty, just so you know, I'm not calling that. And we'll go down and set a breakpoint on the toggle here. And if I debug this...

[Transcript missing]

Clicker. Back to slides, please.

Great. So thank you, Larry. That was a demonstration of some of the common design patterns that you're going to use over and over in all of the modern frameworks that you're going to use, whether it's iPhone or Mac Development. And also, hopefully you realized how trivial it is to integrate C++ and Objective-C code together.

So when I think of Cocoa, I think of it as being both modern and mature in that it's been developed for 20 years now, but it's also been extended over those 20 years. So it has this great design pattern that really allows us to integrate new technologies. So some of the newest technologies that we integrated in the last release of Mac OS 10.5 Leopard include things like 64-bit. So this is a core infrastructure change. So now your applications can be built 64-bit from the ground up.

We added a technology called NSOperation that in a way allows you to incrementally add threading support. And multi-core support into your application. It's resolution independent. So all the views and controls can be scaled to any size. And your views can participate in that as well. But I'd kind of like to take a look at just a little bit deeper at one really killer technology. Just so you can see a little bit how it fits into the operating system and in the development frameworks.

And that's core animation. So if you've ever written animation code before, typically you do it through timers. You're going to set a timer, keep state, and move that thing along. And it's a pretty expensive way to do it because you have to keep on re-rendering that content. Well, when we architected core animation, we did it based on the concept of layers. So that once you render your contact, that expensive operation of rendering that content onto a layer, we can now perform these operations on it without having you re-render that content. Fade it in, fade it out, move it around.

Or you can even apply like 3D matrix transformations to it to have it fly through space. And all without having you re-render that content. Well, we further improved on that performance by letting the core animation engine sit on top of the OpenGL, hardware accelerated pipeline. And then furthermore, we improved the performance by having core animation run in its own thread so that your user interface can stay responsive while you're having animations go on in the background.

We also made this great graphics kind of unification layer in that because it's based on layers, you can render different types of content in these core animation layers and then compose scenes by coalescing these layers together and then change the attributes of each of these layers. So now where this gets interesting is we take all of this functionality and performance and bring it up into the Cocoa layer to make it very easy to add core animation or animation effects into your application. So let's see a little bit how to do that.

So typically, you can probably understand right now, if we're going to call set frame on a view, it's just going to change its origin and its bounds. So we'll just flip it to another location. So how does Cocoa integrate with core animation? How do we make this animate? Well, it's really as simple as adding about half of a line of code.

Instead of calling set frame on the view itself, we call set frame on the view's animator and then we automatically get that smooth animation. Okay, so we've talked a little bit about Cocoa and Mac OS X development. Now I'd kind of like to switch gears and talk about the iPhone.

So when we took a look at the iPhone, we had to take a look at this futuristic device and really design something that can be based on almost on the future. Design an entirely new operating system, entirely new development frameworks. So where we started was with the latest version of Mac OS X 10.5 Leopard and bring all those technologies down onto this little device, the iPhone.

At the heart of your iPhone development is going to be the UIKit framework. Any application you write is going to have to use UIKit. It's responsible for that user interface, all of those controls, views, widgets, table views are a big part of it. We also introduce a number of controller classes. A fundamental one is the view controllers to help you manage all of your user interface items, as well as an event system.

So the way we worked out the UI kit sessions through WWDC is really we go from the fundamental session and then we get into more detailed sessions throughout the week. So I recommend that you go to the iPhone Application Development Fundamental Session at tomorrow morning at 9 o'clock. And then throughout the week, you'll see more advanced and more kind of detailed topics where you can learn more information. So let's start off with the user interface.

Right out of the box, we provide some standard, very good-looking controls that I think your users are used to, understand how they work, and make for an intuitive application. And those include all those standard things, buttons, sliders, text fields, switches, and so forth. Now, you can create your user interface either directly in Interface Builder or if you want to, all of the same functionality is available to create through code. But I really encourage you to take your user interface to the next level, to really make something that's intuitive and easy to use and that your users can be proud of.

And there are some very easy ways to do this. You can, for instance, start to integrate your own custom images into the background of your application or integrate your own custom images for buttons and your own views. You can just take it one little step further and start to add animation into your iPhone applications for, for instance, transitions to convey state changes or context changes. And I think that adds a sense of reality to your application that users can understand and intuitively move around. So we have an iPhone application user interface design session in Presidio on Wednesday morning at 9.

So, when you develop an iPhone application, there are really two fundamental concepts that you need to learn. And I really encourage you to really learn these and not just copy and paste the code from sample code and try and use it in your application. These are fundamental concepts that every application is going to use. And one of them is the concept of view controllers. On any iPhone application that you look at, it's going to be made of several screenfuls of data.

And automatically when I look at that application, I know that every screen that I see is going to be managed by a view controller. So going back to that MVC diagram, that view controller is going to manage all the user interface elements on that screen. When a user clicks a button, it's going to call some method in my view controller, and then my view controller can go ahead and get that image, do some processing, and then do something else with it.

So to take a quick look at what the base UI view controller class looks like, it's got an instance variable called view. Okay, simple enough. And that points to your view container. Within that view container, you can now embed other views and controls and buttons and your own custom views inside of there. It also has a couple of convenient methods associated with it.

Things like viewDidLoad, so that once your user interface loads from Interface Builder, that gives you the opportunity to populate your user interface with your own data. and a number of other ones too. So because view controllers are such a fundamental concept in iPhone development, we have two sessions covering view controllers. The first one is understanding iPhone view controllers on Tuesday at two o'clock in the morning.

And we also have a mastering iPhone view controller session as well. So the next fundamental concept of iPhone development is table views. I don't think that I've seen an iPhone application yet that does not use table views. I mean, some people point to games, but sooner or later they have to represent their high scores, and they're going to do that through a table view.

And one of the things I really like about the table views is that you can get them up on screen with really very little code, and then yet at the same time, they're very extensible, so you can get them to portray really unique data with just a little extra effort. So our table views by default come in two styles, a plain style which stretches edge to edge, and a group style which has those kind of rounded corners that you see in the settings application.

By default, the table views contain sections and section headers. If you look in the address book, the letter H would be a section header and all the names underneath that are going to be included in that section. Or if you go back to that settings application and look at that, the sections are divided by logical sections. You'll have a section header called security and all the security-related sessions underneath that. But my favorite feature of the iPhone table views is the fact that it can support these complex views.

So if you look at any one of these table view rows, it's called table view cell. But a table view cell is actually just a UI view. That means it's a UI view container. At this point, you can put arbitrary views inside of there. Images, buttons, text, your own views. You can make your table row doesn't have to be 44 pixels high. You can make it any height you want. And all of your rows can have different heights if you want to.

The iPhone Table View also has support for editing, so when the user clicks on the edit button, it will automatically slide your views over and put that little add or delete button right next to them. And it supports a lot more. So along those same lines, we have two sessions covering iPhone Table Views. The first one is tomorrow at 3.30, Understanding iPhone Table Views, and later on in the week we also have a Mastering iPhone Table Views session as well.

So those pinch, rotation, and swipe gestures can really make interacting with your application more intuitive. Now, you can get access to all the touches at any time and interrogate them, but UIKit offers a couple of convenience methods to you. So let's go ahead and step through the process of what happens when the user swipes against your iPhone.

When the user puts his finger down on the screen, your ViewsTouchesBegin method will get called. And that gives you a chance to go ahead and store away the location of that first touch. Then as the user swipes his finger across the screen, your TouchesMove method is repeatedly called. So this provides a chance for you to give user feedback. And then finally, as the user lifts his finger from the screen, your TouchesEnded method is called, and now you can go ahead and determine what type of a gesture this was.

But multi-touch is really only one of the input devices or one of the ways to input information into the iPhone. Another very interesting way is to use the accelerometer. So the accelerometer gives you very fine detail as to the gravitational pull along the X, Y, and Z axis. And it will call back into your application up to 100 times a second. So it can detect little changes in the orientation you make. Or I've often seen applications where if you shake them, it will go ahead and erase whatever you have on screen, as an example.

And then view controllers also implement some higher level delegate routines to, for instance, detect the rotation of your iPhone. So as you move it from portrait to landscape mode, it will automatically call you back and give you a chance to relay out your user interface to take advantage of that wider display.

So we have a great session called the iPhone Multi-Touch Events and Gestures Session. The session has some terrific sample code associated with it that really gives you a good head start on supporting things like rotation and those zooming pinch gestures. So if you're interested at all in multi-touch, I highly suggest you go to this session.

So we've talked about kind of the basics of developing Mac software and the basics of developing an iPhone application. But when you think about integrating a new technology, sometimes you think, oh my gosh, that sounds like a lot of work. I'm going to have to roll up my screens. I mean, wouldn't it be nice if integrating a new technology were as easy as one, two, three? So let's take a look at that.

Core location. So when I think of my iPhone, I think of it as a personal computer. I mean, it's a computer and it's on my person. So why not take advantage of the functionality it has and use technologies like core location? You simply supply a delegate and it will call you back with changes in your latitude and longitude changes.

What's nice about the API is it's designed to work regardless of the hardware installed. So it'll work the same API across triangulation through the edge network, Wi-Fi hotspots, or even GPS locations. So let's go ahead and see what it takes to integrate a technology like that, core location, into our application. Well, it's just three lines of code. The first line, we're going to go ahead and allocate memory for our core location object and tell it to initialize itself.

Then we're going to go ahead and set the delegate. 99 out of 100 times, you're going to set the delegate to self. It's typically a controller class that's going to initialize the object and wants to get notified of changes that are made. And finally, we tell core location to start updated. It's that simple.

So we've got a session on core location, the accelerometer, and using the camera on Presidio on Thursday evening at 5. So how else can you personalize the experience on your iPhone? Well, you can add address book information in there. So using the address book APIs, you can query contacts, add contacts, delete contacts, and then when you plug your iPhone in, it will automatically sync with your address book on your desktop machine.

So what does it take to display the address book like this in your own application? Seems like a lot of work. Well, again, it's just three lines of code. We're going to go ahead and allocate in it the address book controller, set its delegate to self, and then tell it to display itself, and it'll come animating in. And then as the user selects one of these names, it'll call your delegate method back with the information about what was selected.

So Alex Abas, the engineer that wrote the address book for Mac OS X and iPhone, is giving a session on Thursday morning at 9. So what else is available on the phone? Well, there's a camera. So using the UI image picker class, you can have access to all the albums on your iPhone. You can tell it to take a picture.

And when you tell it to take a picture, it'll go ahead and create that user experience for you so that when the user clicks the button, it'll snap the picture. You can resize it, crop it, and so forth. And you can also save arbitrary images back into the photo album. And then the next time you sync that phone with your desktop computer, those pictures will be uploaded. It will be synced to your iPhone. your computer.

So again, how do we integrate all this technology into your application? Are you guys seeing a pattern here? Allocate an init, set the delegate to self, and then ask it to present itself. And it's just that easy. Then as the user selects one of these pictures, it will call your delegate method for you to interpret it and pull the image out.

But the image picker is just one of the kind of the media technologies that we have on the phone. I think the Mac has had a long history of really forging ahead on the media technologies. And what we've done is taken what was in Mac OS 10.5 Leopard and integrated that onto the phone. So technologies like OpenGL for embedded systems are available for your 3D graphics. Core animation has been on the phone since day one. You can use Quartz for your 2D vector-based drawing and to go ahead and render PDF.

Core audio for high-fidelity audio input and output. We've got OpenAL to implement surround sound within the iPhone. The media player, which is capable of playing MPEG-4 movies. And UIKit provides a number of other classes to manipulate images. And one of my favorites is the UI image view. It's just the simple way of adding an image to your application. So for instance, if you wanted to change the background of your application, just replace that base container view with the UI image view. And now you can give it a nice like leather or wood grain appearance, for instance.

So we've talked a little bit about iPhone development, Mac development, but there's really a third platform out there, and I think a lot of you are probably web developers. So again, to add, well, so typically in an application, you may have already written a web application. And now you're going to go ahead and write a native application. And when the user clicks on one of these links, the default behavior is to go ahead and launch Safari and maybe launch your web app in Safari. And that's going to cause your application to quit.

But that's not a great user experience. You want to keep the user in the context of your application. So the best way to do that is to embed a web view directly into your application. So now, again, this is three lines of code to embed a web view directly in your application or actually zero lines of code if you do it from Interface Builder. So here we have an embedded web view.

But where this really gets interesting now is that your native application can interact with this web view. You can actually call JavaScript functions within the context of this web page, or you can load your own JavaScripts or create your JavaScripts on the fly and kind of inject them into this web page, and they will have full access to the complete DOM over here. So, for instance, I want to go ahead and change the style sheet from underneath this web page. Well, it's just two more lines of code.

I go ahead and I load my JavaScript, and I call one API to have it evaluate within the context of that page, and it will switch the CSS style sheet. So we've got a great sample associated with this session as kind of giving you a good head start on integrating your web applications with your native applications called Style Switcher.

And I also wanted to mention that it is possible to place things like buttons within your web page, and then when you click on that button, it can actually affect how your native application behaves. So if I placed a take picture button in my web page, I can click on that, my native application can detect that, and then take a picture using the UI image picker, for instance. So all that information is available with the sample code.

Okay, so now we've covered all these technologies. It's been kind of a whirlwind technology tour. And now the question is, how do you write an iPhone application from scratch? Well, I think maybe you've heard about that $100 million iFund and you're thinking, I'm going to come to this session, I'm going to learn how I can grab a piece of that $100 million iFund. And actually, we do have a session on the iFund later on this week. I believe it's on Thursday.

So I think it all starts out with an idea. You have a great idea. You want to do a little bit of research, see if it's feasible, see if there's any sample code you can leverage, see the reference material, the documentation. And I actually have a really good idea, and it's going to make me rich.

So let's go ahead and see what that idea is. I have this idea that I'm going to go ahead and make tutorials. This is going to be a little native application, and I'm going to teach different things like foreign languages or teach people how to write iPhone applications. And I'm going to put them for sale.

On the iTunes Music Store. And the way writing any iPhone application starts is by storyboarding the application. They're always going to take multiple screenfuls of data. So if you were to look in my office right now, you'd see tons of these little printouts of iPhones lying around my desk, and you'd see these little stick figures drawn all over them.

And the idea is, on my main screen, I'm going to want some sort of a title, tutor player, and I'm going to put a play button there. And when the user clicks the play button, I want to go ahead and launch another screen, and that's going to show my tutorial.

And I'm going to provide all these controls on it so that the user can rewind a little bit in case they missed something. So just by looking at this, I can think like, OK, two screens, two controllers. That's what I'm going to need to do. So let's go ahead and walk through the steps of what actually it takes to write this application.

Excellent. So we're going to go ahead and launch Xcode. First thing we're going to want to do is create a new project. In this case, we're going to create an iPhone application. You can see right off the bat, we've got six different default templates to choose from. If you're going to write an OpenGL game, this template will provide a GL surface for you to render on.

We have some common navigation paradigms, like a tab bar that appears at the bottom or a navigation bar where you're going to drill down and get more detailed information. But in this case, we're just going to create a simple iPhone application, and I'm going to call it Tutor Player.

Save it on my desktop. Great. And what we can see straight off the bat, is that we have a view controller file. So great, it's going to create one for me. And we've got our main file and the app delegate where everything gets kicked off. So let's go ahead and run the application.

says it's running. Oh, no, device. Okay, can we switch over to device? Marianne, do I click this button? I can build it for the simulator. Oh, I'm sorry. Oh, great. Thank you. Okay. So now we see our actual application running on my device, on my own iPhone. Now, it looks pretty simple right now. All I see is a white screen, so it doesn't look too fancy yet.

If I quit the application, my application is right here called Tutor Player, and you can see that it just has a plain white square for an icon. Not too fancy yet, but it's a good starting point. place. So let's go ahead and pop open our view controller. So since we did see that one white screen, I have a good idea that my view controller is going to manage that white screen.

Sorry. Can you guys see now? That was a trick, a little bit magic behind the scenes. Actually, I just have my tutor player view controller.h file open. As you can see, it's derived from the UI view controller. And there's a couple things we want to do. First, we want to add in support to Play Movies. Now, that's not directly in UIKit. That's in a separate framework.

So let me-- So we're going to go ahead and include a separate header file that has a definition for our media player. Now within our view controller, we're going to store an instance to that movie player. And we'll just call it movie player here. And when the user presses that play button, we want it to call one of our action methods to have it actually start playing that movie. We want it to load that movie and start playing that movie. So as you can see here, this IB action keyword again will be parsed from interface builder so it understands that this is a method that can be called.

So now that we've added this header file here, we also have to add the library. So let me open up my frameworks. I'm just going to go ahead and find the UI kit framework, and right above it is our media player framework. We'll go ahead and drag that in.

Okay, so now we've added the path into our Xcode build settings. And while we're adding things into our project file, let's go ahead and add our movie and a special icon that an artist made for us. And we'll go ahead and drag that into the resources folder. and we'll make sure that they're copied into the application itself. Okay, so now we've copied the application icon in there, but we still have to kind of say that this is the picture we want to use for our application icon. And you do that by specifying it in your property list.

You can see that there's a key there called icon file. We'll go ahead and tell it the name of it. Appicon.png. Looks like I spelled it correctly. Let's save that. And you'll also notice that we have two interface builder files associated in our project. We've got the main window, which is going to create the main window, and our two-player view controller nib. So this is the one that's going to be responsible for that white screen that we saw. So let's go ahead and open this one up.

And we see, we just see this white screen here. Great. So far things are as we expected. So in my design, I had a label up on top. Go ahead and parse that. Drag our label in there. One of the nice things about Interface Builder, as you can see, as I drag it from side to side, it'll present these blue guides for me. And these guides are created according to the user interface guidelines. So it knows which controls are next to which controls and how far they should be apart. So we'll go ahead and label this Tutor Player.

Great, but I want to make it kind of center justified so we can do all this from Interface Builder. The font's a little small, so let's go ahead and bump it up to about 46 points. That looks better. And the other thing we had down on our storyboard was a button. So let me go ahead and find a button.

We'll just go ahead and drag a standard round button into our application. I'm going to make it nice and big so the user can't miss it. And we'll call it Play. And again, as we drag this around, you'll see a blue guide appear when it's centered. Perfect. But myself, my phone is black, at least this phone, until maybe my boss buys me one of those new white ones. But the phone is black, so I kind of like my applications to blend in with the rest of the phone.

So we'll go ahead and change the color of our background, of our main screen, and make it black here. But now all of a sudden we can't see our text, so let's change the color of our text, and we'll make it kind of a gray color. But now the button stands out, so we'll set the button color a different way in this case. Just for fun, we're going to go ahead and set the alpha of the button, so it's going to blend in with whatever background we have.

Okay, so the user interface looks pretty good, but there's still one more thing we have to do. When the user clicks the play button, we want it to call that start action method that we defined in our view controller's header file. So in order to do that, we can drag a connection from the play button to our controller.

So by holding down the control key, we'll drag the connection to the file's owner and click on the start action. Now file's owner really just represents the object that loaded this interface file, and in this case, it's our view controller. So let's go ahead and save this. Go back to Xcode, and let's find our files.

Okay, so we have already updated our header file to contain the correct instance variables and methods here. Now let's go ahead and write the methods that we need to go ahead and find this movie, load it into memory, maybe we want to play the movie in landscape mode, and add all those controls.

So let's see what's involved with adding a new technology to our application. Deric Horn, Larry Coopet Well, again, it's just one short little method here. All we're going to do in the first line is get the path to our movie file. It's an MPEG-4 file. Convert that file path into a URL.

And because movie player is an instance variable, the first time we run through this start action method, we have to initialize it. So we'll go ahead and ask it to allocate itself and initialize itself. And then once we've done that, all we do is ask the movie player to play. It's that easy. So now let's go ahead and build and go.

The build happened pretty quick. It takes just a minute to copy all those resources, and it's a pretty big movie. So it takes a little bit of time to copy it over the tether onto the iPhone, but let's go ahead and look at the iPhone at this point.

Okay. It's launching our application. And there we go. A little bit out of focus, but there you go. We see the user interface that we designed here, the title along with the play button, and when we go ahead and touch on the play button, We can now see the movie that's playing.

If we tap again, all those standard controls come up that we'd expect. We'll hit the pause button to pause it. When we're done, we click the done button and it goes back to our main screen. Thank you. And finally, when we quit the application, you can see we now have a nice little icon over there for the Tutor Player application.

So again, the sample code for this application, it was pretty simple, but it is available for you and associated with this session. So as you saw, adding new technologies to your applications is really pretty easy, but you are inevitably going to run into problems. And when you do, here's some good advice for you.

One of them is when you run into something in source code that you don't completely understand, you can always option double-click on it, and that will bring up the reference library. So that will tell you detailed information about that method call, as well as kind of the broader picture of the technology.

If you're feeling a little bit more confident, you can command double-click on it, and it will bring up the header file with that exact definition. So I always learn through looking at sample code, and we have some sample code associated with this session and also associated with a number of other sessions here at WWDC, but there's really a wealth of sample code available at developer.apple.com.

So like I said, whether you're doing iPhone Development or Mac OS X Development, about 90% of those concepts are exactly the same. And the book that has really become almost the textbook and set the standard for Mac OS X Development is Cocoa Programming for Mac OS X by Aaron Hillegas. The third edition just came out a few weeks ago, and it also includes the latest Leopard technologies and tools involved with that. So I highly encourage you to buy this book, read it, and go through the examples.

And lastly, WWDC. We've got a number of great technical sessions, but what you may not have heard so much about are the labs on the first floor. The labs are really valuable to help you get up and started. And a lot of the time, you're going to be working one-on-one with an engineer, and that could be the engineer that wrote this technology.

and I also encourage you to take advantage of the social aspects of WWDC. It's a great place to match names with faces, do some networking. We have a few events planned. I know in a few minutes we've got an event upstairs for the WWDC reception. We've got the WWDC bash on Thursday, which is a lot of fun. We always get a good band out there.

So for those of you that are new to the platform, I encourage you to go to a couple sessions. Again, the iPhone Application Development Fundamentals session is tomorrow at 9:00 in the morning. Getting Started with Objective C: Migrating from Other Languages is tomorrow at 2:00. And Cocoa Fundamentals is tomorrow at 5:00. And we also have a couple labs associated with this session that we gave today, and those are Tuesday at 2:00 and Thursday at 2:00. So in summary, I just have a few takeaway points for you. One, view controllers are a fundamental concept in your iPhone development.

Integrating new technologies into your application really is as easy as one, two, three. And finally, this stuff is fun. I mean, I want you guys to go back to your hotel rooms and write a little iPhone application, and I challenge you that when your own user interface comes up on your own iPhone, I challenge you not to crack a smile at that point. It really is fun. So thank you very much. If you guys have any questions, thank you.