Creating Content With iAd JS, Part 2

Session 511 WWDC 2010

Learn to use the iAd JS framework to create rich ad content for iPhone OS applications. See how iAd JS uses the latest web technologies like HTML5 and CSS3, and learn to leverage the iAd JS class structure and built-in controls to deliver high-performance ad content. Understand the basic principles of this framework, and learn to extend iAd JS to make your own custom controls.

Antoine Quint: I'm one of the software engineers working on iAd JS and we're all part of the iOS Apps and Framework team and this is part 2 of our session on creating content with iAd JS and we're going to focus only on the iAd JS Framework today.

Dean did a very good job at covering how you actually build ad content structure and all that.

We're really refocusing on the development and technologies here.

So there are 4 things we're going to talk about.

First, I want to share a little bit, what our motivations and objectives were when we're building iAd JS.

Then we'll discuss some of the few JavaScript enhancements we made for core programming features.

Then we'll discuss the most important parts, which is how you deal with using controls, the things that you actually show on display and interact with.

And we'll wrap up and extend what Dean was talking about in the first part and go in depth about view controllers.

How they work, their lifecycle and what value they provide to your ad.

It is important if you're here that you know and understand the roles and the features of the various web technologies we'll be discussing today.

So things like HTML, CSS, JavaScript and the DOM APIs.

It also helps if you have familiarity with UIKit.

In fact, if you're a native app developer, I think this talk will be very good for you as well.

You'll be able to pick up on the web programming part of it.

So let's talk about what we did with iAd JS.

We sort of looked at iAd and instantly we knew that what we need to provide is a way to convey great emotion through the ad for the advertisers and also which you engage with the interactivity with the brand contents that the user can really interact with the ad.

And we try to translate that in terms of technology to know what we need to address.

And I think we came up with 4 distinctive areas.

The first one is media playback and that's really important for the emotion.

A great video will convey so much emotion, which is maybe hard to convey in machine code.

Then the advertisers probably are showing off a strong brand and these come with you know rich graphics.

They want to have the full extent of what they can do in Photoshop, stuff like that and translate that into their ad.

And to really bring a little bit more of emotion to that, we want to add motion to those graphics.

That's I think really key and that makes the graphics become just another form of media within your page along with audio and video.

And finally, for interactivity, because we're on iPhone, the key to the iPhone experience, what makes it stand out among all other computer products is the multi-touch interface and how fast a response it is.

So these are the 4 components that we identify that the core features or the core things we're trying to do with iAd JS.

And to me, if I was trying to summarize that with a single well, two words, it will be Rich Media.

This is the 4 components for a rich media experience.

In a rich media experience translates in term of technology to HTML5.

The HTML is kind of a buzzword now.

HTML5 has features and et cetera, but it's really just a set of technologies that we've talked about nowadays.

And all these technologies are key features in WebKit on iPhone.

So for example, HTML5 provides audio and video.

The slides you integrate media in your web page just along with any kind of web content.

Just like you would deal with an image, you can deal with audio and video, overlay things scripted with the DOM and JavaScript, et cetera.

First class citizens doing webpage.

Of course we have CSS3 and they've been some great talks this week by some of our colleagues discussing CSS effects using gradients, reflections, masks, et cetera, but I think 3 core CSS3 technologies that are worth highlighting are first, Transforms, lets you transform any part of your web page both in 2D and 3D to re-bring dramatic effects on top of your rich graphics.

And I think Transforms ties in fantastically with Transitions, which lets you go from one state to the other with a nice implicit animation.

You're just saying, here's my start value, here's my end value, just do something pretty.

And when you combine this with 3D effects and I think Dean showed some interesting demos of that in the first session, you really are building tremendous experiences.

There should be a little bit more control over your transitions.

You need special key frames in the middle of the animation.

When you can use CSS animations, we'll give you the full control over the animation that's being performed for you by WebKit.

And as far as interactivity is concerned, I said so, what really matters is multi-touch.

And WebKit on iPhone provides multi-touch events.

They're just special DOM events.

Just like you would deal with mouse on the desktop, you can deal with multi-touch directly on your phone.

But what makes these technologies stand out specifically on iPhone is how well they are integrated into the hardware so that we have tremendous performance and we fully integrate with GPU acceleration.

That means you can use all of these features and get incredible performance from something that just fits in the palm of your hand.

And I think that really amazes me still today.

So that's HTML5, the core of our rich media experience on iPhone.

But I've used the term rich media but it's just, you know one it's kind of a straw man.

It's just one term we can use to characterize what we're trying to do with ads in iAd.

But if you're a native ad developer, you're probably looking at this and thinking, these are more like mini applications, mini apps.

And if you're thinking of apps, you're not really thinking about HTML5 primarily maybe.

You're thinking maybe more about Cocoa Touch.

You're thinking about UIKit.

You're thinking about table views, scrolling components, really rich dynamic user interfaces that come built-in where you have little code to write.

And that's exactly what we're trying to do with iAd JS.

We're trying to combine rich media and mini apps or rather HTML5 and UIKit into one seamless integration.

So that's what we're trying to do with iAd JS.

The first thing we really want is to make it so easy for you to write these really rich ads.

We want to streamline the creation of those rich ads and that's the core value of iAd JS, is make things a lot simpler for you.

The second thing we want is to ensure that we code the best practices so that we leverage as much of the high performance that WebKit on iPhone provides, this hardware acceleration.

You don't really have to know all that much about how it works to get the most performance by using iAd JS.

So some of the core features we baked into the framework we're going to go in depth about this is first, for the user experience, it's key that we have a design that's as close to what we do in native code.

So we're actually looking at UIKit and we ripped completely the design and its features and re-implement all that in JavaScript.

And because we're in the web technologies world, it's HTML5, it's CSS.

That's not really an imperative programming model.

This is declarative.

You're just really writing out things that should happen but you're not really writing code as such.

We want to combine that with the UIKit foundation, which is something that's pretty novel.

And finally, those as we're building a recombination of strains, they're little modules.

So we want to make that modular architecture is at the core of iAd JS so that we can put things together incrementally when we put things on display and we'll get back to that much later in this talk when we deal with view controllers.

And how we did that is by using the same technologies you'll be using when altering content 100 percent web standards.

We haven't used a single line of native code to provide all this functionality to you.

In fact, any of you if you had time and willingness, you can actually write this all yourself.

We're just using HTML5, CSS, and JavaScript.

All open standards, all documented, all for you, so we're dealing at the same level as you are so we know that this is the best integration we can provide inside of web content.

So that is my introduction to iAd JS.

Now let's talk about some of the core JavaScript enhancements we made.

And I want to talk about two things, ADClass and ADObject.

I feel bad about this slide because it starts off JavaScript limitations.

Well, it turns out JavaScript is amazing.

I live everyday in JavaScript.

I write JavaScript all day long and actually love it.

I think their port type or this port type concept of programming is fantastic.

It's so rich and dynamic.

You can insert code.

It's just completely amazing.

It's so flexible.

Someone loves JavaScript.

But it has some limitations.

And these are actually not limitations even in JavaScript.

They're more at the syntax level.

Things you'd want to do a bit easier and these things are for example inheritance.

There is no explicit support for traditional inheritance in JavaScript.

What I mean by that is there's no clear relationship between a class or a superclass.

Even the concept of class is sort of loose in JavaScript.

And there's no super keyword like you would have in Objective-C so you can get to the superclasses implementation of a method.

Nothing that we don't have in JavaScript, which is completely pervasive throughout UIKit is the concept of property synthesis.

That is a JavaScript property which is you're just wrapping a complex piece of code that'll be running in the background so that you have a nice expressive API using properties but you're really running methods.

And there's no built-in support in the syntax of JavaScript for that.

So that's another area that we'd like to target.

And finally to combine with the property synthesis, there's another great mechanism in Objective-C, which lets you it's called key value coding, which lets you run callbacks based on when it probably changes on another object.

That's the kind of stuff that JavaScript doesn't give you for free with a couple lines of code.

You have to do a bit more.

So we want to address those 3 areas with iAd JS.

And the way we do that is with a load of syntactic shooter.

So let's look at some of those Core JavaScript enhancements and how they work.

The first thing you've got to know about is the ADClass Utility.

You might have seen this being used on some of Dean's slide and what it lets you do is to process your class and just make sure the syntactic shooter that we add is actually interpreted and applied to your class in a background magically.

So first thing, for example, you want to do set up inheritance.

Well, inheritance should just be saying, I'm extending this class.

That's all there is to it.

Do whatever it takes to make it happen.

Well, we can do that with superclass property and we'll see about that in a minute.

Same goes for synthesis.

You can just say, here are a list of properties I want to synthesize, they're in array, just make whatever it needs to be done so that they bind to some methods in the background.

And to complement this ADClass Utility, we have a foundation ADObject Class that most if not all of the iAd JS objects extend that tie into ADClass Utility.

For example, what's the point of having inheritance if we don't have a callSuper method.

So we provide that directly in ADObject.

The same goes with synthesized properties.

It'd be great to have notifications happen automatically when you actually update a synthesized property so you can be notified when that property changes.

That's completely automated with synthesis.

Of course, we have APIs for you to do that manually as well but as you opt into synthesis, the notifications happen magically for you in the background.

You don't have to worry about it.

So let's take a concrete example.

Here, I'm creating MyClass.

It's pretty standard code.

I couldn't come up with anything smarter here.

And I want to make sure it extends ADObject.

So that's single line, just say MyClass is superclass is ADObject.

In fact you don't even have to write that line.

By default, when a class is interpreted by ADClass, we assume if there's no explicit superclass it's just a subclass of ADObject.

So you can even imagine this wasn't here.

Then we have to make sure in our constructor that we call whatever the default constructor of ADObject does, it actually sets up a bunch of things for you in the background and you really want to make sure that that ADObject constructor is called.

So here we call callSuper and callSuper no matter if it's a constructor, an instance method, will do all the magic work to make sure it gets to the superclass' implementation of that method and calls it.

You can pass parameters that will return to value.

It does everything you expect from a callSuper type of call.

And here we got just a standard instance method declaration.

There's nothing fancy here.

It's just how you do instance method in JavaScript.

And finally, very important, we need to make sure we process this class to ADClass.

So we just call ADClass with MyClass.

This is just an example of how you can arrange things so that you can, you know it's JavaScript, you can write your code in any way you want to as long as your class is processed through ADClass.

Now let's talk about synthesized properties.

Let's say I want to synthesize a property foo on MyClass.

I set the synthesizedProperties to a list of strings or the name of my properties.

In this case, I only have 1.

You can have as many as you wish.

Just to make things simple, we're dealing with 1 here.

When ADClass processes MyClass, it's connected to two things.

The first thing is it looks for a getFoo method on a prototype.

This is a convention.

If you provide getFoo, that means you have a custom getter and so what we do is we automatically bind any getting of foo.

So for example you have an instance of MyClass and you said .foo on it, this actually calls getFoo in the background.

That lets you compute the value of foo dynamically as the user requests it.

This is like a virtual variable as you will.

If you did not provide a special getter, we assume that all you want to do is actually set the _foo instance variable.

This is another convention.

You'd take the name of your property, in that case foo, add the "_" prefix and that will get set automatically if you do not provide a default getter.

For setting, we do pretty much the same thing.

We look for a setFoo method on our prototype.

If we have it, we bind the setting of foo to setFoo, that means if your user as an instance MyClass and sets .foo on it, whatever value you're setting is actually passed to the setFoo method and it's up to you to deal with that and likely record it into an instance variable as well.

And if you don't do anything again here, we just assign as default to an _foo property.

In fact, you don't need to provide either getters or setter.

You can provide nothing to say, it is a synthesized property and the reason you'd want to do that is because you get automatic notifications being triggered.

So that's even worth doing.

So let's look at how we could provide a custom setter, pretty classic thing for a synthesized property.

So first, we set synthesizedProperties, pass it an array of strings, which are the name of the properties we want to synthesize.

In that case, it's only going to be foo.

Since we are actually not we want to set the real value for foo.

Foo is like a nonexistent property.

It's just going to be bound to our setter.

So we want to make sure we implement a special instance variable or an ivar and add an "_" prefix in the name of the variable so we just set _foo, default value to be 0.

Then all we got to do is implement that setFoo method as a convention set and the name of the property.

And there's a single argument being passed here.

That's actually the new value of foo we're trying to set.

And here you'd really be setting a whole bunch of things, running special code, refreshing, drawing or something.

I don't even know.

What you do what you have to remember is to make sure you keep actually the value of _foo because when the user tries to get foo, since you're now providing a special getter here, it will return _foo automatically.

So for custom getter it's very simple.

The same synthesized property declaration, but here we're just implementing getFoo and returning a variable.

You'll notice here we don't even have an instance variable because likely we don't even have a real property for foo.

We just compute it as we go on the fly when required.

So to tie into synthesis, we have automated property observation.

So let's create an instance of MyClass on a control object and call that property MyObject.

Then we want to be notified whenever foo changes on that object and be called back in the context of a controller.

So we get a pointer to my object, call addPropertyObserver on it.

The first parameter is the name of the property we want to synthesize and the second parameter is the object of the called back whenever that property changes since this is this in this context that means our controller.

So now all we got to do is we have to opt into the contract that tells us to implement handlePropertyChange.

That is the expected callback for whatever object is best as a property handler.

So handlePropertyChange got 2 parameters, first one is observedObject.

The second one is propertyName.

This lets you have a single handler for a bunch of property observer and be able to switch based on the originating object and the originating property name.

Now all we got left to do is to handle the change.

But let's say we actually know exactly what method we want to call back, just a little bit more convenience.

Well you can have a third parameter, which is the string referring to the name of the callback for that specific property change.

So that means we only have to implement fooDidChange and notice here we don't have any parameter because we already know exactly why we're getting that callback and then we can do whatever we want here.

So these were the 3 core JavaScript enhancements we've made and there are not a lot of them.

That just speaks to the value of JavaScript.

We provided first traditional inheritance with the superclass property and callSuper method.

We built in synthesis with the synthesizedProperties completely declaratively, just it's like a here file.

You're just saying, here a bunch of properties I want to be synthesized.

And we automated the property change notifications so that synthesis process.

So these are all the changes we made well extensions if you will we made to JavaScript.

Again, we haven't touched the JavaScript engine.

Within the JavaScript runtime, we've extended these features using simply JavaScript.

Let's talk about views and controls.

That's when you get into the meat of things.

And there are 2 main classes I want to discuss here, ADView and ADControl.

So ADView is just a complete rip on UIView and UIKit.

It provides the same methods, the same properties, the same behavior that breed the intent of what we're trying to do here.

And ADView is just a base class for anything that's going to render on your screen.

When you want to put something on display, you got to make sure there's an ADView and it's actually added to the view hierarchy.

But we're dealing with WAP technologies here.

And if you're familiar with WAP technologies, you know that the concept of rendering is somewhat opaque.

We're really just dealing with a tree of objects, elements and just manipulating them and putting them in different places and stunning them with CSS is what actually renders on screen.

So it's no surprise that ADView, since it is rendering content on the screen, is really just a wrapper for a DOM element.

And that element is what we call the layer.

And that is basically the element that will be the root of the hierarchy of that specific view that will be inserted into the DOM.

We'll look at that in a minute and see what it looks like.

Now let's say you want to contain other views instead of your views.

It's pretty classic.

For example, you have a scroll view and you want to have a bunch of buttons within a scroll view so you can scroll through them.

If we were pending elements directly into the layer, we couldn't actually scroll this content because the scroll view has a lot of different elements.

It has scroll indicators and it has an area that actually scrolls when you touch on it.

That is why we call the hostingLayer.

This is the layer that we want to be containing subviews and et cetera, and we'll look in again I have a little example in a minute.

Something that is really important to us is that we want to make it very easy for you to be dealing with something more complex aspects of rich media content.

And one of these aspects is Transitions.

When they're really complex and you want callbacks and et cetera, it's a lot of work to do on your own.

So we actually build all that directly in ADView.

And on top of that, because you don't really know when your transitions are run in which piece of code, in which run loop, we actually provided transaction system so you can say, here's a transaction that starts.

There may be X number of transitions it completes and all that is going to happen in complete synchronization in your engine.

And finally, there's a special kind of view that gets created automatically for you when you load iAd JS in your content and it basically wraps a view around the body elements and we call that the root view and you can get to it using ADRootView.sharedRoot and that's really the root of your view hierarchy.

If you're familiar with UIKit, it's like the window.

So let's look at building a scroll view with those JavaScript APIs.

First thing we do is we create a variable scroll view and we create a new ADScrollView object.

AD is the prefix you'll see for all the specific two iAd JS JavaScript classes.

We set this position in size so that it's displayed 20 pixels margins on either side and it takes most of the width from the height of the window.

And notice here we have helper little data types like ADPoint and ADSize to make it even more convenient for you to deal with those kinds of geometric properties.

Then we set up some of the call properties of the scroll view.

We're going to turn off vertical scrolling.

We're only interested in horizontal scrolling in that example, I'm sorry, and we want to make sure we don't show any of the scroll indicators either, so we just set that on that.

And then to make sure we actually display the scroll view, we get to point it to our share group and we addSubview, well we just add a scroll view as a subview with a single method call.

So what this does behind the scene is actually generates all this markup.

This is actually pretty simple example but some views are incredibly complex and require a lot of code and you don't want to know about this.

You'll notice here a couple of things.

So the div at the top levels are layered.

You'll see a div with a class hosting layer, that's actually a piece of content that's going to scroll, and this is going to hold all the content.

You'll see all the things that are generated you have nothing to do with.

For example, the scroll indicators.

These are all very private to ADScrollView.

You don't need to know about this.

Why did we have to write so much code?

We're trying to make the best of both HTML and UIKit.

So we've already provided the UIKit part.

But why do I have to write so much JavaScript?

I think if you're a web author, what you really want to do is to be dealing with markup and style with HTML CSS.

And that really builds a case for what we call the declarative approach, the declarative layer that we build on top of those APIs for you to make it super easy to build using controls within just markup.

And there are 2 key points that makes this very compelling.

First is the ease of authoring.

Say you want to style your scroll view.

You want to change the background color, all that kind of stuff.

That's the value of using CSS, right.

It's so easy to style content.

But if you're using an opaque JavaScript class and it generates a bunch of markup, you don't even know what that markup looks like.

In fact, we don't want you to know what that markup looks like because if we want to change that implementation in the future, we don't want you to rely on things that we consider to be private.

So we need to know what the markup structure is and if you were laying out the structure yourself, you know exactly how to style it.

Then it's just good sense to want to separate the logic, which belongs in JavaScript with the content, which belongs in HTML CSS.

And on top of that, it also goes back to performance.

And remember I said one of our primary concerns in iAd JS to make sure things are streaming and we make sure that it's easy for you to get the best performance out of your app.

So if you're dealing with those JavaScript object, they're doing all kinds of manipulation that you don't know about to the DOM tree when you're creating a layer, when you're putting it somewhere.

You don't even know what's going on.

And if you're trying to optimize things, obviously, this is going to it's how you control.

If you have all your markup laid out already, all the CSS created, that's just less time spent rendering, fewer manipulation.

The engine can just deal with that in like one monolithic block and just it's just a lot faster.

So that's the kind of benefits that we get out of a declarative approach.

So let's go back to the code we built.

This looks similar, but it's different.

The first thing you'll notice is we have a body and a class of ADRootView.

That rings a bell.

That reminds me about the sharedRoot, the thing we build automatically with the body.

Well if you're using the declarative layer, this is the entry point.

Having an element with an ADRootView class on it means I'm using the declarative layer and when you process this subtree for any content that has an AD-prefix class so that you can create those rich JavaScript projects that will control those, all those using controls.

So in that case, we're putting down the body, pretty typical example.

You can have it on a subtree elsewhere, that's fine.

So now we need to create a scroll view.

So we set up its class to be ADScrollView, that's just an element.

Having ADRootView on the body will make sure we look at all the children and figure out which one has an ADScrollView class so that we can process it.

Then we want to set the properties of our scroll view.

And we can do that declaratively as well.

No need to write to JavaScript here.

So if you want to throw them out vertical scrolling, we just AD-vertical-scroll-enabled.

And notice here, we're extending HTML attributes.

I was fairly conflicted about that but I think the value of doing this is so great for you as a developer that as long as I think as long as we add an AD-prefix, I think we're in the clear and it's clear enough for you that this is not a core HTML attribute but just an extension specific to iAd JS.

Now what about position and size.

We don't have an ADPosition or an ADSize here.

That's because CSS already does a great job of positioning and sizing things.

We want to integrate as well as possible with the core web technologies.

So instead of having those custom attributes, we actually just look at the styling of your element.

So here we use left, up, right, bottom to actually position it and make its scale to be you know 20 pixels margin on either hand.

And it's not even just about the style attribute here, which is a core HTML attribute.

You can have all this information in CSS style sheets that are loading in the penalty of the element, all that.

We're looking at the computed style when we're trying to figure out the stylistic information related to view and finally, we put in our hostingLayer and we'll just put whatever content we need in there and we'll see about that in demo later on.

You'll notice we don't talk about scroll indicators here.

This will get added to the tree later on.

In fact there's so much that can be added to the tree you don't even want to know about, but that gives you a good way to know what the structure is and so you create all of this using simply markup.

So that was views.

Now let's talk about controls.

And controls are all instances of the ADControl class which is just a subclass of ADView so all the features you know from ADView that's declarative approach, all these APIs and et cetera, this comes for free in ADControl.

It's just an extension of it.

And what they do is that they provide advance and automatic touch tracking.

We're really trying to make it so you don't have to deal with the interaction private so you have control yourself.

We try to do as much as we can on our own.

And the way we do that is we actually extend the set of built-in multi-touch DOM events and add a little bit more granularity to them.

So let's step back and let's see what developing on the desktop.

I'm sure a lot of you are more familiar with desktop web programming and here we're dealing with the mouse.

That's the input method.

So mouse events on the desktop are always related to target element and that makes really easy to program interactivity based on an element.

It's easy to know when the mouse over is onto it and when the mouse leaves it or click on it, super easy.

So we get all these elements, all these events, I'm sorry, which are all related to a specific target element.

So let's focus on iPhone here.

Let's say we're developing a web app for Safari on iPhone.

It has this great multi-touch DOM events.

But these events really only provide you with the raw touches.

You get all the information you need there though.

It's really important.

This is all we really need.

We can tell how many fingers on the screen, where they are, how they're moving, when touch starts and ends and et cetera.

We get this touchstart event when the touch starts, the touchmove when the touch moves and the touchend when it's over.

But we don't actually get the information, the granularity we'd get on the desktop, at least not so easily.

We don't get like the equivalent of mousemove or a mouseout when we're touching over an element or out.

We need to do a little bit of extra work and that's exactly what ADControl does for you for free.

You don't have to worry about any of these.

And so what we do is that we introduce another set of control events that are specific to iAd JS.

And that's all clean and kosher because DOM events were built so that ostensibly you can create your own events and dispatch them.

It's an open process.

So it completely ties in to the good practices of web development.

So what controls do is they basically listen to all the touches, analyze them and trigger additional touch events, which are a lot more informative about what's going on.

So for example, you can listen to TouchDragEnter.

That means within a touch, we started touching over a given element.

But when we exit that element, we get TouchDragExit.

TouchUpInside as well when we've tapped an element, this kind of events.

And we got a lot more.

And you notice they're all prefixed with control so you know exactly they're related to control to ADControl.

And I'd like to refer you to a great session that happened yesterday.

You'll be able to download on a video later on which were all about detecting touch and gestures in webpages on iPhone OS.

It was great and I really urge you to look into that in greater depth.

So now let's talk about actions.

And again, we're dealing here with DOM events.

Control is here to react to user interaction exactly, right.

So in UIKit, the way to be responding to an action on a control is usually with the action-target mechanism.

That's a great mechanism but it's one to one.

There's nothing bad with that specifically but in the context of web development, you're dealing with an interaction with the one-to-many process.

So many different observers can listen to a mouse even on a given element and they don't have to worry about what each other do.

You can add as many as you want.

So we want to do the exact same thing in our case for actions.

So when a control that you changes, for example, say you have the slider and you're dragging it around the screen, whenever that slider's position changes, it will trigger a control that you change event that lets you know that control scroll value has changed and we do that using DOM events.

So it's a single API for any kind of interaction tracking in your ad.

So let's talk a little bit about DOM event handling.

Let's say we have our slider and want to be told whenever the control that you changes, so we use addEventListener.

Remember it's the exact same API we use with just the DOM and here even though it's an ADControl instance we can use that same API.

We make it that easy.

What we do is we actually forward that event listener to that controls layer.

So first the parameter is going to be the name of the event that we're interested in so it's control that you change and the second object is going to be handler, callback or whatever, and then probably that just says we're not using the capture phase.

That's the detail you don't really need to worry about.

So let's consider your user drags the slider around the screen and the control that you changes even start firing on that slider.

So 2 things that may happen here.

A, the handler parameter, the second parameter to addEventListener is a function, and what happens here is that we get a pointer to that function and we just make a callback.

We don't even actually do that.

WebKit does that for you.

And there's no context here.

It doesn't even know what this it's just a function.

So, it just calls it in a global context of the JavaScript program environment which is Window.

When you're dealing the interactions, pretty likely that you're doing that in the context of a controller.

You have an object that needs to respond to that action so it can do something else with, you know, with respect to certain properties that are specific to that controller object.

So, in that case, what you want to do is make sure that the handler parameter is actually an object.

And what that means is that you enter in a contract that you have to implement a handle event method on that object and that gets called back with the context being your handler.

So, if you have a controller object, you just need to implement controller.handleevent, for example, and it gets called and that this object, the context object is just your controller.

And that's really the best practice.

That's I would argue in 100 percent of cases that's what you want to do.

So, controls are various states, selected, enabled or disabled, and highlighted.

I want to talk a little bit about highlighted because this ties into this touch tracking I was talking about.

Traditionally, you'd say OK, I want to react I want to change the state of my controller and my custom controller based on its being highlighted or not so you'd be subclassing ADControl and overwriting the said highlighted method for example.

Well, that's one way to do it and that is fine.

But we wanted to we want to make it a bit easier for you and what we're going to do is we're going to synchronize the highlighted state with touch tracking so we obviously do that behind the scene but on top of that, we're going to make sure that change of state is reflected directly in CSS.

So let's look at what that means.

We're actually going to build a custom control in a single slide.

Let's start with a markup.

Just like we can instantiate a view, we can instantiate an ADControl and in that case, we also want to make sure it's our custom control so we add another custom name on top of that.

You notice we don't have ADView on here even though it inherits from that.

We actually, when we build in the declarative approach, we automatically add the classes as needed when we're parsing the attribute, the elements.

So, you don't have to worry about the superclasses of your element.

Next one is styling.

So the first thing we do is to create a CSS selector that will match both the ADControl class and MyClass control.

So, they will match our development right here.

We want to make sure we only match controls that are accustomed to our application.

So, here I do very basic styling.

You can do so much with these obviously.

You can use CSS effects to full extent to make awesome looking bonds of controls.

So, in that case, we have a background color to be white and color to be red.

And what we want to do is we want to invert that when the control is highlighted, when the user has a finger on top of that element.

So to do that, I had just, actually just add this CSS class name called highlighted on your element whenever it is highlighted so you don't need a subclass.

All you got to do is write another more specific CSS selector that looks into the highlighted class and just invert the values of background color and color to give it that highlighted state.

No need to write any JavaScript here for your custom control.

You can do it all in markup in pure CSS.

So, let's look at some code to see how we can make all that happen and what we're doing here is we're building a full gallery for my world renowned cat.

And it's like the weather app.

So we have the scroll view that will snap to different pages and at the bottom of the screen, we'll have a page control.

These 4 little dots that are synchronized to the scroll view and that lets us go from one page to the other by a tap of the finger as opposed to dragging.

OK. So, we're going to get started by building some markup.

We've already mostly done that.

We set up our root view to be our body, easy enough, then we'll start processing all the subviews.

So, for example, the scroll view.

You notice here one new property which is paging enabled.

That says that we have to snap in pages' worth of content while we're scrolling through that scroll view.

Again, we do that all magically for you.

You don't have to worry about the touch tracking here to make that work.

We do it all for you.

Then we want to put in some content into our hostingLayer.

So, in that case, we'll just have 4 images, one for each page of our with our cat's picture.

Then we have to build a page control, which is new.

So, class ADPageControl, simple enough.

Set the number of pages to be 4, that's the number of images we're actually dealing with and something that I may not advocate but I think is really worth telling to re-show you the full extent of the declarative layer is to put in an inline event handler.

So, if you're dealing with desktop content with web content, you're likely have seen people putting like on mouseover, on mousemove or whatever, event listeners directly on an element and we can do the exact same thing even though we're dealing with custom events.

So, here we're setting up a special event handler for control that you've changed.

All we need to do is prefix 80-on to the name of our events and we can automatically create an event listener for that declaratively.

So, here that means later on we have to implement controllers method, page control that you changed.

OK. Now, let's lay this out.

Take a scroll view, match it with CSS, set its width, set its height to be just little low gap at the bottom for our page control, which is going to be laid up flush with its subproperty in width and height again.

It's easy.

Now, we need to lay out the scrollable content.

So, first of all, we'll get a hosting layer.

You might want to have a more specific selector here of course, but you know we'll just use the global ones to make the code easy.

I want to make sure it's 4 times the size of a single page.

So, 4 times 320 pixels is 1280 and we want to make sure to lay out each image to have a little bit margin on the right, except for the last one.

No margin there.

We want to snap to the last image really nicely.

So, now we have to write a little bit of code but not too much.

So, we want to get started whenever the DOM content is loaded.

That means the DOM is fully interactive and ready for us to interact and that means iAd JS has done all its work and set up all the views and controls that are already laid out in the content using markup.

So, we call that init method just like main in your native code and we called another init method on a controller object.

That's the object that'll be responsible for dealing with all the interaction within little mini apps.

So, we're going to point at your page control and scroll view because we want to connect those two together and we have to do a little work to bind them together.

So, we're going to point at your sharedRoot and we want to ask our sharedRoot, "Give me all the page controls so that I can get one that's interesting."

So, we provide these special properties that are called collection accessors.

They are automatically generated based on what content is within that subview.

So, if you ask for page control, they'll give you all the page controls under that sharedRoot.

So, we get the first one, we only have one, so it's pretty easy, we'll do the same for scroll view.

And for scroll view, we want to be told whenever we snap to a new page by dragging the scroll view so we implement a delegate property here.

And if you're familiar with UIKit, you know exactly what this is.

If you're not, I'm going to summarize real quick.

A delegate is an object that's supporting your element and extends and pipes into its interaction flow.

So, here we're setting our controller object, this, to be our scroll view's delegate.

That means that controller will receive callback that it can implement that will tell that object what's going on with the scroll view.

So, let's actually just do that.

Let's implement some of that scroll view delegation.

So, there are 2 ways you can snap to a page using a scroll view with paging enabled.

The first one is you may start to drag the scroll view, stop for a little bit and release.

You want to snap to a page with nice little animation.

There was no momentum here.

That's another type of interaction.

So, for that first type, we want to implement the scrollViewDidEndScrollingAnimation delegate, very descriptive.

And when that happens, we want to make sure we sync the page control to the scroll view using that method.

We'll have to implement that later.

Now, let's listen to the other delegate.

That one happens when you do a nice little flick, there's momentum so we do nice little friction-based deceleration so that it snaps nicely to the next page with the speed of your gesture.

So, again we call the same method to sync the control page to scroll view the page control, I'm sorry.

So, what we do here is we do 2 simple things.

We get the content offset of our scroll view, that's the amount of pixels, the content within the scroll view has been scrolled and we divide that by the width of the scroll view.

That's the page's worth of content.

Doing that, we actually get the page number that we are on now.

Just make sure we round it so there's no rounding error and we just design it to page control's current page.

That's all there is to do.

That alone ensures that our scroll view is bound to our I'm sorry that our page control is bound to the scroll view.

Whenever we interact with a scroll view, the page control is updated in sync.

Now, let's do the other way around.

You remember that in a markup, we already bound to the control that you change event on a page control.

That event triggers whenever the current page property changes so we have to look at the current page, multiply that by the width and we get the new X-property that we need to assign to the content offset of the scroll view.

Current page has just changed in there the instance so exactly what we want to be looking at and all we got to do is set the ContentOffsetAnimated, get a point with the X-coordinate and just pass through as the animated flag.

They'll make sure our scroll view nicely animates with the single method call.

And that's what we did.

We did a mini app in a very small amount of code.

So, let me summarize using controls.

I think the key thing, which is one thing that I remember today is that we have these 2 techniques.

We have this rich API based on UIKit that lets you have full programming control and how you create, lay out and et cetera, all these great views and controls.

But on top of that, there's a declarative layer that makes it super easy for you to build all this with HTML CSS.

There's a lot more than that.

There's a lot more than what we've seen.

You've seen from this session there's a bunch of different views and control that come for free by just using iAd JS.

OK. So, we've seen like a scroll view which is obviously a big deal but we do so much more.

We do sliders, we do carousel views, which are accustomed to iAd JS.

We don't even have the in UIKit.

We have the nice little 3D rotating carousels that Steve showed in the Toy Story demo back in April.

We have rating control.

We have start control.

We got all these cool stuff.

We even do color flow, which sounds amazing but we just do that and you get it for free by just laying out of HTML in your page.

It's pretty awesome.

So, that was views and control.

Now I'd like to wrap this up and discuss view controllers and this is all about the ADViewController class.

So, let's go back to the demo that Dean was building.

This is our ad and it just looks like a webpage.

Well, it is.

I mean, an ad is just a web view layered on top of your application with interactive content.

If you're thinking about web content, you're thinking about a webpage.

A webpage is just, you know, a big block of markup and some stuff and if you want to do interactivity, you can just double the visibility of different elements in the tree and that, you know, that's awesome.

Well, if you look at that ad you might actually think that this is not really 1 page but is several pages.

We have the menu, we have the photos, we have the maps and if you just start thinking from an architectural point of view, it's important that the interactivity you're dealing with are specific to each of the screens.

The menu doesn't need to know about what goes on within the map, the annotations or where the usual occasion is.

It's only the map's job to figure out what's going on here and make sure the interactivity is correct.

This is really a modular architecture.

These are all little modules, screens, pages, whatever you want to call them.

I want to make sure we address that in iAd JS and there are some important performance considerations taken into account that really makes the case for the architecture.

The first one is if you're building an ad and you load a lot of content.

Let's say you load all that content upfront, all those images, all those script, all those styles, all of that.

That's a lot of network content to get and that may just take a long time to download your ad and that's not good.

The user taps on the banner and he wants to be able to see the content as soon as possible.

It's not just about that.

It's also if you have a lot of stuff even if it's loaded quick and, you know, fast enough, you have a lot of content in your DOM tree and this may have very bad implications from rendering performance.

I mean the iPhone is amazing but you know there's only so much a device can do.

So, you want to make sure you're not dealing with too much of that stuff as well.

So, they mix the case where 2 core features that we want to add to make things easy for you.

The first one, we want to make sure incremental download of your ad's content is really easy and the second one is we want to make incremental display of your ad just as easy.

So, let's look at the implication of a modular architecture on view controllers.

The first thing we want to do is we want to obstruct the loading of all these resources, all these styles, all these scripts, all these images so you don't have to do this work and make sure this just happens automatically.

I want to make sure that we add and remove views or DOM elements if you will only as needed so that we only have a minimal amount of content in the DOM tree at any time to just render what needs to be rendered on screen.

So, let's look at how a view controller is structured, the anatomy of view controller.

It's really like a bundle of resources for your page of your screen or your module.

It all starts with the JavaScript file which is your view controller.

That's the programming logic.

That's where everything happens.

Usually, you probably have that link from the original webpage right away.

But you can inject it at anytime.

That is no problem.

JavaScript is dynamic in that way.

What the view controller does is going to point to a bunch of resources.

It can point, for example, for HTML fragment file, which will just be your views content.

It can point to a series of style sheets.

It can use several style sheets.

A good way to build a modular approach in web content is to separate style sheets in different box so you can link them at anyone time to have the minimal amount of style needed.

And you might have a bunch of images that you want to have pre-loaded when the view comes on the screen so that there's no empty gaps on the screen that load on that layer.

So, we have to make that easy for you and we do that using just a single simple configuration.

Again, we're trying to make like this declarative type of id comes to life even in JavaScript.

So the first thing we do, we implement our menu controller here.

We make it super class to be ADViewController.

We want to have all the great features of the ADViewController come for free so we make sure we just extend it.

Then we call the default constructor of ADViewController with the configuration object and we want to describe the various files that we're interested in.

So we're going to talk about the content view.

We want a given style sheet.

It could be many to different style sheets.

We want a bunch of images to be pre-loaded with the rest of the content.

So, let's look at what happens behind the scenes.

So, we have a phone.

Let's pretend it has an ad loaded into it.

There's a view controller on one end and that view controller is a delegate that's going to get message as the view controller's view is being loaded.

So you can easily have another object be monitoring, the loading of a given view controller.

So, let's consider now your user interacts with the phone and wants to put that view controller's view on screen.

Well, that means we need to start creating a view for it.

Yeah, first.

The view controller manages a view so as soon as you need it, you need to get it back.

You notice here we're not actually getting the content view.

We're just getting a view.

We need to give that back so if the user wants to put the view on the screen right away, you can do that.

It won't have the content, but that will come later, you'll see.

So, it gets a viewDidLoad message onto its view controller class and that says that the process is starting.

So, a loading delegate is getting another delegate method that says that loading is starting as well.

So, that's one we might want to start putting like a little animation spinner say, well, we're loading stuff in background.

That's when a view controller automatically starts sending all those requests to the background using XMLHttpRequest.

You don't have to worry about this.

This just happens for free and the server assembles those files and starts sending them down to our device.

So, we're going to get all those files one by one.

We don't even know which order and you don't need to worry about that but you'll get notifications in your loading delegate as that happens.

It tells you well, here, I've got a new file.

Here it is, here's its URL and that is very useful.

So, if you want to put like a little progress bar you can have it fill in gradually as you get those messages.

So, we're getting towards the end of our content loading here.

What we need now is one last image and we'll be ready to set the whole view up.

Here we go.

So now we start with one last message to our delegate saying we've loaded a required file.

And now we can start doing something interesting.

We tell the loading delegate one last time we finished loading file so you can even listen to just the start and the end.

You don't have to worry about the ones that are coming for each individual file.

And now we get another message just like we have viewDidLoad that says contentViewDidLoad.

What that means is that we've done an immense amount of work for you behind the scenes.

We've actually taken the HTML, we've parsed it, we get in the string, we've created the DOM elements out of that, we've created a view with the DOM elements.

We've done all that automatically for free for you and we've created that content view that we just put into our existing view.

We've also taken the style sheets, put in the tree, loaded it up and made sure all the images were ready to be displayed.

We've done all that for you automatically.

So, that's it.

Our loading mechanism is all done.

So, if we go back to the configuration that we had, we also had this ID property.

This ID property is short but it's very, very, very significant and meaningful.

What it does is it just provides a unique identifier for view controller so you can identify this view controller among all the other view controllers that you have.

You may have a bunch of screens in your ad and you want to get the pointers to that specific one from anywhere else.

Well, because we're given an ID of menu, we can just look into the ADViewController that extends its array and that compiles all the instances of ADViewController out there and just using the name of the the ID of our view controller, we can get a pointer to it.

So, in that case just .menu.

Very simple.

But it has more added values and it really again ties into these declarative features.

It makes it so easy, for example, to match CSS.

Remember when we loaded our view controller we created a view automatically to host all of our content.

Well, you didn't create that view.

You didn't even put a class name on it.

You could do that in code actually if you wanted but, you know, you don't want to do extra work when it's not needed.

Because behind the scenes we make sure we reflect that ID property of your view controller on the content view and the view.

So, your content view, if it doesn't already have an ID attribute, will have an ID attribute as its menu.

And the view that contains the content view that was created automatically for you will use that same ID and add a -container suffix to it.

So, you can start writing styles for content that you didn't even create because we just tell you here's the ID it's going to be.

That's all automated for you.

We talked a lot about coding features but a lot of more declarative features about view controller.

Again, we want to make sure we have really great integration with web technologies.

And the reason for that is we want to add more convenience for you to be dealing with these view controllers and interactivity.

So, let's look at some common programming tasks when dealing with view controllers.

A, you're dealing with a view and a view's content so you'll probably want to reference to different objects that you want to update as you go along.

Then you also really wanted to react to the interaction within your views so the user taps on a button, updates the label of another object that you'll get a reference in step 1.

Well, that's really kind of common.

And the third thing is one of the design pattern that we think is going to be pervasive throughout ads is the transitions between various screens, the various modules.

So, these are a fair amount of code and some are really easy but repetitive and some are really hard like managing a transition is a lot of work.

So we're going to address this with 3 features.

The first one is outlets.

That's the same terminology we use in Objective-C coding and what it does is it automatically creates references to views or elements in your content view.

Notice here I say view and element because we treat both elements that are managed by an ADView and elements that are just regular HTML elements the same.

And you can point to either of those using the same technique.

And that technique is using AD-outlet attribute, just give it a name and that makes it easy for you to get a reference to that object on the outlets property of your view controller.

So you can do this.outlets.title and you get a pointer to that element.

You don't need to do get on with ID.

You don't need to do any of that.

In fact you've noticed here, we don't even use the ID attribute.

That would be a good way to do things except we're dealing again with a modular architecture.

Even though all these things will end up in the same document at some point, to make sure there's not any ID clashing which is supposed to be unique to the whole document.

We want to make sure we have an ID that may be repeated but just specific to that one view controller.

So let's talk about actions.

It would be great if you could bind actions to your view controller just as easily.

Well we provide a way to do that.

We automatically register callback in the context of a view's view controller by just adding one attribute, the AD-action attribute.

And by saying this that means my view controller needs to implement a playAudio method and that gets called back automatically in the context of view controller.

You don't have to worry about getting a reference to it.

This is all done automatically.

All you got to do is focus on implementing that method, that's it.

Let's talk about transitions.

Transitions are like a specific type of actions.

So, we've already simplified things for you.

You can get pointed to your elements and you can know when an element has actually been activated.

So at that point you should be able to just trigger transition using JavaScript.

Well, that's not what we want you to do.

It's so pervasive in what we think people are going to build at, that we want to make it super easy.

So since our view controllers already have IDs, it should be easy to say well, this should just transition to that view controller.

And we just do that using the AD-transition-to attribute.

You can just give the ID of a controller, for example, maps and will automatically transition to that element.

And this abstracts so many things.

First, it abstracts the loading of the view controller.

We load the view controller's content dynamically when are needed so we don't spend too much time on loading the app.

And when we do transition we got to do so much.

We got to load that content.

We got to add its view when it's ready.

We need to make sure we have the transitions happen in sync for both of them and then when it's done, we need to remove the object controller's view, et cetera.

And it's just a lot of work to trigger all the notifications.

You don't want to deal with that.

So we do that all automatically for you.

So to summarize the core features of view controller is first of all the automatic loading of all the screen resources as if they were a single bundle loaded through a network.

You don't have to worry about any HTTP connection.

It's all done for you.

And then when you're actually building your scene, this is all done incrementally with automated transitions for a great effect.

We've gone further and just standardized even like petty little common coding test to make it even easier for you so, and we've done all that very easily with more declarative features so you can write less code and create less errors in your code.

So that's it.

That was our 4 key points today.

We started discussing the motivation of iAd JS, the mix of rich media and mini apps, HTML5 and UIKit.

Some of the core JavaScript enhancements we've made should make inheritance easier, property synthesis, and et cetera.

Dealing with views and control, putting things on screen, both with a rich JavaScript API and a super simple declarative approach with CSS and HTML.

And finally, dealing with view controllers, which we have just talked about.

I want to go back to the original slide when we were discussing rich media and mini apps.

Really this framework is all about this, revealing all this with web technologies, HTML5 and UIKit, 100 percent web standards coming together to build iAd JS.

Thank you.

[ Applause ]

So for more information, you can contact our Evangelist Vicki Murley.

You can download the iAdDeveloper Package, you can download our documentation, which is still a work in progress but we're working hard to make sure everything that's rich framework is documented.

And we're building some forums for you to discuss iAd JS on.

There were some great sessions.

Dean was just here before me giving me a more practical approach at how to build ads.

We had a session about integrating ads with iAd and it's being repeated tomorrow.

There are a bunch of great sessions this week.

Some being repeated tomorrow morning about audio and video, CSS effects, HTML5, Touch Events, and et cetera.

Apple, Inc. AAPL
1 Infinite Loop Cupertino CA 95014 US