Cairngorm 3 Guidelines – Facebook Photo Gallery

Cairngorm 3 guidelines followed in this application, mostly regarding modular development and architectural structure within each module. The application contains the following modules, runtime shared libraries:

asabau_cg3_fb_album , asabau_cg3_fb_authentication
Following Cairngorm 3 guidelines, each application functional area represents a separate flex module project. For Facebook Photo Gallery app we have two functional areas represented by asabau_cg3_fb_album and asabau_cg3_fb_authentication modules.
 
The modules are structured from an architectural point of view in presentation (view related code), application (custom events, command related code), domain (model related code), infrastructure (components used in views but not existing as standalone views).
 
Regarding presentation each view has its own presentation model (PM), all communication between view and its model being done via data binding. This helps unit testing, something not covered here.
 
Each module has a bare minimum launcher based on asabau_cg3_fb_shell main app launcher, allowing for separate development and testing of each module. This app makes use of Parlsey MessageInterceptor tag to provide data to the current isolated module, data that normally should come from other modules. Such an example can be found in the asabau_cg3_fb_album module, where a SampleDataGenerator intercepts album and photo related Facebook calls and returns a static data set.
 
asabau_cg3_fb_api
An API project responsible for defining all the objects shared by multiple functional areas. Most of these objects are custom events received and/or dispatched by several modules like AlbumEvent, PhotoEvent, SessionEvent, etc. Core functionality that doesn’t really belong to any one module in particular is present here as well, like FBCallTask – an asynchronous handler for all Facebook related calls. The API project also contains infrastructure components used by multiple views in different modules.
 
asabau_cg3_fb_shell
A Shell project representing the application starting point. It’s responsible for loading the required runtime shared libraries and modules. Global navigation, module loading and unloading is handled here.

This post is part of Facebook Photo Gallery.

Leave a Reply

Your email address will not be published. Required fields are marked *