HTML and CSS Reference
In-Depth Information
function cacheBust () {
var num = Math.random();
return num;
}
</script>
</head>
<body onload=fireImpression()>
</body>
</html>
When using the previous code snippet, you create a new image and set the source of that image to the URI
you want to hit, but you concatenate a cache-busting method to the string. This cache-busting method, called
cacheBust
, tells the browser to generate a random number and adds it to the
r
param in the query string. This will
yield something similar to
http://tracking.somedomain.com?r=0.123456
, and this practice can be used with any
HTTP request; just keep in mind that caching assets is a good thing in most cases such as heavier k-weight JavaScript
libraries, images, or CSS files that won't change. However, for reporting and analytics, cache busting is pretty
mandatory for accurate results.
When working with in-app, some SDKs require that the ads be cached to the device for offline use. For example,
if you were to view the
Wall Street Journal
iPad application, the content and ads get cached to the device so a user
can view the content in offline mode. This is super-helpful if a user is about to board a plane where a connection is
nonexistent. In this case, the current SDK provider AdMarvel caches the application content and all ads to the device
by way of a cache file. Listing 10-4 shows how this is implemented using the AdMarvel SDK.
Listing 10-4.
AdMarvel Cache File Example
ADMARVEL-CACHE
assets/style.css
http://cdn.domain.com/assets/style.css
assets/script.js
http://cdn.domain.com/assets/script.js
assets/logo.png
http://cdn.domain.com/assets/logo.png
The cache file is saved as a tab-delimitated
.txt
(plain text) file that locates all the assets that make up the ad
experience by relative and absolute locations (local/remote) and is delivered to AdMarvel with the ad creative.
■
every SDk will have its own way of implementing cached ad assets. be sure to check with them before
campaign launch.
Note
Network Connection API
This section covers the Network Connection API, which allows developers to query the strength and type of the
network connection the user is currently using. The API, at the time of this writing, is currently not supported in any of
modern browsers, but its API documentation is being revised and will offer many useful features when this emerging
standard becomes available in modern browsers. The API as it stands now allows for a developer to detect whether a
user is on Ethernet, WiFi, 2G, 3G, 4G, none, or an unknown connection. With this sort of information combined with
Navigator.onLine
and the Ajax test, developers can cater their ad experiences for sophisticated offline use. If you
can't wait for the spec to finalize or browsers to implement this into their architecture, you can take advantage of this
from within in-application advertising by way of the SDKs. In fact, in MRAID, ad developers and designers are able
to query the MRAID-compliant SDK for information about users' connectivity by calling the method
getNetwork
.
In
addition, they can add an event listener for the
networkChange
event when network connections change. Currently,
the possible connection types in MRAID are offline, WiFi, cell, and unknown. Ideally, we'll see these APIs take shape
