Joeflash’s Enigmacopaedia


Rounded Clipping for Fx4 BorderContainer

Posted in Flex, Flex 4 by Joeflash on the March 17th, 2010

A few days ago someone in the Flex 4 prerelease forums posted an interesting question: how do you create a rounded clip area for a spark container? Not knowing the answer off the top of my head, I thought this would be a good opportunity to teach myself some specifics about creating custom container components in Flex 4.

MaskedBorderContainerSample

First I tried the obvious, which was to set up two elements and make one the mask of the other, like so:

  1. <!-- maskee -->
  2. <s:Group id="cpmaskee" width="400" height="250" top="20" left="20"
  3.          mask="{cpmask}">
  4.     <!-- this is the content -->
  5.     <mx:Image source="@Embed('wallpaper-halo-3-01.jpg')" x="-100" y="-100"/>
  6. </s:Group>
  7. <!-- mask -->
  8. <s:Graphic id="cpmask" top="20" left="20">
  9.     <s:Rect width="400" height="250" radiusX="20" radiusY="20">
  10.         <s:fill>
  11.             <s:SolidColor color="0xCCFFCC"/><!-- can be any color -->
  12.         </s:fill>
  13.     </s:Rect>
  14. </s:Graphic>

Which resulted in a nice rounded mask over the content:

MaskedBorderContainerTest1

But this was not quite what I wanted. The entire image was still being rendered, only not visible through the mask. So the edges of the image needed to be clipped regardless of whether the corners were rounded. And to be able to see a rounded border.
(more…)

Simple Monkeypatch to fix ToolTipManager.destroyToolTip RTE

Posted in Flex, Flex 3 by Joeflash on the March 13th, 2010

So I’m coding a custom tooltip which stays visible when you click on the target (more on that in a future post), so I need to manage the tooltip behaviour with ToolTipManager.createToolTip rather than the UIComponent’s tooltip property, or tooltip events. Ben Clinkinbeard’s monkey patch for ToolTipManagerImpl came in real handy for this.

From this “always on” tooltip, I have a button which asks the user for confirmation before performing the action, after which I dismiss the tooltip. Problem is, an RTE “The supplied DisplayObject must be a child of the caller” always ensues.

Until I realized that calling Alert.show() when a tooltip is showing always dismisses the currentToolTip. So calling ToolTipManager.destroyToolTip on a ToolTip which had already been “dismissed” would of course generate an RTE.

Shouldn’t the ToolTipManagerImpl class be smart enough to figure this out without bugging me with an RTE? Shouldn’t it check first to see if there are children present to remove before attempting to remove them? There may be other situations in my app where I may not always be aware of whether my tooltip is located in the toolTipChildren list.

So, taking a cue from Ben’s monkeypatch, I scrolled down to the next function, and monkeypatched mx.managers.ToolTipManagerImpl.destroyToolTip():

Original code:

  1. public function destroyToolTip(toolTip:IToolTip):void
  2. {
  3.     var sm:ISystemManager = toolTip.systemManager as ISystemManager;
  4.     sm.topLevelSystemManager.removeChildFromSandboxRoot("toolTipChildren", DisplayObject(toolTip));
  5.     // hide effect?
  6. }

Monkeypatched code:

  1. public function destroyToolTip(toolTip:IToolTip):void
  2. {
  3.     var sm:ISystemManager = toolTip.systemManager as ISystemManager;
  4.     if(sm.topLevelSystemManager.toolTipChildren.numChildren){//patch to avoid RTE//
  5.         sm.topLevelSystemManager.removeChildFromSandboxRoot("toolTipChildren", DisplayObject(toolTip));
  6.     }
  7.     // hide effect?
  8. }

In addition to correcting my errant destroyToolTip call, this solved any future unknown RTE’s around that issue.

Alternately, if you don’t want to monkeypatch the ToolTipManagerImpl class, you can wrap your destroyToolTip call in a try/catch error block.

Adobe Flex 3.5 SDK Released

Posted in News, Flex, Flex 3 by Joeflash on the December 15th, 2009

Today Adobe released version 3.5 of the Flex SDK.

I noticed that the Flex Downloads and the Flex 3 Release Notes pages have not yet been updated for v.3.5. Let’s hope Adobe releases the automation and visualization SWCs for v.3.5 as well.

UPDATE Jan 23, 2010: As reported on the Flex Team Blog on January 5th, the datavisualization and automation libraries are now available on the Adobe Flex SDK Downloads page

The Pain of Downloading A Complete Flex SDK

Posted in Flex, Tools, Flex 3, Flex 4, Flash Builder 4 by Joeflash on the November 24th, 2009

Usually, when adding new upgraded SDKs to Flex Builder, say to version 3.4, I’ll go to the adobe open source site and download them from here. Problem is, I’ve then got to hunt around for the download link for the datavisualization components and the automation components (not that I use them all that much, I just like to have them handy).

This page on Adobe’s website tells you that the datavisualization components and the automation components are available on this page. And yet you go there, and no download link. Turns out that the actual download page was listed on the Flex Team’s blog, which leads you to the correct download page here. Good thing I bookmarked it, or I might have a real hard time finding it, cause it sure doesn’t show up on a simple Google search.

And then I’ve got to merge the upzipped datavisualization and automation folder structures with the unzipped Adobe SDK download, to get a “complete” SDK.
What a huge pain.

But there’s an easier way.

While I was installing Flex Builder to a new machine, including migrating all my SDK version folders, I thought, why not take a peek at the latest Flash Builder 4 Beta 2 application installation?

And lo and behold, versions of the following SDKs, which include datavisualization and automation components:

  • Flex SDK version 3.4.1.10084 (stable build)
  • Flex SDK version 4.0.0.10485 (milestone build)

(You can find the full SDK version number in the flex-sdk-description.xml file in the root of the SDK folder.)

So all I did was copy those folders from the Flex SDK 4 Beta 2 sdk folder to the Flex Builder 3 sdk folder, et voilà! :)

NOTE: the Flex SDK 4 Beta 2 download from the Adobe Labs page is incorrectly named as version 4.0.0.100509 in the filename. This zip file is in fact version 4.0.0.10485, and is the exact same zip file as the milestone listed on this page, which you can download here.

Except for one thing…

(more…)

Surviving as a Flash Platform Component Maker

Posted in Business, Flex, Community MX, Adobe, Best Practices, Components, Flash Platform Community by Joeflash on the October 17th, 2009

There is no doubt: making it as a commercial component maker is a tricky business, what with open source competition on the one hand, and Adobe being possible competition on the other. Now that we’ve defined the kinds of commercial components in the previous post, with these roadblocks, how do you make it in the current commercial ecosystem?

While reviewing recent discussions over at Grant’s blog while writing my previous post, I was reminded of a few things about successful component companies, which I recently discussed in an email conversation with Jeffry Houser over at Flextras about the matter, who encouraged me to blog about some of the points I brought up.

Now keep in mind I’ve never built a business model around making money developing Flash components, so take this part for what it’s worth; however there are a few things I’ve observed over the last decade in the Macromedia/Adobe/Flash industry about successes and failures in this area.

Most commercial Flash component makers start in one of two places:
a) they begin offering mid-level components
b) they have a successful but related business, and offer commercial components to go with their existing proprietary SAAS or server technology.

We won’t even talk about throwaway commercial components, because as I mentioned in the previous post, they should be open sourced anyways.

Starting a commercial component business based solely on mid-level components, as some have done, offers the benefit of relatively little startup capital (basically sweat equity), which gets you up and running very quickly. However, mid-level components can be challenging to hang a business model on, for a few reasons:

a) If they are “extensions,” (i.e. AcmeEnhancedDataGrid) Adobe could, tomorrow if they feel like it, come along and incorporate those ideas into the next version of the framework. In other words, your components may at some point come into conflict with FOSS components of similar functionality.

b) Which means that someone else could also, if they put in the effort, rip off your ideas, at least functionally, and present unwanted, even “illicit” competition, depending on how much they copied you.

c) The lack of phone support and strict licensing means that IT departments, used to spending big bucks to have added functionality at a minimum of fuss, might not regard it/them as serious candidates for an enterprise app, and may not even bother to dig into the API to find out if it has green threading or loose binding functionality.
(more…)

Competition in the Commercial Flash Component Ecosystem

Posted in Business, Flex, Adobe, Frameworks, Components, Flash Platform Community by Joeflash on the October 17th, 2009

There has been some discussion recently as to whether FOSS competes with commercial component offerings, and whether Adobe is unfairly competing with its own developers. Well, the answer is maybe, and maybe. The confusion is partly due to a lack of definition as to what constitutes a commercial Flash component, which lies at the heart of the matter. In the case of Adobe unfairly competed with Grant Skinner, well… read on.

Whether FOSS constitutes competition with commercial components, it all depends on what type of commercial components we are talking about, which is the crux of the matter.

First, let’s define what is not a commercial component. Components developed under no license, or under a FOSS license is not commercial, whether they be pre-compiled SWC-type component, a component with sourcecode, or a component which is really just part of a larger open source library.

Types of Commercial Flash Platform Components

1. Amateur or ‘Throwaway’ Components:

A throwaway component is more of the “Monster Template” or what I derogatorily call “FlashKit”-style components. It’s more of a one-shot use component, often with an incomplete API, sometimes not very great encapsulation, little documentation, no support, and cheap. Great if you’re a beginner-to-intermediate developer and you need a quick fix, but not very useful otherwise. Most times these components should be released open source, if not due to their incompleteness, then because even if it is just a few bucks, often you’re just paying for some-dude’s-experiment. Commercial software needs to be up to certain standards IMO, or it should be free, and even then.

There is no question that FOSS and future Adobe framework offerings will compete with these kinds of components — but did you honestly think anyone would actually pay for them anyways? So they’re not really a factor.

Most of the controversy about competition, either from Adobe or from FOSS, is due to a confusion in the difference between what I call a “mid-level” and an “enterprise” component.

2. Mid-level Components:

A mid-level component, in my view, can be either a mashup widget, in that its innovation or rather uniqueness lies in doing something new in the realm of webservices or connectivity, like a Google Map widget. It is also common for mid-level components to be enhancements or extensions of existing Flex or Flash components, including some media players, because they enhance what an existing component architecture already does, or provides a better version of an existing Adobe or open source component.

There is a big difference between a throwaway and a mid-level component: mid-level components often have a well-crafted API, sound documentation with examples, sometimes even the source is included. And with some of the better companies, responsive help forums, and/or email support is present.

3. Enterprise-level Components
(more…)

The Perfect Flex Workflow: Flex Builder 3 with FDT 3.2, Part 1

Posted in Tutorials, Flex, Workflow, Flex 3, Flex Builder 3, Eclipse, FDT by Joeflash on the June 27th, 2009

I’ve long wanted to use FDT to turbocharge my ActionScript coding, but without Flex MXML support I couldn’t justify the cost of getting both Flex Builder and FDT. Then FDT 3.2 came out this past May — finally I had an answer to my prayers with FDT’s new MXML support. And I actually won a copy of FDT Enterprise at 360|Flex Indy: total awesomeness! Now I could decide if once and for all I could get rid of Flex Builder in favour of FDT.

So I tinkered with FDT, converting some of my old projects and seeing how they compiled and ran. And for the most part it all went off without a hitch. I was really quite impressed with FDT’s new Flex capabilities. Also, I had been using Flex Builder for the occasional Flash Professional project for code editing, and FDT now makes that sooo much easier, much like SEPY used to do back in the day.

But it was not to be. Shortly after porting over a Flex project I’m working on, I realize I’d gotten used to having aspects of Flex Builder available in my workflow. Like certain Flex project settings, and the Profiler. Maybe later on I’ll explore the enterprise features of FDT like the Debugger or the SoS logger, but for now all I want FDT to do is gimme that sweet coding savvy which Flex Builder sorely lacks. I mean, there isn’t a single Eclipse-based IDE or plugin I’ve seen which comes anywhere close to the sheer overwhelmingly awesome coding intelligence and snippet templates of FDT.

So what I’d like to be able to do is use FDT for coding both AS and MXML files, and use Flex Builder for the actual compilation, debugging and profiling. And of course the faster compiler and the Network Monitor in Flash Builder 4, when it’s released.

So how do I get the best of both worlds? They’re both available as plugins, so I should be able to install and use them both, right?
(more…)

Don’t Panic: The Rebranding of Flex Builder

Posted in Flash, Flex, Adobe, Workflow, Flash Builder 4, Flash Platform Community by Joeflash on the May 24th, 2009

I’m going to throw my hat in the ring here: I think naming Flex Builder as Flash Builder is a good thing overall. Part of the challenge for developers today is that there are now so many interconnecting technologies under the umbrella of the Flash Platform, that some of the naming needs to catch up with technology, and I believe that’s what’s happening here.

The Flash Platform now consists of a technological system comprised of multiple runtimes, tools, frameworks, and languages, so that simple words such as “Flash” and “Flex” no longer suffice to differentiate what we’re talking about anymore. In fact, I personally wrote an entire chapter in our book Professional Flex 3 on describing the Flash Platform and the “Flex ecosystem of technologies” just to clear the matter up.

Personally, associating the word “Flex” with an SDK (consisting of a framework and a compiler), a development tool, a framework and an overall development methodology, in my experience has led to a lot of confusion. Using the word “Flash” generically has also lead to a lot of confusion — is it a runtime, an IDE, the file you run in the browser, or an approach to rich media development? What is Flash? What is Flex?

I think the time has come to drop the generic use of the words “Flash” and “Flex”. Or at the very least, for the sake of tech pundits and journalists who may not have the in-depth knowledge of us designers and developers, to assign the word “Flash” as meaning “the Flash Platform” or “the Flash Player”, and have “Flex” mean either “the Flex framework” or “Flash Platform enterprise/RIA development.” That would be my vote, and how I have come to think of those two words in generic terms.

In rebranding Flex Builder to Flash Builder, what we are seeing here is a move away from using the word “Flex” as describing “enterprise or RIA development in the Adobe technology space” (amongst its other uses) toward using the word to describe simply the Flex framework and associated tools. By moving back toward the use of the term “Flash,” Adobe is slowly rebranding Flex as being a subset of the Flash Platform, not a complete technological ecosystem in and of itself, which on the whole is a lot clearer and more balanced. And I’m all for making things simpler and clearer for clients to understand and adopt the technology.
(more…)

Professional Flex 3 Book Advance Launch at 360Flex!

Posted in AIR, Books, Flex, Projects, Publishing, Flex 3 by Joeflash on the May 15th, 2009

As some of you may know, the eight of us have been eagerly awaiting the publication of our book, Professional Flex 3. Well, I’ve just received confirmation the book will be out in stores around end of May, and that Wrox will have 20 advanced copies of the book, hot off the press (literally), ready for givaways at 360|Flex in Indianapolis this coming week.

Yesterday a colleague of mine asked how our book was going, and how big was it. What I told him sums it up pretty good:

8 authors, 1400 pages, 75 chapters, 12 sections, 750MB of code, 18 months.

You can download a PDF of the table of contents here to give you an idea. It’s a hefty volume — the ToC alone is like 31 pages!!

You can also reserve your copy on Amazon now, or buy it from the publisher’s site when it’s out in stores.

Professional Flex 3 Book Cover
Authors from left to right: Joseph Balderson (me), Andrew Trice, Jun Heider, David Hassoun, Todd Prekaski, Joe Berkovitz, Tom Sugden, [Peter Ent not present]

I cannot say enough about these guys, it’s been hugely awesome working with my co-authors throughout this process, including the tech editors and all the great folks at Wrox. This has been a monumental and amazing journey, for all of us. A year and a half ago, I wanted to write the most kick ass, comprehensive and exclusive Flex 3 book out there. To really paint a broad and deep view of the entire Flex ecosystem of technologies. So after getting together seven other amazing programmers and communicators, and writing for many many months, we’ve done it. There are things in this book that you will not find anywhere else.
(more…)

Converting Flash Projects into Flex

When converting from a Flash CS3/4-based project, to a Flex-based project, there are not just one or two conversion paths to consider, there are many, all of which depends on the Flash project in question.

I’m on a discussion on LinkedIn, in which one guy asks if we know anyone who can do a Flash-to-Flex conversion project, which evolved into a discussion on techniques. Rather than post a pages-long reply, I thought I’d post it here instead:

First, for any Flash-to-Flex conversion to go smoothly, you’ll need at least one person on your team with a good dose of real-world experience with both Flash and Flex-based RIA projects (Flash banners do not qualify ;)), to guide the conversion process and make sure the best deployment strategies are implemented.

As far as the conversion path, there are several possibilities. Depending on the kind of project, you may want to migrate some, most or all of the project to Flex. When migrating from Flash to Flex, you’re not just migrating code, you’re migrating from a visual asset instantiation and state management environment to a purely coding-based methodology (if we forget for a second about Design View in Flex Builder).
(more…)

Next Page »