Visits to this blog

Archive for the ‘open source’ Category

My former employer, Cúram Software, was good enough to give me a couple of months to work on the performance issues that Dojo and it’s widget project Dijit have in horrible legacy browsers IE6 and IE7. Some of the fruits of that labour have now been checked into the code base and will be included in Dojo 1.6, out in Q4 2010.

So what I/we learned from the exercise?

DynaTrace rocks!

To begin with, I can’t praise DynaTrace enough. It’s a fantastic piece of profiling software that delves deep into Internet Explorer’s innards to find every little horrible Microsoft bug. It can take a while to get used to, but that is just because it presents you with so much data, all of it useful, and anyone would have trouble finding a way to make it easily consumable. Long story short, if you’re having performance issues with your site in IE, download DynaTrace.

Touching className makes IE cry

Pretty much every time you change the className property of a node, IE6 and IE7 reflow the page. It doesn’t matter if the new value is the same as the old one, or whether or not the changed CSS class has any visual effect, IE will redraw the page, resulting in a lot of time being lost.

Dojo was changing className too often, for example in dojo.addClass, if the class being added was already present, it would still assign the changed value to className. I put a fix for this into v1.5. There were also many cases where Dojo would use a combination of dojo.removeClass and dojo.addClass to replace a class, which changed className twice instead of just once. To fix this, I’ve added a new public api dojo.replaceClass, which only changes className once.

Dijit widgets often add CSS classes to the DOM nodes which they are creating after the nodes have been inserted into the document. This is costly, and a large performance improvement can be gained by applying these classes earlier in the lifecycle, before inserting into the document. Bill Keese (Dijit master) checked in the first of the fixes for this for the BorderContainer recently, and a strategy is being formulated for the many other widgets that can benefit from this. This work should be completed for v1.6.

Risky but…..

A solution that we cannot use for Dojo, but which we found gave huge performance gains for my company’s application, was to figure out what CSS classes Dojo would apply to a node and write those classes out when generating the HTML. For example, when creating a dijit.layout.BorderContainer, our HTML contains the CSS class dijitBorderContainer. There is an inherent risk with this approach, as Dojo may change the CSS classes in a later release, but if you’re willing to accept the risk and the upgrade pain, you can get a nice performance boost this way.

Reading offsetLeft and offsetTop is costly

When your code reads the offsetLeft or offsetTop of a node, all pending changes to the DOM have to be performed first. This can be very expensive – we saw a number of single operations taking over 500ms each! Many Dijits were using the dojo.marginBox method to get the left, top, width and height properties of a node, when all they needed was the width and height.

To solve this, I introduced a new method, dojo._getMarginSize, a private method that just returns the width and height of a node. This has resulted in huge gains in performance on IE6 & 7, especially when used with layout widgets like the BorderContainer.

Unexplained gaps in DynaTrace profiles

We hit a bit of a wall at one point when analysing the performance profiles, where there was a 1.5 second gap in the profile where it seemed like nothing was happening, but everything was paused with the CPU at 100%.

We eventually discovered that there is a horrible bug in IE7 where if you have a :hover style on something that is not an anchor tag, it causes the rendering engine to go crazy, get all confused, and push the CPU up to 100% for no reason at all.

The solution: don’t user :hover styles on anything other than <a> tags. Ridiculous I know, but so is the IE7 rendering engine.

Give it a go!

So, the long and short of it is that Dojo/Dijit should now be a good bit snappier on IE6 and 7. With our application we got the load time for a huge application down from 20 seconds to 5 seconds using these techniques, making IE7 far, far more usable. Of course it just flies on any other browser, even IE8 which, all credit to MS for once, is far less buggy than the earlier incarnations.

So feel free to try out the Dojo nightlies, you should find them to be a good bit more responsive in IE6 and 7 than just a few days ago, and now that we have learned some important lessons, Dojo will be even faster for v1.6.

Like this:

I’ve been working a lot on Dojo’s new mobile framework (see HERE for my intro post on dojox.mobile.app) and the Image widgets are coming along very nicely. I just checked in a new Thumbnail viewer, and enhanced the ImageView widget. Check them both out at http://bit.ly/cU3akI.

Click the “Browse Flickr” selection to see both images integrated with Flickr, as well as a dynamic group search view using the TextInput and List widgets. Given that these widgets use cool fancy HTML5 effects, you’re best off viewing them in a WebKit browser, so Safari, Chrome, webOS, iPhoneOS (iOS now I guess) will give you the best experience.

The ImageThumbView uses CSS3 transforms to position the thumbnail images, and animates the opacity with CSS3 to fade in/out images.

Jared Jurkiewicz and Yoshiroh Kamiyama recently added the dojox.mobile project. It provides some very nice widgets for use on mobile phones, such as views that can transition between each other, rounded lists, tab containers etc.

However, the focus of dojox.mobile is to be very small, so as to suit websites formatted for mobile devices. When writing cross device apps that are hosted on a phone, the size of the JavaScript is less of a concern, so a much more powerful experience can be created.

Hence, dojox.mobile.app is born.

It is built on top of dojox.mobile, but adds many new features, with more on the way.

Templated views that can be pushed and popped off the stack of views, all of which are lazily loaded.

Templated lists

Input widgets

Image Gallery

Dialog Boxes

Popup Menus

are all available now. The structure of a dojox.mobile.app application is modeled very closely to a webOS app. The templates and code are in a similar folder structure, and the lifecycle for creating and destroying (popping) scenes/views are very similar.

The goal of dojox.mobile.app is NOT to replace or duplicate the functionality in PhoneGap. PhoneGap provides low level access to many phone features. dojox.mobile.app aims to provide an easy to use, flexible application structure, and many widgets that you will find useful, all themed to appear native to each platform. In a real world app, it would make most sense to use both PhoneGap and dojox.mobile.app.

Like this:

My first Palm Pre application, Irish Rain, has been published to the Palm App Catalog. See my first blog posting on it here. Irish Rain is written using Mojo, Palm’s JavaScript framework, and the Dojo Ajax Toolkit, a project on which I’m a committer.

Irish Rain is completely free, and should help make sure that us poor Irish don’t get caught in the rain again. However, I make no guarantees that your house won’t be washed away in a biblical flood!

The Dojo Tree has always been easy to make look just like you want, from changing the icons to changing the labels.

However there was always a limitation in that an entire row could not be styled. Well, today I put through a fix for that, and you can now specify a CSS class and style for each row using the getRowClass and getRowStyle functions.

Like this:

I recently installed Ubuntu Linux 9.04 on my girlfriends lovely new EEE Netbook (I highly recommend the 1005HA + EEEBuntu), but left the original Windows install intact, because, well, I’ve always had a need to go back to Windows for 30 minutes at some point for some reason or another.

The one problem I foresaw with this Ubuntu install was that if she ever had to use the Huawei Mobile Broadband modem I have, she’d have to boot into Windows. I’d read a year ago that Ubuntu supported it, but when I tried with Ubuntu 8.10, it failed miserably.

So today I was using her netbook and needed mobile broadband, and was about to boot into Windows, when I thought “what the hell”, and tried it in Ubuntu first, fully anticipating the same failure as before, or at least 10 hoops that had to be jumped through before I could get it working.

But no – I was presented with a list of operators for my country (Ireland), asked if I was bill pay or pre-pay, I clicked once and I was connected! No install required, unlike with windows, just enter your PIN and away you go.

The main argument against Ubuntu, and Linux in general, is that it doesn’t have enough driver support, making it impossible for non-computer literate people to simply plug in their devices and do what they need to do. It’s great to see that the community is adding in new drivers at a great rate, and that things like cameras, wireless (which is also vastly improved recently) and now mobile broadband now “just work”, and in this case work much better than Windows.

My girlfriend, who is in no way interested in computers or open source, now complains about having to use Windows in university, because Ubuntu is so much easier and faster to use. I can imagine the same story is playing out all over the world. Hopefully at least🙂

Share this:

Like this:

This post explains how to get up and running with Palm Pre development, including getting the tools, setting up the emulator, as well as getting debugging and the inspector working.

In the last few days I’ve started playing around with the development tools for the extremely cool new phone, the Palm Pre. The coolest thing, from a developers perspective, is that all application development is done using HTML, JavaScript and CSS. That means if you can write a website, you can write an application for the Palm Pre (though not necessarily a good one).

However, while Palm does provide a pretty good site, http://developer.palm.com, to help you get started, it’s missing some crucial information, which is scattered all over the web (trying to find out how to do logging is a nightmare). So, this post will explain some of the steps you need to take to get up and running. As I prefer to use Palm’s Eclipse based development tools, this post assumes that you are using it also, and not go into the command line stuff.

The Eclipse page also includes the required steps for creating a new WebOS application, adding scenes (a scene can be though of as a single web page, and you application will be made up of one or more of them) etc.

2. Create a New Scene

After following the instructions on the Eclipse page to create a new application, create a new scene clicking “File-New-Mojo Scene”, and give it the name “main”. You should see a number of files created:

app/assistants/main-assistant.js – This is the JavaScript code that will be executed when your scene, or page, is rendered

app/views/main/main-scene.html – This is the HTML that defines the displayed HTML for the scene.

sources.json has also been modified to add information about your scene.

As we want the “main” scene to be displayed when the application starts, open the /app/assistants/stage-assistant.js file, and in the setup method you see there, add the following line:

One thing I’ve noticed is that if you start Eclipse before starting the emulator, it throws errors and can have problems connection. So, start the emulator before Eclipse.

Sometimes you may also see an error when starting the Emulator stating that the Novacom service must be running. To make sure it is, click Start > Settings > Control Panel > Administration Tools > Services. Find the Palm Novacom service in the list, right click and choose start.

4. Launching the Application in Debug Mode

As you’ll pretty much always want to be viewing debug output from your application, start it in debug mode. To do this:

Click Run > Debug Configurations

Right-Click “Mojo Application” and select “New”

Choose your project in the “Project” drop down box.

Choose the target to be “Palm Emulator”, or if you’re lucky enough to have a Palm Pre, choose Palm Device

Make sure to check both the Inspectable and Mojo debugging checkboxes, and click Debug.

Looking at the emulator, your application should appear.

5. Logging

Debugging with WebOS is currently a pretty nasty affair, that requires a lot of command line wizardry, that I think only a tiny percentage of people will even attempt to use (if you’ve figured it out, well done!).

However, logging is relatively simple to set up, and that’s what I use.

As with developing web applications on Firefox, you can use the Firebug function console.log to print out messages, e.g.

To view the logs, you need to log into the emulator/phone remotely using Putty, a SSH client. Luckily this is included with the Palm SDK you installed earlier.

Go to the bin folder in the SDK, probably in c:\program files\Palm\SDK\bin, and open putty.exe

In Host Name, type localhost

In Port, type 5522

Save these settings for reuse later by typing in PalmEmulator into the Saved Settings box and clicking Save.

Click Open.

When Putty prompts you for a login name, type root

When prompted for the password, just hit Enter, as the password is blank.

Now start the logging application by typing log com.mydomain.myapp. If you’re unsure of what the correct string is, open the appinfo.json file at the root of your project in Eclipse, and the right string is specified as the id in that file.

Now, when you run your application, you’ll see your console.log calls being shown there. It’s a bit verbose, and prepends a lot before your message, but at least it’s readable.

6. Using the Inspector

Palm includes the a DOM inspector with the SDK. Before running it, and after installing your application on the emulator using Eclipse, open a command window in the SDK’s bin folder, and type

palm-launch -d tcp -i com.mydomain.myapp

once again using the correct string for your application instead of com.mydomain.myapp

Now launch the inspector by clicking Start > Programs > Palm > SDK > Palm Inspector. The Inspector window should now launch, and display the HTML of your application.

7. Write Something Cool

I’ll leave this as an exercise to you, the good reader. However, you should now have the ability to log messages and inspect the content of your page, so you’re almost on par with the tools available for web development (a good debugger would be nicer though).

I might write some more posts in the future covering anything cool I found or wrote for the Pre. I’m starting to use a specialized build of the Dojo Ajax toolkit to fill in some of the blanks that Palm’s Mojo toolkit leaves out, and that’ll probably require another post.

Like this:

I previously wrote about work I was doing on the Dojo Ajax Toolkit‘s TabContainer widget. This work prevents the tab buttons from wrapping around when they are wider than the available space, and instead allows you to use either a drop down menu to select the tab (like Firefox/IE7), or to use left and right slider buttons to “slide” the buttons.

Well, thanks to some great collaboration with Dijit master Bill and a Dojo contributer called alle, the work has now been committed to the code base. It should be available to view HERE from Aug 12th 2009 onwards, and will be in v1.4 when it is released.

If you can’t wait for it, you can either download a copy of the nightly code base from http://archive.dojotoolkit.org/nightly after Aug 12th, or checkout the code yourself from Subversion right now. Note that code in between releases is not guaranteed to be stable, as many features may be in the middle of upgrades.

There are a couple of issues remaining to be worked on, such as improved right-to-left support, but for people who have been clamouring for this to make it into the code base, you can grab this now, and get the upgraded, more stable widget in v1.4