wood burning stoves*
The moose likes Flex and the fly likes Should I spend time to learn Flex, currently as a Java/J2EE developer Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Frameworks » Flex
Bookmark "Should I spend time to learn Flex, currently as a Java/J2EE developer" Watch "Should I spend time to learn Flex, currently as a Java/J2EE developer" New topic
Author

Should I spend time to learn Flex, currently as a Java/J2EE developer

Jackie Li
Ranch Hand

Joined: Sep 12, 2010
Posts: 30
Hi all,

I am totally new to Flex. However, I do have three to fours years experience on Java/J2EE.

Recently I saw some job positions are actually looking for java+ flex developers, so wondering should invest time to study this skill. I am currently in the process of pursing SCBCD certificate. And all my daily job is J2EEs.

Thanks for all answers.

Jackie
Preston Thornton
Ranch Hand

Joined: Jun 24, 2008
Posts: 80
Are you kidding? Heck yeah! I am trying to learn J2EE but I keep looking at this 1000+ page tutorial and loose heart. I think they are paying more for Flex developers than J2EE, but you need the J2EE in order to utilize the BlazeDS for remote object access.


Here is learn flex in a week:
http://www.adobe.com/devnet/flex/videotraining.html

Preston Thornton
Flex Hype Man . . .
R. Grimes
Ranch Hand

Joined: Aug 23, 2009
Posts: 42
I absolutely love the Java/Flex combination. I'm a big fan of Flex on the client-side. In my opinion, Adobe rules the client-side on so many levels. And, nothing beats Java on the server side. You can't go wrong by learning Flex. Besides, with Java under your belt, learning Flex's AS3 will be a snap. There's VERY little difference between the syntax. Data types are different, and method signatures are switched up a bit:

Java
public String getCustomerWidgetName(int customerNumber)

AS3
public getCustomerWidgetName(customerNumber:int):String

There's a few other things that differentiate it, but, for me, the learning curve with Flex was pretty short.

The biggest difference is probably that classes can also be expressed as MXML (a flavor of XML). It's a bit odd to getting used to the idea that you can create and instantiate a class with properties and methods expressed as XML elements. For example,

AS3
var myCanvas:Canvas = new Canvas();
myCanvas.x = 10;
myCanvas.y = 10;

MXML
<mx:Canvas id="myCanvas" x="10" y="10" />

They both create a new Canvas and set properties. Once you learn to view MXML as another class creation mechanism, a lot of the mystery disappears.


Ron Grimes
Paul Sturrock
Bartender

Joined: Apr 14, 2004
Posts: 10336

Preston Thornton wrote:Are you kidding? Heck yeah! I am trying to learn J2EE but I keep looking at this 1000+ page tutorial and loose heart. I think they are paying more for Flex developers than J2EE, but you need the J2EE in order to utilize the BlazeDS for remote object access.


Here is learn flex in a week:
http://www.adobe.com/devnet/flex/videotraining.html

Preston Thornton
Flex Hype Man . . .


Just to clarify - Flex is not the same as JEE. Flex is just a GUI technology, one of many, all of which tend to sit on JEE applications. If you are thinking about career objectives, I'd certainly learn both.


JavaRanch FAQ HowToAskQuestionsOnJavaRanch
Paul Sturrock
Bartender

Joined: Apr 14, 2004
Posts: 10336

R. Grimes wrote:I absolutely love the Java/Flex combination. I'm a big fan of Flex on the client-side. In my opinion, Adobe rules the client-side on so many levels. And, nothing beats Java on the server side. You can't go wrong by learning Flex. Besides, with Java under your belt, learning Flex's AS3 will be a snap. There's VERY little difference between the syntax. Data types are different, and method signatures are switched up a bit:

Java
public String getCustomerWidgetName(int customerNumber)

AS3
public getCustomerWidgetName(customerNumber:int):String

There's a few other things that differentiate it, but, for me, the learning curve with Flex was pretty short.

The biggest difference is probably that classes can also be expressed as MXML (a flavor of XML). It's a bit odd to getting used to the idea that you can create and instantiate a class with properties and methods expressed as XML elements. For example,

AS3
var myCanvas:Canvas = new Canvas();
myCanvas.x = 10;
myCanvas.y = 10;

MXML
<mx:Canvas id="myCanvas" x="10" y="10" />

They both create a new Canvas and set properties. Once you learn to view MXML as another class creation mechanism, a lot of the mystery disappears.


Ron Grimes



My biggest issue with Flex as a GUI technology is you need to write behaviour normally available in the browser yourself in MXML/AS components. There are a whole raft of things you tend to rely on when writing HTML/JavaScript applications that you don;t have in Flex. I agree, small. very visual applications can be quickly written in Flex, but be wary of the hidden effort Flex also implies.
R. Grimes
Ranch Hand

Joined: Aug 23, 2009
Posts: 42
Paul Sturrock wrote:
My biggest issue with Flex as a GUI technology is you need to write behaviour normally available in the browser yourself in MXML/AS components. There are a whole raft of things you tend to rely on when writing HTML/JavaScript applications that you don;t have in Flex. I agree, small. very visual applications can be quickly written in Flex, but be wary of the hidden effort Flex also implies.


I'm not really sure what you have to code in Flex that is otherwise available in the browser. Nor, am I sure what "whole raft of things" there are in HTML/JS that is unavailable to Flex apps. And, I've certainly never limited my Flex apps to "small" apps. I've been writing in Flex since 2006, and I've just not found any of your assertions to be true.

But, I feel the benefits far outweigh any costs of using Flex. At our company, we originally started out with DHTML, which is essentially what most client technologies turn into, inasmuch as they transform into HTML pages with some JS embedded. This is true of XSL, Struts, JSP, etc. So, the real question comes down to, "Should I choose a client side technology that depends on the idiosyncrasies of multiple browsers and multiple versions within each browser type, or should I choose a client side solution that depends on a VM engine so that I can truly write once and it will run the same on any platform, any browser, and any version?"

This was why we switched from the former to the latter. Flex runs within an AVM. If you're not going to do anything complex with the HTML DOM and JS on the client side, then yeah, you can probably get away with a technology that ultimately renders into DHTML. But, if you want to insulate yourself from future changes by browser manufacturers, then use a VM reliant technology. I came to this conclusion after Microsoft came out with Windows SP2 and suddenly any cross-frame scripting would no longer work. Then you had to rush to fix any project that used it. I swore I would never subject my 2 dozen web projects to the whimsical changes of a browser manufacturer again.


Ron Grimes
Paul Sturrock
Bartender

Joined: Apr 14, 2004
Posts: 10336


I'm not really sure what you have to code in Flex that is otherwise available in the browser. Nor, am I sure what "whole raft of things" there are in HTML/JS that is unavailable to Flex apps. And, I've certainly never limited my Flex apps to "small" apps. I've been writing in Flex since 2006, and I've just not found any of your assertions to be true.

Fair enough - I've been writing Flex apps since 2008, perhaps we write them for different audiences?

Not start a flame war , I'll clarify myself. I was thinking about things like zoom, which is a key feature of accessible applications. I get that for free in all browsers, I have to write it in Flex. Or rendering HTML - something Flex does not support (despite claims to the contrary) which is a hurdle when it comes to integrating with other sources of data. In the same area, the Flex does not expose a DOM do JavaScript integration from other sources needs to be written in to the application. RTL support is still in its infancy - it sort of works OK, but no where near as mature as in browsers. Another example would be deep linking and browser history behaviour - I have to specifically invoke the browser manager and track navigation in Flex to get these. Or security - if I use out the box HTTP security I need to reload a Flex application every time a session expires (because it is the resource itself that is forbidden, not the remote calls from the Flex app), if I rely on Flex custom security I have to manually work round propagating the subject through the container if I use anything other than Tomcat. Also CSS support; Flex uses its own version of this, so restyling apps if you were not the original developer is hard. Its also hard to inject changes to functionality. With a typical browser application I can drop in a quick change to the UI via JavaScript, in Flex I need to ship a new swf.

By "big" applications I was implying the sort of enterprise rigor required for this sort of development. Flex doesn't really have any good automated testing tools that will run in a continuous integration environment. FlexUnit is difficult to work with and you are not guaranteed to get all the events triggered you would if you were manually testing the application. When it comes to Q4 testing, there are very few tools that can capture AMF format. When we've done this sort of testing we have had to write our own test harnesses. I see this as a real weakness; complex applications without an automated test harness are brittle and difficult to maintain. Web applications however are easy to test with something like Selenium, and Q4 testing is easy with any number of off the shelf tools. Since I mention performance, its worth noting that some Flex controls (DataGrid/AdvancedDataGrid I'm looking at you!) do not do well with larger volumes of data. The network performance differences are marked too; with Flex you have to always be thinking about the amount of data you will be sending over the wire, with traditional development where the end result is HTML, you know that the HTML is never going to be that big. Flex apps, I've found, really require a service layer that streamlines the model specifically for this particular view; something I'm not 100% comfortable with.

And I should probably mention 64 bit browser support does not exist.

Flex has many good things going for it - I like how quickly I can bash up a rich UI in MXML - but it presents a whole different sets of technical problems that you don't have to think about doing normal web development. I like Flex, but experience means I use it with a pinch of salt these days.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
 
subject: Should I spend time to learn Flex, currently as a Java/J2EE developer