ActionScript Developer's Guide to Robotlegs
Building Flexible Rich Internet Applications
1st Edition
Published on 8. August 2011
140 pages
978-1-4493-1584-9 (ISBN)
Description
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 Applicationsfast. 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
More details
Other editions
Additional editions
Book
09/2011
O'Reilly
€19.00
Shipment within 10-20 days
Content
- Intro
- Table of Contents
- 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
- Chapter 1. Robotlegs is a lightweight framework for 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...
- Chapter 2. The Robotlegs dream...
- 80% of the problems can be solved with 20% of the API
- Coding for Robotlegs shouldn't 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
- Chapter 3. Anatomy of a Robotlegs application
- Joel's Personal Kanban
- Lindz's 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
- Chapter 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 they're icky)
- You need to tell the compiler to include the injection metadata
- FlashBuilder/FlexBuilder solution
- Flash CS4/CS5 IDE Solution
- IntelliJ Solution
- Flex SDK Solution-command line compiling
- Flex SDK Solution-compiling 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
- Chapter 5. The Robotlegs context in action
- Provide the context with a root-view
- Ask it to run startup()-immediately or when you're 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
- Chapter 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
- Chapter 7. Models and services: How are they different?
- Models and Services usually extend Actor
- They don't listen, they only talk
- Use your API through a Command
- Distinguishing Models from Services
- Classes that don't dispatch events to the shared event dispatcher don't 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
- Chapter 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 can't 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.
- Chapter 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!
- Chapter 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
- Chapter 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
- ViewMap-injection for your views
- Mediator map performance
- Appendix A. Troubleshooting tips
- Problem: Injection doesn't 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 isn't 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
- Appendix B. Swiftsuspenders: The power behind the Robotlegs Injector
- What does Swiftsuspenders actually do?
- We think limited metadata is a good thing
