Manish Jethani: Weblog

You can see the smiley face

Sat, 22 Dec 2007 22:28:38 GMT

Holy crap! IE8 passes the Acid2 test!

Where money comes from

Fri, 21 Dec 2007 16:17:30 GMT

Here’s a nice 45-minute video on how the monetary system works, and why it’s such a scary thing.

URL: http://tinyurl.com/2p63mr

Setting up default CSS for your Flex component

Sat, 23 Jun 2007 00:10:20 GMT

There are 3 ways to specify the default styling (CSS) for your own custom-built UI components in Flex.

Let's take the example of a component called TagBar that I'm building. The component is very similar to the LinkBar component of the Flex library: it displays a list of "tags" (like a tag cloud) that the user can click through for more information.

The default look of the component is as shown in the image below:

The component itself is simply a subclass of the LinkBar component. The above look is achieved by setting the following styles:

TagBar {
  color: #00A7E3;
  font-family: Lucida Grande, Tahoma, Verdana, Arial;
  font-size: 11;
  font-weight: normal;
  padding-bottom: 0;
  padding-left: 0;
  padding-right: 0;
  padding-top: 0;
  separator-width: 1;
}

How do we provide this default styling as part of the component?

1. Using a static initialiser

A very popular technique, and one recommended by Adobe, is to use a static initialiser in your component class. Unfortunately the Adobe example is wrong. It's worth repeating: the Adobe example is wrong.

The right way to set up styles in the static initialiser is as follows:

public class TagBar extends LinkBar
{
  private static var classConstructed:Boolean = classConstruct();

  private static function classConstruct():Boolean
  {
    var styleDeclaration:CSSStyleDeclaration
      = StyleManager.getStyleDeclaration("TagBar");

    // If there's no style declaration already, create one.
    if (!styleDeclaration)
      styleDeclaration = new CSSStyleDeclaration();

    styleDeclaration.defaultFactory = function ():void {
      this.color = 0x00A7E3;
      this.fontFamily = "Lucida Grande, Tahoma, Verdana, Arial";
      this.fontSize = 11;
      this.fontWeight = "normal";
      this.paddingBottom = 0;
      this.paddingLeft = 0;
      this.paddingRight = 0;
      this.paddingTop = 0;
    }

    StyleManager.setStyleDeclaration("TagBar", styleDeclaration,
      false);

    return true;
  }

  ...
}

The advantage of this method is that the default styling is part of your component and does not rely on any external CSS, while at the same time it is possible to override the styles by using CSS selectors, inline styles, or using setStyle(), just the way it is for the components in the Flex library.

The disadvantage is that it is error-prone and can be hard to maintain, not to mention that the styling can only be changed by somebody who has some knowledge of ActionScript (i.e. a developer, not a designer).

2. Using an MXML component

Another technique I discovered is to write the component in an "abstract" base class in ActionScript and then provide a subclass - the actual component - in MXML.

The base class would look like this:

public class TagBarBase extends LinkBar
{
  /* Implementation of the TagBar component */
  ...
}

The MXML component would look like this:

<!-- TagBar.mxml -->
<TagBarBase 
  color="#00A7E3"
  fontFamily="Lucida Grande, Tahoma, Verdana, Arial"
  fontSize="11"
  fontWeight="normal"
  paddingBottom="0"
  paddingLeft="0"
  paddingRight="0"
  paddingTop="0"
  separatorWidth="1"
  />

The only purpose of the MXML component is to extend the actual implementation class to provide default styling.

The main advantage of this method is that it's very easy for the designer to modify the default look of the component using the Flex Builder properties panel, without having to edit any MXML, ActionScript, or CSS code. The changes made thus are also immediately reflected in the Flex Builder design view.

The disadvantage is that now you have to maintain an additional MXML file for every component. There might also be some performance overhead (though minimal) of having an extra class in the hierarchy.

3. Using a theme CSS file

The default styling for your component can also be bundled into your component SWC as a theme.css file.

/* theme.css */
TagBar {
  color: #00A7E3;
  font-family: Lucida Grande, Tahoma, Verdana, Arial;
  font-size: 11;
  font-weight: normal;
  padding-bottom: 0;
  padding-left: 0;
  padding-right: 0;
  padding-top: 0;
  separator-width: 1;
}

The CSS file, along with any assets, can be compiled into your SWC in the following manner:

compc TagBar -output TagBar.swc -source-path+=. \
  -include-file theme.css ./theme.css

The application developer using your component would then have to specify your component SWC in the list of theme SWCs for the application.

mxmlc main.mxml -library-path+=TagBar.swc -theme+=TagBar.swc

As you can see, the TagBar.swc file is specified twice, once for the library path (which is normal) and a second time for the theme CSS. The theme argument of mxmlc specifies the "theme" CSS (default styling) to be used in the application. (For what it's worth, I haven't figured out how to specify additional theme SWCs using Flex Builder.)

The advantage of this method obviously is that your styling is now part of the SWC file for your component. Having the default styling in a theme.css file also feels right and is easier to maintain.

The disadvantage? For one, the designer cannot make changes to the default look without dabbling in CSS, nor are the changes reflected in Flex Builder's design view. Another problem with this approach is that all the styles in the theme.css are compiled into the final SWF, even for those components that aren't actually used in the application.

Twitter

Mon, 04 Jun 2007 10:53:21 GMT

I've been twittering.

Last day at Adobe

Thu, 01 Mar 2007 13:17:37 GMT

Today was my last day at Adobe.

I was reading Steve Wozniak’s interview in which he says how he thought he was never going to leave HP:

I said, “No, I’m never going to leave Hewlett-Packard. It’s my job for life. It’s the best company because it’s so good to engineers.” It really treated us like we were a community and family, and everyone cared about everyone else. Engineers—bottom of the org chart people—could come up with the ideas that would be the next hot products for the company. Everything was open to thought, discussion and innovation. So I would never leave Hewlett-Packard. I was going to be an engineer for life there.

I felt the same way about Macromedia and Adobe. It was going to be my job for life! But, alas, all good things must come to an end.

The one question I’m not answering is what I’m doing next. Because I don’t know myself! If you have any brilliant ideas, feel free to email me. For now, I’m just taking a break to go pursue some of my personal interests….

To all my friends at Adobe: stay in touch.

Lisp in Flash

Sat, 24 Feb 2007 20:32:52 GMT

Peter Fisk has written a Lisp interpreter in ActionScript.

Picnik: online photo editor

Thu, 08 Feb 2007 10:48:32 GMT

Recently I’ve discovered a couple of useful Flex-based online apps. The first one is Picnik, an online photo editor. It’s good for basic image processing—cropping, resizing, colour adjustment, red-eye reduction, etc.

Like most such editors, Picnik can work with images stored locally on your computer or images from a website, but the best part is the Flickr integration. Yes—it can log in to your Flickr account, grab all your photos, and let you edit them and save them back to Flickr! This could become my primary front-end to my favourite photo-sharing site.

I agree with Ted Patrick that this is probably the best Flex 2 app I’ve seen to date.

India's national motto

Thu, 25 Jan 2007 08:37:06 GMT

"Are you married? Why not?"

Courtesy: Uncyclopedia

2007: the year of OpenID?

Thu, 04 Jan 2007 09:37:40 GMT

Chris Messina has been making posts about OpenID, and I also read similar reports on O'Reilly Radar. Is 2007 going to be the year of OpenID?

I hope so. I've always found it funny how anyone can be impersonated so easily on the internet, be it email or blogs. Imagine when Bill Gates leaves a comment on a blog: who's going to believe it's him?

OpenID is an "open, decentralized, free framework for user-centric digital identity", a system under which users are identified by their URIs. For example, when I end up on an OpenID-enabled site, it asks me for my URI, which it then verifies with my identity provider. At the end of it, the site knows I am who I say I am.

I've been through the specs and also tried to implement a stateless Flash-based OpenID consumer (unsuccessfully). It's a very simple protocol, with implementations available in various languages already. Hopefully I'll find time to complete a pure client-side (either ActionScript or JavaScript) implementation sometime.

'In the end, all that matters is what you've done'

Mon, 11 Dec 2006 13:57:44 GMT

Last night I saw Alexander.

The best part in the movie is when Alexander gives a pep talk to his soldiers, just before their attack on the Persian army (an army six times their size). He addresses some of the soldiers by name and reminds them of their past achievements, of their sacrifices in past battles. There’s many a leadership lesson in there. After all, how does one inspire so many to give their lives for a cause?

There’s a lot of philosophy in the movie. The tale of Alexander is an inspiring as well as a thought-provoking one.

I’m going to spend some time studying the lives of great men and women who have walked this planet. Some of them may be myths. Doesn’t matter.

Moving a motorbike

Sat, 09 Dec 2006 20:21:25 GMT

Bhai log. Have you ever moved a two-wheeler from one city to another? How do you go about it?

In my case, the cities are Bangalore (from) and Mumbai (to). The distance between the two cities is approx. 1,000 kilometres, so riding is ruled out.

Sindhi scripts

Thu, 30 Nov 2006 22:11:38 GMT

My “mother tongue”, Sindhi, is supposed to have been written in more than eight different scripts—including Devanagari! This comes as a surprise to me. My family always wrote it in the Arabic script. I suspect there are very few Sindhis out there who write using Devanagari, let alone some of the other ancient scripts.

It’s a shame I call it my mother tongue: I can barely speak Sindhi.

My grandmother can use both Google and Wikipedia. Unfortunately there isn’t much content out there. It’s upto me and my generation to save our language. It might be worth it—it’s an interesting language.

Expose-like window navigation in Flex

Sat, 25 Nov 2006 23:24:08 GMT

What's the point in buying a Mac if you're not going to copy some of its cool features?

In my spare time, I've been working on an implementation of Expose-like window navigation in Flex 2. It's nowhere near complete, but I got so desperate to write about it that I've uploaded a quick demo here (SWF).

Demo: fTube with Flexpose (SWF)

My implementation is called Flexpose. To see it in action:

Open a few videos by double-clicking on items in the data grid.
Make sure some of the windows are overlapping. If not, you can just arrange them anyhow by dragging them by their title bars.
Press F8 to enter expose mode.
To make a window active, click on it.

As I said earlier, it's nowhere near complete. Here's a list of known bugs and missing features:

F8 doesn't work when none of the controls have focus.
When a window is highlighted (by hovering the mouse over it), its title should be displayed in front, in a larger font.
Keyboard navigation is not yet implemented. To switch between windows, you have to use the mouse.
The windows animate to different positions depending on which one is currently active. This is due to a small implementation glitch: the windows are sorted by their order on the display list, whereas they should be sorted based on their screen positions.
When the number of windows exceeds a certain limit, the whole thing becomes sluggish.

Am I missing anything? Let me know.

In any case, this is pretty good for what you can do in a web browser. And to think it takes only one line of MXML to include this in any Flex 2 application.

<Flexpose />

Yup, that's it. One line.

So, now you must be wondering where you can get the source code. Hang on a little more. In addition to the above list of bugs and missing features, I also need to refactor the code, optimise it, comment it, etc. I'm going on a long vacation now, so I'll probably complete this when I come back in 2007. Meanwhile, feel free to show this demo to your friends (heh).

Happy Hacking.

PS: The demo won't work in Internet Explorer. Sorry about that.

Markdown preview with Vim

Wed, 22 Nov 2006 12:09:04 GMT

JavaScript is ActionScript

Tue, 21 Nov 2006 09:22:26 GMT

I just realised that I’m one of the first JavaScript 2 programmers in the world. Only a slightly different flavour: ActionScript 3.

I started writing AS3 back in December 2004, almost two years ago. Like others in my team, I’ve seen the language evolve. In the beginning, we didn’t have imports, so we’d “include” any .as files we needed. Compiling the entire Flex framework would take anywhere between 2 and 10 minutes (I’m serious!). There were lots of bugs in the compiler and the VM; things we took for granted in languages like C++ and Java were still “under construction” in this new world.

Had I taken notes of my early AS3 experiences, I could have easily created a very interesting blog. Of course, I was too busy coding.

On November 7, 2006, Adobe donated the ActionScript 3 virtual machine—the platform I’ve been programming to all this while—to the Mozilla Foundation. The project, called Tamarin, will form the basis of JavaScript 2 support in future versions of Firefox (and many other projects). This is so cool in so many ways. At the core, JavaScript and ActionScript are exactly the same language (ECMAScript); it totally makes sense for them to use the same VM. Furthermore, writing a new VM is clearly a lot of work: why waste time doing it again?

ActionScript, JavaScript, now we’re one. I’m so proud of Adobe.

Missing the TrackPoint

Wed, 15 Nov 2006 14:31:52 GMT

So I've been trying to get used to my new MacBook. Aside from all the OS X annoyances, the one thing that bothers me most is that there's no TrackPoint. I've been using a ThinkPad T41 for over 2 years now, without ever feeling the need for an external mouse. The TrackPoint is right in the middle of the keyboard—it's actually more convenient. Now I guess I'll have to go mouse shopping.

Anyone have an opinion on the wireless Mighty Mouse?

I excite!!!

Thu, 02 Nov 2006 18:29:40 GMT

Jagshemash! I like you. Do you like me?

My friend Borat from glorious country of Kazakhstan is act in a moviefilm. It release tomorrow in US and A. My office peoples are go to watch Friday evening at AMC Van Ness in San Francisco.

Borat my favourite from Ali G. Show. He have a nice senses of humour. I excite!!!

Now I go for hand relief.

Styles vs. skins? Umm...

Mon, 16 Oct 2006 23:12:53 GMT

Ref.: "Styles are evil and must die. Long live skins!"

In Flex 2, styles and skins complement each other; you can't have one without the other. The skins do the actual drawing, while the styles specify parameters on how to do the drawing. You need both.

The Button component, for example, has 8 distinct states: up, over, down, and disabled, and selected versions of each of those. Each state has a corresponding skin style. By default, the same programmatic skin (mx.skins.halo.ButtonSkin) is used for all states; the default skin knows how to draw each of the states.

States of a Button object

Up	Over	Down	Disabled

The default skin is customisable to a good extent, thanks to styles like fillColor, borderColor, etc. For example, you can make the Button object have a light gray border with a red-white gradient fill.

<mx:Button label="Button" borderColor="#c0c0c0"
  fillColors="[#ff0000, #FFFFFF]"/>

It's easy enough for a designer with no coding background to do this in Flex Builder's properties panel.

The extent to which a skin can be customised depends on the styles it supports. But what happens when, say, you want to change the look of a component in a way that's not supported by the skin?

Well, then, you re-skin it.

A skin can be programmatic (an ActionScript class) or graphical (a JPEG/GIF image, an SVG vector graphic, or an asset from a SWF file). Graphical skins, of course, do not support any customisation, which is why I said it's like having a car without a steering wheel.

If you want to make your Button object look like a smiley face, you'd re-skin it by setting the skin styles upSkin, overSkin, and downSkin.

<mx:Button>
  <mx:downSkin>@Embed('icon_eek.gif')</mx:downSkin>
  <mx:overSkin>@Embed('icon_smile.gif')</mx:overSkin>
  <mx:upSkin>@Embed('icon_neutral.gif')</mx:upSkin>
</mx:Button>

Again, this is easy enough to do in Flex Builder: just click the Browse button, which opens up a file dialog, navigate to the appropriate folder, and select the image file. How much easier could it get?

States of a graphically re-skinned Button object

Up	Over	Down

The only way to apply a new skin to an object is through its corresponding skin style. You could do it in CSS...

Button {
  downSkin: Embed("icon_eek.gif");
  overSkin: Embed("icon_smile.gif");
  upSkin: Embed("icon_neutral.gif");
}

... or you could do it inline, in MXML...

<mx:Button downSkin="@Embed('icon_eek.gif')"
  overSkin="@Embed('icon_smile.gif')"
  upSkin="@Embed('icon_neutral.gif')" />

... or you could do it in ActionScript.

smileyButton.setStyle("downSkin", iconEekGIF);
smileyButton.setStyle("overSkin", iconSmileGIF);
smileyButton.setStyle("overSkin", iconNeutralGIF);

One way or the other, it's styles.

Styles provide a good additional layer of customisation in Flex. If the available styles for a component do not meet your needs, then you re-skin the component using your own graphical or programmatic skins.

Let's not forget that every good Flex component (and every component in the Flex Framework) can be completely re-skinned by the application developer. I just grep'ed the defaults.css that comes with the Framework, and it tells me that the following CSS type selectors (most of them belonging to individual components) have some kind of skin style associated with them.

global: 2
AccordionHeader: 8
Button: 8
ButtonBarButton: 8
CheckBox: 8
ColorPicker: 4
ComboBox: 8
DataGrid: 4
DateChooser: 19
DateField: 4
DividedBox: 1
DragManager: 1
FormItem: 1
HDividedBox: 1
HSlider: 6
LinkButton: 8
LinkBar: 1
ListBase: 1
Menu: 2
MenuBar: 4
NumericStepper: 8
Panel: 5
PopUpButton: 6
PopUpMenuButton: 6
PrintDataGrid: 3
ProgressBar: 3
RadioButton: 8
ScrollBar: 12
SWFLoader: 2
Tab: 8
ToolTip: 1
VDividedBox: 1
VSlider: 6
Window: 4

The numbers indicate the number of skin styles for a component. The Button component, for instance, has 8 skin styles, all of which by default point to the same programmatic skin (that's smart).

Here's the script I used, by the way (if you grok bash):

#!/bin/bash
selectors=`sed -ne '/^[A-Za-z.]/p' defaults.css`
for s in $selectors; do
  styles=`sed -ne"/^$s$/,/^}/p" defaults.css|grep 'Skin:'|wc -l|tr -s ' '`
  echo "$s: $styles"
done | grep -v ' 0$'

8@a

Tue, 10 Oct 2006 23:05:19 GMT

People ask me why I use Vim. Usually I have no answer, except, “I like it!” *grin* Then I get that funny look: Is he on crack?

I'm not on crack (not today). But I am on steroids. Vim steroids.

Consider this: I have this huge file, say 8,000 lines of code (have you seen UIComponent.as?), in which I need to convert all public variables to “properties” (getter-setters).

So, this:

  public var foo:int = 0;

Needs to look like this:

  private var _foo:int = 0;
  public function get foo():int
  {
    return _foo;
  }
  public function set foo(value:int):void
  {
    _foo = value;
  }

Hmm… what do I do?

If I were a Perl guru, I'd whip up a script. Thankfully, I'm not—because there's an easier, faster, and more fun way of doing it.

In Vim, you can record macros using the ‘q’ command. The recorded keystrokes are saved into what's known as a “register” in Vim parlance. In my case, I record a set of keystrokes—a pattern applicable to any public variable—and save it into the register ‘a’.

Here's what my recording looks like (iso-8859-1).

A bunch of gibberish, yes. Of course, you never have to see it! This is how it looks internally, in Vim's memory. The reason I post it here is to show you how there's no reference to the variable name “foo” or the type int in it—it's a pattern. It took me about a minute, and two unsuccessful attempts, to get it right.

Now comes the fun part: playing the macro. I just place my cursor at the top of the file (line 1) and hit ‘@’ (play) followed by ‘a’ (name of register).

Lo and behold! The first public variable has been successfully converted to a getter-setter pair!

Before:

  /**
   *  This object's foo.
   */
  public var foo:int = 0;

After:

  /**
   *  @private
   */
  private var _foo:int = 0;

  /**
   *  This object's foo.
   */
  public function get foo():int
  {
    return _foo;
  }
  public function set foo(value:int):void
  {
    _foo = value;
  }

After running it a couple more times, I realise it's good enough, so I just do a search for “public var”, Vim tells me there's 8 matches, I hit ‘8@a’ (play ‘a’ 8 times), and the whole file has been converted. How cool is that?

Writing code is the most boring part of programming. Someday we'll get rid of it completely, but, for now, a good editor really helps.

More nukes!

Mon, 09 Oct 2006 21:27:22 GMT

North Korea just conducted a nuclear test.

This reminds me of our own situation. How long before we end up in a nuclear exchange with our dear neighbours?

View Poll: #840907

Live life to the fullest. You never know what's to come.

Globals

Wed, 04 Oct 2006 21:11:38 GMT

You have a main application and two sub-applications loaded dynamically using the SWFLoader component.

<Application xmlns="http://www.adobe.com/2006/mxml">
  <Label text="Main" />
  <HBox>
    <SWFLoader source="sub1.swf" />
    <SWFLoader source="sub2.swf" />
  </HBox>
</Application>

The sub-applications have one List object each, with drag 'n drop enabled.

You try to drag items from one sub-application to the other, but the other application does not accept the drop.

Why is that?

Okay, now you add an empty List object (with drag 'n drop enabled) to the main application as well. Try moving items between the three applications now.

It works!

So, why does adding a List object to the main application suddenly make drag 'n drop work across all three applications?

Replace the List object in the main application with a Script block that refers to the DragManager class.

<Script>
  private var dragManagerDependency:DragManager;
</Script>

There's no List object in the main application anymore. Try moving items between the two sub-applications now.

It works? Yes.

Conclusion: For drag 'n drop to work across two sub-applications, the DragManager class must be linked into the main application SWF.

Why so?

Why is it that the DragManager class must be linked into the main application SWF?

If you're familiar with the DragManager API, you know that it's essentially a singleton class with a bunch of static methods.

The way the SWFLoader component works, sub-applications are loaded into child application domains of their own. When code in a sub-application refers to a class, the class definition is looked up (by the Flash Player) in the application domain chain, starting from the root--the system application domain.

(Roger Gonzalez has written extensively on the topic of application domains.)

When the List component makes a call to the DragManager API for doing a drag 'n drop operation, the DragManager class definition used by the component is the one found first in the application domain chain (starting from the top). In the first example, since there's no DragManager definition in the main application domain, the one used is the one found in the sub-application's own application domain; thus, each sub-application uses its own definition of the DragManager class.

Now you see the problem? The DragManager in sub-application #1 is not the same as the DragManager in sub-application #2; as far as the Flash Player is concerned, they're two different classes. If one List object calls doDrag on one DragManager, and the other List object calls acceptDragDrop on the other DragManager, it's not going to work, is it?

By including a DragManager definition in the main application, we ensure that both sub-applications use the same DragManager--the one found in the main application domain. (Both sub-applications still have their own definitions of DragManager, but they're never used.)

Solving it at the framework level

The core problem here is that the DragManager class maintains state in a bunch of global (static) variables, and each copy of the class has its own separate copy of this "global" data. At the framework level, the solution lies in either sharing this data across multiple application domains, or sharing a single instance of the class across multiple application domains--making it a true singleton.

Let's look at some of our options for solving this in the Flex Framework.

Share the implementation

The easiest and quickest solution is to share the DragManager implementation across all application domains by linking it into the main application. This can be done by automatically including the class in the ActionScript code genereated by the MXML compiler.

If we did that, though, we would end up bloating the size of every Flex application out there--even those that have nothing to do with drag 'n drop. This isn't really a solution.

Share the state

Another option is to share the static variables across application domains, by moving them to a separate class, say DragManagerGlobals, and linking that class into the main application.

package mx.managers {
  public class DragManagerGlobals {
    public static var dragInitiator:IUIComponent;
    public static var dragProxy:DragProxy;
    public static var bDoingDrag:Boolean = false;
    public static var mouseIsDown:Boolean = false;
  }
}

The DragManager code would then have to be modified accordingly to use these variables instead.

package mx.managers {
  public class DragManager {
    public static function doDrag(...):void {
      ...
      if (DragManagerGlobals.bDoingDrag)
        return;

      DragManagerGlobals.bDoingDrag = true;
      ...
    }
    
    ...
  }
}

The DragManagerGlobals class would be linked into the main application, thereby making it truly global. Both implementations of DragManager (in the two sub-application domains) would share the same global state.

Share the interface

The previous approach would work fine, except for one problem: What if the two sub-applications are using different versions of DragManager? This could happen if, say, one sub-application was built with Flex 2.0 and the other with Flex 3.0. The implementations between two major versions could differ so drastically that the global variables of one wouldn't make sense to the other. Do you seriously think that the DragManager of Flex 3.0 will have only 4 variables?

This brings us to the third and most elegant solution: share the interface. With this approach, only one implementation of the class is used at any point, while the interface is common across application domains.

To do that, first we would have to move the implementation of DragManager out into another class, say DragManagerImpl.


package mx.managers {
  import mx.managers.IDragManager;

  public class DragManagerImpl implements IDragManager {
    ...
  }
}

When the DragManager class is loaded, it would register its implementation class with another "truly global" class--SingletonManager.

package mx.managers {
  public class DragManager {
    // Class initialisation
    SingletonManager.registerClass("mx.managers.IDragManager",
      mx.managers.DragManagerImpl);
    
    ...
  }
}

DragManager would then forward all calls to the one and only instance of the implementation class.

package mx.managers {
  public class DragManager {
    ...
    
    private static function getInstance():IDragManager {
      if (!instance) {
        var implementationClass:Class = SingletonManager
          .getClass("mx.managers.IDragManager");
        instance = new implementationClass();
      }
      
      return instance;
    }
    
    public static function doDrag(...):void {
      // Forward to implementation
      getInstance().doDrag(...);
    }
    
    ...
  }
}

The actual implementation used would be the one from the sub-application loaded first. If sub-application #1 is loaded first, the DragManagerImpl class of sub-application #1 would be used for all drag 'n drop operations, including those local to sub-application #2. If sub-application #1 is Flex 3.0 and sub-application #2 is Flex 2.0, then sub-application #2 would also get to benefit from the new drag 'n drop features in Flex 3.0!

Wallop: Social networking 2.0?

Wed, 27 Sep 2006 19:35:44 GMT

A couple of weeks ago, I was having a conversation with someone about killer apps, and I said that social networking sites needed to go to the next level, enabling sharing of rich media, live video chat, screen sharing, digital whiteboards, and so on. I called it “social networking 2.0”. (“Social networking 2.0?! Interesting. You should be in marketing!”) What I had in mind was something feature-rich like Breeze but on the scale of MySpace.

Today I got my Wallop invite from Ryan Stewart. First impression? Awesome user interface!

So far, I've created a home page, uploaded some pictures, posted a couple of blog entries, exchanged notes with Ryan, and connected with a couple of other folks on the network. In terms of navigation, the experience is superb. This is what we call a rich internet application (RIA).

In the “Mods” (widgets) section, I saw a little piano that I'd probably like to purchase and add to my page. It was for $0.25. Cute.

What I found the site sorely lacking in was actual social networking features. It seemed impossible to look someone up on the network. The site also didn't seem to care for my personal details, interests, and such, which means it probably won't connect me with others very easily.

Coming back to the 2.0 thing: Is Wallop social networking 2.0? In terms of UI, yes, I think they're on the right track. In terms of advanced social networking features, I'm afraid I have to say they've got a long, long way to go. I'd like to do a video chat with Ryan, or share my screen so we can work on something together, and actually save the session for later viewing. And why do user profiles always have pictures but no audio or video clips?

All that said, if there's any site that's going to be social networking 2.0, it's got to be Wallop. They're already on the right client platform (Flash).

Here's my Wallop home page. If you need an invite, just leave a comment or shoot me a quick email!

Update, 2:20 PM: I'm out of invites!

API binary compatibility in ActionScript 3

Sat, 23 Sep 2006 19:43:09 GMT

An API change in a component is backwards compatible if existing client code written against the component before the change continues to compile and run without errors, and perform as expected, against a new version of the component after the change.

There are 3 levels of API compatibility:

Binary compatibility: Code runs without errors
Source compatibility: Code compiles without errors
Contract compatibility: All conditions mentioned in the API specification are met

Binary compatibility in ActionScript 3

Binary compatibility depends on the programming language, runtime, and tools, and thus poses the greatest challenge to component developers.

Based on a series of experiments aimed at understanding the nature of binary compatibility in ActionScript 3, here's a listing of the different types of API changes and whether or not each one is binary compatible.

Type of Change	Client Role¹	Binary Compatible
Adding a new package	-	Yes
Deleting an existing package	-	No
Adding a new member to a package	-	Yes
Deleting an existing member from a package	-	No
Adding a new member to a class or interface²	Caller	Yes
Adding a new member to a class or interface²	Implementor	No
Deleting an existing member from a class or interface	-	No
Expanding the supertype set of a class or interface	-	Yes
Contracting the supertype set of a class or interface	-	No
Re-ordering members in a class or interface	-	Yes
Changing the name of a parameter in a function	-	Yes
Adding a non-optional parameter in a function	-	No
Adding an optional parameter in a function³	Caller	Yes
Adding an optional parameter in a function³	Implementor	No
Deleting a parameter (optional or non-optional) in a function	-	No
Changing the type of a function parameter, or the type of a member, to a compatible type⁴	Caller	Yes
	Implementor	No
Changing the type of a function parameter, or the type of a member, to an incompatible type⁵	-	No
Changing a constant to a variable	-	Yes
Changing a variable to a constant	-	No
Changing a final member to non-final	-	Yes
Changing a non-final member to final	Caller	Yes
Changing a non-final member to final	Implementor	No
Increasing the access-level of a member in a class or interface from protected to public⁶	Caller	Yes
	Implementor	No
Decreasing the access-level of a member in a class or interface from public to protected	-	No

For some changes, binary compatibility depends on the role played by the client. The client may play the role of a caller, an implementor, or both.
If a new method is added to an API class, and clients may extend the class (the class is non-final), it's possible that a client class might have declared a method of the same name as the one being added to the API class; in this case, the change is not binary compatible and will lead to a runtime error. If a new method is added to an API interface, and the interface is implemented by a client class, the change will cause a runtime error in the client class for not implementing the newly added method.
If a new optional parameter is added to a member function of an API class, and a client class extends the API class and overrides the function, this will cause a runtime error in the client class for not overriding the function with the correct number of parameters.
If the new type is “compatible”, meaning that a variable of the old type can be cast to a variable of the new type, the change is compatible. e.g. changing the type of a variable from String to Boolean.
If the new type is “incompatible”, meaning that a variable of the old type cannot be cast to a variable of the new type, the change is incompatible. e.g. changing the type of a variable from flash.display.TextField to flash.display.Sprite.
If a member in an API class is changed from protected to public, and a client class extends the API class and overrides the member, this will cause a runtime error in the client class for not overriding the member correctly.

Note on source compatibility

Most changes that are binary compatible are also source compatible. In practice, the difference between binary and source compatibility in ActionScript 3 is small enough that they can be considered as one and the same.

Pyaar Ke Side/Effects

Mon, 18 Sep 2006 19:44:22 GMT

Man and woman, a steady relationship, one day the inevitable strikes: she wants to get married. Oops! :)

Pyaar Ke Side/Effects is a sweet romantic comedy, Rahul Bose-style. My favourite scene in the movie: the argument match between the couple (scoreboard and all). It was just hilarious.

Apparently Rahul and Mallika are blogging too.

Pioneering clipboard spam

Mon, 18 Sep 2006 14:59:43 GMT

Hi. I'm starting a web 2.0 company. Our main product is a lightweight cross-platform clipboard spammer called Spookey. Check it out!

How does it work? It's a little Flash application, written in AS3. Here's the source: Spookey.as.

We set up a timer to write to the system clipboard every 100 milliseconds.

public function Spookey() {
  parameters = loaderInfo.parameters;

  var timer:Timer = new Timer(100);
  timer.addEventListener("timer", updateClipboard);
  timer.start();
}

private function updateClipboard(event:*):void {
  System.setClipboard(parameters["content"]);
}

The content to be written comes from the “content” parameter passed to the application in the HTML wrapper. You can set it to anything.

<script type="text/javascript">
  var flash = new SWFObject("Spookey.swf", "spookeyObject",
    "0", "0", "9");
  flash.addVariable("content", "5p00k3d?");
  flash.write("playerDiv");
</script>

And that's it! Now you can spam your website visitors' clipboards to your heart's content. Isn't that kool?

Here's the SWF file: Spookey.swf (821 bytes).

We don't have a business model.