Farata Systems      

Was not planning to write this post. It was ignited by the  “Disappointed with Flex” article posted by Valery Silaev, our lead Flex/Java developer.  I’ve been working with Valery on a couple of projects. He’s good software developer. And when he says that he’s disappointed with Flex 4, you should listen.

I really value people who speak up freely and have something to say. Valery is disappointed with Flex 4, but I’d like to take it one step further. I’m disappointed with Adobe.
To put it simple, Adobe is sloooooow. I mean really slow, and I’m not sure what’s the reason.  I know some people from Flex team. They are smart. They can deliver given the right support from top management and proper investment, which is definitely not there.

Let me build the case. Slowly.
Four years ago, when Adobe purchased Macromedia, I was looking for a decent tool for development of the enterprise Web applications.  At that time I was disappointed with Java Swing. Wrong decisions at the top level of Sun Microsystems resulted in having 75% of the computers running Internet Explorer with… ten years old Java run-time. Sun Microsystems won the lousy $10B law suit with Microsoft back in 1998, but lost the battle. Their runtime (yes, the JVM) is not installed at the consumers’ computers.

Four years ago, Adobe’s Flash Player (it’s a VM too) gave me some hope. The runtime was there, the library of rich components  was there too, installing Flash Player was piece of cake. I started working with Flex.

This new for me Flex/Flash community was a bit unusual after Java. It was small.  I had a feeling as if we are in a small country club chanting, “We are the best”.  Flex developers knew each other by names. Adobe Flex technical evangelists were Gods. This was different from Java community of six million of professional developers.

But Adobe didn’t have competition in the area of enterprise rich Internet applications in 2006, 2007, 2008… Until the greatest “Me too” firm from Redmond, WA realized that RIA is the right place to be and IE is not the only browser people have. They started working on this Silverlight thingy. Two years ago they released the 1.0 version that could be ignored – nothing but video streaming was there. At the same time Adobe released Flex 3, which had pretty much everything: 98% penetration of runtime, rich library of components, fast communication protocols, and the server-side component LCDS, that nobody but filthy rich Wall Street firms could afford.

Two years later, Microsoft released three more versions of Silverlight, and the only thing that stopped them from presenting a serious threat to Flex was low penetration of their runtime. Microsoft has tons of cash and excellent engineers. During the same period of time, Adobe has released Flex 4 in hard labor. It took Adobe two years to release the next incomplete version of Flex. Why?

Being a Java developer, I was watching closely the evolution of JavaFX, yet another wannabe player in RIA.  I clearly a similar pattern there. Top-level management proclaims at every keynote that “We are the best” without giving enough juice for engineering teams that work hard developing a product.
The bad guy, Steve Jobs, doesn’t even know what Flex is. He’s not happy with Flash Player. Need to admit, he’s not playing by the rules trying to say that Flash Player is junk and a main reason that crashes the OS. He’s bad, but he’s not stupid. Adobe couldn’t offer a better response than “We love Apple”.

Yes, Flash Player is installed on 98% of desktops, as if we don’t know that not many consumers are using desktops today, and in five years they will become minority.
Steve Jobs, the bad guy, made Adobe moving just a little bit faster and they finally released Flash Player 10.1 in 18 months (!) after the 10.0 release.

Two years for the next and incomplete version of Flex. Eighteen months for 0.1 upgrade of Flash Player. Dumb pricing policy on LCDS that makes it unaffordable for even a small group of loyal customers. Not a Wall Street giant? Get out of here. Is this the way to treat customers?
Let’s get back to the tooling. This smart idea to bring together designers and developer gave birth to yet another prototyping tool called Flash Catalyst. Is it more than just a prototyping tool? Tell me why?

Here comes the Flash Builder (formerly Flex Builder). Flash developers (they haven’t seen any better) were so happy with Flex Builder 3… From the Java developer’s perspective, this was a mediocre and damn slow Eclipse plugin. Flash Builder 4 after two years of development was not a major improvement either. I’m not sure why JetBrains doesn’t want to invest a couple of rubles and add a WYSIWYG designer for Flex. As soon as they do it – Flash Builder is brain dead.

The next target is Flex 4 SDK.   The new Spark library of components with separating the functionality of components and their skinning implemented just half of the components comparing with Flex SDK 3. In two years they could have done better if they were a large company catering for developers.  But they are not. Until Photoshop and PDF remain their main source of revenue, the tooling for software developers will be pushed aside.

Adobe was and remains a small company. They do what they can.  And it doesn’t seem that they can do much more for us, developers.

Yakov Fain
P.S. This is my personal opinion. My employer may think differently.

After spending some time working with Flex 4 on a real project, I can’t say I’m happy with this product. My list of complains  is based on moderate sized project, 5 months, 4 developers, WebService-only back-end.

1. Flash Builder 4 has lots of issues – more than Flex Builder 3. AS of today it has lots of bugs:
-it doesn’t release resources;
-debugger does not allow to run several instances and consumes a lot of resources;
-debugger intercepts all network calls and the debugging proxy is terribly slow and inefficient;
-code navigation between several projects is absolutely impossible;
-compiler is unpredictable and slow;
-it periodically tries to do incremental compilation, even if you explicitly tell it not to do so — and you have to disable incremental compilation, because it’s slower than full rebuild of all related projects with Maven.
-Help system is not well designed — Adobe moved help to a separate AIRr application, in-place contextual help is non-existent; search always shows one link — “yes, there are probably some topics for your query — open separate application to search again”

2. Flex compiler is broken
It’s slow. It’s slower than any previous version I’ve used. And it’s buggy. Periodically it shows some cryptic messages like “there is no x or y or width or height properties on UIComponent”. It never points to exact source of problem — and I doubt it exists. Because sometimes fix is to set “-keep-generated-actionscript” flag on. And sometimes off. And if it doesn’t help then the fix is to reorder attributes in MXML tags. Just insane. And I can’t find the exact root of these messages, the only thing I can say for sure that they are caused by new MXML skins — no skins, no errors.

3. The new Spark library is over-engineered.
I worked on some Java Swing projects some time ago. It seems that Adobe takes the Swing route, however Flex becomes popular just because of the opposite — it was way far simpler than Swing. Flex ideology was “keep simple things simple, make complex things possible”. Now it turns to be the Swing ideology: framework usage is irrelevant, the only relevant thing is framework per se, and it should be perfect.

I can’t do a lot of things with Spark I was able to do with MX. Icons in buttons? Develop descendant component of Button, define new parts and develop separate skin. ComboBox where items in drop-down are large than input field? Develop own skin — just copy-paste and tweak a bit. Paddings? What paddings? It’s not a css attribute any longer, extend and develop own skin. Left/right/top/bottom? You can’t customize this via css, or develop your skin if you truly need this option.

But architecturally Spark is beautiful, no doubt. Astronauticaly beautifull architecture, if Joel Spolsky permits me to use this term.

4. New Spark library is incomplete.
Yes, this statement doesn’t contradict with [3]. Being overdesigned it’s missing a lot of functionality from MX: no Calendar, no DateInput, no ColorPicker, no PopUpButton etc. No clone for MX SWFLoader/Image. There is no complex containers at all (like Accordion and TabNavigator) Needless to say, there is no advanced controls like DataGrid and the supplied “proxies” for ItemRenderers confirm that there are will be none any time soon.

5. New states engine encourages unmaintainable code
Previously we have states with explicit overrides. All data related to override was co-located, so it was easy to see what and when changes. There were inheritance of states, and it was sufficient. There were no groups, but when you need state groups — then 99.9% of times you in fact have to extract part of component as sub-component, and coordinate isolated state changes there. But now the great property.inStateFoo=”xyz” notation comes.

Now you have to scan over tens or hundreds of lines of code and check all and every includeIn / excludeFrom attribute and decompose them back to the very same old “overrides”. In short, when you are debugging states you have to do job of compiler but without the help of compiler. And the existence of state groups multiples the complexity by the factor of ten. It’s a Ruby-way productivity — it’s easy to develop a sketch / prototype, it’s a nightmare to polish this sketch to be a real product and it’s absolutely impossible to support it. But sure, you can start quickly, who cares about the rest…

6.  Vectors (Flash-10 related, not just Flex 4)
Vector is a canonical example of a half-pregnant woman. Hey, developers! Use new features -  Vectors and Generics (or this is templates??? we are not sure on our own). Yep, it’s cool, Vector is a parametrized type. Though, there is no type covariance/contr-variance and no type bounds in syntax. So you have to cast data Vector whenever it’s declared as parameter or as a return value. But who cares?

7. Text engine (Flash-10 related, not Flex 4 only)
It’s great that “Gordon works on text”, and new engine is indeed superior. But may we have both Spark and MX on same engine by default without the dual way to embed fonts and dual size of embedded fonts?

Am I missing something?

Valery Silaev

We’ve expanded to four days our popular Advanced Flex Master Class. In 2010 this training will be available only for US-based enterprises. Course outline can be downloaded at http://myflex.org/yf/AdvancedFlex4days.pdf

Yakov Fain

Recently, I’ve been teaching a class and one of the students stopped by after the class and said, “I’m just learning object-oriented programming, can you explain me the benefits of casting?”. How would you answer such a question? I did my best in a short period of time I had, but felt obligated to give better explanations and wrote this blog. I’ve been using example from Java language here, but all this apply to other object-oriented languages too.

All Java classes form an inheritance tree with the class Object on top of the hierarchy – all Java classes are direct or indirect descendants of Object. When you declare a non-primitive variable, you are allowed to use either the exact data type of this variable or one of its ancestor data types. For example, if the class NJTax extends Tax each of the following lines is correct.

NJTax myTax1 = new NJTax();
Tax myTax2 = new NJTax(); // upcasting
Object myTax3 = new NJTax(); // upcasting

Java is smart enough to automatically cast an instance of the class to its ancestor. When the variable has more generic class than an instance of the object it’s called upcasting. Let’s say the class object has ten methods and class variables defined, the class Tax (it’s an implicit subclass of Object) adds five more methods and variables (total 15), and NJTax adds another two (total 17). The variable myTax1 will have access to all 17 methods and variables, myTax2 will see only 15, and myTax3 just 10. Why not always use exact types in variable declarations?

Let’s say you need to write a program that will process the data about workers of a certain company. Some of them are full time employees, and some are contractors, but you’d like to read them from some data source and into the same array. Arrays can store only the objects of the same type, remember?

Since Java can automatically upcast the objects, you can create a class Person with two subclasses: Employee and Contractor, and then read the records from a database, and based on the employment type, create an appropriate object instance and put it into an array of type Person:

Person workers[] = new Person [100];
workers[0] = new Employee(“Yakov”, “Fain”);
workers[1] = new Employee(“Mary”, “Lou”);
workers[2] = new Contractor(“Bill”, “Shaw”);
…

Of course, you could’ve created two separate arrays for employees and contractors, but I’m laying the foundation here for explaining polymorphism – a powerful concept of object-oriented languages.

At some point you’ll need to process the data from the array workers. Say, in a loop you can test the data type of the current element of the array with the operator instanceOf, then downcast the object (it can’t be done automatically) to Employee or Contractor, and process it accordingly.

for (int i; i<20; i++){
Employee currentEmployee;
Contractor currentContractor;

if (worksers[i] instanceof Employee){
currentEmployee = (Employee) workers[i];
// do some employee processing here
} else if (worksers[i] instanceof Contractor){
currentContractor = (Contractor) workers[i];
// do some contractor processing here
}
}

Placing a data type in parenthesis in front of another object means that you want to downcast this object to specified type. You can downcast an object only to one of its descendant data types. Even though the above code has correct syntax, it doesn’t represent the best practice of processing similar objects. In the next lesson you’ll see how to use polymorphism to do it in a more generic way.
If a class implements an interface, you can cast it to this interface. Say, a class Employee implements Payable, Insurable, Pensionable interfaces:

class Employee implements Payable, Insurable, and Pensionable {
// implementation of all interfaces goes here
}

If in particular code you are interested in its Insurable behavior, there’s not need to cast the Object to type Employee, just cast it to Insurable type as shown in the code fragment below. Keep in mind though that if you do so, the variable current employee will expose the access to only those methods that were declared in the Insurable interface.

Insurable currentEmployee;

if (worksers[i] instanceof Employee Insurable){
currentEmployee = (Insurable) workers[i];
// do some insurance-specific processing here
}

Is it clear enough? I’d appreciate your feedback.

Yakov Fain

If you create classes that may be used by other developers, declaring methods as final will make them not overridable in the subclasses.

While today, it may seem obvious to you that a particular method will never ever need to be overridden, you might not properly predict all use-patterns of this class. If this happens, some other developer will have to jump through the hoops to create another version of such a method in a subclass. If you don’t want to be cursed in the future, think twice if you really really want to declare this method as final. Do you see any benefits in using final methods?
We had to extend a third party library to improve their implementation of a certain networking protocol. As it usually happens, the code was poorly documented, so we had to read the code to find out which method to override in the subclass. Sure enough, that method was declared as final.

We found a workaround and still replaced the call to the final method to the call to our own. So what the original developer achieved by using final? He made our work more difficult than it should have been.

Originally, Java compiler was optimizing (inlining) final methods. Today I’ve learned (thank you, Heinz) that Java compiler doesn’t do it anymore, and they are optimized by the Hotspot JVM:

http://www.javaspecialists.eu/archive/Issue157.html

http://www.javaspecialists.eu/archive/Issue158.html

Who are these guys we’re protecting from by using final? BTW, I also believe that the keyword protected is equally useless.

Yakov Fain

As many Flex developers waiting for release of Flex on iPhone for over a year, last 2 months were Denial, Anger, Bargaining, Depression and finally Acceptance. The acceptance came in the form of the Android phone and new battlefields/pastures.

Apple and Google are in open war right now – over tv/media, virtual assistants, navigation and ads. Lately it became obvious that workspace and social networking are also becoming part of the battle – and that is the fields we specialize, so we need to adopt.

I picked up Nexus One recently to do some research work. N1 is a bit better as research device then particular carriers ones as you can share the same providers card with your iPhone (no extra contract). I am quite used of swapping AT&T cards from iPhone with other phones (50$ Samsung phone +iPhone account = better phone + bluetooth/usb network hotspot, etc). It also has no provider’s protection so updating software and rooting is a bit simpler.

Let’s make sure you have been warned: N1 is not a replacement for iPhone for consumer or either status seekers/heavy phone users. It has some significant pluses – better Navigation, voice integration and web experience are superb. Hardware spec beats 3GS easily, but the actual hardware quality is sub par:
- quality of the phone subsystem (signal reception, sound quality, integration with provider) is much lower
- quality of the screen is bad ( easily greased, bad touchscreen recognition, predictable typing is not working as expected)
- touchscreen and buttons do not always respond as expeced.

Once you accept that Google phone is development device and not your primary phone, you can appreciate really great features it provides for software enthusiasts:
- open development environment including AIR with reasonable debugging and diagnostics
- top of the line hardware stack including fast CPU
- standard open OS

The last few weeks spent with physical device were a lot of fun. The development cycle is much faster then with iPhone and the applications perform MUCH better. There are quite few adjustments you need to make to your development in order to deploy application on the phone, but I will talk about it in the next post. For now, grab your Android phone and experience new platform for yourself.

Sincerely,
Anatole Tartakovsky