ActionScript Developer's Guide to Robotlegs. Building Flexible Rich Internet Applications (e-book)

ActionScript Developer's Guide to Robotlegs. Building Flexible Rich Internet Applications (e-book) - Opis

Robotlegs is a standout among the ActionScript 3 development frameworks available today. With it, Flash, Flex, and AIR developers can create well-architected, testable, and flexible Rich Internet Applications-fast. This concise guide shows you how the light footprint and focused scope of this open source framework not only solves your immediate coding problems, it helps you gain insight into AS3 architecture on a much deeper level.The authors provide a walkthrough of specific features in two applications they've written in Robotlegs, complete with code for each application as a whole. You'll learn how to achieve a balance of flexibility and consistency in your own projects.Solve 80% of your coding problems with 20% of the APIGain code-base flexibility with automated Dependency InjectionLearn the anatomy of a Robotlegs applicationUnderstand the relationships between models, services, control code, and views in the framework's MVCS architectureSee how the Robotlegs... approach facilitates Test Driven Development (TDD)Pick up practical methods for architecting Robotlegs solutionsGet expert insights to power-up your existing Robotlegs code Spis treści:
ActionScript Developers Guide to Robotlegs
SPECIAL OFFER: Upgrade this ebook with OReilly
A Note Regarding Supplemental Files
Preface
Robotlegs: Something a little bit special
Who this book is for
Who this book is not for
Conventions used in this book
Using code examples
Safari Books Online
How to contact us
Acknowledgments
1. Robotlegs is a lightweight framework for (...) więcej ActionScript 3
What does Robotlegs actually do?
Robotlegs is a communication-and-cooperation framework
Direct conversation
Passing messages
Robotlegs helps with direct conversations and message passing
Robotlegs makes use of three object-oriented architectural patterns
Do you need a framework at all?
Reasons to use a framework
Consistency
Common understanding brings easier collaboration
Peer-reviewed solutions
A well-tested skeleton
Less code to write
Reasons not to use a framework
Framework learning curve
Terminology confusion
Performance tradeoffs
Framework coupling
Black box code is hard to debug
Robotlegs aims to amp up the pros and minimize the cons
Less boilerplate code is a good thing...
2. The Robotlegs dream...
80% of the problems can be solved with 20% of the API
Coding for Robotlegs shouldnt tie you to the framework
Robotlegs aims to enable and not dictate
Most AS3 applications benefit from the MVCS approach
Testing, testing! (We test, and we make it easy for you to test)
Some final things every Robotlegs cadet should know
3. Anatomy of a Robotlegs application
Joels Personal Kanban
Lindzs Mosaic Design Tool
How a Robotlegs application gets things done
Architecture begins with Events and Commands
Getting to grips with Robotlegs architecture
The context is the heart of your Robotlegs application
Your models and services are Actors in your app
The MediatorMap provides a way to join your views to your app layer
Robotlegs mediators are bridges, not view controllers
The CommandMap makes things happen
The shared event dispatcher joins everything together
... and it goes a little something like this (event flow)
User stories as implemented in Robotlegs
Personal Kanban example: Moving a task from backlog to doing
Mosaic Design Tool example: Saving a design
The same but different
All of this is possible because of the Robotlegs Injector
4. Automated Dependency Injection
So, what exactly is Automated Dependency Injection?
A dependency is just a requirement to use another object
You can fulfil a dependency in three different ways
You already use Dependency Injection
There are different ways to inject dependencies
Statics and globals make code rigid, brittle, hard to test, and prone to memory leaks
Locator patterns push extra responsibilities on your classes
Automated DI gets around the need to pass the parcel, but keeps code flexible
How does Robotlegs Injection work?
Automated DI is a handshake
You can specify an injection point in three ways
And you also have to tell the injector what you would like it to do
Robotlegs has different types of injection
If you only want one instance, use mapSingleton
mapSingletonOf keeps your code coupled only to interfaces
What if my class has to be created elsewhere? (e.g. a factory)
Named rules let you create multiple rules for each class (but theyre icky)
You need to tell the compiler to include the injection metadata
FlashBuilder/FlexBuilder solution
Flash CS4/CS5 IDE Solution
IntelliJ Solution
Flex SDK Solutioncommand line compiling
Flex SDK Solutioncompiling with ant
Automated Injection Gotchas
If an object has an [Inject]ed dependency you have to create it using the Injector.
You can map injection rules at runtime, but beware of race conditions.
The injection point and rule have to be of exactly the same type
If you override a method that has an [Inject] tag, you need to add it in the subclass
5. The Robotlegs context in action
Provide the context with a root-view
Ask it to run startup()immediately or when youre ready
Use startup() to provide your injection rules, map your mediators to views and commands to events
Shutting down a Context
Now you have some Context
6. The CommandMap in action
A Command is a concise single-purpose controller object
Commands are triggered by events
Commands can be any class with an execute method
Commands should do their thing and then die
Commands rely on their injections to be useful
You can inject the event that triggered the command
Commands know about the injector, command map, mediator map and context view
Commands can also dispatch events
Great command names pay dividends
Use helper classes for shared logic
Detain and release when you need your command to hang around
7. Models and services: How are they different?
Models and Services usually extend Actor
They dont listen, they only talk
Use your API through a Command
Distinguishing Models from Services
Classes that dont dispatch events to the shared event dispatcher dont need to extend Actor
Configuring services
Configuring services using a command
Configuring services by injecting the configuration
Working with non-Actor models and services (including third party code)
Wrap them in an Actor
Use the command that acts upon them to dispatch the events
Model design tips for Robotlegs
Keep those responsibilities separated
Use strong-typed wrappers for collections
Never create mutually dependent models
Managing the relationships between models and services
8. Connecting views with Mediators
Introducing the MediatorMap
Wiring views with the MediatorMap
Mediating your view components
Mediators are created when your view hits the stage
Mediator Structure
Avoid logic in your Mediators
Do your wiring in onRegister()
Using the EventMap
Use the eventClass parameter to make mappings that are type safe
You can do manual clean-up in onRemove
Why cant Mediators be injected into other objects?
Working with complex composite views
Using the same mediator with more than one view
A good Mediator is just a mailman
Signs that you need another mediator
Never put view logic into the mediator.
9. Working with Robotlegs: Rich Examples
Feature implementation walk-through: Mosaic Tool
Challenge 1: Keeping things on a need-to-know basis
Challenge 2: Keeping the view snappy
Keeping the models in line with the visual design
The crucial Robotlegs mappings that tie it all together
The tile color update again, but this time with code
Feature implementation walk-through: Personal Kanban App
How new tasks are entered
The crucial Robotlegs mappings that make this sequence work
Adding a new task again, but this time with code
Wait, I want more examples!
10. Testing your Robotlegs application
Your test provides the injections
Testing models
Testing services
Testing commands
Testing mediators
Testing that an event dispatched by the view results in the correct event being dispatched on the shared event dispatcher
Testing that an event received on the shared event dispatcher results in an action on the view
11. Power-ups
Bootstraps can break up fat contexts
The ContextEvents help keep control
Tag methods with [PostConstruct] to run them after injection is complete
Use Signals between complex views and their mediators
Modular and multiple-context Robotlegs
ModuleEventDispatcher and child injectors make it work
Extend Robotlegs with utilities and add-ons
ViewMapinjection for your views
Mediator map performance
A. Troubleshooting tips
Problem: Injection doesnt occur
Broken injection point declaration
Metadata is being stripped by the compiler
Instantiating an object with injected dependencies using new
Injected properties are null in constructor
Problem: Things work for a while and then mysteriously stop
Problem: Event dispatch does not work as expected
Problem: Mediator isnt running onRegister
Make mediator mappings from the inside out
Problem: Handlers in the mediator are running repeatedly
Error: Injector missing rule for X
Missing injection mapping
Inconsistent injection mapping
Warning: Duplicate mapping in the injector
Error: Call to a possibly undefined method X
Where to get more help
B. Swiftsuspenders: The power behind the Robotlegs Injector
What does Swiftsuspenders actually do?
We think limited metadata is a good thing
About the Authors
Colophon
SPECIAL OFFER: Upgrade this ebook with OReilly mniej