I see a number of reasons for this plethora of Android variants:

• It takes longer for old versions of Android OS to fall into disuse; it takes in the order of a year for a new version from Google to be adopted, updated, and tested by the device manufacturers and tested by the carriers.
• Companies like Samsung and HTC take a spaghetti against the wall approach, creating large numbers of different devices in the attempt to cater to different customer interests. For example, I counted 34 current models advertised by HTC, with 23 of them running Android, and 5 Android tablet models. Samsung shows 144 models (!), with 54 running Android, and 17 Android tablet models.
• Not reflected in the report, but smart-phone manufacturers using Android need to differentiate themselves from the other manufacturers also using Android. To help with this, these companies extend the base Android install with their own user interface customization layers. HTC adds Sense UI, Samsung adds TouchWiz, and other makers such as LG, Motorola, and Sony Ericsson have their own equivalents. This of course introduces additional functional differences between handsets from different vendors, not to mention bugs and performance issues.

As a consumer, I’ve looked through lists of Android devices trying to pick one that is suitable, and it’s actually quite intimidating. Compare that with Apple where your choice is between the legacy iPhone 4 or the current iPhone 4s. As a developer working increasingly with mobile, it’s intimidating from a testing standpoint. While proponents cite the level of choice that exists, that choice comes with a big cost.

From a developer’s point of view, there are a few things that would be a big help:

• Google should update their emulator so that it simulates individual models. Right now, that’s pretty much impossible. In contrast, Research in Motion includes virtual machines for pretty much every iteration of every single Blackberry that they sell, including the variants from every carrier.
• Google should update the Web browser in their emulators so that they also do a better job of simulating real devices. The one they have now is piss-poor, the only thing it’s good for is showing that yes, there is a web page showing. In contrast, mobile Safari in Apple’s emulators makes a very accurate representation of the real thing and can be used for testing and debugging purposes.
• Not that this will happen anytime soon, but it sure would be helpful if handset vendors stopped taking the spaghetti against the wall approach and focused their offerings with fewer models.

Having emulators is no replacement for the real device, but who’s going to have a testbed of 4,000 devices? I would be very happy to see these things happen, but I’m not holding my breath. Still, I can dream.

The idea is that adaptive design can give you different views on the same content, and with adaptive design you should be able to get a “full” site that’s better formatted to the smaller screens. The one caveat though about having the same site for desktop and for mobile: many use cases often are different between mobile and desktop, some content should be featured more prominently on mobile devices than on desktop sites so that the more common mobile activities can be achieved more quickly. Adaptive design techniques should be able to handle this, it just means you still have to consider mobile separately even though the site is shared.

And while we are talking about Jakob Nielsen, when is he going to get around to making his site even mildly appealing? He’s had the same ugly design when I last commented on it 8 years ago. When is he going to learn that visual aesthetics are part of usability as well?

Does that sound good? Well, in theory yes, but pretty much all the chatter I’ve heard so far about this tool omits some critical details:

• Swiffy does not support ActionScript 3, even though it’s been out since 2006 and is superior to AS2 in almost every way. It even only partly supports ActionScript 2.
• Google recommends that Flash content is exported as Flash 5 (we are currently at 10.3). That version is well over 10 years old, has only basic scripting capabilities, no components, nor any of the 10+ years worth of other enhancements that have been made to the platform. Even then, they don’t support the whole Flash 5 spec.
• Swiffy currently requires WebKit based browsers, such as Safari (mobile and desktop) or Chrome. Firefox and IE aren’t supported.

The only thing that this tool is suitable for is animations, which means that the only place it will likely be used is for ads. For even the simplest of Flash-based applications, it’s not remotely useful. Google does make it clear that this is for animations in their FAQ, but that detail is getting missed. Converting anything other than an animation would not terribly feasible, there is a significant capability that Flash has that HTML5 does not have, and there is the potential for significant complexity in applications created using the platform. It would likely not be feasible to implement a conversion tool that adapts an actual Flash application to HTML5.

There is no panacea when it comes to Web applications. There are things that are more suitable for Flash and Flex, and other things that are more suitable for HTML5. Sometimes you need both to target different audiences. An automated conversion tool isn’t going to apply the needed thought to adapt functionality for the audience.

I took a closer look at the issue and initially was not able to replicate the issue. The tester sent me some screenshots showing more details of the crash, including a screenshot showing memory usage. System memory was high, but not outrageous. Still, I suspected a memory leak.

A quick bit of background as to how this application works. There are a number of screens which open up an overlay containing our Flex charting application. Those overlays basically consist of a DIV element set up so that it can display some custom content, and also block any clicks to the surrounding page (a modal layer using Yahoo’s UI library). Every time this modal window is opened, it writes a bunch of markup and script into the DIV to set up the Flex app, every time it is closed, it clears out the DIV contents and destroys the app.

Eventually I stumbled on the fact that if I opened and closed this panel 10-15 times (even between visiting other pages), IE would crash. Now at least I had a simple test case to do testing. I did quite a few tests to see if perhaps the Flex application itself was leaking, but the Flash player’s garbage collection seemed to work fine. I used Microsoft’s DebugDiag tool and a tool called sIEve to take a look at what was going on. With sIEve, I saw that there were a whole schwackload of variable handles pointing to each Flex application (22-24, depending on the situation). I would have expected only one or two. I also saw by just monitoring the Windows task manager that each time I opened/closed the modal panel, IE’s memory profile would increase by anywhere from 30-50MB.

I tried many techniques to try to clear these handles (use removeElement on parent and/or child, set handles to null, transfer element to another DIV and delete, set expandoProperty to null), but none worked. I also tried to see what scenarios resulted in a proper cleanup. When I used a popup window, no memory leak occurred. When I used an iframe, no memory leak occurred. Only when I put the Flash application in a DIV element would the leak occur.

Next, I tried to see if it was something about the Flex code that was triggering the leak. I trimmed everything down to a bare bones app, and lo and behold it stopped leaking. I added features back in until it started leaking again, and found that what triggered the problem was Flex’s ExternalInterface library. This library allows a Flex application to call JavaScript methods, and allows JavaScript methods to call Flex methods. In order to make a Flex method available to JavaScript, ExternalInterface injects some JavaScript code into the calling page. This injected code then hangs around, and when the application gets destroyed, IE does not dispose of the additional code. This resulted in orphaned handles that prevented the Flex application from being garbage collected. It so happened that the number of ExternalInterface methods we were exposing corresponded exactly to the number of orphaned handles that sIEve reported for the Flex application, which was my clue that the extra orphaned handles sIEve was reporting were a direct result of the injected ExternalInterface methods.

We were in the process of changing our implementation to use popup windows instead of modal windows (shudder) but at the last minute I got a clue as to how to clear the handles – iterate through the Flash object’s properties and set all the JavaScript methods to null. Something like:

for (var prop in flashHnd)
{
if (typeof(flashHnd[prop]) === "function")
{
flashHnd[prop] = null;
}
}


You can better see how to implement it by taking a look at the source to the SWFUpload project. Take a look at the cleanUp method.

So in the end we were able to deal with this issue in about 15 lines of JavaScript code instead of the significant re-implementation we were otherwise going to have to do right at the end of testing, along with the associated changes in requirements documentation and testing plans. The whole thing reinforced to me though just how much I dislike developing for IE. My guess is that after this experience, the IE-only requirement of this project will likely be reviewed.

This move is a good thing. It removes a distraction and helps browser makers focus their attention on one implementation. As for what it means for Web developers? As far as impact to our coding, it appears the impact should be low. As long as you code to current standards, your code should be compatible to either HTML5 or it’s XML-based XHTML5 sibling. Of course there will be some impact in learning the new language elements, but the learning curve should be relatively gentle. For those who like agonizing detail, here’s the HTML 5 spec. The HTML 4 to 5 differences article by the w3c gives you the skinny on what are the new language elements. For a higher level overview, A List Apart has an older but still relevant overview.

From what I see, Thermo is a tool that helps to integrate the visual design process in more tightly with creating Flash/Flex-based Rich Internet Applications. If you take a look at the demo, you will see how it can import artwork and use that as a template for creating a Flex-based application. From what I see of this application, this is really what the visual design feature of Flex Builder really should have been, and this also looks to be very suitable for quick semi-functional prototypes. The workflow looks like it will work well as well: Visual designers can use Thermo to start off the application, then Web developers can work with the same project in Flex Builder to add in the structure, additional functionality, and server integration.

Since Thermo creates code that can be also edited in Flex Builder, one thing I would like to see is that they keep Cairngorm in mind. That would help make Thermo more suitable for larger scale RIAs.

The idea is that we should really be using more of the keyboard to be productive, but only for tasks which can be qualified as discrete, such as managing documents, launching applications, and working with text. I definitely agree with the premise. We have long had keyboard shortcuts, part of the problem is how to associate the shortcut with an action: there are so many, memorizing them is impossible. As an aside, f-keys are the absolute worst way to implement shortcuts as there is no mnemonic to help with the association, and no consistency save the F1 key for help (why not just label it “help”).

The author has some good thinking in his second article about a way of improving the feedback mechanism for shortcuts. I think it’s a good start, but perhaps a bit heavy in the information presentation. Many programs have a huge number of commands which would simply be overwhelming, even with the author’s proposed trimming search functionality. A great Mac utility called Quicksilver shows a way of achieving this in more of a compact way. Hitting ctl-space brings up the search field, then typing whittles down the list of commands available while using less real estate. Integrating this kind of functionality more tightly in the operating system. One problem with this particular program, though is the merging of commands with applications. Typing in “qui” could potentially mean “quit” or “quicksilver”, one being a command, one being an application. I think it’s probably best to keep those separate.

One thought I have relates to an example given in the book “The Design of Everyday Things” where one shortwave radio with lots of buttons on the front was found to be generally easier to use than a radio with similar functionality condensed into fewer buttons. The problem with having fewer buttons is that most of the functionality is hidden behind modes, which make it very difficult to “save” actions to muscle memory through simple memorization of where the button is. Similarly, our keyboards are inherently modal, with “shift”, “ctrl”, “alt/option”, and “Windows/Apple” buttons each representing different modes of operation. Doing something like replacing our F-keys with buttons that have distinctly labeled functions such as “open”, “close”, “save”, and whatnot would allow us to commit many of those common actions to muscle memory rather than having to memorize key combinations which may not fit our own mnemonic associations.

One more thought, approaches such as those used by QuickSilver and Windows XP Start Menu claim to be adaptive. The problem with this approach is that they are not predictable: trying to invoke the same command/program that you normally use, but on someone else’s machine, will result in different actions or at least a different set of movements to invoke the same action. Moving or hiding items based on usage is a really bad approach, however something more subtle such as slightly changing the appearance of the most frequently used commands might work better.

Anyways, there is lots to consider in how to best use the keyboard. It would be fun to come up with a shortcut feedback system that works well.

Grrrr… WordPress is munging the object and embed tags. The example can be seen here for the moment.

Another update: Did I mention error handling is not quite robust yet? Seems to not be loading anything over the server, however feel free to download the zip file and play with it locally.

Update 3: Seems it was just a case sensitivity issue on the file name, it’s up and running now.

Update 4: I have a new example up that adds some constructor options to some of the classes, and also adds a simple frequency spectrum display. Take a look and grab the updated source if you wish.

Note: this only works if there are no duplicated elements in each data set, which fortunately is not too hard a condition to impose.

Here is some code representing the algorithm:

var dataSet:Array = new Array();
dataSet.push(["1", "2", "5", "10", "11", "12", "15"]);
dataSet.push(["2", "5", "11", "14", "18", "21"]);
dataSet.push(["0", "1", "2", "3", "5", "7", "11"]);

var elementTallies:Object = new Object();
var currentElement:String;

for (var i:Number = 0; i < dataSet.length; i++)
{
	for (var j:Number = 0; j < dataSet[i].length; j++)
	{
		// Go through each element for each dataset. For each element,
		// add one to the tally for that element.
		currentElement = dataSet[i][j];
		if (elementTallies[currentElement] == undefined)
		{
			elementTallies[currentElement] = 1;
		}
		else
		{
			elementTallies[currentElement]++;
		}
	}
}

// Go through the tallies looking for elements with a tally of 3. 
// Those elements will make up the intersection of the three data sets
for (var element:String in elementTallies)
{
	if (elementTallies[element] == dataSet.length)
	{
		trace("element: " + element);
	}
}
// Outputs: 11, 5, 2