HTML and CSS Reference
In-Depth Information
function closeExpand () {
As you can see from the previous example, working with Pandora's SDK via JavaScript calls is fairly straightforward,
but it works only for Pandora. An advertiser running ads across other publishers will need to have a customized ad
for each one, and operationally this does not make sense for scale and quick turnaround times because you could be
tasked with creating a large conditional statement inside your script to interface with all the vendor's APIs.
The pandora code in listing 9-1 works at the time of this writing, but please note all of this is subject to change
at the discretion of the publisher and application provider.
For the purposes of thinking that this ad could be trafficked to publishers outside of Pandora, I like to wrap my
calls in a try/catch method. While not the best coding practice, it ensures that if the Pandora object does not exist,
the code would just log a message and continue running without any breaks. For now, this is a good practice when
you want one ad to run across multiple sites and networks. Again, this specific use case is just for Pandora, but you
can easily see how this can get out of hand quickly! Having a developer add numerous try/catch statements or
conditionals is a lot of added work and testing, and between what features you can use in what browser, on what
device, on what operating system version, adding this SDK fragmentation to the puzzle can really make your head
hurt! (Remember how advertisers want scale?) There has to be something better, right?!
So, with all of these applications, you may be asking yourself, “What gives? Why do I need to worry about this
additional SDK fragmentation on top of everything else I need to worry about in this already diverse landscape with
HTML5 ad development?” Well, for some time (and even as I write this), this is the way it has been because vendors
thought they could tie their clients into using their own proprietary SDK code base, thus resulting in the clients being
“stuck” with them for ad serving. While a pretty clever business model because it makes it hard for developers to make
the switch, the reality is that it's not a long-standing one, and with that, I introduce to you ORMMA ( http://ormma.
org ) and MRAID ( ).
Open Rich Media Mobile Advertising (ORMMA) was an industry-wide initiative for advertisers to have one
common set of rules for displaying rich media ads across various mobile application platforms. ORMMA was an
SDK and an API for allowing ad designers to use a common way to interface with ORMMA-compliant applications.
Application developers would have needed to follow the ORMMA specification to allow ad designers to add
compelling rich media ads into their apps. While ORMMA started the building blocks for executing mobile rich media
at scale, it is a thing of the past now with the release of the IAB's MRAID.
Mobile Rich Media Ad Interface Definition (MRAID) is essentially what VPAID is to publisher video players
except for mobile applications. Founded on many of the principals that ORMMA addressed, its sole purpose is to ease
fragmentation across devices, applications, and ad servers so mobile rich media can be a profitable industry. MRAID
is backed firmly by the IAB and has a dedicated working group committed to its development. The IAB believes
that MRAID should be the de facto standard for having mobile rich media ad units communicate with application
environments. Currently on its second version, MRAID allows mobile ad developers to utilize a set of standard
functions to communicate between the ad and application's SDK, for instance telling the application the ad will
Search WWH ::

Custom Search