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 (0)
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 (0)
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:
NOTE: Requires Flash Player 8.5 beta 2.
[Demo - sliding Drawers]
[Source code]
- Programmatic instantiation of these drawers has not been tested. I have only used <Drawer> as a tag in MXML.
- Drawers shows up in Flex Builder's design view at (0,0), which can be misleading.
- There is something funky about depth management. For example, if you put a <CompletionInput> in a drawer, the hints show up underneath the drawer.
- Resizing of children doesn't seem to be happenning correctly. For now, either use fixed sized contents inside of drawers, or help me find the bug! :-)
- There appears to be a compiler bug that makes it impossible to use an MXML component that is based on <Drawer>. If you would like to make an MXML component for your drawer contents, base the component on a container (such as <Canvas>) and put your component inside a <Drawer> tag, as opposed to basing your component directly on a Drawer.
Posted by sho at 10:36 AM | Comments (16) | TrackBack (0)
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 (0)
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:- Using object instances for enumerations makes your program more typesafe. This can be a huge win!
- More complex -- you have to create another class to hold your enumeration type.
- Somewhat less readable.
- Possible memory or performance issue, although I bet it's negligible.
Posted by sho at 10:16 AM | Comments (6) | TrackBack (0)
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:
- Saved form data is never automatically removed, which may eventually lead to running out of shared object space. The user can always manually delete the saved form data using the right mouse
- When you navigate through the hints, keyboard events continue to propagate to the control. So, for example, if you hit the up arrow while the hints are showing, the selection in the hint menu will move up one, and the insertion point in the text field will move all the way to the beginning of the control. This is due to a player limitation, and I am still struggling to find a good workaround.
- Sometimes, when using the "keepLocalHistory" feature, you will find multiple versions of the same string in your history. I am 95% positive it is just a programming error on my part, but I can't track it down. (help?)
- Hints don't reposition themselves if the control moves while the hint is visible.
- A scrollbar appears in the hint dropdown even when not needed.
- Do not use this for password fields! I have never actually tried it, but I bet you can get it to show you a popup that lists the last few passwords you've typed... Probably not what you want, security-wise!
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 (0)
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 (0)
March 28, 2006
Last minute change - speaking at FITC
Hi folks.
As it turns out, I will be speaking at FITC in place of Christian Cantrell*, who is on leave. Nominally, the talk is on Flex Builder, but I'd like to solicit your opinion -- what should I be talking about? Is it worthwhile to have a one hour session focused purely on the tool? There is only one other Flex talk, which is a Flex overview given by Chafic.
The reason I am asking is that my gut tells me that spending 50% of the time on the framework and 50% of the time on the tool feels like the wrong balance.
* (footnote) This is ironic, because Christian was actually filling in for me, because I was originally unable to do FITC because of my schedule, which has since changed.
Posted by sho at 10:19 PM | Comments (2) | TrackBack (0)
March 21, 2006
Flex 2.0 beta 2 now available
Flex 2.0 beta 2 is now available at labs.adobe.com.
Highlights
--
- The API has been scrubbed for consistency. A lot of names have been changed, but in a fairly straightforward way.
- The new contraint syntax is in place (yes!)
- You can now choose a subdirectory within your project to place your source files
- You can use the [Bindable] metadata on getters and setters
- You can initialize inherited properties through MXML tags with the id attribute. (this is usually used to support a "code behind" idiom)
- Many, many bugs fixed, of course.
All the gory details are available at http://labs.macromedia.com/wiki/index.php/Flex:Beta_1_to_Beta_2_Changes
Posted by sho at 08:49 AM | Comments (3) | TrackBack (0)
March 08, 2006
Some personal thoughts on the Flex/AJAX Bridge...
Before moving to the Flex project, I ran engineering for the HTML tools division at Macromedia. Back then, we thought a lot about advanced DHTML techniques, including the technique of using XMLHTTPRequest to update portions of a page locally, which has since come to be called AJAX.
As you can see from my posts, I eventually ended up moving to Flex. AJAX is wonderful and has its share of strengths, but I find working with Flex to be more fun for me personally. Flex is a great way to put together richer and more complex front ends. It has a runtime that is consistent across browsers, and an object model that is designed from the ground up to support networked application UIs.
I'm still a big fan of AJAX. I believed in it way back when, and I believe in it now. But Flex can do a lot that would be difficult in AJAX, both visually and in terms of data connectivity.
I'm quite curious to see how people use the two together. I'm convinced that some of the raw building blocks inside of Flash/Flex (e.g., binary sockets) have a lot to add to the AJAX puzzle.
P.S. In my last post, I mistakenly called this the Flex/ActionScript Bridge, which is obviously much less interesting. :-) Thanks to Robert Penner for pointning this out to me.
Posted by sho at 01:05 PM | Comments (9) | TrackBack (0)
