On February 2nd we will host the first conference from a series of conferences about web technologies and development. Our presenter will be Vincent Hardy, principal scientist at Adobe Systems.

See you on February 2nd!

You can find more info about this conference and register here (the presentations will be in English).

PS. I am so happy to see this finally get started as I’ve been working on it for some time.

If you want to learn how to use PhoneGap to build mobile applications with JavaScript and HTML, one good way is to watch this great series of nine videos. My fellow evangelist Kevin Hoyt spent some time in the studio for shooting and the result is great. It will take you less than a hour and a half to watch all the videos.

Here is the list:

1. Getting Started with PhoneGap

2. Developing for iOS

3. Developing for Android

4. Device API

5. Accelerometer API

6. Camera API

7. Compass API

8. Connection API

9. Contacts API

In  a previous post I explained how you can use weinre to remotely ”debug” web pages that run on your mobile devices. If you are familiar with weinre then you also know its biggest limitations: no JavaScript debug support and CSS styles introspection.

Now there is no need to be sad if you happen to have a PlayBook device. If so, then you are back in business. What do I mean by that? I mean full access to Web Inspector/Developer Tools goodies while browsing web pages on the PlayBook tablet. Yes, including JavaScript debugging and CSS introspection.

A question or a doubt might pop in at this point … how this could this be possibly useful for developing web applications that run on mobile devices when Android and iOS devices have the greatest market share? Relax my friend, no need to lose your faith :D Because iOS, Android, and PlayBook default browsers are all based on WebKit. Although there are some differences between them I think they are close enough that you can get lots of value out of using the PlayBook device as the “debug” mobile platform. It also performs fine, at least today. I mean it is not too far off from the latest mobile phones or tablets.

So let me guide you through the steps you need to complete if you want to remotely debug web pages using a PlayBook.

1. Get a PlayBook

The most important step is actually getting a device :D. You might be able to buy a used one for a good price. I think it is a good investment if you plan to (or  you already) do lots of mobile web development.

2. Connect the PlayBook and your computer to the same WiFi network

This is another important step. The PlayBook browser has Web Inspector support. While you can use it directly on the device I bet my 2 cents that it is far more convenient to use it on your computer. So this is the reason you need to connect them to the same network

3. Enable Web Inspector on your PlayBook

Set up a password for your PlayBook if you haven’t already set one (Settings > Security > Password). Then open the browser application and go to Settings. Select Privacy & Security and then enable Web Inspector (it will ask for your password when enabling this option).

Once you enter the password a message window will give you the IP and port number of the PlayBook Web Inspector. Write down this info because you will need it.

4. Load the page you want to debug/profile

Now it is time to get serious. So open the web page you want to debug in the PlayBook browser. Please note that it is possible to open up a web page hosted on your computer web server (remember that the PlayBook and your computer are connected to the same network; so if you have a web server running on your computer you will be able to access it from your tablet).

5. Start Web Inspector

You can do this in two different ways. If you are a masochist you could use the Web Inspector on the PlayBook: open a new tab in your browser and type in this URL http://localhost:1337. You will see a page that has an entry for each opened tab in your browser (the URL must be opened after you enable Web Inspector in order to be listed). Here is an image to get an idea:

And here is the Web Inspector running for the first tab on my PlayBook on the PlayBook if you know what I mean:

But probably the sane way to do it is to run the Web Inspector remotely on your computer. So open a browser and type in the URL you got from Step 3. Once it is loaded you can select the tab you want to debug. And once you select the tab the Web Inspector should be displayed. From now onit is business as usual: you can access Elements, Resources, Scripts, Timeline, Profiles, Storage, Audits, and Console. You can debug the JavaScript code, audit the page for performance, and all sorts of magical things.

Here are screenshots with the Web Inspector running on my machine and the page I am debugging on the PlayBook. In the Web Inspector I selected a DIV element and you can see that the element was highlighted in the PlayBook browser.

Word of warning: it might take a while for the Web Inspector to initialize on your machine. Be patient and don’t give up.

Conclusions

If you are not excited by this amazing workflow then there must be something wrong with you (or you are not a web developer and then it is OK :D). Again it might not be the perfect solution. I mean in a perfect world you’d have something similar for each mobile platform. Until then don’t whine too much and do your work with what you got!

Here is a screencast that takes you through the setup steps of the PlayBook Web Inspector and shows a simple debugging session. Enjoy!

While using Canvas 2D context for drawing stuff I discovered that the drawing line API can surprise you a bit especially when drawing horizontal or vertical lines. Here is a screenshot with a Canvas element and 5 lines drawn using lineTo() calls:

In case you haven’t noticed, let me tell you what’s wrong with this: the lines are suposed to be 1 pixel width and black. Clearly what you see on the screen is not 1 pixel and the lines are somehow grayish. It looks more like 2 pixels. The code for drawing this looks like this:

<input onclick="draw()" type="button" value="draw" />

<script type="text/javascript">// <![CDATA[
function draw() {
    var context, i, y;

    context = document.getElementById('canvas').getContext('2d');
    y = 20;
    context.lineWidth = 1;
    context.strokeStyle = '#000000';
    for (i = 0; i < 5; i++) {
       context.moveTo(0, y);
       context.lineTo(450, y);
       y += 10;
    }
    context.stroke();
}
// ]]></script>

Let’s change the line width to 2 (line 10 in the above code snippet) and check the result:

Interesting, isn’t it? So the lines width is basically the same, but the color now is really black. Now, let’s try something else: change the line width back to 1 and adjust the y property of the moveTo/lineTo functions with o.5 (line 13/14):

context.moveTo(0, y + 0.5);
context.lineTo(450, y + 0.5);

And surprise, surprise the lines are now exactly 1 pixel and black:

So what’s happening? After some research I think that this is what is happening:

• When you use integer coordinates like 10 or 15 the drawing algorithm is actually trying to draw a line in between two pixels (for example between the 9th and 10th pixels). As a result it will actually draw two lines.
• I think the line is slightly lighter than the color set because of the antialiasing algorithm.
• When you offset the coordinates by 0.5 then you “end” up with drawing the line exactly on one pixel.
• If you draw a 1 pixel vertical line from (0,0) to (0,200) you will see that this time the line is exactly one pixel wide but the issue of lighter than defined color remains. As there is no other pixel to the left of the 0 pixel on the X axis on the screen you will see only one line.

Using fillRect() function instead of lineTo()

If you don’t like adding those 0.5 to any coordinate when using the lineT0() API then you can actually use the drawing rectangle API. As you probably already guessed, the trick is to draw a rectangle of one pixel for one dimension and the length you need for the other one. So here is the script for drawing 5 horizontal lines:

function draw() {
    var context, i, y;

    context = document.getElementById('canvas').getContext('2d');
    y = 20;

    for (i = 0; i < 5; i++) {
       context.fillRect(0, 10 + y, 450, 1);
       y += 10;
    }
}

And here is the result:

If you are wondering about performance differences between lineTo() and fillRect() then you shouldn’t. fillRect() is probably even faster than lineTo().

You can see here a page that illustrates the differences between lineTo() and fillRect() when using integer coordinates.

If you are a web developer chances are that Google Chrome Developer Tools, Safari Web Inspector, or a Firefox equivalent are your best friends when it comes to debugging web pages (check CSS styles, verify generated HTML, or debug JavaScript). Isn’t that great? I mean not so long ago we used to debug JavaScript using alert() calls.

Once you get used to these tools it is hard not to have them. And this is exactly what happens when you move to mobile web development. As you probably know there is no web inspector running on your iOS device browser.

How do you debug your web apps when running on mobile devices? The best answer to this question is using weinre (if you know a better way, please let me know).

What is weinre?

weinre is a remote Web Inspector that runs on your computer but it is connected to a browser (or a PhoneGap application) that is running on a mobile device. In terms of user interface it reuses the Web Inspector project at WebKit.

weinre consists of a debug server that runs on your computer and a user interface that also runs on your computer. The server component is able to communicate with the web page you are “debugging” (that typically runs on a mobile device) thanks to a JavaScript script that you have to inject in the page you want to debug (the script is served by the server component). And here comes the first thing you have to know: because of this architecture your mobile phone must be able to reach the server running on your computer (you can easily achieve this by connecting the computer and mobile device to the same WiFi network). If you are curious about how the web page running on the mobile device is able to communicate with the debug server, the answer is using XMLHttpRequest.

Finally, weinre is distributed either as a Java JAR file or as a Mac OS X application. This means that you can use this tool on a Windows, Mac OS X, or Linux machine.

Are there any limitations?

Unfortunately there are: you can’t debug the JavaScript code. This means you are not able to set breakpoints in your JavaScript code and introspect the variables. Unfortunate though this limitation might be, weinre is still incredibly useful because you can introspect the HTML code, see the Console output, execute JavaScript code in the console, get information about the XHR calls made by your page, and even select DOM elements.

How can you use it?

Here is a step-by-step list that explains how you can use weinre to “debug” a web page that is running on your mobile phone:

1. Download the weinre debug server application

First download the weinre application (this will be basically the debug server). I will use the Mac OS X application instead of the JAR file and I will point out what is different if you use the JAR file.

2. Connect the computer and mobile device to the same WiFi network

After you download the weinre file it is time to connect your computer and mobile device to the same WiFi network. Once the computer is connected, it is time to find out what IP address it is using. On my case the IP address is 42.1.2.250.

3. Configure the weinre debug server application

Now, it is time to configure the weinre debug server. Because I am using the Mac OS application, all I have to do is to create a server.properties file in the following location: ~/.weinre/server.properties

Next, open the server.properties file and add these two lines (for boundHost you have to introduce the IP address of your computer and for httpPort you can use any port number you want that doesn’t conflict with other web servers that might be running on your computer):

boundHost: 42.1.2.250
httpPort:  8080

Make sure you save the file.

If you use the JAR file, then you can set the options either using the server.properties file or adding them as options to the command line when invoking the JAR file.

4. Start the weinre debug server

For the Mac OS X app all you have to do is start the weinre application. If you use the JAR file then you should start the application using the command line.

5. Inject the JavaScript file in the web page you want to debug

With the debug server running it is time to inject the JavaScript file that makes all the parts to communicate. To do so, open the HTML page you want to “debug” and add this line:

<script src="http://42.1.2.250:8080/target/target-script-min.js#anonymous"></script>

Please note that the IP address and port number must match the values you set in the server.properties file. Make sure you save these changes.

6. Make the web page available to your mobile phone

Now, you are ready to debug the web page. However, in order to do this you have to load this page in the browser that runs on your mobile device. You will have to copy the web page and its dependencies to a web server running on your computer. In my case I’m running a MAMP instance on port 80. So what I’ve done is to copy the folder where I created the web page to the htdocs folder of the MAMP. Make sure the web server you want to use is running.

7. Load the web page on your mobile device browser

Open the browser on your mobile phone and load the page: http://42.1.2.250/weinre/index.html

Please note the IP address and port number must be your computer IP address and your web server port number (in my case I am running on the default port so there was no need to add it) and the rest of the URL must match the folder/file name you have.

8. Debug the page

Once your mobile browser loads the page, the weinre application should look like this:

In the picture above Targets refers to the mobile device browser (so the IP address is your mobile device IP) and Clients refers to the debug client/server.

Here is a screenshot with the weinre application when the Elements tab is used and the console is opened too. You can see that the whole body element is selected. And in the console you can see some outputs. These were dysplayed once I hit the two buttons I have created in the web page.

And here is a screenshot of the web page running on my Android phone. As you can see the body is selected – because in the weinre app the body element was selected.

Finally, the web page used in this example looks like this:

<!DOCTYPE HTML>
<html>
<head>
<meta charset=”UTF-8″>

<title>Testing</title>
<script src=”http://42.1.2.250:8080/target/target-script-min.js#anonymous”></script>
<script>
function clickBtn() {
console.log(‘clickBtn() was called!’);
}
function click2Btn() {
console.log(‘click2Btn() was called!’);
}
</script>
</head>
<body onLoad=”init()”>
<h1>A simple page</h1>
<h2>To test weinre – Web Inspector Remote</h2>
<button onClick=”clickBtn()”>Click Me</button>
<br>
<button onClick=”click2Btn()”>Click Me Too</button>
</body>
</html>

If you use the JAR file, then you should open on your computer this URL: http://42.1.2.250:8080/client/#anonymous. Again change the IP address and port number to what you configured for the weinre debug server. Here is a screenshot with the debugger client opened in my browser:

For your convenience, I captured this workflow in a short screencast:

Conclusions

Although you don’t get all the features available in the desktop Web Inspector, weinre is still a formidable asset in any developer’s toolbox. I mean without this you would have to use alert() or some other ten times more time consuming technique. Recently I was working on a web mobile application and weinre came to my rescue on a number of occasions.