Nate on Tech

Day 3. Session 1. Joe Berkovitz talks about design patterns are mini-architectures, applicable to small, recurring problems. Frameworks are larger and instantiate an architecture and set of patterns.

Flex application goals:

Isolate presentation, state, actions, communication; Cope with unpredictability with client/server issues and UI interactions; Handle testability, logging, security, error handling; Prototype easily

By example – ReviewTube: a mashup web app of YouTube and a comments service on a separate server.

Here’s your standard MVC:

• Models – YouTube data, comments data
• Views – Video display, comments scrub, videos list
• Controllers – primary app logic, mock app logic

And just for fun, two more concepts:

• Services – video stream, available videos, comments
• Operations – asynchronous call that could succeed, fail, and sends status events

Easy to mockup any of these components, without depending on the external interfaces, such as finalized visual design, data feeds, data models (for the most part).

Application path for loading the video:

1) user enters tag and presses enter

2) view tells the controller to getVideosByTag() – returns model for list (note, with Cairngorm2, probably just use the static model)

3) controller tells comment service to loadVideos(model)

a. video query operation initiates, waits for response or failure

b. while waiting, fires status events as event (controller would be listening)

c. when data returns, populates collection

4) comment service populates the model with the returned data

5) Flex automatically fires ondata events for the view

MVC+SO:

Views reference controllers.

Controllers reference services, views, and models.

Models reference nothing – contain bindable data, and should always implement ICollectionView or IList.

Services reference nothing – communicate via events.

Operations reference nothing – fire events, and are sent data to populate

Tips:

• Use inheritance to separate view logic (actionscript) from layout information (MXML). The super class contains a bindable property, the MXML contains a component by the same ID.
• Childless MXML components – used to customize super class properties for simple re-use.
• Sometimes easier to replace a bindable property with a setter function – less code necessary.
• Never assume component properties will be defined in a specific order.
• Avoid too much abstraction – simplicity vs. agility

Tags: