Blog Coding

Remove jQuery plugins at runtime

A good friend of mine asked me last week how she could remove jCarouselLite on the fly, after it had been instantiated. Allow me to share with you guys how to do this, and hopefully show you a trick or two along the way.

As you may know, a typical jCarouselLite plugin is instantiated as such:
$(function() { $(".anyClass").jCarouselLite({ btnNext: ".next", btnPrev: ".prev"}); });

where “.anyClass” is the name of your gallery container, “.prev” and “.next” are the gallery’s previous and next navigation links, respectively.

Removing the plugin at runtime is fairly simple once you understand what is involved:
$('.anyClass').jCarouselLite = null;

These 3 lines allow you to re-initialize jCarouselLite later on within the same page. Pretty simple and neat, isn’t it?
Let’s decompose what just happened so you may get a better understanding.
$('.anyClass').jCarouselLite = null; removes the jCarouselLite instance from our gallery. In other words, you will have to reinitialize jCarouselLite if you want to reuse it on this page for this gallery.
This isn’t all, however. When jCarouselLite is initialized, it creates what we call event bindings.
Whenever you destroy the jCarouselLite instance the bindings are still lingering and problems will start occurring if you re-initialize jCarouselLite on the same page, for the same gallery, as the click events on the navigation links will have been bound twice.
To prevent this issue from occurring, we add the two following lines:

Which brings me to one last pro-tip about dealing with groups and bindings.
There are two main ways to deal with group bindings in jQuery:
– The first one is fairly common. It consists of using a common class to all elements of a similar group.
$('.clickable').bind('click', function(){ alert("Hi, I'm clickable!"); });

In the code above, all elements of the class “clickable” will have the mouse click event bound (then unbound) to them.

There is however a second, more mystical way to do this in jQuery: Namespacing.
Let’s say you create an instant link preview feature that you want to disable and re-enable at will on your page. We will call our namespace “linkPreview”.
Here’s the event binding to our namespace:
$('a').bind('mouseover.linkPreview', myPreviewFunction);

And the event unbinding, just as easily:

This makes it easy to unbind only specific events from our elements. In this case, all other mouseover events would still be bound to our page links. Isn’t this amazing?


OS X 10.7 – What features can we expect?

Apple just announced their “Back to the Mac” event happening on October 20th, 2010.
The only hint at new features leaked to the press refer to a job posting. As is usual with Apple, the posting is about a “revolutionary” feature that will take over the world as we know it. Except, it’s Apple. We believe them when they say it.

So what is this revolution we will soon be dealing with? Well, your guess is as good as mine but I have a feeling we are talking about an app store for OS X.

OS X has been missing an official package manager for the longest time, and a common place to buy/download/find new packages or “apps” makes sense in that regard.

Also, Apple, great as they are at finding the honey pots, must definitely drool at the idea of recreating the app store craze, only this time on the desktop/laptop OS market.

What thinks you?


Apple vs. Adobe – And the Winner is… Google!

Apple has given many answers as to their lack of flash support on the iPhone. From battery life reduction to buggy implementation to the evil nature of web plugins to the HTML5/Open-Source stance, we have heard about every possible reason out of Cupertino; including a death sentence to Adobe Flash-to-iPhone Compiler in the CS5 suite.
In return, Adobe has long stated their position on openness, willingness to meet standards, battery reduction refutations, partnership with other mobile OS makers should a deal with Apple fail. Last attention grabber on Adobe’s part was this pseudo-viral marketing campaign about love and Apple.

The more we bore witness to this ever-evil fight the more we lost focus on Google and the brews that were coming to maturity inside their busy labs.

In a most shock-and-awe fashion, the world received last week an open-sourced gift from Google. A gift most of us would not know what to do with, but a gift all of us will eventually benefit from. I am talking about Native Client.

How can this resolve the Apple vs. Adobe issue, you ask?
Native Client’s premise is that native code would run on any browser that is compatible with native client on any OS.

How it does this translate into our world? In theory, any web tool such as the flash player or Unity Web Player could potentially run on a Native Client compatible browser without the need for any plugin. Unity showed us the way by demoing Lego Star Wars running on the chrome browser in Linux, plugin-free.

Google offered us a first-class look at the future of the web, a plugin-less future; a future where the line between browser and native applications is blurred to the point where the browser becomes a virtual OS that can run code on any platform, regardless of their desktop OS.

While Adobe fights for the life of its plugin and Apple fights for the death of Flash, Google demonstrated a true act of peace-making. In this very instance, Google’s fight seems to be focused on a better web.

Due to the open-source nature of its technology, native client will certainly make its way into all major browsers. There is no doubt about that. Adobe has the best opportunity of all to get out of Steve Jobs’ deadlock by integrating the native client API into their flash technology.

Apple, via pressure, will reluctantly have to integrate Native Client into Safari, short of rendering their web browser obsolete.

The next question is: How long will Apple be able to keep Native Client out of Safari mobile? It seems to me that Section 3.3.1 of the iPhone OS 4.0 ToS is dead before it is even born.


Unity Rocks Google I/O

Unity has unveiled yesterday at the Google I/O 2010 an impressive demo. Using Google’s Native Client – a new Google sponsored open-source technology aimed at running native code on the web browser, the Unity team managed to run the Lego Star Wars game on Google Chrome without the need to install any plugin.

While this is great news in itself, it is only a shadow of the real benefits pursuing such a technology would bring.
As stated on the project’s homepage, one of the main objectives of Native Client is OS portability. You hear that right:
Unity games are coming to Linux!

I was able to confirm this with the Unity developers. Here’s proof.

The future is bright for Unity, who thanks to native client, may end up maintaining a unique web player codebase while maximizing OS portability. Google might just have been able to justify the existence of a Unity Player for Linux, since the added cost of maintaining a Linux Web Player (or any additional OS) would be virtually inexistent.

Of course, both native client and the plugin-less Unity Web Player are very experimental, and will have to overcome quite a few obstacles (such as support for native client on IE, Firefox, Safari, Opera) before they can reach consumers’ hands. But if nothing else, we should applaud both Google and Unity for their ambitious objectives and stellar accomplishments.