Introducing Theseus – an open source JavaScript debugger

This is really hot news! We’ve just announced Theseus, an open source JavaScript debugger that might change the way you debug web apps. This is a project developed in partnership by MIT and Adobe.

The main difference is that Theseus allows you to better understand how the code was executed in terms of number of calls for each function and how the calls were chained together, all of this while running the page in Chrome or Node JS. You can click on any call of a function to inspect the arguments and return value.

Theseus can be integrated with Brackets. You can install it from the extension manager.

Continue reading

Infinite timeline scrolling chart with HTML/CSS/JS

Awhile ago, my fellow evangelist Christophe Coenraets created a cool desktop application (and later a mobile version) as a concept of how an application used by sales people could look in the 21st century. Part of that app was a nice chart that allowed you to quickly see all the projects while swiping back and forth on the timeline.

Now, that little piece was developed using the Flex framework. In a moment of complete boredom I decided to recreate the chart part using HTML, CSS, and JavaScript. And to make things more interesting, I wanted the same code to run on desktop and mobile devices (tablets and smartphones).

Continue reading

aTabSplitter – the web standards edition

I thought that it would be helpful to document the experience I had while building a web application using jQuery Mobile. And this is what this article is all about. But before going into details let me set the context.

I started building mobile applications a while ago using Adobe AIR and the Flex framework. My first “production ready” application was called aTabSplitter and it is available for download in Android and BlackBerry markets. It was a fun and eye-opening experience. I mean it is one thing “to play” with technology and an entirely different thing to build something that will be actually useful and people will love to use.

Recently, as I was playing with jQuery mobile I had an idea: what if I tried to rebuild the application using HTML, CSS, and JavaScript? To make things more complicated I wanted to retain the same UI and user experience. In other words I treated the mobile application as the design and user workflow diagrams you’d get from a UX.

If you haven’t tried the application yet let me briefly describe it: it allows you to split a restaurant bill. The important workflows are the first screen, where you add new persons, delete them, move them around the table, or adjust the tip, and the calculator screen where you add the items for a single person. Actually, I am pretty proud because I think I found a good/intuitive user interface.

And by the way, here is the link for this web app.

Here are screenshots with the application running on desktop and mobile devices.

 

Android 4 Phone:

 

On iPad:

 

Continue reading

Quick hack to deal with touch and mouse events

If you build web pages that are interactive and work on desktops and mobile devices then chances are that you need to work with touch and click events. For mobile devices you’d want to use events like touchstart, touchmove, and touchend and for desktops you’d use mouse events (mousedown, mousemove, and mouseup).

Most of the time the code you execute as a response to these events is the same between these two platforms. So one way to avoid duplicating your code is to take advantage of the JavaScript’s dynamic nature to inject additional data into the event object and chain the click and touch event listeners.

Here is a snippet of code that illustrates my point:

[code lang=”js”]
function init() {
   var el = document.getElementById(‘myDiv’);
   el.addEventListener(‘mousemove’, onMouseMove);
   el.addEventListener(‘touchmove’, onTouchMove);
}

function onMouseMove(e) {
   e.touches = [{clientX: e.clientX, clientY: e.clientY}];
   onTouchMove(e);
}

function onTouchMove(e) {
   //do something with e.touches[0].clientX or e.touches[0].clientY

}
[/code]

The code should be pretty simple to follow:

  • I register listeners for mousemove and touchmove
  • If the code runs on a desktop then the mousemove listeners will be triggered. When this happens I inject the mouse X and Y position in the event object using the data structure used by touch events (touch events have a touches property, which is an array of objects that follow this pattern: {clientX: value, clientY: value}). The touches property is an array because you can expect more than one touch point on some devices. Then I call the onTouchMove function passing along the modified event object
  • The logic I want to execute for that specific action is declared in a single place, the onTouchMove function

I put together a simple page so you can see the code and test it on you computer/devices: demo here.

What method do you use to deal with this?

Debugging web pages remotely using a PlayBook tablet

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.

Continue reading

Canvas Quirks

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:

[code lang=”js”]

<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>
[/code]

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:

[code lang=”js”]
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;
   }
}
[/code]

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.

Debugging Web Pages and PhoneGap apps on mobile devices

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).

Continue reading

CoffeeScript or JavaScript?

Recently I played with CoffeeScript a bit. Friends were talking about CoffeeScript and also I read couple of interesting blog posts. Based on my limited experience with it here is my understanding of what is cool and not so cool.

Cool:

  1. It is much more compact than JavaScript. This translates to up to 1/3 less lines of code than the equivalent JavaScript
  2. Offers the concept of classes – something that is familiar for people coming from the Java world
  3. Insulates you from JavaScript pitfalls like global scope
  4. Some times you can get a performance boost – hard to tell when and by how much
  5. Some compile-time error checking, which helps you to write code with fewer bugs right off the bat

Not so cool:

  1. Hard to debug. You have to debug the generated JavaScript code and from there you have to trace back to the CoffeeScript code
  2. Writing less code can actually be something bad. Anyone remember Perl? And how hard it can be to read Perl code?
  3. Adds another layer of abstraction on top of the browser stack. Adding to this jQuery or other frameworks and you can easily be in a situation where you can put together reasonably complex apps but you have no idea of what is happening under the hood nor how to fix a bug that originates from the frameworks you used
  4. While I understand from why is done the way it was, I still think it would have been nice to have optional data typing

Maybe not so surprisingly , I’ve seen people coming from OOP languages (Java or C#) that totally love CoffeeScript and this is their preferred way to write JavaScript apps.

As I said, I just played with it. So if I misunderstood something or completely missed a point please let me know.