Maximizing Code Reuse Across Screens

MAXIMIZING CODE
REUSE ACROSS SCREENS
Flash Builder 4.5 and Flex SDK 4.5
(including mobile Flex)

www.jasonhanson.com/360flex

Your Presenter
• Jason Hanson
• twitter @jayfour000
• ﬂexfood.blogspot.com
• www.jasonhanson.com
• Building for Flash Platform since 1999
• Working with Hero SDK since Aug,
2010 (beta)

Stuff to check out if
you get bored

• http://www.jasonhanson.com/360ﬂex


• All photos © Michael Schoenewies
@atomic_playboy


So many screens
So little time
• Desktop
• Laptop
• Phone
• Tablet
• TV
• Car Dashboard
• Fridge, windows, clothing, coffee table

All Very Different
• OS
• Size, Shape
• User Interaction
• Pixel Density
• Passive vs Active © @atomic_playboy

Experience


LOCATION, Location,
location
• Take your business to your users
• Your business stays the same
• Your apps need to change based on how
the user interactions with the screen of
their choosing
• Your business should seamlessly ﬂow
between screens


Drink the Kool-Aid?


Flash Platform
Offers One Option
• Write core business code once
• Reuse on each new screen target
• Build custom views appropriate for
each screen target
• Modify core code as needed for
special cases


Code Reuse with
Flash Builder 4.5

Code Reuse with
Flash Builder 4.5
core
lib

Code Reuse with
Flash Builder 4.5
core
lib

Web

Code Reuse with
Flash Builder 4.5
core
lib

Web

AIR for
Desktop

Code Reuse with
Flash Builder 4.5
core
lib

Web

AIR for
Android
Desktop

Code Reuse with
Flash Builder 4.5
core
lib

iOS Web

AIR for
Android
Desktop

Code Reuse with
Flash Builder 4.5
core
lib

iOS Web

AIR for
Android AIR for *
Desktop

Code Reuse with
Flash Builder 4.5
core
lib

iOS view Web
lib

AIR for
Android AIR for *
Desktop

Code Reuse with
Flash Builder 4.5
core
lib

iOS view view Web
lib lib

AIR for
Android AIR for *
Desktop

Code Reuse with
Flash Builder 4.5
core test
lib runner

iOS view view Web
lib lib

AIR for
Android AIR for *
Desktop

core
lib core lib
• Business Logic
• .model
• .controller
• .presenter
• .service
• .event
• No view code

core
lib core lib
• Flex Library Project
• Remove “view” libs from Library path
• Keep framework.swc for data classes
like ArrayCollection and BindingUtils
• Keep rpc.swc for HTTPService and
AsyncToken


core
lib core lib

keep:
framework.swc
rpc.swc

remove view libraries


test
runner Test Runner
• Flex Project
• FlexUnit 4 built
into FlashBuilder
• You can build
out most of the
core lib with
only unit tests
• Mock services

Screen Targets
• Web (.swf)
• AIR (.air)
• AIR for Android (.apk)
• iOS (.ipa)
• AIR for BlackBerry Playbook (.bar)
• AIR for * (.***)


Your Projects Might
Look Like This


Tips for
AS3 Projects


Architecture
• MVC (with presenters) i es controller
e rt
r op
p

method
• Model re

calls
o

event
st

• View
• Presenter model presenter

event
• Controller

method
calls
• Passive view
view
view
view
view
view

presenter
Presenter
• Same basic concept as Presentation Model
• Separates business logic from view
• Views change more frequently then any
other part of the app
• Views for different screen targets may
have vastly different display code


presenter
Presenter
• Public methods to do ‘stuff’
• Contract exposed with interface
• Communicates by dispatching events
• Dispatches events to controller
• Dispatches events to views
• Never holds instance of views


presenter
Presenter
• Why Bother?
• Same presenter can be used for multiple
views in multiple screen target apps
• Code in presenters can be unit tested,
while code in views is often very hard to
test


controller
Controller
• Control messaging (Grand Central)
• Manage state
• Listen for events from presenters
• Make service calls
• Set properties on presenters
• Set properties on the models


model
Model
• Hold instances of top-level presenters
• Sparingly hold instances of data
shared between multiple presenters
• Singleton
• Easy to ‘inject
• Only place a singleton is used
• Not an IEventDispatcher

view
view
view
view
view View
• Never in core lib
• Screen speciﬁc display code
• Holds instance of presenter (interface)
• Makes function calls on presenter
• Listens to events on presenter
• Holds little or no data


view
view
view
view
view View


view
view
Screen
view
view
view Targets
• View code is “throw-away” code
• Resist the urge to over-engineer views
• Often faster to just rewrite view code
then it is to build conﬁgurable
components
• Screen speciﬁc view code


view
view
Screen
view
view
view Targets


Application State
• Application state per functional area
• Presenter for each application state
• Presenter to view ratio may not be 1:1
• Some views may reuse the same
presenter


Application State
• Presenter currentState property
• For MXML view bind the
presenter.currentState to the currentState
of the view
• Change state on the presenter changes
state on the view
• In most cases views and presenters do not
modify currentState, the controller does

Application State


Tip: No States as a
String-Based Contracts
• Bad idea in general
• Typos break apps at runtime :(
• Use enums or constants for state
names
• Spark state name property does not
support constants values. Must use a
string in this case.


State Enum


Spark States

User error failure point.
Strings not compile checked
against enum.


ViewNavigator
State Translator

• Mobile View-Based Applications use a
ViewNavigator
• Similar to a stack of cards
• pushView(viewClass:Class, ....)
• replaceView()
• popView(), popToFirstView()
• not state friendly by default

ViewNavigator
State Translator
• ViewNavigator methods require a
view class type
• State is held in the ‘core’ presenters
• Presenters have no knowledge of
screen-speciﬁc view classes
• Need to translate states to view
classes


ViewNavigator
State Translator


Let’s Look at
Some Code
• Show code
• Show apps running on devices
• Try not to break it


Where to go
From Here?
• Get Flash Builder 4.5
• Check out other talks this week for
more details on different parts of what
I covered today
• Go build something!


END
(almost)


Advert:
My Other Talk
• Deep Dive into Flex Mobile Item
Renderers
• Wed 10:50am - 12:00pm
• Snip from that preso on next slide


END


Intentional Left
Blank


• Extra Slides After This Point


Test Runner Project


Deploying


Maximizing Code Reuse Across Screens

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (6)

Similar to Maximizing Code Reuse Across Screens

Similar to Maximizing Code Reuse Across Screens (20)

More from Jason Hanson

More from Jason Hanson (6)

Recently uploaded

Recently uploaded (20)

Maximizing Code Reuse Across Screens