Thoughts on Commercial Ecosystem for the Flash Platform

This post is in response to Grant Skinners post on a thriving commercial ecosystem for the Flash Platform. For those who are just getting caught up with the conversation, it all began with Adobe labs releasing Squiggly, a spelling library for Flash apps which may compete directly with Grant’s own Spelling Plus Library which prompted quite a few people (including Grant himself) to talk about how Adobe may be competing with developers who build on their platform. This conversation isn’t new, quite a few people said the same thing when Adobe came out with Photoshop.com which competed with services like Picnik. As Adobe starts eying the services market with apps like Share, Buzzword, etc, developers may (justifiably) feel that it may be a matter of time before Adobe competes with them should their product seem lucrative. Considering they own the platform, ie the Flash Player, they may very well put features in that give them the advantage. For example, Adobe Connect already leverages the screen sharing capability that gets enabled on the Flash Player with the Connect plugin (yes a plugin for the browser plugin), something that non-adobe developers cannot access.

Can Adobe navigate these waters carefully enough to not alienate its developers remains to be seen, but this post is more regarding Grant’s follow up post on what Adobe can do to create a vibrant commercial ecosystem for the Flash Platform.

Actually there is a slight difference in the title of Grant’s post: “How Can Adobe Encourage a Commercial Ecosystem?” and what he writes about: “… lack the high-quality, well-supported, production-ready components that a commercial marketplace can provide.” While both are in similar vein, I feel a thriving commercial ecosystem on the Flash Platform doesnt have to be based around production ready components. There will be a few, like SPL that make a decent amount of money but those are going to be the exception and not the rule.

Adam Lehman, ColdFusion Product Manager made the point on one of the comments on that post which I most agree with: The Free Open Source marketplace which is pretty thriving on the Flash Platform does tend to kill the commercial component marketplace.

A Commercial Ecosystem on the Flash Platform is different from a commercial ecosystem on the Flash Platform based around commercial components. Grant’s own SPL is only viable till an open source version came out that may even be half as good as the SPL. The Flash developer community has become used to the Open Source way: find something out there that fills your need, if not and you find a fledgeling open source project that may have those ambitions, see if you can contribute, else build it yourself. My personal opinion is that the market for commercial components is pretty small no matter what Adobe does, and I dont think too many people miss it (except maybe a few folk coming from the Microsoft side of the world who are used to paying for components they use).

Flash Platform’s own commercial ecosystem would/should probably be around full products, embeddable widgets, AIR applications, Flash lite/mobile AIR apps etc. The best thing Adobe could do is keep powering the platform even more, add more capabilities to the runtimes, create distribution and monetization channels for the developers and make sure the developers dont feel threatened. And the developer services products on Adobe devnet seems to be a step in the right direction.

On Innovation in big companies

These notes are from BarcampPhilly ’08 that were lost in the depths of my computer’s hard disk and I only just found again. At the event, a few of us from CIM held a round table discussion on innovation, especially developer led innovation in big companies. Here are the points that people mentioned:

  • Innovation only comes from free cycles, even the best ideas need time to be thought through
  • Leverage something thats existing rather than a brand new idea
  • Agile development can actually hurt innovation with too much transparency. Its hard to justify something that you may feel has a long term win
  • Technical managers should whet the ideas of their team members
  • Innovation comes from bottom almost never from top
  • Innovation = Risk
  • True story: At AOL, the AOL IM service was declared a risk
  • Constraints actually push innovation
  • Innovation wont happen without proper incentives/rewards.
  • How about cross team innovation. How do designers/developers collaborate to innovate?

So this has only taken almost a year to put up, with BarcampPhilly ’09 coming up soon. Since then there has been a few opportunities within CIM to push bottom-up innovation, including a labweek for all of engineering.

Are you in/around Philadelphia and into Flash, Flex or AIR? You should be at FlashCamp!

I am pretty excited that Rob Hall has formally announced FlashCamp Philadelphia to be held on Nov 7th. The event promises be pretty fantastic with some of the biggest names in Flash and Flex circles coming in to participate. While the event promises to be technically very educational, I am personally excited to see how different companies within Philadelphia use Flash and Flex. The event will be held at Philadelphia University’s Kanbar Campus Center and is priced at $45 with early bird pricing of $35 (till Sept 30th or the first 75 tickets). Students tickets are priced at $22.

So if you are in the neighborhood and interested, check the event site and register here. You can also follow the event on Twitter at @flashcampphilly

See you there.

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