Friday, April 23, 2010

Enterprise Flex Development Do's and Dont's

I recently had an interesting discussion with a friend who manages a team of developers. He was complaining that although his team members are experienced Flex developers, many of them had very bad coding habits. I knew what he was talking about. Years of developing relatively small GUI applications on a very tight schedule caused AS3 developers to adopt bad habits. Poor tutorials and a lack of good professional literature also contributed to this situation. When a person dives into Flex, many of the articles he or she will view online describe solutions for small applications. In such examples MVC and other patterns are absent, layout code is mixed with functional code, and many antipatterns are applied.

I think that Flex developers who are switching to Enterprise development will find the following short list of Do's and Dont's very useful.

1. Do use an MVC framework/architecture and stick to its rules! An MVC framework is essential when writing large-scale applications. Such a framework will already contain solutions to common challenges and thus compel the use of common design patterns. Enterprise applications are often developed by a large number of developers. The MVC framework encourages developers to adopt the same methodology and "speak the same language". When you write small applications on your own you can avoid using an MVC framework and get away with it, but this is not the case when you are writing a large application and sharing the task with a number of team members.

image taken from Priyang Patel’s Weblog

2. Forget XML handling. Flex online docs are filled with XML handling tutorials. Many developers seem to be excited by the possibility of loading and handling XML and incorporate these solutions in their code. While loading and parsing XML maybe useful in small applications, it is redundant in enterprise applications.

In an enterprise application XML may be present in the integration layer. For instance, if you are using SOAP web services, the messages to and from the server are constructed from XML. However, in an enterprise OO application, data should be handled as objects. The data might consist of XML but your code at large should not be aware of it. Your code does not need to be dependent on a specific XML structure coming from the server because a specific encoder and decoder should be handling the XML. If you are using a standard integration layer (SOAP, REST) third party solutions should be used to perform the XML-related tasks thereby relieving you from the need to write large chunks of XML parsing code. For example, the SOAP Encoder and SOAP Decoder should handle XML for you if you are using SOAP.

3. Use resource bundles Enterprise application texts should be customizable. They should allow administrators to change the content, or even the text language, when necessary. Large organizations in many countries (the EU for example) require the applications that they purchase to be entirely (100%) in their native language.

4. Stay away from the Flex Builder WYSIWYG Editor Flex WYSIWYG Editor (design mode) can be used to drag and drop or resize components on the application screen. This method is really efficient when you need to create something quickly and can compromise on it being dirty. Unfortunately the Flex WYSIWYG Editor generates code that is very difficult to maintain. One symptom is the hard coded x and y values of each component on the screen, which will be problematic when you need to resize or scale your screen.

5. Don't mix AS with MXML MXML is used to describe your application layout whereas AS is used to create business logic, and the two should not be mixed. A number of methods are available to help you keep the two separate and the View Helper pattern is one of them. By sticking to this rule you will be able to create a clear separation between layout and functionality. It will also be easier to manage and your code will be readable to others.

6. (Rob's addition) - Maintain a library of reusable generic UI components such components should not be dependent on your application code or used only in a specific scenario. Instead they should be generic and available for all team member to be used in different scenarios. Try to determine where a piece of UI code can be separated and isolated for reuse and make that piece a separate component.

These are my do's and don'ts feel free to comment and add yours..


Herzaso said...

Hey Boord, Nice post.
For server communications use AMF instead of XML. Remoting is much faster and more efficient than HTTPServices or WebServices.

Rob OToole said...

Great post! Glad to see that I'm implementing all of the do's and none of the don'ts. ;)

Another thing to add to the MVC section, is that decoupling your application into separate layers(M,V,C) is going to help immensely when debugging also.

Something else to add is building re-usable components, not use once and destroy components that are specific to the exact situation. Of course, there's always a need for extreme customization, but a base re-usable component could(should) be built and then extended to fit the custom criteria.

Anonymous said...

The Flex Builder WYSIWYG design tools is only a problem if you don't know how to use it. Similar to the way that you describe XML in your application, you need to understand that just because you can do something doesn't mean that it's enterprise grade. For developers/designers that understand constraint based layout and are comfortable laying out their applications in Flex Builder, it is a very useful tool. I agree that if you just create a Canvas and drop components onto it, it's going to create problems, but when you use constraint based layouts mixed with x,y it's very useful to see how your application will behave.

Lior Boord said...

Thank you all for your comments..

Herzas, obviously AMF should always be preferred over text based communication, when it's available. This is not always the case, I've had the chance to develop Flex clients that use third party services, such services are not client deponent and as such expose generic protocols such as SOAP. I guess that as more companies are now adopting cloud computing, you see more demand for SOAP and REST.

Rob, you are 100% correct, I will add an additional paragraph which will cover re usable components concept.

Anonymous, you wrote: "you need to understand that just because you can do something doesn't mean that it's enterprise grade", that is exactly my point. I guess I need to take a closer look into the WYSIWYG editor.

Michael Iv said...

I could argue on your statement "lack of good professional literature ...". The real problem of flex/flash developers is rather a lack of previous programming experience and/or in many cases a laziness to read professional literature .

a.s. said...

As someone who have only recently started looking at Flex, I wanna ask you to clarify the "separate MXML from AS" point.
My first impression was that MXML makes sense for layout, while for logic AS is the thing. But then someone pointed out that using the non-visible Flex components (take HTTPService for example) shortens coding times, and once you learn to read MXML they don't make your app look like a mess (as they do for me at this point :)) So... is it one of those grey borders that you find with time, or why did Adobe create all the none-visible comps, or.. what?

Lior Boord said...

a.s...what I meant is that you should not mix MXML code with your AS, or in other words avoid adding script blocks to your layout code and instead put AS in separate classes. there are a number of solution that will help you keep this separation.

Do feel free to use the declarative nature of MXML for none UI elements like HTTPService. Actually, I've made tutorial that does that with WebServices:

In that example Services are declared in the Services.MXML class
but the business logic resides in other classes.

Michael, I do think there are not enough good resources out there. I totally agree regarding the lack of previous experience but this is changing over the years. Engineers are usually lazy or too busy to read literature, this is not unique to Flex or AS.

Shai R said...

Great post,

About the design mode, it is also good for managing states (in flex 3). 'till I'll make the transition to 4...

Another thing that is important, is breaking parts of your app into modules and loading them only when needed...

Keep up the good work,

Vlad said...

There is an additional usage of mxml, that probably is not less important than layout - objects instances creation and initializing. I mean, there are sometimes conditions when cause of flash lifecycle you never know if your object was already created/initialized. In that case, just to be sure that AS will not try to access "null instance", you can use MXML for object creation, it runs before AS code.

Lior Boord said...

Shay, yes modules are important and useful as applications grow.

Vlad, not sure what you mean. If you are referring to none GUI objects there are better ways to handle this like using an IoC container.

Borek said...

I second the comment about the WYSIWYG editor - it is very very good and if you know how to set correct layout in the properties panel, there is no reason not to use it. FB's design view generates very clean code...

daves said...

Hi, thanks for sharing, i like very much

michaelvk said...
This comment has been removed by a blog administrator.