Component Development Guide > Guidelines & Best Practices

Code Architecture

We recommend using the Model-View-Controller (MVC) software engineering pattern when structuring your component code. The idea is to use separation of concerns to create three largely independent modules.

• The Model manages the component’s data and state. When something changes in the Model, it notifies the View of the change.
• The View controls how the component is displayed. It renders all the graphical elements on the user’s screen based on the Model’s state. 
• The Controller listens for user events, and makes changes to the Model based on those events.

The typical control flow of a component using the MVC architecture should go something like this:

• The user interacts with your component in some way, generating an event.
• The Controller handles the event generated by this interaction via a callback.
• The Controller notifies the Model of any changes that need to be made based on the user interaction.
• The Model changes its state based on the Controller’s input.
• The Model notifies the View of the state change.
• The View updates the user interface in accordance with the new Model state.

The cycle repeats when another user interaction occurs.

We recommend creating separate classes for the Model, View, and Controller, and making these classes as independent from each other as possible. Decoupling the component’s internal representation from how it is displayed in this way leads to code that is clearer, more flexible, and easier to maintain.

There is a lot of literature about the MVC pattern and its many different implementations, so we will not go into further detail here. We do not recommend any particular MVC implementation or framework; you can select whichever one works best for you.

Beyond using the MVC pattern, you should follow general guidelines for writing good, clean code when creating your component. We provide some basic guidelines below, but do not go into very much detail, as we expect component builders to already be proficient in ActionScript 3 programming and Flash design.

At a high level, your code should be easy to understand and modify. If it meets these two requirements, you are on the right track.

Readability: Your colleagues, both at your organization and, potentially, at Flite (depending on the nature of your partnership agreement with Flite), need to be able to easily read and understand your code. This makes collaboration and debugging more straightforward, significantly accelerates the Flite certification process, and makes the code much easier to maintain. Some things that improve code readability are:

• Consistent variable naming conventions across your code base;
• Descriptive variable names;
• Comments throughout your code;
• Avoiding unnecessarily complex coding idioms;
• Etc.

Extensibility: Your code needs to be written in a way that makes it quick and easy to modify and extend. You will want to add new features to your components based on customer requests, update it to conform to the latest industry standards, etc. The component should be written in a way that makes this easy to do. The key concept here is modularity. Break down your code into smaller, self-contained blocks. Use functions to perform commonly repeated operations. Using the MVC framework goes a long way in this direction, but further modularity is usually warranted depending on the complexity of your component.

For further details, please refer to the many texts out there on software engineering, code architecture principles, and proper programming.