In-Application Advertising - HTML5 Advertising - page 227

check what MRAID version the SDK is supporting, and check what placement type you are. This information can be
very important to an ad developer so they can adapt the ad experience if certain features aren't supported in earlier
versions of the MRAID API. You also set your expand properties by setting a width of 320, setting a height of 480, and
telling the SDK that you are using your own custom close button so you do not need to have the SDK supply one for
you when you are expanded. Lastly, you add two more event listeners for errors on MRAID as well as state changes
on the ad. Finally, when the ad calls expandMRAID() and closeMRAID() ,you can call the mraid.expand() and
mraid.close() methods to instruct the application that the ad is opening and closing, respectively, and this function
should pause any content in the application environment.
The example is fairly straightforward but may take some getting used to as far as the syntax goes. MRAID doesn't
end there; there is much more to add if the creative or SDK requires it, including methods for saving pictures, playing
videos, and even saving reminders to the calendar app of the mobile device. In version 2.0 of the API, open these
feature sets, which offer great benefits to an ad developer where those standards aren't quite finalized and adopted
in HTML5 or other specifications just yet. That said, MRAID isn't intended to conflict with HTML5 and DOM APIs
or new features of browsers. It's there to act as a layer of communication between the ad and the application, as well
as provide feature detection to the ad creative if it needs it and allow the ad to degrade gracefully. The IAB describes
MRAID 2.0 as follows:

MRAID v.2 provides a standard way to query a rich media SDK regarding certain device capabilities,
offers consistent handling of video creative, and addresses two native device capabilities not well
implemented by HTML5 at present: adding an entry to the device calendar and storing an image
in the device photo roll.

MRAID is a blessing for anyone developing ad creative to applications, and if you find an application not
supporting it but offering advertising, I strongly recommend contacting the developers and getting them to adopt
it. In fact, push very hard for it; you'll be doing a service to them, yourself and everyone else that will need to run
campaigns in the future. For more information on the MRAID documentation, visit http://iab.net/mraid .

Testing
In the world of in-application advertising, nothing works better than testing creative on the device in the
application it's intended to run in. However, in many cases this is far from the actual reality. Publishers and content
owners of the applications often do not have the ability to allow every ad developer access to a “test build” of their
application, either because they're unaware of how to do so or because they've reached their limit of devices that
they can hand out.

Not ■ a great app testing service called TestFlightapp ( http://testflightapp.com ) can aid with this problem.

Whatever maybe the case, just know that most times it's a luxury to get a test build of the publisher's application,
so debugging your ad code can be a hell of a challenge. The catch here is that testing on a device in the application
provides the most accurate results, much like testing in multiple browsers for desktop campaigns. Think back to
when publishers would offer up test pages so ad servers could traffic their ad tag to an environment that resembles
accurately what will be live the day the ads launch. It's the same concept here, just much harder to get!
Always ask the publisher and/or app provider you're working with at the very beginning if they can support
this and, if not, in what other ways they can support testing. Find out whether they can provision a build of their
application so you can run your ads without just testing in the browser or taking someone's word for it. Personally,