Transcript
>> Wil Turner: Welcome to Integrating Ads with iAd.
Today, we're going to give you an
overview of the iAd Objective-C framework.
How to use is in your application and the
best practices you want to keep in mind.
We also talked about the business
side of using iAd in your application.
My name is Wil Turner.
I am the iAd Framework Manager.
So today's agenda, we're going to
start of with an advertising overview.
The advertising industry, how it works.
Then we will get in to the technical
side of the iAd framework.
Putting the ads in your app, what we call the banner view
life cycle, how to support multiple interface orientations.
So your apps already may support autorotation.
You want the apps do the same thing.
Then we'll talk about responding the actions
that the user chooses to go into the ad,
is there something your app should do in response?
And finally, we will finish with the business
side what it means to become a publisher.
But first, a little recap of why iAd.
We think with iAd we can reinvent mobile advertising.
Right now the status quo of mobile advertising is
that things are somewhat interactive because it's web
or some other kinds of dynamic content, but the ads usually
exit the application which is a really poor user experience.
And then there's television which is on the
other side of things and it's fantastic.
It can convey an emotion but there's not really
interactive side, there's a captive audience.
With iAd rich media ads we think we can capture both
of these, both the emotional and the interactive.
The best of both worlds will provide media through audio
and video and interaction through emotion and touch.
The iAd rich media ads are built on HTML5.
That means that audio and video are
first class citizens in the web content.
They're not provided by plug-ins and they execute natively.
We get interaction with CSS3 and
Multi-Touch which is only on the iPhone.
So WebKit provides extensions in the browser that allow us
to do animated transitions and even keyframe animations.
They are hardware accelerated.
So no more JavaScript to animate
something across the screen.
This is happening down on the graphics hardware and
the touches are exposed as DOM events by WebKit.
Finally, we're going to deliver an optimal
user experience in the iAd rich media ads
because the user will never leave the application.
The background process we have is going to execute the
ads so it's not in your apps memory space but it's going
to be presented on top of your application
and your Apple always remains foreground.
The user dismisses the ads at any
time and is returned exactly
to the point in your application where they left off.
So this will change the game.
Combining emotion and interactivity
and we don't leave the application.
So, let's talk about advertising a little bit.
There are several common roles in the advertising industry.
It starts off with the advertisers.
These are the people, the companies with products
and services that they're trying to advertise.
The next piece in this chain are the ad agencies,
they help create the advertising campaigns.
Now mobile and web advertising, we have this notion of an
ad network which aggregates the advertisements and campaigns
from the ad agencies and distributes
them out to the publishers.
So publishers is the term that harks back to the
origins of advertising which is in print media.
Newspapers, journals, magazines, sold space to advertisers.
And so we still use the term publishers today.
And then finally, the advertisement reaches the consumer
who hopefully either chooses to
make some purchase based on the ad.
Today, we're really interested in two parts of
this chain, the publishers and the ad network.
The publishers are you, the application developers,
because you are the people with space that you can sell.
And the ad network is iAd.
Advertising has two basic moving parts.
There are banners which are a finite amount of space
that contain some kind of graphical called actions.
When the user chooses to interact with the banner
it leads them into what we call the ad action
which is some kind of web experience usually.
There're also two common business models in advertising.
The first is based on just viewing the banner.
We call that an impression and advertisers
will purchase some number of units of viewings.
So they call that a cost-per-mille because
they purchase these by the thousand.
The other side is clicks.
So they don't care about the user seen in the banner,
they want to pay when the user interacts with the banner
which they consider maybe more
effective measure of how good the ad was.
So that cost-per-click method is the other approach.
The iAd business model is a hybrid approach.
It combines cost-per-click and cost-per-mille.
And so you're paid, you, the application developer when the
user views the banner in your app and also when they tap
on the banner and the tap is weighted
so it's a higher revenue rate.
So now, let's get in to the technical side of things.
The iAd framework is an Objective-C framework.
It's new in the iOS 4 and it makes it
easy to embed ads in your application.
It also promotes high-quality, rich media ads.
We are going to talk about implementing this today.
There are four sections.
The first is just putting the ads in your app.
And, you know, maybe once you get that done you feel
like your finished but there's a little bit to it.
The next thing is what we call a banner view life cycle.
So what that means really is whether
the banner view that you put in your app
at any given time has ad content in it or not.
If you think about where ads come from,
they're kind of come over network.
So if you're not connected to the
network, you might not get ads.
Finally, we're going to talk about
supporting multiple interface orientations
which is the autorotation part
and how to respond to actions.
So when the user does to choose to interact
with the banner, what should your app do?
Let's start off with putting ads in your app.
So here's your app, you want ads.
It's pretty simple really.
You just make a little space and
add a banner view, you're done.
The banner view is ADBannerView.
It does all the heavy lifting for you.
You added into a view hierarchy, maybe make one
or two configurations to it and you're done.
It's a core class in iAd framework.
In fact, it's the only class that
you'll see or interact with.
It's just a view.
Add it to your view hierarchy.
It does require to be part of a
view controller's manage hierarchy.
That has to do with how the ads present the action.
We need to present this frontal view controller.
So you can't just throw your banner
view into an empty window.
And the banner view manages the retrieval and the display
of the advertisements which it gets from the iAd network.
When the user interacts with the banner view, the
banner view takes care of how that interaction proceeds.
Your App does very, very little.
But what does it do?
Well, it really comes down to placement.
Placement is the most important decision
you'll make when you use ADBannerView.
We're balancing attention between
providing a great user experience
and effectively promoting the advertising materials.
And as we've seen over the years in
the web space some people have, think--
have decided that it's effective for banners
and ads to just kind of explode in your face
and fly around the screen but that's
not a great user experience.
That is a very annoying user experience.
And as a result the user is really
unlikely to want to interact with that,
they're going to be hunting for that close button.
Instead, you want to place the banners where they're
visible, they're conspicuous, but they're out of the flow
of what the application is supposed to do.
So we've determined there are two really great places
to put banners, at the top of the screen or the bottom.
That way your application maintains its integrity
as a unit and the banners are very visible.
If the user wants to interact with them,
they have no trouble getting to it.
It's not in such a great idea to put your banners into a
scroll view or table view because they're going to fly by,
the users going to have minimal visibility, and
if they choose to interact it's a moving target.
And if it's moving, they might interact with it
inadvertently and that's also not a good user experience.
So to give you some insight into what this is like.
We're going to take an existing application.
SeismicXML is sample code in the developer reference
library and we're going to modify it so that it uses ads.
The banner view-- this application
uses a UITableViewController.
And we have to make a few modifications to it,
because we want the banner view to be a sibling
of the table view not a subview of the table view.
So that when we scroll in the table
view, the banner view stays where it is.
So we're going to take things apart a
little bit, create a container view,
add the table to that, and then
add the banner at the bottom.
So now, Juan Carlos is going to take
you through a demo of doing exactly
that so you can see just how a little work it
takes to get ADBannerView up in your application.
[ Applause ]
>> Juan Carlos Jimenez: As Wil said the application
we're going to be modifying today is called SeismicXML.
Let me show you what it looks like so we can
talk about what we're going to be doing to it.
As you can see, it consists of a table
view with data that comes from an RSS feed
that comes from the US Geological Survey.
Now, what we're going to be doing
to this application is we're going
to add a banner view to the bottom of the screen right here.
It's important to note that the banner
view will be a sibling to the table view.
This way, if the user scrolls up or down the table
view, the banner view will remain at the bottom.
So let's get started.
The very first thing I want to do is I want
to add the iAd framework to the project.
Next, I'll go into interface builder and I'm going to
add a general purpose view that acts as a container
for both the existing banner-- the
existing table view and the new banner view.
So I'll drag in the table view, make sure to resize
it, and leave enough room for the banner view
which in this case takes up 50 pixels in height.
Then, I'll drag in the banner view.
I want to make sure that I set the auto
resize mask to let the banner view know
that it's going to be placed at the bottom.
And now-- I mean, before I go into more details
in the code, I want to talk about what I just did.
Because I've changed the view hierarchy in such a way
that the root view in this hierarchy is a UIView instead
of a table view, I'll need to change
my controller to reflect that change.
So I'll change it into UIView controller.
But at this point, I've lost the
reference to the table view.
So we'll need to add a property
to reestablish that connection.
I'll go into the implementation file and make sure that I
synthesize the property and that I release the table view.
Now, I just have to go back into interface
builder and reestablish these connections.
So first, I want to make sure that the controller
references the table view using the new property.
Also, I want to make sure that the controller references
the container view using the original view outlet.
At this point, if I run the application, you should
see a banner view appear at the bottom of the screen.
In this case, this is a fully functioning test ad.
And that's really all there's to it.
So just to summarize.
What we did, is we added the iAd framework to the project.
We modified our view hierarchy to leave room for the
banner view and then we readjusted any other connections.
It's that simple.
Now, handing back off to Wil.
[ Applause ]
>> Wil Turner: That's pretty great.
You just add a view and boom you're making money.
[Laughter] So you may have noticed when that banner
view first appeared, it was an empty white frame.
So that frame is something we provide that tells our
users that this is an ad provided by the iAd network.
And that's how we build trust with them because they
realize that that frame means that if I tap on this,
I'm not going to leave the application,
I'll be right where I was when I'm done.
And you also notice that after
slight delay, the ad appeared.
So that leaps us into the banner view life cycle.
What this means is we have to manage
connectivity and inventory changes.
That sounds kind of scary.
Let's see what that means.
So ADBannerView may not always have ad content in it.
Content comes from the iAd server.
Network conditions as you all know are dynamic
and the server inventory is also dynamic.
It's constantly changing and things are targeted
by the advertisers to reach certain audiences.
So the banner view has two basic life cycle states.
It's either loaded or not loaded.
And let's look at a little diagram
of what that might look like.
You start off, you create the banner view.
There's no content.
It makes a call to the server, loads its content.
And then we cycle content automatically.
At some point you, may run into a network or inventory error
and then it later resolves itself
and you start loading content again.
And as we mentioned we cycle content.
So you get that first ad and it's displayed and after
a certain period of time we load a new ad for the user.
It's not something that you have control over.
We just manage all that for your.
So you really don't have to worry about the cycling.
All you have to worry about is
the state of loaded or not loaded.
So the way we manage this is we implement
the ADBannerViewDelegate protocol
in one of your controller objects.
Most likely, you'll implement it in the
view controller that owns the banner view.
There are two callbacks that are
associated with the content life cycle.
The first is bannerViewDidLoadAd and you'll
get that the first time it loads an ad
and you'll get it every time we cycle a new ad in.
And this just tells you that you've got ad content.
On the other hand you'll get
bannerViewdidFailToRecieveAdWithError
and that means you don't have content.
So network issues.
These are mobile devices.
The user is always on the go.
The network is changing.
They may go into a subway tunnel, into a building
with no connection, they may be still driving
between cell phone areas and switch off one tower
into the other and that interrupts the connection.
Ads require a network connection so
we have to get the ads from remote
and then while the ad is running,
it has to talk back to the server.
So if there's a poor network connection or a change in
network connection, the flow of ads may be interrupted.
The other issue is the inventory issue.
So ads are targeted and the demographic
or your application or filters you've set
up to exclude things and I'll talk about that later.
But these-- all these impact how the ads
are targeted by the server and it's possible
that at some times there will be
an appropriate ad for you app.
So no ads.
Errors? They're not really errors.
Yes, we're using a callback mechanism that has the
word error in it to communicate this message to you.
But really, these are just part
of normal operating conditions.
It sort of like memory warnings on the iPhone and, you
know, memory pressures are constantly changing and you have
to be ready to release things and
then load them backup on demand.
It's just part of how things function on the device.
So what matters is how you respond to them.
And that's where you have control over things.
So when availability changes, remember that space has value.
The way we arrived at this point in the first place
is that somebody said, "Wow, I've got some space."
And somebody else says, "Hey, I'd love
to put some information on that space."
Well, let's do a deal.
So space has value.
If you don't have ads, then you
should put that space to good use.
What does that mean?
Well, there's a very simple pattern
that we encourage you to adopt.
Create your banner views offscreen.
Wait for the callback that says it's loaded and then animate
it into position and then if you get another callback
that says there's an error, just hide the
banner view or move it offscreen again.
Now, I say move it offscreen.
Important to keep in mind that you
don't want to take it out of its window.
Just adjust its frame so it's positioned
somewhere that's not onscreen.
If you take it out of the window
completely, remove from super view,
then we'll think that, "Oh, you're done with that.
You don't' want to cycle ads anymore."
Because we don't want to send ads down
if they're not going to be visible.
So just move it offscreen but keep it in at super view.
So, Juan Carlos is going to take SeismicXML again and he's
going to update it so that it implements this pattern.
So that when we first launched the app and there's
no ad you won't see the space put to poor use.
>> Juan Carlos Jimenez: OK.
So now that we've covered the life cycle and the
two delegate methods, I'm going to modify SeismicXML
so that it only shows the banner view when the
banner view has notified me that it's ready to go.
So the first thing I'll do is I'll add the import--
I'll add an import for the iAd main header file
and then a property to reference the banner view.
Again, I'll go into the implementation file and make sure
that I synthesize the banner view
and that I release it on the alloc.
I also want to make sure that I reset the
delegate to make sure that I don't have a crasher
because the banner view is notifying
my controller when it's released.
So, I'll go back into interface
builder and make the connections.
So I'll make sure that the controller
references the banner view using the new outlet
and that the controller becomes the banner view's delegate.
OK. So now I'm ready to add the two delegate
methods that Wil was just taking about.
First, I'll tackle the delegate
method that handles errors first.
Now, for this, I'll add another
method called moveBannerViewOffscreen.
What I want this method to do is to calculate a
frame so that it browses the table view to take
up all the space available in the container.
Then, I'll make sure that I'll
calculate a frame for the banner view
so that it sits offscreen, in this
case, below the table view.
Finally, I want to set these two
frames under respective views.
And that should be all I need to do for this method.
All I need to do now is call it
from the delegate error callback.
Now this only takes me a part of way there.
At this point, I'm hiding the banner view only when that
the banner view has notified me that there's an error.
I still want to make sure that I hide
the banner view before it's ready to go.
So I'll make another call to this method from viewDidLoadAd.
And now, I can look at the case in which the
banner view has notified me that it's ready to go.
So, I'll create another method
called moveBannerViewOnscreen.
In this case, I want to do the opposite thing.
Here, I want to calculate a frame so that the banner
view is able to sit at the bottom of the screen,
taking into account the size of the container
and the size of the banner view itself.
Then, I'll calculate a frame for the table view to
shrink it so that it leaves room for the banner view.
Again, taking into account the size of the
container and the size of the banner frame.
Finally, I want to set these two frames on their views,
but this time I'm going to do it slightly differently.
This time, I'm going to wrap those calls
in an animation block so that the--
so that both views animate into their
new frames smoothly and at the same time.
And that should be all I have to do for this method.
So now, I just have to call it--
oops, and launch the application.
At this point, the banner view should slide up
from the bottom of the screen when it's ready.
That's all we need to do.
So just to recap, what we did is we registered
our controller as a delegate of the banner view.
Made sure that we also connected to the banner view and
then we responded to the delegate methods accordingly
so that we can hide the banner view when it's encountered
an error and that we show it only when it's ready to go.
Now, back to Wil.
[ Applause ]
>> Wil Turner: OK so, we put the ad in the application
and we've learned how to use this space wisely so that
if there aren't actually ads visible,
we use the space for some other purpose.
But if they are visible, then we show them to the user.
So to recap quickly about ADBannerViewDelegate, we can use
the banner view delegate for managing the ad content state.
It tells you when you've got ad content and when you don't.
And we recommend that you move your banner
view on and off the screen accordingly.
And as a note, before releasing the banner
view, you should set its delegate to nil.
This is a pattern you may be familiar
with in your UIWebView.
And the reason for it is that the
framework sometimes has to hold
on to the banner view while it's off talking to the network.
And if your controller object who is the
delegate, releases it and then itself goes away.
By the time we're finished with the network activity,
we're still holding the banner view and we might try
to access the delegate at that point
because we don't know that it's gone away.
So just remember, always set the banner
view delegate to nil before you release it.
So now let's talk about multiple interface orientations.
This is really a question of ad content sizes.
So everything we've seen so far today
has been in a portrait user interface.
But there are several different
ad sizes that are supportive.
And ADBannerView manages the actual view size.
The ad designers build their ad
campaigns around fixed standard sizes.
For portrait, we use 320 x 50.
For landscape, we use 480 x 32.
Both of these work out to be about
10 percent of the screen size.
So when you're using the banner
view, the configuration you may need
to do is tell it what kind of sizes it's going to be using.
Now, if your UI is only portrait or
only landscape, this is very simple.
But if you're supporting both, it's still very simple.
So the banner view needs to know all possible sizes
that it would be asked to support because it's going
to ask the ad server to provide it with
content that can support both orientations.
So that if the user changes the device, you can make a
seamless transition from one content state to the other.
So we have a property called requiredContentSizeIdentifiers
and this is a set.
And we have some constants that name
the specific sizes that are supported.
And in this set, you just add all
the ones that you want to support.
So what you're seeing here is this has been set up for a
UI that is going to support both portrait and landscape.
If it were only portrait then it
will just be a set with one object.
And if it were only landscape,
again, just a set with one object.
The other thing is the current content size.
So you've told the banner view it might support both of
these sizes but which one should it be supporting right now?
That's the question.
So we have a property called currentContentSizeIdentifier.
And you'll set this to be one or
the other of these constants.
It's worth noting that if you set the current
content size to a size that isn't actually included
in the required sizes, we'll throw an exception because
you've told us to do something that's not possible.
So set it up in front, configure the required
sizes and then set the current content size.
And when you autorotate, you'll change the
currentContentSizeIdentifier to the new orientation.
So you see, when the application
rotates, the main part of the app resizes
and then the banner also resizes simultaneously.
So view controller provides us very useful callback to
its subclasses which is called willAutorotatetoInterphase.
And what this does is this takes place inside the
animation block which handles that entire transition.
So anything you do, modifying your views,
their properties, their sizes, their alpha,
anything you do inside this becomes
part of that larger animation block.
So these animations will happen in sync.
So what we do is we just look at
what the new orientation will be.
We say, well, OK, we're going into landscape.
We need to set the currentContentSizeIdentifier
to landscape identifier or vice versa.
So once again, we'll take up SeismicXML for the
last time I promise and we'll see what it looks
like to take this portrait-only app and not only support
autorotation but support the ads with both interfaces.
>> Juan Carlos Jimenez: All right so
like Wil said, what we want to do first,
is we want to set the requiredContentSizeIdentifiers
over the banner view to a list that
or a set that includes both sizes,
in this case, 320 x 50 and 480 x 32.
At this point, the banner view should be ready to go fetch
over the network exclusively ads
that match both of these sizes.
Now, what we want to do is we want
to make sure that this application
or this controller, accepts any rotations, any orientations.
So I'll use this method here that you're probably already
familiar with to return yes for any orientation changes.
And then I'll use the method that Wil was
mentioning earlier to make my decision based
on the orientation in which we're moving.
So in the case of portrait, I want to make sure
that I set the banner view's currentContentSizeIdentifier
to the constant that ends with 320 x 50.
Otherwise, I'll assume that the orientation is landscape.
So I will set the currentContentSizeIdentifier to 480 x 32.
At this time, I should be able to run the application
and see the banner view resize
itself when the orientation changes.
Now, notice that there is a little space here
between the table view and the banner view.
I am willing to bet that this is because
I forgot something in interface builder,
probably, the autoresize mask of the table view.
And sure enough, here it is.
The bottom margin of my table view
is set to be a fixed bottom margin.
So I am just going to make that into flexible so that the
table view can resize freely once the orientation changes.
So let's try this again.
This time, by changing the orientation,
I should see the banner view
and the table view be flushed next
to each other in the right position.
And that's all, really, there is to it.
So just to summarize, the two things
I need to do is I need to make sure
that the banner view has its requiredContentSizeIdentifiers
to a list that includes the values
that match all the orientations
that we are going to be displaying.
And then finally, I want to respond to the orientation
changes by setting the currentContentSizeIdentifiers
of the banner view to a value that matches the orientation.
And that's it.
Back to you, Wil.
[ Applause ]
>> Wil Turner: OK.
So we've added the ads to your application,
we have dealt with the content life cycles,
so we're always maximizing our use of space, and
now, we've learned how to support autorotation.
So the final thing that we need to talk about from
the technical side is how to respond to the actions.
This is really a state management
and resource consumption problem.
Let's say problem, but it's really quite simple.
So, in the ad action, this is where the
user enters the rich media ad experience,
they tap the banner, and they enter the iAd.
So if you've looked at the APIs during the developer seed,
you may have noticed that it looks like there is some kind
of actions that can be supported that would--
actually, would take you out of the application.
The API allows that flexibility, but
we're not using it at this point.
So right now, all the ads will
still keep you in your application,
and there will be the iAd-rich media experience.
So let's recap what this do.
They combine emotion and interactivity,
and they don't leave the application.
So when the user returns, they are
right where they were when they started.
So your job is just to reduce activity.
These ads are running in a separate process,
so they're not polluting your memory space.
But they may need resources if you are looking at a Nissan
Video, or playing an interactive HTML5 game inside the ad,
you're going to require some hardware
resources, maybe some network resources.
You do not want your application to be in contention with
the ad, because right now, the user is seeing the ad.
The ad is on top, and while your app is still running,
it does not need to be doing anything
because the user is not looking at it.
So you want to reduce your activity.
When the ad starts, you should
pause any media you are displaying.
And after all, the user's watching media in your app, they
will probably prefer that you pause it so they can, it's--
you know, when they come back, they
can pick up where they left off.
If you are doing a big download, you should
pause that as well because that is going
to really hamper the ad's ability to
get its resources from the network.
And if you are doing graphic intensive work, you should
pause that as well, because that is going to heat up the CPU
and then the ad performance is
not going to be as great either.
You are also going to save off
some minimal state information.
Now, this is not the kind of state information
you save when you are being backgrounded,
or if your apps is exiting, it is lightweight state.
So it is just what you would need to return to some exact
moment, given that your app will never stop running.
When the action completes, you resume
all of the activities you paused.
And based on the lightweight state that you
saved, you will know exactly what to restore.
So once again, we go back to ADBannerViewDelegate to give
us some insight into this user interaction life cycle.
When the user initiates the action, your delegate will
get this callback that says, bannerViewActionShouldBegin.
And then you will notice the second part of the
method says, has this bit about willLeaveApplication.
And that is going to be No, for now.
You app returns a Boolean from this method,
because you do have the power to say, "No,
I do not want to allow the action to begin."
You should not do that, because you
are saying, "No, don't give me money."
OK. Sure, it is possible that your app may be doing
some really mission critical thing at this instant
that it cannot possibly allow the user to go into, and
maybe it is OK just this once to say no, but I doubt it.
It is there, but I do not think you need it.
OK. So inside this method we are going through, we are
going to pause all of the activities we talked about.
Now, the other side, when the user comes back, you will get
this bannerViewActionDidFinish, and then you can resume.
It is worth noting that all the UIApplication
life cycle messages still take place.
So willResignActive, if the user hits the Lock
button, or sets the device down and it sleeps,
didResumeActive, willEnterBackground, etcetera.
All of those life cycle messages are still delivered,
both as notifications and to your application delegate.
And that is where your heavier duty
state saving should take place.
In the bannerViewDelegateMethods, it is very lightweight.
So now, we are going take a different
application, and this is a media application.
It is also from our sample code library.
And Juan Carlos is going to show you
how to handle the action appropriately.
>> Juan Carlos Jimenez: OK.
So this application, like Wil said, is an existing
sample application called iPhone Multichannel Mixer Test.
And I've modified it a little bit so that
includes a banner ad in its interface.
So let me show what it looks like.
Now, for the purposes of this demo, we will
just be looking at this Play Audio button.
And just to explain what it does, it plays an
audio loop, toggles an audio loop on and off.
Now, pretend that the user's interacting with this
application, and they decide to click on this button.
But immediately after that, they see
the ad, and it catches their eye.
And so, they decide to click on that.
So I do not know if you could hear it, but as I
clicked on the ad, there was an audio loop playing.
This is less than-- this a less-than-great user experience,
especially if the ad had its own audio with a play.
So I will make the changes on this application
so that it handles this case more appropriately.
I have added all the delegate methods that we've
covered so far, and I am going to be looking
at the first one that-- of the ones that Wil just mentioned.
In this case, what I want to do is I want to make sure that
I store the state of the application so that I can pause--
so that I can resume when the ad comes back.
So in this case, this state really
just consists of whether or not--
a Boolean that tells me whether or not the
audio was playing before the ad loaded.
Then I want to respond by pausing
any activity that was going on.
In this case, I just want to stop the audio.
And finally, I want to return yes.
I do not want to deny the user the
request for interacting with the ad.
And so now, when the user dismisses the ad, my controller
will receive the bannerViewActionDidFinish message.
In this case, I want to do the opposite thing.
The first thing I want to do is I want to look at the state
of things before the banner ad loaded-- or I'm sorry--
before the ad actually went into full screen.
And then respond accordingly by restoring any
activities that were going on at the time.
In this case, I just want to start the audio playback again.
So if I run the application now, I should be
able to go through the same steps I did before.
But this time, the audio should pause once I go into the ad.
[ Pause ]
I do not know if you could hear,
but the audio is now paused.
And if I click on the Dismiss button,
the audio should resume.
And that is really all we need to do in this case.
So just to summarize, what we did is we made
sure that implemented the two delegate methods,
we stored the state before we went into
the ad, and then paused any activity.
The converse when the ad is dismissed, we want to look
at the state and restore any activity that resulted
in being paused before the ad loaded,
and that's all there's to it.
Back to you, Wil.
[ Applause ]
>> Wil Turner: We had to work our imagination a little
bit there to hear the audio, but I think you could see it
from the state of the button, that things were changing
as we went into the ad, and then being restored properly.
So responding to actions, saving off some light
state information, and pausing your activity,
reducing your resource consumption while the ad is running,
and then picking up where you left off when you return.
So let's talk about everything we've looked at in
using the iAd framework, putting ads in your app.
You just add the ADBannerView to a
view controller managed hierarchy.
Deal with the BannerView life cycle by implementing
the ADBannerViewDelegate callbacks to know
when you've loaded an ad, when you don't have an ad,
and move your BannerView on or off screen appropriately,
so you're getting the best view set of your screen.
We support multiple interface orientations,
we manage the size changes for you,
you just tell us which current content size identifier
to use, and configure your BannerView in advance
so that it's set up to review requesting
the right kind of ads.
And finally, respond to actions by using the
other ADBannerViewDelegate methods which tell you
that the user has entered an action, and
that the user has finished an action,
and just pause your activity there,
and resume it when they're done.
So let's switch our mental gears a little bit
and get into the business side a little bit.
Publishing with iAd.
So we talked about publishers earlier because
that's what you are, you're publishers.
You have space that you're going to sell to the iAd network.
It all starts in iTunes Connect.
We've expanded the iTunes Connect portal to have a
new iAd specific portal, and this is where you'll sign
up to be a publisher, and then you'll manage each
of your applications that's actually using ads.
Becoming a publisher has two steps, and they're very simple.
The first is agreeing to the Paid App agreement,
and many of you may have already done that.
If you've only done free apps, the Paid App agreement
is what sets us up to be able to cut you a check.
I think that's important.
The other part is the iAd agreement, and this is
specific to using iAd network, and it's just terms
and conditions associated with
displaying the ads in your application.
And in the iTunes Connect, you'll be able to
make both-- sign both of these agreements.
And once you've done that, you're a publisher.
And the next step is to configure your applications.
So, iTunes Connect is going to show
you all of your current applications.
Some of your apps may be live on the store,
and some of them may be in production.
And the interface lets you go in and see if they're seeing
test ads, which is what ad-app center development will see,
and lets you see what the revenue generation
is like, and we'll talk about that a bit more.
Now, for any given application to be able to host adds,
there's a little bit of configuration
that you have to do upfront.
You basically need to say, "I want this
application to be eligible for ads."
and then you get to tell us what
the target audience is like.
We just need to know if that target audience for your
app is under 17 or not, because there are certain ads
that we want to make sure don't go to minors.
The other thing you can do is what we call exclusions.
So you might not want your closest
competitors advertised in your app.
That might not be great.
So we'll allow you to exclude advertisements
based on keywords and URL's,
and you can add as many of these as you want.
But keep in mind, every exclusion you add
will impact the inventory available to you.
So you might not want your competitor's ads in your app, but
you want to make sure you're still eligible for some ads.
So don't get too crazy with the exclusions.
So summarizing, configuring applications tells about
your target audience and set up any exclusions you want.
And finally, the best part of all is monitoring the revenue.
Sit back and watch the money roll in.
So our interface will show you, and these are
just some members that got mocked up for this.
So don't necessarily rely on this.
But our interface will allow you to see what kind
of revenue you generate over the last seven days,
even on a day-to-day basis, how hot
the activity is in your application.
And we also provide you with a figure called the ECPM.
So if you remember, CPM, that was the cost-per-mille,
and that was if we were just going based
on impressions, what you'd be making.
And that's what the ECPM, it's the effective cost-per-mille.
So if the business model were just a
cost-per-mille model, ECPM is what you'd be making.
And you'll notice that the revenue is higher than the
ECPM, because we're paying you also for the clicks.
So everything we've covered today, integrating
ads with iAd, it starts off with the iAd network
which presents rich media, high quality
ads and a great user experience.
Using the iAd framework is easy.
You just add the banners in, configure them,
handle the action, and the content life cycles.
And for the business side, we use iTunes
Connect, which you're already familiar with.
We just added one more piece to it.
You go in, you register, configure
your apps, and monitor the revenue.
So for more information about iAd,
you can contact Mark Malone.
He is our Integration Technologies Evangelist.
And you can also go to our documentation.
We've got some great documentation that talks
about the framework, some conceptual overview,
we have documentation for the publisher's
side and the iTunes portal.
And you can also go on our Developer Forums
because our engineers are active on the forums,
and we have a great community there for answering questions.
So if you run into trouble, that can be your first stop.
We have some related sessions.
Tomorrow, we're going to talk in two back-to-back sessions
about creating the actual content of the ads themselves,
and we provide a JavaScript framework
called iAd JS which really makes it easy
to create these incredibly interactive-rich ads.
And there'll also be a session
tomorrow, if you have questions
or need to get more familiar with the iTunes Connect portal.
That takes you through a lot of
the aspects of using the portal.
Thanks a lot everybody.
[ Applause ]