The Downfalls of Flex

I know I've been saying Flex all over the office and stating how great it is and how it makes some things so easy... But there are problems with it.

States - Great or Not?

The mx:State tag is very nice for grouping changes to a screen and applying effects easily. I only have a few issues with the implementation of this.

1) It caches the last time the user navigated there. Ok - not too bad you say. This could be a good thing right? Well, yes and no. If you are building a static screen that won't change again in your program then sure, it's great. If you know exactly what you are going to display, it works fine. The problem is: you won't get startup events again and you can't "reset" the state to clear out this "cache".

This makes dynamic applications difficult to write. How? Well I need to know how many options I can display on a screen so I can split it up into multiple screens (no scroll bars). I need to know how large the area is that I can draw in so I can create multiple screens which have an equal number of options in each. Getting this to work the first time was a bit of a pain... but getting it to work the second time (with different options) required a lot of frustrating work. You may be thinking of solutions - trust me it was difficult and not obvious to implement what I was working on.

2) States are in the same mxml file and share the same code. Yes, you can write components for all of your screens and place them in a ViewStack but, well it has the same problem. You would have to remove the screen each time if you wanted to ensure it would get properly recreated. (and having multiple applications isn't a viable solution).

Solution?

You could create a wrapper for the ViewStack, or create your own State class called Screen - why did this not come bundled? Or you do what the rest of the world does and write a lot of ActionScript rather than mxml so you can control startup/shutdown code, events, etc. Blah.

Waiting for JavaFX may not be the solution you are looking for either -- I know it's different than Flex but, like most things written in Java, it's very sophisticated and probably will not have these types of problems.

Other Issues

Most of the issues I've had all stem from States and their inability to re-dispatch events and re-apply "overrides". This causes a lot of confusion for traditional developers who work with screens. Creating components for each screen doesn't work well if you require other things to change (such as a title bar which is shared with all other components - yes, you can duplicate it in each, but that's not the OO way and doesn't leverage any of the powers of flex such as applying common transitions to some but not all elements.)

Oh ya.. and I want at least a dozen Adobe made themes to come bundled with Flex Builder. Why am I paying money for eclipse to edit mxml? Oh, right, it has better code completion than Flash and FlashDevelop.

I like states - I just want a flag on them that says "re-apply every time it's used". It would also be nice to have them in a separate file (1 per state) if desired. This way, the main mxml file would be quite small. This other file should be able to contain event handlers for the state as well.

I may be able to come up with a solution but I shouldn't have to. This is a very obvious oversight on Adobe's part. I suppose most RIAs are quite static (even though they don't appear to be) but I have situations where I have to produce an application which is different in each install without re-writing it every time.

Please post my oversights below. =)