« March 2006 | Main

April 26, 2006

My blog has moved

Hi folks. I've decided to move my blog off the Adobe servers and onto my own domain. The new address is http://kuwamoto.org/.

The blog at this address will no longer be updated.

If you have any links, please update them. Thanks!

Posted by sho at 10:14 PM | Comments (0) | TrackBack

April 17, 2006

Openings on the Adobe Flex team

Hi folks. We are still looking for great people to help us build Flex and Flex Builder.

Here are the openings in the US:

WW020602-Developer, Flex Enterprise
TB010604-Senior Quality Engineer
LM020604-Flex Builder QE Engineer
WW020603-Architect, Flex Enterprise
SK120506-Computer Scientist
HW020602-Computer Scientist - Flex Builder

And here are the openings in India:

Senior Computer Scientist
Quality Engineer
Quality Manager

If you or someone you know is a good fit for these positions, let us know!

Thanks!

Posted by sho at 11:09 AM | Comments (0) | TrackBack

April 10, 2006

New Flex component - Sliding Drawer v 0.5

I created a panel that slides into view when you mouse near the edge of the screen as part of a personal project. I'm distributing the sliding drawer under creative commons so that other people can use it.

To use the drawer component, just add the tag to your view:

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" xmlns:ui="sho.ui.*">
	
    <ui:Drawer title="Left" dockSide="left">
        < !-- drawer contents go here -- >
    </ui:Drawer>

</mx:Application>

This results in a drawer that pulls out from the left edge of the screen like so:

DrawerDemo.png

NOTE: Requires Flash Player 8.5 beta 2.

[Demo - sliding Drawers]
[Source code]

Known issues:

Posted by sho at 10:36 AM | Comments (16) | TrackBack

April 05, 2006

AS3 -- on the lack of private and protected constructors

As I was talking about using objects as enums, someone made a comment about the lack of private and protected constructors. I know that the this is a sore spot, so I thought I'd explain my view of how we got here, and give my two cents.

The problem is that unlike what we did with ActionScript 2, we are working tightly with people from Mozilla and others to standardize on ECMAScript edition 4. The ECMAScript standard is not final, but we are adhering as closely as we can to the spec as it develops.

Private and protected constructors is not something that the group has been able to tackle yet, and it is a nontrivial change to the language that requires lots of careful thought.

Ideally, we would have been able to think through all the ramifications of private and protected constructors and work with other ECMA members to make sure the design was sound, but that just wasn't possible in the amount of time we had.

Given this, there were three choices:

1) Delay ActionScipt 3 (and Flex, etc.) significantly.
2) Just "go with" a quick and dirty implementation of private and protected constructors for AS3 and risk compatibility problems down the road once the ECMA spec becomes final.
3) Don't allow private and protected constructors for now.

We went with option (3).

The main uses of private and protected constructors are singletons and abstract base classes. In both of these cases, I agree that the lack of real private and protected constructors is a pain. There are hackarounds which will work for now, but I am eagerly awaiting the day when we don't have to use them anymore.

As for the specific use case described in the previous post (using objects as enumerations), the main thing that private/protected constructors allows you to do is to ensure that the set of "enum" values cannot be extended later by someone else.

I personally like having this level of control, but I am willing to live without it. It "feels better" to create a system where no one can add any more values to the enumeration, but in practice,

a) If people create new values for the enumeration and try to use them with code that wasn't expecting those values, it will obviously break. So who is going to do this?

b) If people create new values for the enumeration and use them only within their own code... well... it kind of breaks the spirit of what an enumeration is, but it might be just fine.

Here's a concrete example of scenario (b). Imagine that I create a text control with three values for alignment: LEFT, RIGHT, and CENTER. Someone subclasses this control, and wants to create a fourth enumeration value: JUSTIFY. This new value would obviously only be useful for this person's subclass, but who am I to say that he/she shouldn't create it?

Like I said, I would ideally like the option of controlling what can and can't get extended, but in the case of enumerations, I'm ok with not having that control for now.

Posted by sho at 09:03 AM | Comments (5) | TrackBack

April 04, 2006

AS3 technique -- using object instances as "enums"

Just after posting the updated version of the CompletionInput control, it occured to me that I should read through the source code to make sure there's nothing too strange lurking in there.

One thing that might warrant some explanation is why I used object instances to represent "enums". This is a technique that should be familiar to Java developers but may not be familiar to all AS developers.

In LoopResult.as, I define constants like this:

public class LoopResult {
    public static const KEEP_GOING : LoopResult = new LoopResult();
    public static const STOP : LoopResult = new LoopResult(); 
}

Whereas in CompletionInput.as, I define them like this:

public class CompletionInput extends mx.controls.TextInput 
{
    public static const COMPLETION_FAILED    : int = 1;
    public static const COMPLETION_SUCCEEDED : int = 2;
    public static const COMPLETION_ASYNC     : int = 3;
    ...
}

In both cases, I use these static members as if they were "enums".

	...
	return LoopResult.KEEP_GOING;
or
	return CompletionInput.COMPLETION_SUCCEEDED;

The main difference between the two is that the first version is typesafe -- I can declare my function as returning a LoopResult, not an int or a String.

PRO:
CON:

Posted by sho at 10:16 AM | Comments (6) | TrackBack

April 03, 2006

Flex auto complete text input control v0.6

Here is a new version of the auto complete text input control, which is a cross between Google suggest, the "save information I typed in forms" preference found in browsers, and the HTML <select> control.

If you provide a static list of items to the control, the control can do the filtering. Alternatively, you can create a function to give suggestions (which is necessary if you are doing the filtering on the server).

As before, there is a "mustSelect" flag which turns the control into a sort of super version of the HTML <select> tag. The main benefit to using this instead of <select> is that using the keyboard to narrow down your choices is much easier.

Finally, I added the ability to automatically save form data as local storage and provide hints based on this data. This makes it behave similarly to HTML text fields in most browsers.

Unlike how browsers work (so far...) you can individually delete these hints. I hate it when I mistype something into a field and I get a hint for that typo every time I visit the app! With these controls, you can right mouse on any of the hints you don't like and delete them.

NOTE: Flex beta 2 is REQUIRED for viewing or using this control.
[Sample -- Simple form using CompletionInput]
[Source code]

Known issues:

Let me know what you think. And if you find any bugs, please let me know (especially if you have a fix!!)

Posted by sho at 10:41 AM | Comments (16) | TrackBack

Layering Flex over AJAX and collaborating with data services -- whoa!

Christophe just posted an example of how to layer Flex over AJAX to do video chat and shared whiteboard as an overlay to Google Maps. You could use this to draw a route on a map for someone else to see, for example.

I think my head is going to explode.

http://coenraets.com/viewarticle.jsp?articleId=100

Posted by sho at 09:11 AM | Comments (0) | TrackBack