Tuesday, June 26, 2012

Dynamic, asynchronous websites made simple with JSONP

I remember the first time I discovered the potential of XMLHttpRequest. It was mind-boggling. I was in heaven with all the stuff I could do. I played like a kid in a candy store until, suddenly, cruelly, I ran headlong into two major problems with XMLHttpRequest:

  1. You couldn't get info from anything but the originating server
  2. XML stinks.

And then one day, I stumbled upon JSONP. I still remember the day. I had been working with the Google AJAX APIs, and I wanted to know how they got around the two inherent limitations in what I understood to be AJAX. So I dug into their obfuscated code and watched their network traffic for hints. And there it was: they didn't use XMLHttpRequest or XML.

Instead, they used a method called JSONP. (They just called it AJAX because that was the major buzz word at the time.)

JSONP is really a very simple, elegant, and flexible way to communicate dynamic data between client and server. And it's fast. Because it uses JSON rather than XML, the data transfers are smaller and the time it takes for the Javascript engine to parse the data is dramatically shorter. So in comparison to traditional "AJAX," JSONP screams.

Why is it, then, that most people haven't heard of JSONP? And why is it that, whenever I suggest it to people, they stare at me with this blank expression on their face as though I was speaking in some alien language?

Well, the only reason I can come up with is that "AJAX" is the buzzword. It just sounds a whole lot more cool (and clean) than JSONP. And so, since most people have heard only of AJAX, it actually is as though I'm speaking in some alien language when I suggest JSONP.

So let's fix both of these problems in one shot. From here on out, we'll call JSONP the "Super Spiffy Way To Communicate Data Between Your Client And Your Server" (SSWTCDBYCAYS).

Okay, let's not do that.

Seriously, though. Let's see if we can't figure out this mysterious thing called JSONP quickly and easily, once and for all.

In any dynamic web application, there are two sides of the equation: client and server. The client side is what's going on in the user's web browser. The server side is what's going on in - you guessed it - my web server. For the sake of this discussion, we're going to start on the client side, with the Javascript, since that's where the bulk of the hocus-pocus happens.

On the client side, everyone knows that an HTML page is comprised of a series of elements formed into some semblance of a hierarchical structure. (It doesn't matter if you don't get that. Just pretend and keep reading.) Some of these elements can instruct the browser to fetch additional resources from the server. For instance, <img> tags tell the browser to ask the server for an image file; <link> tags can ask the server for a CSS stylesheet, and <script> tags can order the browser to fetch a Javascript file. That last one right there is the key to JSONP.

You see, the secret to the black magic of JSONP is that you can use Javascript to dynamically construct additional <script> elements to append to your page. And the browser will obediently go and fetch those scripts from the server whenever you do.

So all we have to do is write a little Javascript function that uses DOM methods to build and append a new script element to the page. Something like this:

function do_json(url){
  var el = document.createElement('script');
  el.src = url;
  el.type = 'text/javascript'; // gotta be PC here!
  document.getElementsByTagName('head')[0].appendChild(el);
}

Now, any time you want to fetch information from the server, all you have to do is call do_json(<url_of_the_js_file_i_want>); .

Of course, that doesn't help us a whole lot if the server returns a blank stare. So for the next step, we have to turn to the server, where we write a script or program that will get data from any source you can dream up (e.g., database, XML, thin air, subspace transmission from Starfleet Command) and return it in a JSON format.

JSON, by the way, stands for JavaScript Object Notation. It's essentially a string which represents a Javascript object. Something like this:

{
  "name" : "Jeremy",
  "rank" : "Generally Cool Guy",
  "serialNo" : "1234567890"
}

That is a very simple JSON string representing an object with three properties: name, rank, and serialNo. So the bulk of this step in the JSONP process is getting my server to return data in that sort of format. Of course, exactly how you will do that will depend on your backend and language of choice. So I will let you Google how you might do that.

Once you figure out how to get your server to return JSON, we still have a problem. Simply returning JSON to the browser is like taking a phone message without writing down who it's for. Now, you could set the message on the corner of your desk in the hopes that the right person will happen by, notice it there, and grab it. But the chances of that happening are pretty slim. So our server has to be a little more specific. Namely, it has to encapsulate the JSON string in a Javascript call. So instead of the string we had above, we end up with something like this:

my_callback({
  "name" : "Jeremy",
  "rank" : "Generally Cool Guy",
  "serialNo" : "1234567890"
})

Now, that should look familiar. It's plain Javascript. You're calling the function my_callback and passing it the Javascript object you created above. Simple enough.

The problem now is that my_callback isn't home on the client-side just yet. So let's add it to the client-side Javascript code that we had before.

function my_callback(response){
  // do something!
}

All of a sudden, my_callback is eagerly awaiting its message, and as soon as it gets it, it can take off running.

Now, this is just the tip of the iceberg. Because the actual body of the server's response could be an array, an object, a number of arrays or objects, or any number of other things. And you could use it to rewrite your page, update particular elements, and much, much more. The sky is the limit! And because you're not using the SOP-restricted XMLHttpRequest, you can request data from any server on the web, making it possible to create services on one server which can be utilized from any number of sites. And it's a whole lot faster, to boot!

Once you grasp the concept of JSONP, your mind will just start seeing possibilities for uses. Search engines. Maps applications. Updating content. The list is virtually endless.

Well, folks. That's all the time we have for today. We hope you've enjoyed the broadcast! Please tune in next time as Jeremy writes about taming your very own water buffalo!

Thursday, June 14, 2012

Google I/O 2012 expectations

So, I happen to be one of the lucky 5,500-ish people who has a ticket to Google I/O 2012. That is, if the confirmation email I received is to be believed. This will mark the fourth time I've trekked to San Francisco and the Moscone Center for what has become one of the most anticipated technology events of the year. (In fact, you could probably make an argument that it is the most anticipated tech event, but I will leave you to decide how it ranks with CES and WWDC, etc.) But this year is different in a number of ways for me.

In the past, while I have always looked forward to the tech stuff, I/O has been an annual opportunity to meet friends from around the globe that I never see otherwise. This year, however, none of my friends are making the trek for I/O.

Also in the past, I have scheduled flights to and from SFO so that I would be there and back as quickly as possible (i.e., I arrive late afternoon/evening the day before and depart early morning the day after). However, this year, the airlines have left me with what is going to amount to a half day of nothing on either end of the trip. So I may actually have a chance to get out to see a couple of sights.

I suppose, though, that all of that is a moot point. And it's probably not why you're reading this post. With less than two weeks to go before the opening keynote of I/O 2012, you're looking for what I'm expecting to see and hear coming out of the Great Big G. So here are some thoughts that I've been contemplating.

  • Android. It is a foregone conclusion that Google will use I/O, as it has each of the last three years, to preview the next iteration of the Android operating system. I expect we'll hear some astounding activation numbers and see some awesome developers spotlighted. But what I am really looking for is some sort of plan to stop Android fragmentation. Clearly, with any open platform, there is going to be fragmentation as companies try to distinguish their products, but when I bought a Samsung Galaxy S phone from my cell carrier 2 years ago, I expected that it would be stable and receive updates in a timely manner. To the contrary, while the phone is stable most of the time, I am still compelled to remove the battery every few days because it's frozen or going berzerk. The Froyo update, which was released nearly 9 months after the fact, was such a disaster that I skipped it altogether. And the Gingerbread update, while fixing some bugs, came only after Ice Cream Sandwich was already in the wind and included issues of its own. And then there was the fact that I had to use Samsung's Kies software to install the updates. Kies, however, does not run on my Mac. And I was never able to get it to perform the updates on a PC. So I want to see a mandate that Android phones will receive automatic OTA updates of at least the base platform in a timely manner.
  • HTML5. With the introduction of MSIE9, HTML5 became a viable option for a wide variety of things. I am looking for Google and others to provide insight into what browsers will be doing to push the envelope over the next year. I'm particularly interested to hear about advanced filters in CSS3 and such.
  • Chrome OS. I have been a fan of Chrome OS since it was first officially announced. I have a CR-48 that I use frequently. I had a Samsung Series 5 Chromebook, but I gave it to someone who needed it. The lightweight platform has very real potential for those who live, primarily, in the cloud. However, adoption has been somewhat lackluster. I am therefore concerned that the big G will grow weary of maintaining two complete operating systems (i.e., Android and Chrome OS). So I will be listening for a sense of direction on that front. I hope that Chrome OS does not go the way of Wave and Buzz and such.
  • Performance. Over the last couple of years, I have been spending increasing amounts of time working to optimize my web applications and sites for performance. It's like a challenge to trick out every bit of speed I can. (Some people do this with lawnmowers or cars; I do it with web stuff). So I'm looking to learn a lot about what the Chrome team and others are doing to ramp performance in the browser.
  • Brainfreeze. I hope to learn so much that my brain seizes sometime during day 3 of I/O. That's right, they added an extra day!

So, that's about it for my expectations. I would love to hear what others are anticipating at I/O!

Monday, June 4, 2012

What I learned about the canvas element

So, I am apparently a sucker for challenges. A couple of weeks ago, my friends at the Des Moines Web Geeks issued the challenge to re-build in Javascript a simple dungeon game, which one of the organizers had built with his son in Python. I was unable to be at the coding dojo itself, but I joined in via Google Hangouts. And for some reason, I was hooked on the challenge.

But it was more than just the notion of rebuilding this simple game. The idea behind the whole thing was to teach someone how to code, a prospect which I have long thought to be a distinct challenge for our times. And we were supposed to use OOP JS as much as possible, something which I really enjoy. And then there was the fact that, beyond the basic parameters of the game, the concept was left wide open, which immediately got my imagination going.

So I decided from the very start that this little game, for me, would have two primary objectives:

  • I would learn something
  • Someone else would be able to learn something

For the thing that I would learn, I decided I would explore canvas to build a dashboard of sorts to display at a glance the status of the current player, the monster in the room, and a map of the world. Namely, since I had never before utilized the HTML5 canvas element in any project, I wanted to learn some of the basics and then explore just what the thing could do. I was incredibly pleased with what I came up with, and I wanted to share just a couple of quick lessons that I learned in the process.

The first lesson has to do with the canvas element itself. When I first started using canvas, I was simply putting the basic element into my HTML and then setting width and height with CSS. At first, things looked great. But as soon as I started drawing in the canvas, I realized that something was messed up. The images were distorted somehow. For example, a 5px vertical stroke was thicker than a 5px horizontal stroke. And then I noticed that filled rectangles that should have filled the entire canvas were all messed up. And I was compelled to realize that, somehow, there was a discrepancy between the internal dimensions of the canvas (i.e., how many pixels it thought it had) and the external dimensions of the canvas (i.e., how many pixels the page thought it had).

Sadly, it took me quite some time to find a tutorial or other documentation which acknowledged what I thought must have been an issue. But it wasn't an issue. Rather, it was a design feature of the canvas element.

<sarcasm>Imagine my surprise.</sarcasm>

So here's the deal. The canvas element's height and width attributes (i.e., the height="xxx" width="yyy" bits you put in the HTML) set the dimensions of the drawing space within the canvas element. While the CSS height and width rules set the dimensions of the element in relation to the rest of the page. The thing is, those two things don't necessarily correspond.

In fact, the canvas element, regardless of its size in the CSS, will have a drawing space of 300 pixels wide and 150 pixels in height. Unless, that is, you specify otherwise. The question is, how do you do that? Well, there are two options.

The first option is to specify it in the markup. Namely, by providing the height and width attributes in the opening tag, like this:

<canvas id="myCanvas" width="1000" height="1000" />

That's not so difficult. But what if you want the canvas drawing space to be exactly the same as the canvas element's actual dimensions on the page? And what if the actual dimensions are given in a percentage or may change? Try something like this in your JS onload callback (or onresize, etc.):

var el = document.getElementById('myCanvas');
el.setAttribute('width', el.offsetWidth);
el.setAttribute('height', el.offsetHeight);

And there you have it. One of the things I learned about canvas elements while playing with this simple little game.

i love my wife