 |
Adobe has released its new version of the Flex Builder, now renamed Flash Builder 4. This version is radically different from previous versions of Flex, introducing the new Spark architecture and theme support. While I’m pleased Adobe has finally added support for Eclipse 3.5, I’m disappointed with some of the new architecture changes that make doing simple things, such as skinning a button, now quite cumbersome. |
1. Spark and Halo: Duplicate Code will be Flex’s downfall
The Spark framework introduces a new set of UI components that sit on top of mx, and in many cases, duplicate the logic. For example, you can now define an old Halo button <mx:button/> alongside a new Spark button <s:button/>, both within the same component. I predict this duplication of code will lead to confusing and muddled codebases. Some developers will use all Spark components, some will use all Halo components, and some will use an inconsistent mix of the two.
The idea of two different components with the same name existing within the same application worries me greatly. It would be like Sun releasing a new version of the String class in Java 8, and rather than updating the old String class you now had 2 distinct classes to choose from, both called String, with the package name determining which you use. Sometimes reinventing the wheel is a sign the developers were too lazy to merge their changes into the existing wheel.
2. Broken Migration Paths
When I attempted to migrate some of my Flex 3 applications into Flash Builder 4, I received a number of compiler errors. The first thing I needed to do was right click on the project and change the Theme to Halo (Flex 3-based theme), since it defaults to Spark. This fixed many, but not all, of the compiler issues. After fixing the remaining compiler issues by hand, I ran the application only to discover none of my buttons had text on them! I enabled “Use Flash Text Engine in MX components” which fixed some, but not all, of the button text, but there were still dozens, possibly hundreds, of UI issues that caused the application to look awful. Realizing migrating the entire application into a native Flex 4 application would take endless amount of hours, I reviewed the compiler options again and checked the “Use Flex 3 compatibility mode” option, which, again, fixed some, but not all, of all the issues. Even with Flex 3 compatibility mode enabled, the compiler still handled the following components differently than it had in Flex 3: drag/drop pop-up images, recognizing css text-align property on certain components, and adding padding on some components. With the compatibility mode enabled, the number of issues was drastically reduced to a few dozen issues, but this was at the cost of limiting the new features available in Flex 4.
3. Skinning a button: 5 lines of code now take 51 lines of code
Previously, skinning a button was just a matter of defining some images in a CSS file and telling the application to use this style. It was intuitive, quite similar to HTML/CSS so it was easy to pick up, and only took a few lines of code, such as the following:
.myButton{
skin:Embed(source="/assets/menu.png");
overSkin:Embed(source="/assets/menu_over.png");
downSkin:Embed(source="/assets/menu_down.png");
}
Flex 4 now makes skinning extremely complicated. In order to accomplish the above example in Flex 4, you would need to define a custom skin class such as in the following example taken from here:
<?xml version="1.0" encoding="utf-8"?>
<!-- http://blog.flexexamples.com/2010/03/24/using-a-bitmap-image-skin-in-a-spark-button-control-in-flex-4/ -->
<s:SparkSkin name="ImageButtonSkin"
xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:s="library://ns.adobe.com/flex/spark"
xmlns:fb="http://ns.adobe.com/flashbuilder/2009"
minWidth="21" minHeight="21"
alpha.disabled="0.5">
<!-- states -->
<s:states>
<s:State name="up" />
<s:State name="over" />
<s:State name="down" />
<s:State name="disabled" />
</s:states>
<!-- host component -->
<fx:Metadata>
[HostComponent("spark.components.Button")]
</fx:Metadata>
<fx:Script fb:purpose="styling">
<![CDATA[
/* Define the skin elements that should not be colorized.
For button, the graphics are colorized but the label is not. */
static private const exclusions:Array = ["labelDisplay"];
override public function get colorizeExclusions():Array {
return exclusions;
}
override protected function initializationComplete():void {
useChromeColor = true;
super.initializationComplete();
}
]]>
</fx:Script>
<s:BitmapImage source="@Embed('/assets/menu.png')"
source.over="@Embed('/assets/menu_over.png')"
source.down="@Embed('/assets/menu_down.png')"
left="0" right="0" top="0" bottom="0" />
<!-- layer 8: text -->
<s:Label id="labelDisplay"
textAlign="center"
verticalAlign="middle"
maxDisplayedLines="1"
horizontalCenter="0" verticalCenter="1"
left="10" right="10" top="2" bottom="2" />
</s:SparkSkin>
Talk about wasted space! I understand the power the new skin mechanism adds (you can now layer effects), but I personally don’t feel it’s worth it.
The future of Flex
Adobe has touted the power of Flash Builder 4, but as we have all seen in the past sometimes more powerful designs lead to failure. I think Adobe forgot the KISS principle, or perhaps they had one too many designers at the table instead of developers when they were creating the new architecture. While I liked the ease, power, and simple nature of Flex 3, I’m not convinced of the merits of Flash Builder 4 from a developer perspective. It seems like they made our job a lot more difficult and time consuming.
More articles to follow as I delve into the beast that is Flash Builder 4!
umm you should use FB4 before you judge so harshly. More than half of your code is unnecessary.
this code does the same thing, i just removed unnecessary stuff:
<?xml version="1.0" encoding="utf-8"?> <!— comment for ASDOC –>
<s:Skin name="ImageButtonSkin"
xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:s="library://ns.adobe.com/flex/spark"
minWidth="21" minHeight="21"
alpha.disabled="0.5">
<!– states –>
<s:states>
<s:State name="up" />
<s:State name="over" />
<s:State name="down" />
<s:State name="disabled" />
</s:states>
<s:BitmapImage source="@Embed(‘/assets/menu.png’)"
source.over="@Embed(‘/assets/menu_over.png’)"
source.down="@Embed(‘/assets/menu_down.png’)"
left="0" right="0" top="0" bottom="0" />
<!– text –>
<s:Label id="labelDisplay"
textAlign="center"
verticalAlign="middle"
maxDisplayedLines="1"
horizontalCenter="0" verticalCenter="1"
left="10" right="10" top="2" bottom="2" />
</s:Skin>
Ok, so 29 lines instead of 51? That’s really better than 5?
well.. moving from AS2 to AS3 also meant that instead of button.onRelease=function(){ do Something(); } it required quite a bit more code.. however I prefer the more verbose AS3 method of doing things, as it is much more powerful.
Not that this is exactly the same, but I’m willing to bet there’s an even better solution somewhere.
So your primary complaint is that upgrading a Flex 3 app to Flex 4 isn’t a piece of cake (backwards compatibility isn’t preserved, so it doesn’t “just work”); and your secondary complaint is that it’s too verbose.
Firstly, when has upgrading major versions in Flex ever been easy? Have you upgraded a Flex 1.5 app to Flex 2? Or 2 to 3.x? No easy task, but definitely worth it. And once again, 3 to 4 is not exactly easy, but the changes are all for the better of the developer.
Secondly, you’ve already admitted that you don’t know Flex 4 MXML that well; as evidenced by your example skinning code being cut in half. Chances are that the more you learn, the less abrasive you’ll find it.
A lot of changes, specifically those involving skinning, were done for the purpose of making it easier to make unique-looking Flex applications with Flash Catalyst and a professional designer. If you check out a demo of Flash Catalyst some time, you might start to appreciate just how powerful these changes are, and be willing to write a few extra lines of code.
Lastly, nobody is twisting your arm. If you hate it so much, go write Silverlight apps.
Ok first off, I didn’t write the example. As I mentioned in the post I borrowed it from another author. Second, going from 51 lines to 29 proves my point! The Flex 3 way of doing things is 5 lines. It’s not that I think Flex 4 is verbose, its that I think its unnecessarily verbose. For example, there shouldn’t be two versions of the Button class, Halo and Spark, there should be one. Having two implies a complete lack of organization on Adobe’s part and makes me believe someone just came in and rewrote the classes to Spark without trying to modify the Halo versions. They have essentially forked the code base.
Lastly, I like Flex up to version 3. It’s a great language that I thought had the power to become the next big platform. The changes they made in Flex 4 make me seriously rethink this though.
I think that you’re right with the new namespace stuff in flex 4, it can be confusing, especially for new developers.
But
You can do much more stuff with flex 4, when i do everyday work i usually need way more than just 3 images for a button ( transistions between states, text aligned, size, elements of the button changing between states,…. ). These thing were a pain to do in flex 3.
An example: Today i had to do an itemrenderer for a chart datatip in flex 3. after 3 hours of searching it turned out that i need to write an itemrenderer for the background of the datatip, an an itemrendererfunction for the text on the datatip. The renderer was in AS code and i needed to override functions like updatedisplayList. It was a pain to do and cost me 4 hours.
In flex 4 i just write everything in a single skin file, where i have control of everything.
For simple cases ( like i just want to be the text bold on my tooltip in ) flex 3 is faster cause there is a property for it.
But if you want to really customise how your stuff looks flex 4 produces more simple code and its more easier to write.
from a flex doc:
“In MX, each of the components had lots of styles for you to tweak. In Spark, we’ve shied away from styling in favor of skinning, which gives you more flexibility. However, this approach does make some simple tweaks a little harder.”
source: http://opensource.adobe.com/wiki/display/flexsdk/Spark+Skinning
@Adam: “Firstly, when has upgrading major versions in Flex ever been easy?”
You should mind your own comments. It anything this is an advertisement that says in BIG RED LETTERS, “go write Silverlight apps”. Oh, but then again, you said that too.
The fact is over the last 25 years writing software, what Scott says has not only merit, but very valuable insight. So he’s not as up on Flex 4…big DEAL. Unless the jump from one version of a framework ( and unless you were around for the jump from C++ w/o template….TO C++ w/ templates back in the EARLY 90’s, don’t presume to lecture anyone on “paradigm shift” ) to another is revolutionary, there’s no need for this sort of phantamagorical agglomeration of baggage.
@sydd: It’s not just borderline confusing, it’s downright redundant. And anyone who ignores cyclomatic complexity introduced by mixing redudant systems is prone to that greater difficulty in maintaining quality. And no offense “skinning” doesn’t just make “simple tweaks a little harder”. Of course you’re shied away from styling to skinning. It means you have to take more control, and frankly, it’s been pushed to a level that’s just unnecessary.
Scott’s pointed out some good points. Try to make them sound as specious as you want, but the fact is, Flex 4 has just given MS a very nice opening for folks to migrate over. Having built some SL1 apps, moving them to SL2 was not painful. Now skipping SL3 and testing one out on SL4 beta…again….not painful. Hello ! Is someone listening at Adobe ?
Interesting that you use Java as an example when complaining about Spark and Halo existing side by side, when Java’s had Swing and AWT for ages. I’m not saying it’s a good idea — I think it’s been a problem for Java as well, but I don’t think that Java’s a good counter-example
@Geoffrey Wiseman
True, but the difference is many people use Java without ever touching Swing/AWT. That’s why I chose the String class as an analogy since it is so commonly used. It’s hard to imagine a Flex developer who has never used a Button component before and it is on that level of fundamentals, like the String class, that Adobe has changed Flex in this new version.
“Ok, so 29 lines instead of 51? That’s really better than 5?”
It’s better than 51…
“It’s better than 51…”
It’s worse than 5.
Flex4’s programmatic skinning is far, far better than Flex3’s.
Your Java example backfires in 3… 2… 1… java.awt.List vs java.util.List
@karl
And you think the split between “java.awt.List” and “java.util.List” was a good thing? As a moderator on the JavaRanch, I’ve seen first hand how lack of coordination on libraries influences every-day developers. At least with Java, it is just a handful of classes that have these issues. With Flex 4, they re-implemented dozens of the most used classes in the API. Talk about a nightmare!
Guess its back to Silverlight 4 for me. Right click menus for the win! Try to do that in flash!
@jason
In the words of Mart Twain, “Don’t say the old lady screamed. Bring her on and let her scream.” You can’t just say “Flex 4 skinning is better”, you need to qualify it. I didn’t say Flex 4 had issues, I demonstrated it.
Funny… I can skin a mx:Button in just as many lines of code with Flex 4. Nobody is forcing you to use . is still available. Sure, you had to update your CSS, it’s not that big of a deal.
Flex 4 skinning is better because you don’t have to conform to what the flex team thought you’d want to do. If you want to have an image on either side of your button’s label, that’s possible now, without rewriting the entire button class.
And no, you didn’t say it had issues, you said it was defective. There’s nothing defective about offering more flexibility and customization opportunities. If you don’t want to use spark, DON’T.
You admit that you’re ignorant of the reasons behind the upgrades, but that’s YOUR problem, not the internets’. The Flex team has documented the crap out of why they’re making these changes, and the specific vs is actually a community decision, and was pushed for by the people that use Flex every day. If you actually cared, I would have guessed that you would have been part of that conversation.
@Dusty
I never said I was ignorant of the reasons behind the upgrades. I understand why they wanted to support more powerful skinning, I just disagree with how they went about doing it. Forking the code base into 2 separate sets of classes isn’t exactly graceful. The Flex team can document whatever they want, but it doesn’t mean they didn’t make a lot of mistakes with this release that will come back to haunt them.
Scott a straw man isn’t necessary. I think that util vs awt list was bad because they are two classes which supplement each other’s functions. On the other hand spark and halo are competing implementations and should not be mixed if at all possible.
@karl
That’s my point exactly. Halo and Spark components shouldn’t be mixed but the fact that can be mixed is a very bad thing. To paraphrase an old expression, Adobe gave developers enough rope to hang themselves with. Software applications written by multiple developers run the risk of being muddled messes of Halo and Spark components. It’s hard enough to enforce developer standards without them having the ability to intermix two different libraries.
While I understand your complaint, the two have different intentions and as such have the ideological basis to exist simultaneously. I see it as analogous to using traditional text vs the text layout framework/text engine.
As soon as you want to use the TextFlow for example, you will add almost 200kb to your SWF. The TLF is much, much more verbose as well — but it comes with every bit of control you might want.
If Adobe were to drop spark, they would be breaking the conventions and expectations with Flex: imagine having to rebuild the UI of a huge, multi-platform flex app you deployed with spark components because you want to tap into some new features/abilities. In Flex 5, I imagine spark may get deprecated but still exist, and in 6 they could drop it.
Again, flex is already a mature framework, but it can certainly use innovation. You either fuck with your entire user base and potentially cost companies many thousands of dollars in rebuilding their UIs, or you support some level of backward-compatibility.
In JavaFX you make your own controls
var button = ImageView {
image: Image {
url{“{__DIR__}button.png”}
}
onMouseClicked: function (e: MouseEvent): Void {
SomeFuction();
}
}
thats written from memory so forgive me if it doesn’t work.
Essentially, the trend is a little worrying. I am sure many others have had second thoughts about flash. I like flash, and have been an advocate in using it in projects because of its cross-platform nature and rapid development. Allow me to say that again: rapid development. Flash has become more and more complicated to the point that there is less and less differentiating the effort (and time) required to develop an application in Java and Flash.
This is a potential problem for the flash platform, because if you take away the simplicity and rapid development parts, there is essentially no reason to choose flash over Java, JavaFX or others.
Also, while some vendors have been reluctant to include flash support (for whatever reason) on some of their devices, no such debate seems to be developing over Java. If that doesn’t scare the Adobe Flash guys into at least building some “quick and easy” solutions over their versatile and overpowered (read: overly complicated) platform, then nothing will.
Its great to have a super-flexible overpowered super button class, but one should not forget about the hundreds of thousands of instances, when you just want to do a simple thing with it. EASILY. Thanks for listening.
“while some vendors have been reluctant to include flash support (for whatever reason) on some of their devices, no such debate seems to be developing over Java”
Apple’s the best-known hold-out on Flash for devices, and Java’s equally left-out here. This is slightly less contentious because even Java advocates recognize that it has little “client” traction, whereas Flash is all client.
Scott, I agree with you. I’m currently prototyping with Spark and while some of the new features are great (state-based appearance is much easier now), the trends you mentioned are troubling.
Another point that no one has mentioned is how much more difficult integrating the new skinning system is with Flash CS4. I have an artist that is familiar with creating button skins in CS4 using the Flex Component Kit and associated templates. Before, you could just set the mx:Button’s skin to the exported class name of the skin class, but now you have to either export each button state as a separate swf or keep using mx:Button, which goes back to the point about mixing styles. I’ve been told that CS5 will have some sort of standard integration with Flex but only time will tell. Of course this also means shelling out more $ for the newest version.
Oh, and now there’s a push for FXG, yet another xml-based vector format. Wasn’t the whole point of Flash to avoid having to draw programatically?
Scott just keep with Flex 3. I don’t think you’re adding any value in this post. If your going to critic Flex 4 give a balanced view not just a negative view of why Flex 4 is “bad” or at least reference a post or article which represents the other side of your opinion.
A quick rebuttal of your points
1) I guess developers in your world are particular dumb. They would not understand that a mx/Halo component uses a different skinning process to that of s/Spark?
2) Flex 1.5 had a broken migration path to Flex 2 but it didn’t stop it being a success. Hmm I guess your using it’s successor Flex 3 so yeah broken migrations paths are not the be all and end all.
3) Com’on X Vs Y lines of code? Bit of an old argument when comparing frameworks/languages. The code is generated by the IDE so you can save your precious fingers. All they are doing is exposing more detail to you and giving you more control.
Also you make no substantiated comment about Flash Builder 4 being “defective by design”? Com’on are you just seeking attention? This post is about Flex 4 not Flash Builder 4.
Overall it is a bit of disappointing post and hence the other comments in similar sentiment.
@Ross Phillips
When they released Flex Builder 3, they made a lot of enhancements to Flex but did not significantly change the language. In this release, though, language changes are of paramount importance. I acknowledge Flash Builder 4 is technically separate from Flex 4, but they were released together and it makes no sense to me to talk about one without the other.
Also, I didn’t just say Flex 4 was bad, I gave specific reasons. Some people have responded “Flex 4 is great” without saying how. As I said to Jason in an earlier comment, qualify your statements.
Quick comments about your rebuttals:
1) Most developers are extremely dumb, or at least very lazy. Read http://www.thedailywtf.com for some examples. As a senior developer on applications with hundreds of people involved, I don’t have the luxury of writing every line of code. If you’ve never come across bad code at work, you are either lying or the luckiest developer in the world.
2) When I upgraded from Flex 2 to Flex 3, the number of changes I had to make to my existing projects were minuscule. It wasn’t perfect, but it was pretty close. On the other hand, if you want to upgrade your application to Flex 4 and not leave the “Flex 3 compatibility mode” on all the time, the changes are not simple. Skinning a component in Flex 4 is a radical change to a Flex 3 that requires hours of redevelopment.
3) I’m a fan of code generation when its left as machine generated code. According to the Flex 4 documentation, after generating the skins, the developer customizes them by hand. At this point, its no longer machine generated code and can’t be regenerated in the future. Besides, it seems lazy of me for the architects of Flex 4 to rely on the user code generating pieces. If anything, they should be handled by the compiler and they should have found ways to extend the existing language to support the new options in a simple and straight-forward manner.
Oh, and as for line X count versus line Y, let’s do the math shall we. Let’s say you skin 20 buttons in an application. Previously, this could be maintained in a single CSS file for a total of 100 lines of code. Sounds simple to me. In Flex 4, you now have 30+ lines of code in each of 20 files. I don’t know about you but maintaining 600+ lines of code across 20 files is a lot more painful than maintaining the former.
You’re welcome to your opinion but I’ve had enough Flex developers and consultants agree with me, that I don’t think I’m off base here. I wrote my article because I was generally dissatisfied once I started using Flex 4 and am gravely concerned with the direction Flex is going. As technical lead with years of experience in the field and expertise on a number of languages, I’ve seen where things can go wrong ‘in the name of making a language more powerful’. At the end of the day, if its not easy to use, beginners will shy away from it. I thought Flex 3 maintained a great balance of power and usability, but Flex 4 tramples that line.
great use of the word phantamagorical. I wish I could be creative enough to use it in a sentence. Oh wait, I just did.
Nice post, Scott. Yes, FB4 has become way too complex and is probably going to lose a bunch of devs. And what’s with the messy workflow? I guess this was to accommodate Catalyst. AS3 was more involved than AS2 for a (very good) purpose, but FB4 seems complicated for no good reason at all.
I’ve been a huge Flash/Flex supporter and was initially impressed with cool new stuff in FB4 (like threaded text – see my tut at http://goo.gl/D4Z4), but with this new complexity/bloat and (more importantly) lack of wide support on mobile platforms, I’m moving on to AJAX/HTML5 (with GWT).
Pingback: inconsequence › CS5
Nice post, Scott. Yes, FB4 has become way too complex and is probably going to lose a bunch of devs. And what’s with the messy workflow? I guess this was to accommodate Catalyst. AS3 was more involved than AS2 for a (very good) purpose, but FB4 seems complicated for no good reason at all.
I’ve been a huge Flash/Flex supporter and was initially impressed with cool new stuff in FB4 (like threaded text – see my tut at http://goo.gl/D4Z4), but with this new complexity/bloat and (more importantly) lack of wide support on mobile platforms, I’m moving on to AJAX/HTML5 (with GWT).
While I understand your complaint, the two have different intentions and as such have the ideological basis to exist simultaneously. I see it as analogous to using traditional text vs the text layout framework/text engine.
As soon as you want to use the TextFlow for example, you will add almost 200kb to your SWF. The TLF is much, much more verbose as well — but it comes with every bit of control you might want.
If Adobe were to drop spark, they would be breaking the conventions and expectations with Flex: imagine having to rebuild the UI of a huge, multi-platform flex app you deployed with spark components because you want to tap into some new features/abilities. In Flex 5, I imagine spark may get deprecated but still exist, and in 6 they could drop it.
Again, flex is already a mature framework, but it can certainly use innovation. You either fuck with your entire user base and potentially cost companies many thousands of dollars in rebuilding their UIs, or you support some level of backward-compatibility.
Nice post, Scott. Yes, FB4 has become way too complex and is probably going to lose a bunch of devs. And what’s with the messy workflow? I guess this was to accommodate Catalyst. AS3 was more involved than AS2 for a (very good) purpose, but FB4 seems complicated for no good reason at all.
I’ve been a huge Flash/Flex supporter and was initially impressed with cool new stuff in FB4 (like threaded text – see my tut at http://goo.gl/D4Z4), but with this new complexity/bloat and (more importantly) lack of wide support on mobile platforms, I’m moving on to AJAX/HTML5 (with GWT).
In JavaFX you make your own controls
var button = ImageView {
image: Image {
url{“{__DIR__}button.png”}
}
onMouseClicked: function (e: MouseEvent): Void {
SomeFuction();
}
}
thats written from memory so forgive me if it doesn’t work.
Pingback: Flash Builder Fail: Flex Run Time Resources » Mind the Emigrant Gap
Pingback: Skinning a Button « StepGreen Research Notes
Above are some very compelling arguments four and three. Outside of the occasional crash, I think FB4 is to Flex what Flex was to Flash. There was a lot of unnecessary reinventing the wheel going on with every project while developing with Flash years ago. Then Flex helped straighten much out… and allowed a developer to focus on the problem at hand. The same holds true with FB4 too. Moving forward, I do not want to write and rewrite the same thing again and again – I am getting lazy. If 40 extra lines offer me that flexibility and re-usability I will accept that. Many AS experts will go even further and recommend doing most of the work in AS. At the end of the day, it’s about what works for you, your organization and work. And IF used properly, it can leave limitless design options.
The switch from Flex 3 to 4 for me required a week’s worth of learning. ie. nothing. The new skinning abilities of Spark by far exceed those of Halo. The ability to integrate these skins with stylesheets – treating the stylesheet as a variable repository – means I’ve been able to make some amazing effects using a single skin linked to a class on a stylesheet. If you’re busy writing separate skins for your different coloured buttons, you haven’t been reading the documentation or investigating Spark’s power.
Halo’s ability to style an application is simplistic by comparison.
I agree with you men… FB4 is too harsh for us developers. Just to dig money for their Catalyst their forcing some native FB developers to embrace the new architecture. Why Adobe making things too complicated because they feel they’re the only one in the market (silverlight considering gone).
I skinned my Flex 3 app using a Flash template to design many components.
Is there an equivalent template for Flash to design and export a swf for Flex 4 Spark components?
I am actually having a hard time having everything transition over into Flex 4 from Flex 3 and I want to start from scratch and go 100% Spark.
has anyone bared the thought that halo might go to the dearly departed?? Personally, Digging around for the last 2 weeks in FB4, and noticing all the sprucing done with the spark, and the halo just kind of left in the swing of it.
I think that in the future Halo will be a theme styled option, and nothing more. I think they are moving their core design over to this newer framework. I would not want to include all my new stuff into my old stuff, if I planned on tanking it down the road. that would be REDUNDANT coding.
I see no problem yet mixing the 2 right now. I like the halo theme. I like the green one. I use them through out all my apps. I use spark containers. But I use halo Mx style everything where I can. There are still bugs with the style stuff. Mainly warnings and such, but I know that in future revisions they will continue and finish the move. So when 4.1 or 4.5 or 5.0 comes…. I will be scrapping my app and rebuilding it in their newer non compatible and non friendly upgrading process, but I bet it will revel like no other.
oh, and for people like me that like the older look of things. It only took me 3 lines of style code to get my greenish halo theme to work on the spark stuff. so, really I could care less about halo. Just have to spend time with the app to learn where everything is, and what it can do.
regards.
@stuffmatters
I don’t disagree that the new Spark components aren’t wonderful things, but overall its not a good sign of a language if, by upgrading, you have to throw out everything that has ever been previously developed in it. It’s what happens when you fork a language.
A GREAT THE TIMELY ARTICLE. Stupidly I attempted to stay on the edge by going over to Flash Builder from Flex 3. The complexity is absolutely absurd and a waste of my time. At some point you have to stop learning and start earning. Adobe obviously forgot that and shot everybody in the foot, including themselves. You could spend a month just trying to figureOut FigureOut or figureout what the hell to capitalize and what to camelCase and how and when and where. Do I really want to spend the time to figure out a A from an a ????
At least in Flex 3 you could hit a button, get a lot of relevant code and start to figure it all out. Good luck on this stuff. Thanks for wasting my year Adobe.
Flash Builder 4 is worse than Flash Develop.
I have to pay £500 for a product that is worse than a free one.
/facedesk
Pingback: Where’s the Flex Plug-in for Eclipse 3.5? | Down Home Country Coding With Scott Selikoff and Jeanne Boyarsky
Funny! I googled Flex 4 and not found results, so I tried Flex 4 reviews and found your article. I’d like to post here to show I agree and add some points.
You cannot add in any easy way load an external (generated) CSS file on runtime.
You can group states to change maintain them in a single change. But the Design mode doesn’t support it.
We don’t have yet a decent way to put a HTML inside our application and make them interact (it’s very common since we develop to web :))
We don’t have yet decent support to any method to make an application search engine friendly, when needed (what would make FB4 a very good alternative to AJAX).
While they improved greatly the language Flexibility and Power to make good things, they dismissed the COMMON USE CASE and made the execution of trivial work very expensive to make.
Adobe should really take care and pay attention on your review. I think any analysis of the changes they made in architecture, free of passion, should got the same or very near point.
Yes i do agree with most of the people over here that Flex 4 termed as ‘Flash builder 4 ‘ is complicated infact the name itself flash builder 4 leads to ambiguity whether is flex or flash.. i hope adobe realizes the concern of developers
Flex 4 is terrible. Try migrating an entire business model based on Flex 3 to Flex 4, including re-training employees and re-creating a code base. Most developers I know who are too busy working to catch a breath don’t even give Flex 4 a second thought. There are a few things in AIR 2.0 that are worthwhile, but for the most part, Flex 4 is “Emperors New Clothes.”
I have been struggling for quite some time now with the flex framework, I am extremely comfortable with it and was very impressed with it in the beginning when I began learning flex 3 later flex 4. But I must say that as time goes on I am beginning to feel like I have wasted my time in learning it, due to compatability issues with flash player and mac, as well as lack of indexable content for search engines etc….(the list goes on). Not to mention that the FB ide throws a ton of warnings as soon as you begin to get into complex skinning with spark(which I still haven’t gotten to the bottom of).
I love the whole idea and concept of Flex and have wanted to use it so badly, but I am not confident enough with it to make the full switch simply because I am feeling like I am just going to end up with a big headache down the road.
Just out of curiosity, since many of you seem to be a bit more experienced than myself, do any of you feel that Jquery/Javascript libraries would be the smarter way to go giving the direction html5 is heading and adobe’s lack of care for the developer?
In Spring of 2011, I was very excited at the fact that we would be using Adobe Flash Builder 4 in a semester-long software engineering class project at a leading university. I had used many Adobe products in the past and was very happy with them, particularly Photoshop, Illustrator and Dreamweaver. I had also been wanting to learn ActionScript/Flex, and this project would give me the opportunity. However, after extensive use of Flash Builder, I have realized that this product was the biggest let down since Windows Vista.
There were several people working on the same project using Subversion. In addition, we would have a lab session once a week using different computers, so it was necessary to frequently import projects into Flash Builder. Importing Flex Projects was the most annoying and time consuming aspect of many. Firstly, when one selects the import option, a dialog is presented and is positioned mostly off screen. It is necessary for one to drag the dialog to the screen manually every time. In addition, the path of recent projects is not saved, so one must manually navigate to the proper directory each time. Since there were so many problems with projects falling apart, many imports were necessary. It is necessary to manually navigate through the long hierarchy of directories to reach the project. This is very time consuming and unproductive.
After the import, the project will not run because of some problem finding the HTML files. It was necessary to create new projects from scratch and do a lot of copying/pasting until a team member directed me to delete the html-template directory. I am not sure how he came across this tip, as I had searched the Internet for solutions to no avail. One more tedious step is necessary. The html-template directory needs to be recreated, and the only way, at least that I see, is to rebuild the project, then after the error appears in the Problems window, right-click the error and select Recreate HTML Templates. That’s quite a bit of work, and maybe there should be an explicit option to recreate HTML templates that’s not buried as a right-click option in the errors list.
This leads to the next problem. Errors do not appear in the code until the file is saved. Every time I type in a new statement, it is necessary to save the file in order to see if there are any errors. This is very counterproductive. In addition, it would be much more productive to add a feature in the code hints that would allow for mouse wheel scrolling. It takes much longer to navigate through the hints without this feature.
Another problem related to importing projects is with executing it. Sometimes after importing a new project, a dialog displays that says that it may be necessary to restart the browser. This turned out to be a huge problem, as I frequently have many, many Firefox tabs/windows open at a given time. It is very unproductive to restart Firefox several times until the project finally imports correctly. Sometimes it will work without restarting, however, and I cannot pinpoint any differences between when it works and when it doesn’t. This may be related to the Flash plugin as opposed to Flash Builder.
This leads to another problem. For testing purposes, sometimes it is necessary to locally run the HTML file in the bin-debug directory. Even after a successful import and rebuilding of the HTML template, the Flash content will not load at all – just a blank screen. Sometimes the content will load, but it will not function correctly. If I upload the files to a live web server, it works just fine. However, sometimes it is necessary to run the HTML files locally, and it is very inefficient to have to upload/run to/from a web server.
After all the trial and error of simply importing a project and when you think you’re making progress, something happens to the project along the way. All of a sudden when you try to execute an MXML application, which is in the same directory of several others, only one certain MXML application decides to run (when you are trying to run another one). The only workaround that I found is to either bring up a backup or create a new project and copy/paste the code. This is highly unproductive.
All the inefficiencies and bugs in Flash Builder made it necessary for me to make constant backups. When a project fell apart, I had to open a backup and copy/paste the code. This was a lot of wasted time. In addition, I learned early on not to count on Flash Builder when presenting or making minor, last minute changes before a presentation. Flash Builder always managed to encounter some strange problem.
Flash Builder is unreliable and highly inefficient. I love Adobe products and Flash is great, but at this time I can no longer use or support Flash Builder, and I could in no way justify its purchase in the future until most of these bugs and inefficiencies are fixed. It has potential, and could be a great product if this were the case, but in my experience I spent more time overcoming bugs than coding. When something would not work right, I first had to determine whether it was a bug in my code or a bug in Flash Builder. If Adobe needs an engineer to fix some of these seemingly simple issues, I would be willing to take on the task for the sake of saving this potentially amazing product.