Osoby które kupowały "ActionScript Developer's Guide to Robotlegs", wybierały także:

• Tablice informatyczne. Flash MX 2004 ActionScript 12,58 zÅ‚, (3,90 zÅ‚ -69%)
• Flash i Wallaby. Projektowanie animacji zgodnych z HTML5 24,69 zÅ‚, (7,90 zÅ‚ -68%)
• Flash i ActionScript. Aplikacje 3D od podstaw 97,23 zÅ‚, (54,45 zÅ‚ -44%)
• Adobe Flash CS5/CS5 PL Professional. Biblia 126,70 zÅ‚, (70,95 zÅ‚ -44%)
• ActionScript 3.0. Biblia 97,23 zÅ‚, (54,45 zÅ‚ -44%)

Spis treści

ActionScript Developer's Guide to Robotlegs. Building Flexible Rich Internet Applications eBook -- 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 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