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.
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!!
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.
So I’m updating an old Flash project to AS3, and I need a quick solution to add a few scrollbars onto a few textboxes. So I get out the Flash CS3 UIScrollBar. Only problem is, it’s not working. Works in a standalone FLA, but when I bring it into my app, there’s no scroll bar, no arrows, and the component is unresponsive to textfield content changes.
The UIScrollBar class is a simple scrollbar component that ships with Flash CS3 and CS4, that when associated with a given TextField, enables you to scroll that TextField. Simple, right? Or it should be. After cursing the gods for yet another buggy Flash component — I mean, I thought the days of hacking through the Flash component set to get it to frakin work were done with! So after slogging through a few useless hacks — like purposefully populating the textfield with a gazillion line feeds to get the scrollbar to initialize, then deleting them — I figured out a solution.
There must be a bug with the component, because it was not registering new text being added to the TextField. If the TextField was populated with more text than vertical space allows before the UIScrollBar initialized, then the scrollbar would work. But this was the exception to the rule, since most textfields in the app would be dynamically populated form an XML file. So I needed a way to force an update of the scrollbar when the content in the TextField had changed.