Flight Framework: Application Structure

The core of Flight’s methodology is in its prescribed structure. The framework guides the architectural process by establishing package (folder) structure and modularization of code. It helps answer the question, “where does this go?” Though its concepts are simple they are effective in promoting iterative development and code reuse. A common application structure is also important in organizing team development and in creating a familiar development environment.

NOTE: the diagram also establishes the following package structure

Package Structure

An application should have a root package named after the application. If you don’t have a real name for your app give it a code name. Clear and descriptive naming helps you dig down through your folders to locate code quickly. This initial package can follow any naming convention you’re comfortable with, such as com.flightxd.superhero, or just superhero.

The application contains these 3 packages:

(application)

• config - holds all of the applications configurations
• domains - contains one or more domain package, the real logic of the app
• view - all of the user interface logic specific to the app

The config package is flat and just holds ActionScript and MXML files. The view package usually starts out flat when the user interface is sparse but should be organized with additional packages once complexity increases. Divide up your application components by their function in the system, not by their type, style or layout. For example, the EditHeroScreen class would reside in the view.herobuilder package and not in a view.screens package.

The domains package holds any number of developer-defined packages which each contain a specific set of Flight-defined packages. These “domain” packages should also have descriptive names reflecting the logic they embody. For example, a domain that deals with all the details and logic of a super hero’s power could be called superpower.

Each domain package structure is defined:

(domain)

• commands - all commands used by the controller
• model - all of the underlying data and logic for a particular domain
• view - optionally defined for portable components tied to a domain
• (DomainController) - this class represents the public API to a domain

Defined commands are named after their action. Because no other type of class is named by a verb, commands are easy to identify and do not require a trailing “Command”. For example, the action “lift off” can be named LiftOff rather than LiftOffCommand. More on commands and models are discussed later on.

Each domain has a public class which extends DomainController. This class acts as an entry point and a manager to the domain and is named in a like manner after the domain. For example, if the domain package was named domains.superpower then the DomainController class would be named SuperPowerDomain. Domains and their function in the application are an important part of Flight and are described in greater detail later on.

These guidelines define a template for all Flight applications and libraries. By following the prescribed structure of the Flight Framework developers will enjoy a consistent and straightforward approach to application organization.