Why use an application framework? Why choose PureMVC? The PureMVC meta pattern PureMVC cons Can we SCRUNM it?

1. PureMVC GUYA.NET

2. Why use an application framework? Bottom line - Help us to be more efficient, more dynamic, less error prone. Good for parallel development (multiple developers). Patterns force good design. Code for the future - Easier to make changes and update. Enhance performance. Faster for new team members to start along. GUYA.NET

3. Spaghetti? – No thanks!!! GUYA.NET

4. GUYA.NET

5. Image Credit GUYA.NET

6. Why choose PureMVC I like it :) Highly documented. Community - Been out there long enough to prove it strength and maturity. More approachable, easier to understand. Out of the box better support for modular applications. Not, so old and somewhat obsolete (cairngorm). Handle views better using mediators. Open sourced with a good license (CC). GUYA.NET

7. Why choose PureMVC, continues Platform/context independent - no need to worry about updating Flex versions. Will be much easier to support more platforms (e.g. Pure Flash (mobile), Ajax, WPF, etc’) Scalability – Cope with big applications. Flexibility – Easy to extend. Clean implementation – Hides the singletons, uses a main Façade. GUYA.NET

8. The PureMVC Meta Pattern MVC Singleton Command Mediator Observer Value Object GUYA.NET

9. GUYA.NET

10. Main Actors Model – Proxies hold the model VO’s, also take care of remote services. View – Mediators encapsulate unaware UI components. Controller – Commands, can be think of as encapsulated autonomous functionality untied to an owner. GUYA.NET

11. Notifications - Internal communication PureMVC uses notification (Similar to Flash Event). All actors can send and listen to notifications. sendNotification(name, body, type); Data can be sent along inside a notification’s body. GUYA.NET

12. Model - Proxy Encapsulate the data object. Interact with remote services. Provide an API to access the data and the proxy functionalities. Send notification to the rest of the system. e.g. DATA_HAS_CHANGED Can use delegates, helpful when many proxies use the same remote object. GUYA.NET

13. View – Mediators Mediators interact with the public API of the view components. A view component is any UI component regardless of its complexity. Should encapsulate as much of its own states and operations, and expose as simple as possible API. Sends and receives notifications to communicate with the rest of the application. Shouldn’t handle large amount of notifications. Should hold no complicated logic (Business logic belongs to commands) facade.removeMediator( this.getMediatorName() ); GUYA.NET

14. Controller - Commands Commands handle the business logic of the application. Commands are mapped to notifications and are never called directly. registerCommand( LOGIN, LoginCommand ); Coordinates the Model and View states. Used for complex actions and business logic, e.g. transactions. GUYA.NET

15. Communication best practice Mediator -> Proxy (can reference a proxy for data. One way coupling) Mediator -> Command -> Proxy (Better) (Proxies don’t handle notifications) Mediator -> Notification/Command -> Mediator Proxy -> Notification/Command -> Mediator Commands -> Mediator/Proxy (can interact with mediators and proxies). GUYA.NET

16. Demo GUYA.NET

17. Lets see some code GUYA.NET

18. PureMVC cons Platform/Context independent – Doesn’t utilize Flash/Flex capabilities. E.g. not using Flash’s events system – has it’s own notification system. Still uses a lot of singletons (Hidden in a easy to use façade). Not the best for unit testing. For max flexibility everything is typed as an Object – Lots of casting needs to be done. GUYA.NET

19. Can we SCRUM it? By nature the architecture encourage separation of concerns - Model, View and Controller. The layers are completely autonomous, e.g. the views are completely unconcerned about the rest of the app. Can be developed by different developers and be “tied” easily. Easier to separate stories into tasks since things are separated by default. In the end of the sprint we’ll have much more efficient code with less bugs. Will be much easier to debug in these final critical hours (Even with other people code). GUYA.NET

20. Implementation - Our main challenges Making changes and being dynamic is always more difficult. Especially when things are relatively working. A lot of code will be thrown and/or refactored. A lot of proprietary knowledge will be thrown, In favor of common best practices. GUYA.NET

21. More about performance Things will happen when it should and only when it should. E.g. setting a dataProvider only once instead of unneeded multiple times. We will be able to kill heavy UI components, and even unload modules at runtime. Currently we can't do it since unload/killing component isn't freeing their memory. Mostly because it's still referenced in multiple places of the application. GUYA.NET

22. Bonus – Flex PMD http://opensource.adobe.com/wiki/display/flexpmd/FlexPMD Flex Builder PMD tool: http://flashmattic.blogspot.com/2009/09/flexpmd-from-flex-builder.html GUYA.NET