Archive for February, 2007

Bruce Eckel, Flex, and Improving the Developer Experience

Bruce Eckel is a man who understands software development. Eckel has authored the “Thinking In …” series of excellent programming books, was a founding member of the ANSI/ISO C++ committee, and makes his living these days speaking at conferences and doing seminars on how to develop good software correctly. Eckel is an active participant in the software development community and regularly contributes valuable insights on development issues through his presentations, participation on development panels, and online distribution through his blog. His “Thinking in Java” textbook was revolutionary because he offered an online version for free, ensuring that it would be the most widely distributed, and thus the best edited, Java text in history, and was the foundation of my Java education.

A few weeks ago Eckel wrote something pretty insightful about the failure of Java to offer good interfaces, specifically for the web. He opens the article discussing the state of web application interfaces today, and what our options are, and why most of them aren’t good. Eckel first discusses Java, and why it’s failed to revolutionize the web with Applets in the way promised. He hits on something really important here:

The initial user experience with AWT did a lot to dampen the enthusiasm about Sun’s Java fanfare, and I don’t think applets ever recovered. “(emphasis added)

We spend a lot of time here talking about “user experience”, and how a good user experience is critical to making interfaces that users will accept, and that user acceptance is by far the most important factor in determining the success of an application. I never considered before how “developer acceptance” is just as critical in determining the success of a technology, but it makes perfect sense. If developers find a technology hard to use, hard to manage, hard to learn, or hard to maintain, it’s probably bound to be quickly replaced by something easier to use.

I have to say that ease of development is one of the main things that’s attracted me to Flex. There’s a healthy sort of laziness inherent in all good software developers that drives the production of software that’s easy to use, and I’m prone to probably a little more than this healthy amount. I come from an application development background and like thinking about problems abstractly. Spending time searching the web to figure out which browsers the JavaScript function I want to use is compliant with is just about the last thing I want to do as a developer. Ease of development is probably the number 2 reason why I love flex, just behind the the cool effects it adds to interfaces.

Eckel moves on from Java to discuss some other web-interface options. Ajax has created some extremely elegant solutions in the past few years and provided for some of the greatest applications on the web today, but it’s tedious to develop in, and requires the combined brain power of an organization like Google to really make it work well. JavaScript and CSS aren’t really as cross-browser compatible as they’re supposed to be. The Google Web Toolkit is genius, but limited to the libraries it supports, and it’s nearing the limit of what’s possible with JavaScript, CSS and HTML.

Flex, he says, is the solution to interface problems – it provides a framework that makes development of interfaces that are easy to use and always work much easier than any of its competitors. It’s free, elegant, and easy to access. He sounds excited, and compares its potential influence on the front-end of an application to Ruby’s on the back. Eckel believes the future for Java is in “hybridizing” itself with technologies like these that solve problems Java hasn’t been able to.

Eckel’s also excited that Flex development has moved beyond the web to desktop applications as well. Adobe recently announced Apollo, which is a small flash-player for the desktop that enables cross-platform support of the .swf file format for desktop applications. We made a prototype Apollo application for Ebay that was featured at the Demo conference last week, and as one the developers involved in building the demo I can say the experience was great. The Apollo framework required a few small installations that worked excellently the first time, and after these installs creating our Apollo application was as easy as building any other flex project. Why should we as developers have to learn so many different interface libraries and techniques? Flex is a single solution that solves interface problems for both the web and the desktop, and it does it well.

To conclude, here’s a good example of an area in which Flex could provide a really great application solution: spreadsheets. Excel has, for a long time, been the standard in spreadsheet applications. Microsoft has spent tons of time and effort building a really good and easy to use application for all your spreadsheet needs, and it works, as long as you only want to look at your spreadsheet on your desktop computer. Google has more recently created the “google spreadsheet” application, which re-produces all of the basic functionality of Excel for the web using some really astounding JavaScript and HTML, but the application is web-only, and sacrifices features in exchange for stability. To compete, Microsoft is making web-friendly versions of Excel and other office products for the release of office 2007, and while it’s going to be very expensive and time consuming, they’ve got to move with the market, and the software market has been moving towards rich internet applications for a few years now.

If Excel had been made in Flex originally, Microsoft wouldn’t have to change a thing. Their biggest challenge would be to create a business model that supported a web-friendly version of the product, but practically none of the code would need any sort of update to be ready for the web. Countless man-hours could be saved. The same comparison could be made between Writely, now Google documents, and Word; outlook and gmail, or yahoo mail, or even hotmail; Flickr and iPhoto, or just about any other desktop application that has an online equivalent.

It’s not like Microsoft really had this option – Flex 2 was just released last summer, and Apollo won’t be production ready for a few months, but as developers today looking to make our applications ready for tomorrow, it’s another compelling reason to consider Flex.

As if Bruce Eckel’s endorsement wasn’t enough.


February 13, 2007 at 1:48 pm 1 comment

“setActualSize” actually doesn’t

As a relatively new Flex user, I run into issues every now and then where flex doesn’t behave as I expect it to. Recently I was trying to resize an object dynamically through a “click-and-resize” interface. I looked over the API and found a “setActualSize” method on the UI component class that seemed like it would work well, but when I used it, my shapes weren’t actually resizing. A half hour of weeding through stack traces helped me discover this comment in the UI component code:

* Sizes the object.
* Unlike directly setting the <code>width</code> and <code>height</code>
* properties, calling the <code>setActualSize()</code> method
* does not set the <code>explictWidth</code> and
* <code>explicitHeight</code> properties, so a future layout
* calculation may result in the object returning to its previous size.
* This method is used primarily by component developers implementing
* the <code>updateDisplayList()</code> method, by Effects,
* and by the LayoutManager.
* @param w Width of the object.
* @param h Height of the object.
public function setActualSize(w:Number, h:Number):void

This is the issue I’m seeing – a future updateDisplayList() call from the canvas my object is on is immediately resizing my object after my call to setActualSize. In fact, I think my call to “setActualSize” is causing the canvas to invalidate my object and immediately call setActualSize again with the wrong width and height, which is kind of ironic, if you think about it.

The preferred solution in my case is to set the width and height properties of my object explicitly. Another option is to override the “updateDisplayList” method to take width and height changes into consideration. Methods with titles like this frequently lead me down the wrong path in Flex, since they rarely do the sorts of things my Java brain thinks they would.

Getting used to explicitly setting public properties is just part of the transition from more traditional OO languages to Flex.  At least you can override the property’s setter with a method, upholding the principal of encapsulation.

February 7, 2007 at 10:36 pm 6 comments

February 2007
    Mar »

Recent Posts