Download to read offline
Uploaded bySupercharge
Good bye Massive View Controller!
The document outlines the architecture shift from traditional MVC to MVP and other patterns in large-scale mobile applications developed by Supercharge, a strategic mobile product company. It discusses historical challenges faced with MVC, presents the adopted MVP framework for better separation of concerns and testability, and shares lessons learned regarding project requirements and documentation. The presentation also highlights tools used for testing and environment configuration, emphasizing the importance of adaptability in architecture choice.
![[PDF Download] Architecting ASP.NET Core Applications Carl-Hugo Marcotte full...](https://cdn.slidesharecdn.com/ss_thumbnails/14913-240731152559-9e08b611-thumbnail.jpg?width=640&height=640&fit=bounds)
Good bye Massive View Controller!
- 1. Good bye Massive ViewController! Balazs Kovacs
- 2. About Supercharge Supercharge 2 •Our mission is build strategic mobile products with a large impact (usually meaning 1+ million users) • ~40 people strong team • Technologies – Native iOS, Android, Windows Phone – Ruby/Rails, JS • Large-scale international products e.g. – Self-care app for Europe’s biggest telco company (multiple countries) – Mobile banking app for the 2nd largest bank in Indonesia (100+ million customers)
- 3. Agenda Supercharge 3 • History •Problems / Requirements • Our Solution • Pros & Cons • Tools • Lessons learnt
- 4. History – MVC Supercharge4 • Lots of logic in ViewController classes • View manipulation, UI interaction handling, network handling, local persistence in one layer • Bad testability :( • Separating data sources/delegates – Makes the classes smaller – Does not make the code more readable, logical
- 5. History – MVVM Supercharge5 • Experimenting with Xamarin • Cross platform MVVM (MvvmCross) • Data binding – Can be hard for custom attributes/views
- 6. History? – VIPER Supercharge6 ✓ Good fit for large products ✓ Complete separation of concerns (Clean architecture) ✓ Good testability ✗ Bit too complex for projects with little business logic
- 7. Problems / Requirements Supercharge7 • Large-scale applications – Many functions – 100+ screens • Relatively little business logic on client side • Large team – 6-10 people / platform • Hard deadlines • Complex backend systems – Integration is a tough nut
- 8. Our Solution –MVP Supercharge 8 • Layers – View – ViewModel – DataPresenter – APIModel – Service • Framework – UI elements – Network Communication – Navigation • Dependency Injection
- 9. Our Solution –Framework Supercharge 9 • UI elements – Branded elements (buttons, input fields, etc) – Form composition • Network Communication – HTTP/JSON requests – Serialization (APIModel) • Navigation – Standardized patterns (push, pop, modal, etc)
- 10. Our Solution –Framework Supercharge 10 • UI elements – Branded elements (buttons, input fields, etc) – Form composition • Network Communication – HTTP/JSON requests – Serialization (APIModel) • Navigation – Standardized patterns (push, pop, modal, etc)
- 11. Our Solution –Framework Supercharge 11 • UI elements – Branded elements (buttons, input fields, etc) – Form composition • Network Communication – HTTP/JSON requests – Serialization (APIModel) • Navigation – Standardized patterns (push, pop, modal, etc)
- 12. Our Solution –Layers Supercharge 12 • Service – Fetch/send APIModel objects • DataPresenter – Implement business logic – Transform APIModel objects into ViewModel objects • View – Multiple screens per function – Handle UI interactions
- 13. Our Solution –Layers Supercharge 13 • Service – Fetch/send APIModel objects • DataPresenter – Implement business logic – Transform APIModel objects into ViewModel objects • View – Multiple screens per function – Handle UI interactions
- 14. Our Solution –Layers Supercharge 14 • Service – Fetch/send APIModel objects • DataPresenter – Implement business logic – Transform APIModel objects into ViewModel objects • View – Multiple screens per function – Handle UI interactions
- 15. Our Solution –Workflow Supercharge 15 • Technical planning – DataPresenter interfaces and ViewModel classes – View composition – Service interfaces and APIModel classes • Building UI – Implement screens – Use mock Presenters! • Backend integration – Implement “real” Presenters
- 16. Our Solution –Workflow Supercharge 16 • Technical planning – DataPresenter interfaces and ViewModel classes – View composition – Service interfaces and APIModel classes • Building UI – Implement screens – Use mock Presenters! • Backend integration – Implement “real” Presenters
- 17. Our Solution –Workflow Supercharge 17 • Technical planning – DataPresenter interfaces and ViewModel classes – View composition – Service interfaces and APIModel classes • Building UI – Implement screens – Use mock Presenters! • Backend integration – Implement “real” Presenters
- 18. Our Solution –Workflow Supercharge 18 • Technical planning – DataPresenter interfaces and ViewModel classes – View composition – Service interfaces and APIModel classes • Building UI – Implement screens – Use mock Presenters! • Backend integration – Implement “real” Presenters
- 19. Our Solution –Workflow Supercharge 19 • Technical planning – DataPresenter interfaces and ViewModel classes – View composition – Service interfaces and APIModel classes • Building UI – Implement screens – Use mock Presenters! • Backend integration – Implement “real” Presenters
- 20. Our Solution –Workflow Supercharge 20 • Technical planning – DataPresenter interfaces and ViewModel classes – View composition – Service interfaces and APIModel classes • Building UI – Implement screens – Use mock Presenters! • Backend integration – Implement “real” Presenters MockDataPresenter MockDataPresenter MockDataPresenter
- 21. Our Solution –Workflow Supercharge 21 • Technical planning – DataPresenter interfaces and ViewModel classes – View composition – Service interfaces and APIModel classes • Building UI – Implement screens – Use mock Presenters! • Backend integration – Implement “real” Presenters
- 22. Our Solution –Testing Supercharge 22 • Unit/integration tests – Business logic, low level code – iOS: XCUnit, OCMock – Android: JUnit, Mockito • Acceptance tests – Testing UI and interactions – Mock on Presenter level, or Network level? – iOS: KIF, VCR – Android: RoboGuice, Espresso
- 23. Our Solution –Testing Supercharge 23 • Unit/integration tests – Business logic, low level code – iOS: XCUnit, OCMock – Android: JUnit, Mockito • Acceptance tests – Testing UI and interactions – Mock on Presenter level, or Network level? – iOS: KIF, VCR – Android: RoboGuice, Espresso MockDataPresenter MockDataPresenter MockDataPresenter
- 24. Our Solution –Testing Supercharge 24 • Unit/integration tests – Business logic, low level code – iOS: XCUnit, OCMock – Android: JUnit, Mockito • Acceptance tests – Testing UI and interactions – Mock on Presenter level, or Network level? – iOS: KIF, VCR – Android: RoboGuice, Espresso Mock requests
- 25. Pros / Cons Supercharge25 Feature ? Separated UI / Integration tasks + Supports team scaling (parallelized work) + Easy to understand (simple tech onboarding) + Good testability + Handle complex client-side logic -
- 26. Tools Supercharge 26 • Buildschemes – Centralized configuration for different environments (mock, staging production) – iOS: Build Schemes (not targets!) / Android: Gradle flavors • SCConfiguration / SCForceUpdater / SCComponentCollection – Environment-based configuration (available on GitHub) – Basic force update functionality (available on GitHub) – Management for horizontal/vertical layouts (soon to be open sourced) • Reactive programming – iOS: to be introduced – Android: RxJava is extensively used
- 27. Lessons learnt Supercharge 27 •Project requirements should determine the architecture, not the other way around • Always document your architectural planning • Do not compromise on testability • Feel free to experiment • Learn from your bad choices
- 28. Thank you, anyquestions? Balazs Kovacs Supercharge balazs.kovacs@supercharge.io // www.supercharge.io
- 29. • References – https://github.com/MvvmCross/MvvmCross –https://www.objc.io/issues/13-architecture/viper/ – http://typhoonframework.org/ – http://square.github.io/dagger/ – http://ocmock.org/ – https://github.com/kif-framework/KIF – https://github.com/roboguice/roboguice – https://google.github.io/android-testing-support- library/docs/espresso/ – https://bitbucket.org/martijnthe/nsurlconnectionvcr – https://github.com/team-supercharge/