Chapter 1 Robotlegs is a lightweight framework for ActionScript 3What does Robotlegs actually do?Do you need a framework at all?Less boilerplate code is a good thing...Chapter 2 The Robotlegs dream...80% of the problems can be solved with 20% of the APICoding for Robotlegs shouldn’t tie you to the frameworkRobotlegs aims to enable and not dictateMost AS3 applications benefit from the MVCS approachTesting, testing! (We test, and we make it easy for you to test)Some final things every Robotlegs cadet should knowChapter 3 Anatomy of a Robotlegs applicationJoel’s Personal KanbanLindz’s Mosaic Design ToolHow a Robotlegs application gets things doneGetting to grips with Robotlegs architectureUser stories as implemented in RobotlegsAll of this is possible because of the Robotlegs InjectorChapter 4 Automated Dependency InjectionSo, what exactly is Automated Dependency Injection?You already use Dependency InjectionThere are different ways to inject dependenciesAutomated DI gets around the need to ‘pass the parcel’, but keeps code flexibleHow does Robotlegs Injection work?Chapter 5 The Robotlegs context in actionProvide the context with a root-viewAsk it to run startup()—immediately or when you’re readyUse startup() to provide your injection rules, map your mediators to views and commands to eventsShutting down a ContextNow you have some ContextChapter 6 The CommandMap in actionA Command is a concise single-purpose controller objectCommands are triggered by eventsCommands can be any class with an ‘execute’ methodCommands should do their thing and then dieCommands rely on their injections to be usefulCommands know about the injector, command map, mediator map and context viewCommands can also dispatch eventsGreat command names pay dividendsUse helper classes for shared logicDetain and release when you need your command to hang aroundChapter 7 Models and services: How are they different?Models and Services usually extend ActorThey don’t listen, they only talkUse your API through a CommandDistinguishing Models from ServicesClasses that don’t dispatch events to the shared event dispatcher don’t need to extend ActorConfiguring servicesWorking with non-Actor models and services (including third party code)Model design tips for RobotlegsManaging the relationships between models and servicesChapter 8 Connecting views with MediatorsIntroducing the MediatorMapMediating your view componentsWhy can’t Mediators be injected into other objects?Working with complex composite viewsUsing the same mediator with more than one viewA good Mediator is just a mailmanChapter 9 Working with Robotlegs: Rich ExamplesFeature implementation walk-through: Mosaic ToolFeature implementation walk-through: Personal Kanban AppWait, I want more examples!Chapter 10 Testing your Robotlegs applicationYour test provides the injectionsTesting modelsTesting servicesTesting commandsTesting mediatorsChapter 11 Power-upsBootstraps can break up fat contextsThe ContextEvents help keep controlTag methods with [PostConstruct] to run them after injection is completeUse Signals between complex views and their mediatorsModular and multiple-context RobotlegsExtend Robotlegs with utilities and add-onsViewMap—injection for your viewsMediator map performanceAppendix Troubleshooting tipsProblem: Injection doesn’t occurProblem: Things work for a while and then mysteriously stopProblem: Event dispatch does not work as expectedProblem: Mediator isn’t running onRegisterProblem: Handlers in the mediator are running repeatedlyError: Injector missing rule for XWarning: Duplicate mapping in the injectorError: Call to a possibly undefined method XWhere to get more helpAppendix Swiftsuspenders: The power behind the Robotlegs InjectorWhat does Swiftsuspenders actually do?We think limited metadata is a good thingColophon