As you start to use Adobe Edge Inspect, you will realize that there are a wide variety of things that you can do with it. This section will teach you all about the most commonly performed tasks and most commonly used features in Adobe Edge Inspect.
With Adobe Edge Inspect you browse in Google Chrome on your computer and all the paired mobile devices stay in sync. This means that any page you open in Chrome either from your local HTTP web server (via localhost) or a production server, that same page is opened synchronously in all the paired mobile devices. After that you can target any mobile device for inspection and start remote debugging.
In this section, I will talk about the most important feature of Adobe Edge Inspect, that is, how we can remotely inspect and debug a mobile web page. First, let's create a simple demo application for our testing purpose. After that we will go step-by-step into debugging.
Remember that in the Installation section, we talked about installing a local HTTP web server on our computer for development and testing purpose. As a frontend developer developing for mobile devices, I always prefer to test things out in a local development environment before moving things into production, and since Adobe Edge Inspect can open pages from localhost we are going to run and debug our demo application from our local web server.
Our demo application will be a very simple structured HTML page targeted for mobile browsers. The main purpose behind building it is to showcase the various inspection and debugging capabilities of Adobe Edge Inspect. If you are a seasoned developer and you want to skip this section, you can continue from the Open the Edge Inspect web inspector window section and directly start looking at how to debug your mobile web application. But, it is better if you continue with the flow as building the demo app will not take much of your time.
Now, let's get started by creating a directory named adobe_inspect_test inside your local web server's webroot directory. Since I have the WAMP server installed on my Windows computer, I have created the directory inside the www folder (which is the webroot for the WAMP server). Create a new empty HTML file named index.html inside the adobe_inspect_test directory. Fill it with the following HTML markup:
<html>
<head>
<title>Simple demo</title>
<meta name="viewport" content="width=device-width, initial-scale=1.0, minimum-scale=1.0, maximum-scale=1.0"/>
</head>
<body>
<div id="wrapper">
<div id="div1" class="divStack"><p>First Div</p></div>
<div id="div2" class="divStack"><p>Second Div</p></div>
<div class="divStack">
<input id="btn1" type="button" value="Button1" />
<input id="btn2" type="button" value="Button2" />
</div>
</div>
</body>
</html>From the Installation section we remember that Adobe Edge Inspect is compatible with Google Chrome only, so throughout our testing we will be running our demo application in Chrome. As I have also said in the Installation section, you may note here that Adobe Edge Inspect cannot open pages from the local filesystem (via the file:/// protocol), so if you are dragging and dropping your index.html page into Chrome then Edge Inspect will not be able to open it in the paired mobile devices. You need to run the page from the web server over HTTP. Now let's check our index.html file in Chrome. This is how it looks as of now:
As you can make out we have two div elements (#div1 and #div2) and two buttons. We will play around with the two div elements, and make changes to their HTML markup and CSS styles when we start remote debugging. And then with our two buttons we will see how we can check JavaScript console log messages remotely. You may also notice the use of the <meta name="viewport" /> tag in the head section of the HTML code block. Let's talk about it a little later. First, let's add some styles to our demo application, as it's not looking attractive at all. As you can see in the previous HTML block, I have already added the class and IDs (which will act as our CSS selectors) to the elements so that I can style them using CSS. Now, add the following CSS style in the head section of the index.html page:
<style type='text/css' >
html, body, p, div, br, input{
margin:0;
padding:0;
}
html,body{
font-family:Helvetica;
font-size:14px;
font-weight:bold;
color:#222;
width:100%;
height:100%;
}
#wrapper{
width:100%;
height:100%;
overflow:hidden;
}
.divStack{
padding:10px;
margin:20px;
text-align:center;
}
#div1{
background:#ABA73C;
}
#div2{
background:#606873;
}
input[type=button]
{
padding:5px;
}
</style>Save the file and reload Chrome to see the page with some styles now. The following screenshot shows this:
The two div elements now have a background color and a boundary. The text is center aligned. The two buttons are also center aligned now.
If you go through the CSS style block, you can see that I have made use of percentage width and height to define the dimensions of our application. This ensures that the elements (especially the two div elements) are adjusted automatically according to the browser window size. So the same application when seen on a mobile device will have the same look and feel with the exact amount of padding and margin, and no elements will be cut off from view. For more responsive designs you can use CSS3 media queries to declare different CSS styles for different devices or screen sizes, but for this very simple demo I preferred to use percentage width and height. For a simple test resize Chrome on your computer and you will see that the elements in the page adjust automatically. The following screenshot shows this:
Now, let's focus on the two buttons. I introduced the two buttons into the demo so that we can check out JavaScript console log messages while remote debugging. So, let's add some interactivity to the buttons. Open the index.html file again in your editor and insert this script in the head section of the file:
<script type="text/javascript">
window.addEventListener('load',init,false);
function init()
{
document.getElementById('btn1').addEventListener('click',button1Clicked,false);
document.getElementById('btn2').addEventListener('click',button2Clicked,false);
}
function button1Clicked()
{
console.log('Button 1 Clicked');
}
function button2Clicked()
{
console.log('Button 2 Clicked');
}
</script>Save the file and reload. Just for checking things out, let's find out if these two buttons are generating console messages when clicked on. For that, right-click inside Chrome and select Inspect element. This will open up the Chrome web developer tools window. Click on the Console tab. Now click on the two buttons and you will see console messages based on the button clicked. The following screenshot shows this:
Coming back to the script that we inserted just now inside the index.html file, I have used a DOM level 2 mechanism to register event listeners for the two buttons as well as the browser window object. So whenever the window loads and our DOM is ready, the two buttons get their event handler functions registered. Inside the event listener functions for the buttons (which are button1Clicked() and button2Clicked() respectively) I have defined the corresponding console log messages. So whenever the buttons are clicked a log is generated in the console. With that our demo application is ready to be tested in a mobile device with Adobe Edge Inspect.
Now that you've got with the demo application running in Chrome and your mobile devices paired to your computer (if not then you can look at the Quick start – pairing mobile devices with your computer section again), you will instantly see the same page opening in the web view of the Edge Inspect client app in all your mobile devices. The following image shows how the page looks in an iPhone paired to my computer. Note that the page will be displayed inside the Edge Inspect app running on your mobile device.
Before we move on to remote inspection let's talk a little about the viewport meta tag that we added earlier in the head section of our HTML markup.
Typically, mobile web browsers render a normal web page using a viewport width of 980 px (which is the default for desktop browsers). It then re-scales all the content of the page so that it fits nicely within the mobile browser's visible screen area, which is also called the viewport. This makes the web page view very small to read since a mobile device's screen width is less than 980 px and the mobile browser tries to fit the 980 px wide content into its viewport width (for example, 320 px in iPhone browsers). So the user has to zoom in on specific areas of interest and view the content. This normally serves the purpose for most sites. But for mobile optimized sites there may be situations where you want to control the size and scaling of the page. This is where the viewport meta tag comes in handy. The viewport meta tag allows you to specifically mention a viewport size to which the page will scale. The viewport meta tag was introduced by Apple for Mobile Safari to let web developers control the viewport's size and scale. Post Mobile Safari, a lot of other mobile browsers, specifically Webkit-based browsers, also have support for the viewport meta tag. The typical syntax is as follows:
<meta name="viewport" content="width=device-width, initial-scale=1.0, minimum-scale=1.0, maximum-scale=1.0"/>
width=device-width sets the width of the viewport to the device's screen width. The other properties of initial-scale, minimum-scale, and maximum-scale allow the developer to control the scaling of the viewport. A value of 1.0 for initial-scale specifies to not do any initial scaling, letting the viewport be of the same size as the device screen. There are a few other properties as well with which you can control how your page would scale. I will not go too deep into the viewport meta tag. For now you should continue using it and then explore it further on the Web. Now, let's start debugging.
Now that you can see our demo application in all your paired mobile devices we are ready to remotely inspect and debug on a targeted mobile device.
Click on the Edge Inspect extension icon in Chrome and select a device for inspection. I am selecting the iPhone from the list of paired devices. Now click on the Remote Inspection button to the right of the selected device name. The following image should help you:
This will open up the Edge Inspect web inspector window also known as the weinre (WEb INspector REmote) web inspector. This looks very similar to the Chrome web inspector window, doesn't it? So if you have experience with the Chrome web debugging tools then this should look familiar to you:
As you can see, by default the Remote tab opens up. The title bar says target not connected. So, although your mobile device is paired it is not yet ready for remote inspection. Under Devices you can see your paired mobile device name with the URL of the page opened in it. Now, click on the device name to connect it. As soon as you do that, you will notice that it turns green. Congratulations! You are now ready for remote inspection as your mobile device is connected. The following screenshot shows this:
You can see the weinre logo on the right. Edge Inspect uses an open source tool called weinre for remote inspection. You can find more information about weinre by following this link: http://people.apache.org/~pmuellr/weinre/.
Adobe has hosted an instance of the weinre debug server at http://debug.edgeinspect.adobe.com/. This weinre debug server is the most important part of the entire debugging process. What happens is that when you click on the Remote Inspection button, the Edge Inspect extension in Chrome reloads the same URL in the paired mobile device and the Edge Inspect app running on your mobile device injects a JavaScript snippet into the page as soon as the target mobile device is connected. This makes the page running in your mobile device act as a debug target and it references the weinre debug API. Both the debug target and the debug client (the Edge Inspect web inspector) communicate with the weinre debug server via XMLHttpRequest (XHR) and whenever changes are made in the debug client it is instantly reflected in the target mobile device. I wrote a blog post that talks about the weinre server in detail. You can read it here: http://jbkflex.wordpress.com/2012/04/12/debug-mobile-web-applications-remotely-with-weinre/.
Your target mobile device (the iPhone in my case) and the debug client (the Edge Inspect web inspector) are connected to the weinre debug server now and we are ready to make some changes to the HTML. Click on the Elements tab in the Edge Inspect web inspector on your computer and you will see the HTML markup of our demo application in it. It may take a few seconds to load since the communication is via Ajax over HTTP. Now, hover your mouse over any element and you will instantly see it being highlighted in your mobile device. For example when I selected the #div2 (Second Div) element in the Edge Inspect web inspector on my computer, it is instantly highlighted on the iPhone.
The following screenshot shows #div2 selected on my computer:
And this corresponding image shows it being highlighted on the iPhone:
Now let's make some changes to the HTML and see if it is reflected in the target mobile device. Let's change the text inside #div2 from Second Div to Second Div edited. The following screenshot shows the change made in #div2 in the Edge Inspect web inspector on my computer:
And magic! It is changed on the iPhone too. Cool, isn't it? The following screenshot shows the new text inside #div2. This is what remote debugging is all about. We are utilizing the power of Adobe Edge Inspect to overcome the limitations of pure debugging tools in mobile browsers. Instead, you can make changes on your computer and see them directly in your handset.
Let's do another test. Let's remove an element node from the markup. Select the div element holding the two buttons. Click on it and press the Delete button on your computer keypad. It is temporarily deleted from the DOM tree. The following screenshot shows the DOM state after the node is removed on my computer:
The change can also be seen on the iPhone instantly. The following image shows this:
Similarly, you can play around with the HTML markup and check it in the target devices.
Now, let's make some CSS changes. Select an element in the Elements tab and the corresponding CSS styles are listed on the right. Now make changes to the style and the results will reflect on the mobile device as well. I have selected the First Div (#div1) element. Let's remove its padding. Uncheck the checkbox against padding and the 10 px padding is removed. The following screenshot shows the CSS change made in the Edge Inspect web inspector on my computer:
And the following image shows the result being reflected on the iPhone instantly:
Similarly, you can change other style rules such as width, height, padding, and margin and see the changes directly on your device.
Click on the Console tab in the Edge Inspect web inspector to open it. Now click/tap on the buttons one by one on your mobile device. You will see that log messages are being printed on the console for the corresponding button clicked/tapped on the mobile device. This way you can debug JavaScript code remotely. Although Edge Inspect lacks JavaScript debugging using breakpoints (which would have been really handy had we been able to watch local and global variables, and function arguments by pausing the execution and observing the state) but nevertheless, by using the console messages you can at least know that your JavaScript code is executing correctly to the point where the log is generated. So basic script debugging can be done. The following screenshot shows the console messages printed remotely from the paired iPhone:
Similarly you can target another device for remote inspection and see the changes directly in the device. And with that we have covered how to remotely debug web applications running on a mobile device.
You have seen how I targeted one mobile device (the iPhone) for remote inspection and then using the Edge Inspect web inspector I remotely debugged the demo application. Now, you might be thinking that we paired multiple devices but during remote inspection we selected only one. One thing to note here is that you have to target mobile devices individually for remote inspection. It's not that there is a common Edge Inspect web inspector for all the paired mobile devices such that you debug in it and the changes are reflected simultaneously in all devices. Instead for every paired mobile device you have to open the Edge Inspect web inspector separately and only one instance of the web inspector will run.
For example, this time I have selected the Android device for remote inspection from the list of paired devices. Using the same methods that I discussed previously you can also target and connect another device for remote inspection.
The following image shows Button1 being selected in the Edge Inspect web inspector on my computer:
And the corresponding image shows the selected button being highlighted in the Android device:
You have your mobile web project already hosted on a live server. You have deployed your project before Adobe Edge Inspect came out and did not really use remote inspection techniques to test your application. So what can you do now? There is not a problem at all. Just browse to your project URL in Chrome on your computer and it will open in all the paired Edge Inspect mobile devices. Now, target any paired device for remote inspection and follow the steps mentioned in the previous section for debugging.
With Adobe Edge Inspect you can use your own weinre debug server for remote inspection. This will improve performance, speed up connection time, and will keep the remote inspection traffic local. So if you have a local instance of the weinre server running on your computer or on your local network, you can use that as a debug server instead of using the default weinre server hosted by Adobe.
To use your own weinre server, first of all you will need to have the weinre server set up on your computer. For that you will need the weinre JAR file and Java installed on your computer. This is out of the scope of this book but I have written a detailed post on setting up and running a local weinre server here: http://jbkflex.wordpress.com/2012/04/12/debug-mobile-web-applications-remotely-with-weinre/. You can read it if you like.
After you have a weinre server set up locally, you can follow these steps to use it with Edge Inspect:
Right-click on the Edge Inspect extension icon in Chrome and select Options. The following screenshot shows this:
This will open up the Options page in Chrome.
Now in the Weinre Server section select the Custom option from the drop-down list.
Enter the path of your weinre server in the textbox that appears and then save it.
The following screenshot shows the Options page with a custom weinre server path:
From now on, Edge Inspect will use your local weinre debug server. You can again revert back to the default weinre server by selecting Default (Adobe) on the select list.
You can individually clear the cache and refresh the page in the paired mobile devices by tapping on the Refresh button in the Edge Inspect mobile app menu on your mobile device. The following screenshot shows the Refresh feature on an iPhone:
You can also refresh and clear the cache for all the paired mobile devices by clicking on the Refresh all devices button (the first button at the bottom) in the Edge Inspect browser extension in Chrome. The following screenshot shows this:
Take a screenshot of the page on one paired mobile device by tapping on the Screenshot button (fourth from the top) in the Edge Inspect mobile app menu as shown in the following image:
You can also take screenshots of the page in all the connected mobile devices by clicking on the Request screenshots button (the third button at the bottom) in the Edge Inspect extension in Chrome. The following image should help you out:
By default, screenshots are saved in the Edge Inspect subfolder in the Documents (Mac OS X) or My Documents (Windows) directory , which you can view by clicking on the Open folder containing screenshots button (the fourth button at the bottom) in the Edge Inspect extension in Chrome. The following image shows it. All the screenshots are saved in the folder with some metadata in separate text files.
You can also specify your own folder to save the screenshots. For that follow these steps:
Right-click on the Edge Inspect extension icon in Chrome and select Options.
Then under the Screenshots Folder section click on the Edit button.
Enter the path of the folder where you want to save the screenshots and then save it.
The following image shows the process:
With a single click on the full screen toggle button (the second button at the bottom) in the Chrome Extension menu on your computer you can toggle between the full screen views on all your paired mobile devices. The following screenshot shows the full screen toggle button in Chrome:
So when you click for full screen view, the menu bar in the Edge Inspect mobile app is hidden. This provides more real estate or viewport height to test your projects. The following image shows the resultant view in the paired iPhone after the full screen button is clicked in the Chrome extension:
When you browse a page in Chrome that requires HTTP authentication, you will see a login form in the paired Edge Inspect devices. Enter the same username and password to open the page in the connected mobile device. After that you can start remote inspection and debugging as usual. The following screenshot shows this:
Use unsigned SSL certificates during development. When your browse a page in Chrome that requires you to accept a certificate, the connected Edge Inspect devices will provide a dialog prompting you to accept an unsigned certificate. After accepting the certificate on your mobile you can start remote inspection. The following screenshot shows this:
