Migrating to Java 1.6 on a Mac (Warning: Flash CS3/Flex Builder/Eclipse wont work with it)

[Update: Changed the title, added “on a Mac” because everything mentioned here is applicable to that platform alone]

After not looking at it for 4 years, today I started playing with Java again for a new open source project called RedCar, a programmers text editor that is now being ported to SWT and JRuby. Mat is getting pretty involved in it and he got me curious about the project. However to actually get it to work I had to get the Java 1.6 code to compile on my Mac which was a little tricky. Here are some notes from that.

The JDK 1.6 was part of one of the recent Mac Software updates but what I found out was that the update does not actually change the default JDK/JRE for the system. The first thing I did was to change the symlinks for java and javac as mentioned on this post. That seemed to work and calling java – version and javac -version seemed to return the correct versions, but running the build file still did not work. After a few other attempts, including trying the Java Preferences Application without any luck, I finally found this post that basically talked about the CurrentJDK symlink that apparently my build.xml was using (and was still pointed to JDK 1.5). That seems to have worked.

One last thing. Apparently Eclipse (and Flex Builder which is built on top of Eclipse) doesnt work with Java 1.6 on a Mac. As this post suggests, you may have to make a change to the Info.plist for the application to make it run with Java 1.5.

[Update] The Flash CS3 IDE doesnt work with 1.6 as well, so I am reverting back to 1.5 for the time being.

Is CSS the best metaphor for styling for a UIToolkit? Maybe not

Writing your own UI Toolkit is, if nothing else, educational. As the OpenPyro framework continues to evolve, every time a new feature is added, I look around at prior art in the domain and evaluate the choices made by different frameworks which has been fascinating. Of course, the first framework I look at (since I have had most experience with that) has always been Flex (both Flex 3 and 4 separatly since they are so different), but often I do compare that with choices made by the IPhone’s UIKit, HTML/CSS and (rarely) Swing or any of the Java toolkits.

One of the features that I know I will need to add in a future version will be a simpler way to style/skin the controls. OpenPyro controls are based around composition so creating new UI assets and passing them in as skin elements is simple enough but there is always a need to do something simpler. A blue scrollbar for example shouldn’t need blue assets, more the ability to tell the scrollbar to draw itself with a stroke/fill of blue color.

Flex’s choice in this domain has been CSS and thats not surprising. A lot of the way Flex was developed was to enable it to be a gateway drug to ActionScript for developers from other technology domains and who doesn’t know CSS? Flex 3’s CSS capabilities were very basic and I keep reading how Flex 4’s CSS engine is so much more complete. And considering how much easier it is to create a Flex 3 theme compared to a Look and Feel in Swing, that seems to have been a decent choice. Someone recently asked when OpenPyro would support that functionality which led to this post.

I have often found writing CSS for Flex a chore, for most of the reasons I find writing CSS rules boring: complete loss of any logic system. Deep in ActionScript land while developing an application, switching to CSS is irritating. Suddenly I am in a file where I cannot really code any logic or rules. One of the first libraries of ActionScript I wrote over 3 years back had explicitly defined style objects. For example, ScrollBars would have a corresponding ScrollBarStyle class that listed all style properties. Being a pure AS class, I could also code logic in that, so conditionally apply style properties because I could inspect the properties of the UI element the style was being applied to. Heck, I could even get code hinting of relevant styles for a particular component.

What spurred this post today was seeing how the engineering team I work with at Comcast Interactive Media adopting the Less CSS engine. I have personally not worked with this yet but I might in a coming sprint. By accounts so far, its awesome to work with and I completely don’t doubt that. Most of the logic here seems something that you can write pretty easily in pure AS3 classes and pass them around as something equivalent to Flex/Javascript’s CSSStyleDeclaration object (link to JS CSSStyleDeclaration object)

Anyway, the point of this post was, while CSS may be the most familiar styling metaphor, there may be better ones. I hope OpenPyro can probably adopt something more powerful like lessCSS rather than pure CSS.

Update: Another flavor of a *better CSS* system: SASS

Update 2: Smashing Magazine has a pretty good writeup on CSS ideas and debates. More food for thought as I spec out a styling language for OpenPyro.

On Toolkits vs Frameworks: Why not both and how OpenPyro does it

I was just catching up on Keith Peter’s blog and one of the posts that really caught my attention was on Toolkits vs Frameworks. The defining difference between the two, as Keith quotes Gamma, is “Toolkits do not attempt to take control for you…”.The Framework vs. Toolkit debate was in my mind when I started OpenPyro, but I feel I never stressed that enough so I felt it was worth a blog post.

OpenPyro was written in a way that it can be leveraged in either fashion. Lets take a few of examples:

The “Sprite” equivalent in OpenPyro is the UIControl, which does a few things like interpret percent based measurements, etc. It can also have a painter attached to it that can paint solid colors, gradients, stripes etc. So to create a gradient on a UIControl, all you have to do is:


var uic:UIControl = new UIControl();
var painter:GradientFillPainter = new GradientFillPainter([0xdddddd, 0xffffff]);
uic.backgroundPainter = painter

Now everytime the UIControl resizes, the painter repaints the gradient on its graphics context. However if you are not using a UIControl, and just plain sprites, you can leverage the painters again as so:

var sprite:Sprite = new Sprite();
var painter:GradientFillPainter = new GradientFillPainter([0xdddddd, 0xffffff]);
painter.draw(sprite, 200,200);

Now the painter paints the gradient on the Sprite’s graphics context. Its up to the developer to decide when to repaint the Sprite.

Here is another example with the layouts package:

var container:UIContainer = new UIContainer();
container.skin = new AuroraContainerSkin();
container.size(600,100);
container.layout = new VLayout(10);

var c1:UIControl = new UIControl();
c1.size(100%, 60);
container.addChild(c1);

var c2:UIControl = new UIControl();
c2.size("100%", 60);
container.addChild(c2);

In the above example, we have bought into the OpenPyro framework and just this code will let you create 2 control, position them vertically with a gap of 10px and automatically create a scrollbar since it will be needed ( The 2 children measure up to 60+10+60 pixels > 100px)

But the layouts package classes can be used for pure sprites too by using something like this:

var layout:VLayout = new VLayout(10)
layout.layout(sprite1, sprite2);

Similar examples can be drawn from the effects package etc. Also, OpenPyro has a fairly complete controls package each of which can be instantiated in a few lines of code as well completely independent of any framework dependencies. In fact almost all my tests are pure AS3 classes applying the package classes to non OpenPyro classes.

My take on the “Has ActionScript failed” debate

There is a lot of buzz going around twitter and the blogosphere the last couple of days around the future of AS3 and what the community wants. These discussions include Joa Ebert’s post on community contribution, language extensions and compiler performance, Nicolas Cannasse’s (author of the Haxe programming language) post on AS3 as a failed language and Andre Michelle’s post adding to the earlier two.

All the above posts do have valid points even if they are rather sensationally titled, though calling AS3 a failed language would be stretching it considering how many of us use it and do fairly complicated things with it even if typing “addEventListener” is a pain in the ass. The flip side to the above arguments come from Peter Elst’s post Making the case for ActionScript.

So here are my takes on the topic:

  • AS3 has not failed but is definitely gotten more verbose as painful to type. Traditionally ActionScript seemed to suffer from a love affair with Java which is probably why Java/C# developers do not see the points here. However the new fashionable languages are a lot less verbose and draw a lot of attraction on that front.
  • A lot of twitter conversation at this moment is talking about decoupling the AS3 language from the ActionScript Virtual Machine, and that would be cool, you could write Flash apps in a language you feel is cleaner. Alchemy enables this with C++ code, could probably be extended. For me the excitement isnt about compiling Python to the Flash Byte code but rather leveraging the language specific libraries I could use with my apps.
  • I had already blogged how AS3 has gotten a bit slower to work with than AS2. Adobe should look at the mistakes people are making everyday and improve either the language or the tooling (like maybe Flash Builder could warn you if you created a displayobject but never added it as a child). Simpler constructs for everyday things like getURL, loadXML would realllly help. This could be done with a framework that wraps lower level calls, but its a pain to add a swc to a classpath that I could do without.
  • Finally, lets have Adobe concentrate on features than language aesthetics. Take a look at how ugly Objective C is and you’d know we dont have it so bad. And yet, the language would not be the deterrant for me to write an iPhone app. So Adobe, I’d much rather get some player level features, and better performance for sure.

Oh and my big request of the Adobe peeps:
Adopt a secondary language and integrate well with it, especially AIR. AS3 will never have the libraries I would like to use, so if there could be a way to leverage Python or something as well on the desktop at least, that would be great. I am right now looking at TitaniumApp for some apps I wish I could have done in AIR.

Optimized List: A pure AS3 List with renderer recycling

One of the things that the Flex List component does pretty well is handle large data collections (Arrays, ArrayCollections, etc). The List uses renderer recycling when displaying data, ie, it creates an itemRenderer only for the items that are displayed and not for each item in the dataProvider. As items scroll offscreen, the renderers associated with those data items are reused to render the new data that appeared on screen.

For the last few projects I have worked on Flex has not been an option because of file size concerns besides others which prompted me to start working on OpenPyro, a light weight Flex-esque framework and I have been pretty happy with it so far. However its List component is a far cry from Flex’s, implemented more like a Repeater, creating as many renderers as the length of the dataProvider, and as my new projects seem to get more data intensive, I started feeling a real need for a List that does the efficient renderer recycling that Flex does. Not finding any on the web, I decided to write one for myself.

The algorithm is as follows: The List creates an instance of a class called ObjectPool, which manages used and unused renderers. Whenever the List needs a new renderer, it asks the pool for a new one and when it does not need a renderer, it returns it to the pool. The pool tries to find unused renderers to satisfy the request for a new renderer and if it cannot, will create a new object and return that.

The core part of the logic resides in the onVerticalScroll function. The list always maintains a map of all visible renderers and as the scrollbar scrolls, the map is recalculated and renderers managed if the map is changed. The source and embedded example are the first stab at the implementation. The example renders an array of 200 values but ends up creating only the 8 or 9 renderers it needs to display.

The code is not complete but I am blogging it here so that if someone feels I am on a wrong track or should investigate a different approach, you can let me know.

http://www.arpitonline.com/blog/downloads/optimizedList/EfficientList.swf

It should be noted that this technique only works right now for fixed rowHeight lists. I haven’t thought of the variable height renderers yet, so suggestions on that front are welcome.

Object Oriented JavaScript Techniques

This post is in response to a couple of conversations I had with some friends around OOP in JavaScript. Over the last couple of months I have gotten really deep into the language with JQuery (which is a fantastic library by the way) so I thought I’d quickly list some techniques I have been using to structure my JavaScript code.

Creating a very simple class with an instance variable:
JavaScript has no concept of classes but they can be mimic-ed by creative uses of the Function object. So for example this is completely valid:

var vanillaFunction = function(){
	this.name = "vanilla"
}
var instance = new vanillaFunction();
alert(instance.name) //	vanilla


In the above case, “name” becomes an instance variable of the vanillaFunction class.

Constructing instance methods

var vanillaFunction = function(){
	this.name = "vanilla";
	this.sampleMethod = function(){
		return "SampleMethod was called";
	}
}

var instance = new vanillaFunction();
alert(instance.sampleMethod())

Under the hood whats going on is that the JavaScript interpreter is attaching the Function objects to the vanillaFunction’s prototype chain. So to add another function, we can append that function right on the prototype:

vanillaFunction.prototype.getName() = function(){
	return this.name; // returns "vanilla"
}

Note that these functions have access to the name instance variable defined in the main vanillaFunction class.

Creating class variables and methods (kinda):
Since all functions are essentially Objects, variables can be tagged on to the function object and then referenced as static class variables.


vanillaFunction.classVar = "some value here";

Same way, static functions can be created as well:

vanillaFunction.staticFunction = function(){
	alert("static function called");
}

However it should be noted that the static variables and methods do not have access to each other unless explicitly passed during invocation. Personally, I hardly ever use this and prefer static classes as shown below.

Creating Static classes:
A static class is one you can never create a new instance of. For example, instead of having static methods in a JavaScript class, you can create a static class by declaring your functions as variables on a pure JavaScript Object. This method can be used for example for creating a class of utility functions:

var utils = {
	trim:function(str, numCharacters){
		return str.substring(0, numCharacters);
	},
	
	log:function(msg){
		if(console){
			console.log(msg);
		}
	}
}
var s = utils.trim("Good day to you sir", 4);

Creating classes with JQuery
To create a class with JQuery, we use the jQuery.extend function which pretty much adds the instance methods to the prototype chain as we saw before:


MyClass = function(){
this.title = "MyClass";
};

$j.extend(MyClass.prototype, {
toString:function(){
return this.title;
}
});

Events:
Even though the ECMAScript specification defines events and how they work, they are not implemented consistently across browsers. The JQuery event system is much nicer since a) it works cross-browser and b) the event source doesn’t necessarily have to be a DOM element.


var obj = {name:"SimpleObj"};
jQuery(obj).bind("objectChanged", listener);
jQuery(obj).bind("objectChanged", listener);
jQuery(obj).trigger({type:"objectChanged"});

In the above example, we are binding to a custom event of type objectChanged. Usually, I access the event type as a static class variable:


var CustomEvents = {
OBJECT_CHANGED:"objectChanged";
}
jQuery(obj).bind(CustomEvents.OBJECT_CHANGED, listener);

That covers pretty much the basics oF OOP in JavaScript. A lot of metaphors (like private/protected/public accessors) may be missing here but I havent really found that to be too much of a problem. These metaphors have made my code a lot more manageable.

Further reading:
John Resig’s list of lessons in advanced JavaScript

Personal landmark moment: My first patent: On the design of Comcast’s Fan Player

I joined Comcast four years ago, fresh out of graduate school with a Masters in Computer Engineering and a passion for the Flash programming language. Back then, Comcast was one of the rare companies that had invested heavily in Flash and getting the opportunity to develop applications in Flash that would be seen by a huge number of users was an exciting opportunity.

One of the first apps I got involved in and was my main project till about a year ago was the Fan. Originally conceived by my then boss and later friend and mentor Jeremy Landis, the Fan was a unique application. Comcast was probably one of the first companies who invested in Flash video back when it had just about come out.

History

  • When I joined, the Fan version 1, was written with all the goodness of Flash 6: code in frames, gotoAndPlays, etc etc. That was not too easy to work with.
  • The app was ported to the goodness of ActionScript2 soon after the release of Flash Player 7.
  • Version 3 of the application added some amazing redesign by our new design lead, Alfredo Silva and some amazing interaction models by Gabo (of Gabocorp fame).
  • The 3.5 version of the player introduced the ability to switch to a more conventional square view. There was a sentiment that adding a more conventional interface would lower the barrier to users actually interacting with the application more.
  • The square view was extended even further in Fan 4 which was also written from ground up in Flex 2. Porting the circular view to Flex 2 was an interesting challenge and I think we did an amazing job with Flex custom components.
  • The circular view was discontinued early this year as was the monolithic Fan application with the Comcast.net portal moving to a more conventional single-video-on-page experience.

Its kind of ironic that today the original team responsible for the Fan was awarded the patent by the United States Patent office on the design of the application. My first patent! How f-ing awesome is that !!!

The Fan was always unique if anything, and there was always the debate whether a circular interface was indeed the best to watch rectangular video. But the people loved it for sure, so much so that it even won the Flash Forward People’s Choice award in Sept 2006, and yes, that was for the circular interface. I remember a lot of stories from friends who had parents/relatives who loved the circular interface, and it was perplexing to the usability folk, after all it was clearly breaking all rules of application design. But that was where the magic was. It was different, iconic and had a long history with the Comcast customers who used it to catch up on daily news, events, gossip, etc. Heck, it was cool! Cool enough for even Philebrity to run a post titled The Only Thing Comcast Ever Contributed To The Internet: “The Fan” (Philebrity posts are not usually the most Comcast friendly).

But anyway, this is a moment to celebrate. I have one more fond memory of the Fan now, and believe me, this one is hard to forget :). Special thanks to all who went towards making the Fan a successful product, the editors, content video team, the design,dev and QA teams, etc. This was a fun ride.

Fan 1, 2

Fan 3

Fan 4

When things go wrong: Communicating error and gathering information for client side code

Having developed client side applications for the last few years in a variety of languages (Java, Flash, AIR, Javascript and recent forays into Objective C for the IPhone), its funny that some discussions appear cyclically and are discussed as though for the first time in every new project. Communicating errors in your application seems to be one of them, and I wanted to pen a few thoughts on that.

Serverside developers have it easy!
Well, no ;). But there are paradigms that have become the norm now. If something bad happens and you get a 404 or a 500 error on a webpage, its pretty likely that its been logged and if its on a major product, alarms have been raised. Client side code, especially in the languages I have worked in the last couple of years, have been less…communicative. I would like to focus on AIR and Flash here since those are the technologies I work with most often. The problem becomes more critical in AIR where you have much more things that can go wrong since you are interacting with items on the user’s machine which is not a controlled environment.

Why communicate the error?
Very few client side web apps I have worked with, including my own, have ever seemed to have handled error correctly. Most of the time, the app has been scoped with time allocated against the features and error states have never been considered. Occasionally, a developer will put in an Alert window or something similar just as a precaution (I know I have). In Flash/AIR there doesnt seem to be a good library that I can integrate into my application that encapsulates best practicess. Heck, I dont even know what the best practices are, which is what prompted me to write this post.

What would you include in the error window?
While you may want to include app specific information in the error window, I think there are a few things that make most sense:

  • An error description: What happened ? Corrupt file? Cannot connect to server? Something readable. For bonus points, can the user do anything about this, like restart the application?
  • An error code: This makes sense and if you include a support system, like a bug tracker or a 1-800 number, it would make the conversation a lot more meaningful
  • The detailed stack trace: A good paradigm I have seen here is a toggleable details state that shows/hides the detailed error stack trace, would go a long way in figuring out the source of the error
  • Extra points: email API integration, or some other way for the user to send the error description with as little pain as possible

The last point is kind of interesting, cause you might want to send more than just the stack trace of the error. You might want to set the whole application state. If you have application logging enabled, say with something like the CIM logging framework, the whole log file might be of interest. Again, the developer must ensure that he is only logging non-personal information there.

Of course there are situations when the error might cause the entire app to blow up, without giving it enough time to react to the error. Would it make sense to log and end of session event and allow users to send the application log to the server if the end of session was not successfully logged for a prior session?

Prior Art:

I started looking at some Google results for Error dialogs and crash reporters. Here are some screenshots:

First is the JXErrorPane, a Java class part of SwingX project. This seems to be the most familiar UI for reporting errors(link to API docs)

jxerrorpane

The usage is pretty simple:

try {
//do stuff.... something throws an exception in here
} catch (Exception e) {
JXErrorPane.showDialog(e);
}

A step up would be the UI from crash reporters which would perhaps be overkill for a web app, but would make a lot of sense for desktop apps, especially in the beta stages. Here is a screenshot from something called Bug Buddy.

Bug Buddy

Whats kind of interesting here is that it adds a field that allows user to add information about the context of the crash, as well as an email address that may be used to contact him or something.

The last screenshot is from an open source library called JRFeedbackProvider someone presented at the Philadelphia Cocoa Users Group.

JRFeedbackProvider. This has the features of the previous crash reporters but also adds a “request a feature” tab which is great if you are running an alpha version of your application and are looking for more than bug reports.

If you have seen any other error UI that seem to do a good job, please add a comment here.

Quick Tip: Correct folder for Unit Tests in Flash Builder 4

I really like the fact that FlexUnit is built right into Flash Builder since one of the main reasons unit testing used to fall off our radars was it was a pain setting up Flex Unit and executing scripts. However one of the things that struck me pretty weird was that Flash Builder was writing tests in the source directory. Best practices in unit testing say that the tests should be in a separate folder called tests/ which should be a sibling of the src/ folder. This lets the tests be written with the same package as the code being tested. This allows, for example, testing functions with a package level visibility.

The correct way to get this working is, when starting the project add another folder called tests for the build path. Now Flash Builder will look at both the source and the tests path when looking for .as files. To write a unit test Test Case, right click on the tests folder and click on the new Test Case option.

New folder for Unit Tests

[Update] I have filed a bug in Adobe’s ticketing system to track this issue. Please vote for it if you agree: http://bugs.adobe.com/jira/browse/FXU-50