Prerequisite knowledge
Experience working with the Adobe Digital Publishing Suite is required. This article also assumes you can create a custom storefront or other custom button in the viewer for a developer IPA. Experience with HTML, CSS and JavaScript is also recommended when developing custom storefronts.
 
User level: Intermediate, Advanced
 
Required products Documentation and API

 
 
 
Enterprise customers of Adobe Digital Publishing Suite can use a JavaScript API to create custom libraries and stores using HTML, JavaScript, and CSS. These views are displayed in webviews which are accessed by tapping a tab at the bottom of the viewer app. In this article, you will learn a few techniques on how to debug your custom tabs on iOS.
 
Note: For users of Adobe Edge Inspect, because DPS runs in its own application, Edge Inspect is not compatible with the DPS viewer.
 
The following sections discuss a few techniques on how to debug your code.
 

 
iOS 6 and Safari 6

Using iOS 6 and Safari 6 is the most extensive debugging technique available and makes use of the Web Inspector on Safari desktop to debug the webview on your iPad. This enables you to view console output, view JavaScript errors, set breakpoints, and much more. iOS 6 requires iPad 2, iPad with Retina display or iPad mini. Safari 6 requires a Mac running at least OS X 10.7.4. To enable debugging follow the steps below:
 
  1. On your iPad, select Settings > Safari> Advanced and then set the Web Inspector switch to ON (see Figure 1).

 

The switch to enable debugging
Figure 1. The switch to enable debugging
 
  1. In desktop Safari, if you do not have a Develop menu option at the top, select Safari > Preferences > Advanced and then check the "Show Developer menu in menu bar" checkbox (see Figure 3).

 

The checkbox to display the develop menu
Figure 2. The checkbox to display the develop menu
 
  1. Plug your iPad into your computer and launch your development viewer.
  2. When your custom view has loaded, in desktop Safari, select Develop > the-name-of-your-iPad, and then select the file name (see Figure 4).

 

The menu to select the webview to debug.
Figure 3. The menu to select the webview to debug.
 
 
Keep in mind that you will not be able to open the Web Inspector until your webview has loaded. To reload the webview, press CMD + R from the desktop.
 

 
Firebug Lite

For users accustomed to Firebug for Firefox, Firebug Lite runs a subset of the Firebug features and runs in your webview in an iframe. To use Firebug Lite, you only need to include the following in your page:
 
<script type="text/javascript" src="https://getfirebug.com/firebug-lite.js#startOpened=true"></script>
For a complete list of features, visit the Firebug Lite site. When using Firebug Lite, it is important to keep in mind that the Firebug Lite UI is displayed in an iframe, which has fixed positioning at the bottom of your webview. Because of this, if you replace the contents in your <body> tag, such as $("body").html("Hello"), then the Firebug Lite UI will be removed. Firebug Lite is a useful alternative if you do not have iOS 6 and Safari 6, but does not have anywhere near the capabilities of the latter. For instance, you cannot set breakpoints or highlight regions on the page from the HTML source view.
 

 
textarea output

This is the most basic technique and simply outputs text to a textarea via a global function. This is useful because you can see your debug output directly on the iPad without having to switch back to your desktop, and you can set the textarea's opacity so you can see the content below it.
 
To make use of this technique, follow these steps:
 
  1. Add this to your HTML: <textarea id="debug"></textarea>.
  2. Add this to your JavaScript:
window.debug = function(value) { var textarea = document.getElementById("debug"); textarea.value = textarea.value + (textarea.value == "" ? "" : "\n") + value; }
  1. Add this to your styles:
#debug { width: 400px; height: 300px; position: fixed; top: 0px; left: 0px; z-index: 9999; opacity: .5; }
The CSS above places the textarea in the upper left of your webview. To view your output in the textarea, call debug("hello") and your output will display in the textarea. Keep in mind that since the textarea only outputs strings, your output will always be converted to a string and you won't be able to inspect your objects.
 

 
Debug configuration

To minimize the number of IPA builds and installations, it is recommended that JavaScript and CSS files be loaded remotely at development time. So, rather than something like this:
 
<script src="AppView.js"></script>
you should use something like this:
 
<script src="http://lighthouse.adobe.com/dps/library/AppView.js"></script>
Using this technique will allow you to make changes to your JavaScript file without having to create a new IPA and installing it.
 
The same applies to your stylesheets, so rather than something like this:
 
<link rel="stylesheet" href="library.css" type="text/css">
you should use something like this:
 
<link rel="stylesheet" href=" http://lighthouse.adobe.com/dps/library/library.css" type="text/css">
Once you make a change to a file and upload it to your server, you most likely will have to hard-close the app and relaunch it for the changes to pick up, because iOS will usually cache your file until your app is closed. In the event that iOS continues to cache your file, uninstalling and then reinstalling the application will usually clear the file from the cache.
 
One technique for making sure your files are not loaded from the cache is to load your JavaScript using JavaScript rather than a <script> tag, and then appending a random URL variable to the end of the URL. For example:
 
var head = document.getElementsByTagName("head")[0]; var script = document.createElement("script"); script.type = "text/javascript"; script.src = "http://lighthouse.adobe.com/dps/library/AppView.js?r=" + Math.random(); head.appendChild(script);

 
Loading data cross-domain

Although not directly related to debugging, because the viewer is a native app, you are not under the same cross-domain security restrictions as desktop Safari. This means that you can load cross-domain data into your application if your HTML file is embedded with the viewer. However, if you redirect to a remote page to display your custom store, the standard cross domain security rules are in place.
 

 
Where to go from here

This article discussed various techniques on debugging a custom tab in DPS. For more information on developing custom storefronts and libraries please visit the Digital Publishing Suite Developer Center.
 
If you'd like information about debugging a custom store, see Getting started with the v2 Library and Store API.