... .  .    .       .joeberkovitz.com

Boston Flex Users’ Group ready to spread its wings

It’s official: at long last, Boston now has its own Flex Users’ Group! The first meeting will be on Tuesday April 8 at 7pm at Adobe Systems’ office in Newton, MA. Peter Farland of the Flex development team will be our first speaker, talking about the new Flex Open Source SDK. Check out the Boston Flex Users Group web page for more information from here on out, about this and subsequent meetings.

I’m really pleased about this. It’s been something that badly needed to happen, given that this is one of the major nexuses (nexi?) of Flex development in the country. A bunch of us Boston types had virtually the same idea at the same time, and since then we have been laboring to bring this users group into the world. I’m excited about the potential for great conversations, new connections and novel things to learn. We’re going to have us a good time, yes we are!

1 Comment

360Flex Presentation Posted

Thanks to everyone who just attended my presentation at 360 Flex in Atlanta this morning, “Advanced Case Study: Building the Allurent Display Architecture”. For anyone who’s interested (including attendees of my talk of course), you can download it at:

http://www.joeberkovitz.com/presentations/AllurentDisplayCaseStudy.pdf

4 Comments

A Single Link for MVCS Resources

A few folks have pointed out that it’s difficult to track down all the resources about my MVCS approach to building Flex applications. They were right, and in response I’ve consolidated everything into a single page accessible at this URL:

http://www.joeberkovitz.com/mvcs.

I’ve also included a few addenda to MVCS reflecting more recent thoughts and practices. As more materials become available, I will add them to the above location.

Thanks to everyone who prodded me into doing the right thing!

1 Comment

Too many TextFields and not enough beer makes FP9 crash

I’m working on an interesting and involved project (that I can’t say very much about right now), and it uses a ton of dynamic TextField objects on the screen. I thought things were going superbly, but my app started to crash the player at odd times as the display became more complex. I wanted to tear my hair out, but said hair is kind of short-to-nonexistent and it was hard to get a good enough grip. I tried to reproduce the crash, but each time I thought I knew what was causing it and made the “fix”, it would come back.

It was right around then that I recalled David Coletta of the Buzzword team mentioning at Flex Camp Boston that the Buzzword application uses a bunch of clever techniques to avoid creating and destroying TextFields as the user types (since they use lots of them to render what appears to be a unified display of a rich-text document). Among other things, he mentioned that they pool TextField instances offscreen — while keeping them on the display list — and reuse them by bringing them back onscreen to show stuff as needed. [Continued…]

1 Comment

Douglas McCarroll releases AS3 visual-comparison testing library

Douglas McCarroll has just released the first public incarnation of Visual FlexUnit as a Google Code project. I’m very excited about this project, partly because I think it’s going to be super useful to some people (myself included!) and partly because Douglas did a ton of great work on it during his internship this year at Allurent and it really is his baby.

I don’t want to recapitulate the whole project description, which you can read for yourself, but… what the heck is Visual FlexUnit? [Continued…]

1 Comment

UrlKit 0.92 now available with IE7, Safari support

I’ve posted a new download of UrlKit version 0.92 to the UrlKit project on Google Code. (Note that 0.91 was formerly mentioned here, but a distribution script error was discovered to have omitted a few files.) It has some nice new features, some based on user feedback:

• Uses deep linking approach from Flex 3 to support all major browsers including IE7 and Safari
• Code for UrlKit apps in Flex 2 and Flex 3 is now identical
• New navigate() method allows apps to internally change state by directly specifying a new URL fragment
• New enabled property of FlexBrowserManagerAdapter optionally delays UrlKit startup until application is fully initialized

Happy Holidays!

10 Comments

Using Flex 3’s Deep Linking Features in Flex 2

If you don’t already know, Flex 3’s deep linking support is a tremendous boon to the RIA developer, insulating our lot from having to worry about the whole sorry, shoddy business of communicating little strings between our application and the fragment chunk of the browser’s location URL. Applications that have some notion of navigational state benefit greatly from using this feature: their state (as embodied in such a URL) becomes automatically hooked up to the Back/Forward buttons, becomes bookmarkable, and of course becomes exchangeable via the usual Web means with any other user of the same application.

For those of us who have real products that need to be released on a schedule independent of Adobe’s corporate whims, however, Flex 3 isn’t necessarily a good option. Where does that leave the would-be deep linker? One of the few options for Flex 2 users has been the UrlKit library written by Todd Rein and yours truly, which provides deep-linking support in Flex 2. (In Flex 3, UrlKit uses the built-in deep linking mechanism.) Unfortunately, in Flex 2 the deep linking support in UrlKit is not equally good for all browsers. UrlKit supports FireFox, IE6 and Safari pretty well, but I’ve never had the time to catch up with IE7, and the prospects of my keeping up with the dirty little world of browser compatibility have been — and remain — dim. In contrast, Adobe is a big company with lots of smart QA people and a business motive to toil in the compatibility trenches.

Now, something not generally known is that the Flex 3 deep linking support is derived directly from the UrlKit code (and, yes, they had the authors’ permission!). As such, it has virtually no dependencies on the rest of Flex 3 — not surprising, since Todd and I built it for Flex 2. So it occurred to me recently that it should be possible to port the Flex 3 BrowserManager class and accompanying Javascript back into Flex 2, where it would probably simply compile and work out of the box. And the good news is: it does! (Actually that is a slight lie: I did have to comment out a single line of code, and add a one-line magic incantation to my application startup. But that’s not too bad.)

This means that Flex 2 developers (and UrlKit itself) can now take advantage of the Flex 3 BrowserManager subsystem in its entirety. Furthermore, I am aiming to provide a new revision of UrlKit shortly that incorporates this approach for its Flex 2 deep-linking support.

I cannot legally redistribute the slightly modified Flex 3 source that works in Flex 2, but here’s how to do it yourself:

• create a new Flex Library project based on the Flex 2.0.1 SDK
• copy the following files into it from the Flex 3 SDK source:
  mx/core/Version.as (note: this is included by the other files, but not compiled itself)
  mx/events/BrowserChangeEvent.as
  mx/managers/IBrowserManager.as
  mx/managers/BrowserManager.as
  mx/managers/BrowserManagerImpl.as
• comment out the line in BrowserManagerImpl.init() which sets the historyManagementEnabled flag — this does not exist in Flex 2.
• compile the above files (excluding Version.as) into a SWC
• in your Flex 2 application, drop in an HTML template generated by Flex Builder 3 for a Flex 3 deep-linking app. This template will include a history/ subdirectory with JavaScript and CSS files in it, and the HTML page loading the app will refer to those files.
• Add the following line to your application startup, prior to calling BrowserManager.getInstance()

  Singleton.registerClass("mx.managers::IBrowserManager",
      Class(getDefinitionByName("mx.managers::BrowserManagerImpl")));
  

I have some more testing to do, but a development version of UrlKit that I just compiled with this approach seems to work well at first blush.

Happy linking!

3 Comments