Sergio Pereira : HTML5

Chrome Extension Development

sergiopereira — Tue, 29 Jun 2010 03:20:00 GMT

Do you like JavaScript? Have you been looking for a reaon or an idea to learn and start using HTML5? Google Chrome extesions are a great way to get into HTML5 and all its new APIs with bite sized applications.

Anatomy of a Chrome Extension

A Chrome extesion is nothing more than a tiny website that runs hosted inside Chrome. Like any website, it consists of regular web components. Grossly simplifying it is just a directory full of files, such as JavaScript, CSS, images, HTML5, and anything else you usually add to a web page.

Because it runs inside the browser, you have access to things like browser events, browsing history, and open tabs.

Essentially, your extension gets loaded as an HTML page called background.html where you can put any common/global functions and variables. This page is never visible and even if you don't provide a background.html in your extension, Chrome will load an empty one for you. All other pages in your extension can access the background page's functions.

Here's a diagram of a common scenario.

Today's Brew

Our sample extension will be something simple but that at the same time will let us explore interesting aspects of extensions development, namely local storage and cross-domain requests.

The sample is also a hat tip to the valuable work Chris Alcock does with his The Morning Brew, collecting some of the best links for all of us.

What we will do here is create an extension that will show us his latests links at the click of a button.

Introduce yourself

The extension needs to inform Chrome a few details about itself, such as name, default icons, along with any permissions it requests to access privileged browser features. This is done through the manifest file, which is just a JSON document. Here's our manifest file, aptly named manifest.json.

{
  "name": "Today's Brew",
  "version": "1.0",
  "description": "Latest links from The Morning Brew.",
  "icons": { 
    "48": "icon48.png",
    "128": "icon128.png" 
  },
  "browser_action": {
    "default_icon": "icon.png",
    "default_popup": "popup.html"
  },
  "permissions": [
    "http://feeds.feedburner.com/",
    "tabs"
  ]
}

What you can do

Extensions can perform several different jobs, like showing notifications, providing new themes, changing some of the default Chrome pages, etc. One other thing they can do are the browser actions, which basically means adding a button to the toolbar that acts independent of what page is being shown, as if it were just another browser feature.

If you look at our manifest file you'll notice we declared a browser_action, with its icon and the page it opens wen clicked.

Our extension does not have a custom background page, we will just rely on the default one Chrome will give us and put all of our logic in the popup page that we will open.

What you need to do that

Here's how our extension will look like when we're done.

In our extension, other than manipulating our own extension's HTML dynamically (which doesn't require any special permissions) we will need to fetch the RSS feed from Feedburner and eventually open new tabs as the user clicks on the links.

That's what you can see in the permissions section of the manifest file above.

Getting down to business

To create our extension we start by creating an empty directory and adding our manifest.json file and all the icon image files that we mentioned in that manifest file.

Then we create our popup.html file, which will be pretty empty and will be populated with the content we will retrieve from the RSS feed. Here's that file.

<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript" src="popup.js"></script>
<div id="main">
  <h1></h1>
  <div id="content">
  </div>
</div>

As you can see, we will be using jQuery so we should also add that file to our directory. We will leave all the beautification of the popup in the popup.css file, which I won't bother showing here; you can download it along with the rest of the code at the end of this article.

The other file referenced by the HTML is popup.js. That's where all the action happens.

$(document).ready(function(){
  SERGIOPEREIRA.samples.todaysBrew.init();
});

var SERGIOPEREIRA = {
  samples: {
    todaysBrew: {
      state: { },
      feedUrl: 'http://feeds.feedburner.com/ReflectivePerspective?format=xml',
      todaysUrl: '',
      maxAgeHours: 12, // keep it for 12 hours
      
      init: function(){
        $('#content h3').live('click', function(){
          $('#content ul:visible').slideUp();
          $(this).next().slideToggle();
        });

        $('#content li a').live('click', function(){
          $('#content ul:visible').slideUp();
          chrome.tabs.create({url: this.href});
        });

        $('h1').click(function(){
          chrome.tabs.create({url: SERGIOPEREIRA.samples.todaysBrew.todaysUrl});
        });
        
        if(typeof chrome != 'undefined') {
          this.state = localStorage.getItem('latestBrew');

          if(this.state){
            var now = new Date();
            var minTimestamp = new Date();
            minTimestamp.setHours(minTimestamp.getHours() - this.maxAgeHours);
            minTimestamp = minTimestamp.toJSON();

            if(this.state.timestamp > minTimestamp) {
              this.renderLatest(this.state.latestData);
              return;
            }
          }
          this.refresh();
        }
      },
      refresh: function(){
        console.log('will get feed data...');
        $.get(this.feedUrl, function(xml, status, xhr){
          SERGIOPEREIRA.samples.todaysBrew.update(xml);
        });
      },
      update: function(feedXml) {
        var latest = this.getFirstItem(feedXml);
        this.state = { };
        this.state.latestData = latest;
        this.state.timestamp = new Date();
        localStorage['latestBrew'] = JSON.stringify(this.state);
        this.renderLatest(latest);
      },
      renderLatest: function(latest){
        $('#main>h1').text(latest.title);
        $('#content').html(latest.content);
        this.todaysUrl = latest.url;
      },      
      getFirstItem: function(feedXml){
        var items = feedXml.evaluate("//channel/item", feedXml, 
                                 null, XPathResult.ANY_TYPE, null); 

        var item = items.iterateNext(); 
        if (item) {
          return this.createItem(item);
        }
      },      
      createItem: function(postXml) {
        return { 
          title: this.readElementText(postXml, 'title'),
          url: this.readElementText(postXml, 'feedburner:origLink'),
          content: this.readElementText(postXml, 'content:encoded')
        };
      },
      mapElements: function(contextElement, path, map){
        var result = [ ];
        var items = contextElement.ownerDocument.evaluate(path, contextElement, 
                                this.namespaceResolver, XPathResult.ANY_TYPE, null); 
        
        var item = items.iterateNext(); 
        var i = 0;
        while (item) {
          result.push( map(item, i++) );
          item = items.iterateNext();
        }

        return result;
      },      
      readElementText: function(contextElement, path){
        var results = contextElement.ownerDocument.evaluate(path, contextElement, 
                                   this.namespaceResolver, XPathResult.ANY_TYPE, null); 
        var first = results.iterateNext(); 

        if (first) {
          return first.textContent;
        }
      },      
      namespaceResolver: function(prefix) {
        if(prefix == 'content') {
          return 'http://purl.org/rss/1.0/modules/content/';
        }
        if(prefix == 'feedburner') {
          return 'http://rssnamespace.org/feedburner/ext/1.0';
        }
      }

    }
  }
};

Wow, that's a lot of JavaScript at once, right? Hopefully you'll notice that most of it is just to parse the RSS xml.

Only a few parts of this code deserve commentary. The refresh method (line 45) is the one that retrieves the RSS data. It uses the jQuery.get method to do so. Once the data arrives, it will invoke update, which will use the parsing methods to get an object representing the latest news item in the data.

      update: function(feedXml) {
        var latest = this.getFirstItem(feedXml);
        this.state = { };
        this.state.latestData = latest;
        this.state.timestamp = new Date();
        localStorage['latestBrew'] = JSON.stringify(this.state);
        this.renderLatest(latest);
      },

The above code also shows the use of two important APIs that Chrome implements. The localStorage is a way to persist information that lives in the client machine and lasts even after the browser closes. We use it to remeber our last results and avoid fetching and parsing the RSS each time the popup is opened.

The other API is the native JSON object that can replace any dedicated library we are used to have in cross-browser websites. We need to stringify the data because we can only save strings in the local storage.

With the parsed data at hand we just need to replace the content in those empty html tags in popup.html with the information we have.

Adding some life with events

The last piece of this puzzle are the jQuery event handlers that we created in the init method. They make some of the elements clickable, including the links, which open new tabs using chrome.tabs.create(). Also note starting on line 29 that if we find recent local data we use that instead of refreshing the content from the RSS feed.

Let's load this thing up

Now we just need to run it and see how it goes. Go to the extesions page, expand the Developer Mode area and click Load unpacked extension....

Then simply browse to your extension's directory and select it. The extension should now be listed as seen below.

While you're developing your extension you can debug it using the developer tools included in Chrome. To do that, right click the extension button and select Inspect popup.

You can download the code for this extension and play with it all you want. I'm still early into learning this so feel free to give me pointers or ask questions.

The Ground is Shaking Again. Get Mobile.

sergiopereira — Thu, 17 Jun 2010 05:08:00 GMT

A little over two years ago I commented how surprising it was that VisualBasic was still more popular than C# in the .Net world. Back then I checked the TIOBE Index and saw that VB (in all its flavors) enjoyed almost 11% of relevance while C# wasn't even at the 4% level.

When we look at the June 2010 rank below we see that C# has finally caught up with VB, and it's safe to say C# is now the most popular .Net language (remember, the VB index is not made up of just VB.NET.)

1	Java	18.03%
2	C	17.81%
3	C++	10.76%
4	PHP	8.93%
5	(Visual) Basic	5.87%
6	C#	5.20%
7	Python	4.27%
8	Perl	3.20%
9	Objective-C	2.47%
10	Delphi	2.39%
11	JavaScript	2.19%
12	Ruby	2.07%
13	PL/SQL	0.79%
14	SAS	0.70%
15	Pascal	0.70%
16	Lisp/Scheme/Clojure	0.65%
17	Lua	0.59%
18	MATLAB	0.59%
19	ABAP	0.58%
20	PowerShell	0.53%

Again, anyone can debate the importance of this ranking system, but at least it has been there for a while and to me it seems to represent the pulse of software development quite well.

Movers and shakers

But this post is not about C# vs. VB.NET.

This time around what caught my attention was the impressive rise of Objective-C (up 36 positions in one year). Now, no matter how more common Macs have become in the last few years, no one will convince me this increase in Objective-C is due to native OSX application development :)

Of course we all know it's caused by the surge in mobile and device app development (iPhone, iPad, and anything that they decide will run the iOS, like the AppleTV in the future, who knows?)

If you look at the trending chart on the TIOBE page you'll see that Objective-C started to gain significant steam around June of last year, coincidentally (maybe not?) when the iPhone 3GS was announced.

Keep your eyes on the ball

Are you playing with Mobile yet? Have you:

Started reading about mobile development?
Developed a Mobile web site?
Written and tested a native app against a device emulator/VM (iPhone, Android, WebOS, WP7)?
Written and deployed an app to your own mobile device?
Published an app on the market?

It's not like you will find yourself out of a job if you don't get into mobile but for many developers, from software shops to corporate environments, sooner or later a request for a mobile product or a mobile version of an existing one will swing by your desk.

It's an exciting time. Once again you have the chance of taking the lead and play an important role in your team by staying ahead of the game. Remember when you started seeing request for Ajax and fancy UI's in your web applications. Remember how you were one of the few that knew anything about it in your team? Same thing here. Only much bigger.

What I'm looking into

There are two different fronts that interest me in mobile development: Native Android apps and Mobile Sites. I'll explain.

The time I spent in Objective-C and XCode in the past was enough for me to know I'd be grinding my teeth and blowing off steam every single day if I wanted to develop for the iPhone (it's probably just me, I can live with that admission.) Besides, I don't like the idea of an approval process before I can give away or sell my apps.

Windows Phone is something that I'll have to wait more and see what kind of traction it gains. It also has the approval process issue. The big plus will be the development tools, which I think will better than iPhone and Android.

All that, combined with the enormous momentum that Android has, made me start coding for Android when it comes to native apps.

Don't forget Mobile Web

Native mobile development is fun and rewarding but let's not kid ourselves. History shows that businesses will favor the simplicity of web development.

I went through that transition period when custom desktop application development quickly lost market to web applications. And that happened in a world where Windows was virtually in every workstation that mattered.

Now imagine the mobile scene, where there's more than one big player, none equivalent to what Windows was back in 1998. Do you really think anyone will want incur the cost of maintaining 3 or 4 different native versions of each mobile application that we will start cranking out like we do web apps today? Native apps will probably be the minority, for environments where you have the luxury of dictating your end-user's choice of mobile device.

Didn't we just spend the better part of the last 10 years trying to get out of a certain single-browser paradigm? Do we want to repeat that mistake?

Moving to HTML5

Why is HTML5 so important in Mobile and not as much in the standard Web yet? Well, for one there is a greater percentage of HTML5-capable browsers in Mobile than on the desktop browsers. Android, iPhone, WebOS (and soon BlackBerries) have WebKit browsers.

With things like richer forms, offline support, canvas, video and the Geo-Location API (not really HTML5 but present in those WebKit browsers) we can build really capable mobile web apps. Not just small screen versions of the regular web apps.

To be very straight forward about it, the way I personally see it is that HTML5 is where the bulk of the mobile development will happen in the Enterprise and consumer-facing applications.

Maybe something like Flash, AIR, or Silverlight makes a run for their mobile money too but with all the bullying from Apple and diverging opinions everywhere, that's not something I'm spending time on right now.

Native or Web?

Both. But definitely much more of the Web kind.