Good bye Massive View Controller! Balazs Kovacs
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Good byeMassive View Controller!Balazs Kovacs
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)
Agenda
Supercharge 3
• History
• Problems / Requirements
• Our Solution
• Pros & Cons
• Tools
• Lessons learnt
History – MVC
Supercharge 4
• 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 morereadable, logical
History – MVVM
Supercharge 5
• Experimenting with Xamarin
• Cross platform MVVM (MvvmCross)
• Data binding
– Can be hard for custom attributes/views
History? – VIPER
Supercharge 6
✓ Good fit for large products
✓ Complete separation of concerns (Clean architecture)
✓ Good testability
✗ Bit too complex for projects with little business logic
Problems / Requirements
Supercharge 7
• 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
Our Solution – MVP
Supercharge 8
• Layers– View– ViewModel– DataPresenter– APIModel– Service
• Framework– UI elements– Network Communication– Navigation
• Dependency Injection
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)
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)
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)
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
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
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
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
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
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
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
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
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
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
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
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
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, EspressoMockrequests
Pros / Cons
Supercharge 25
Feature ?
Separated UI / Integration tasks +
Supports team scaling (parallelized work) +
Easy to understand (simple tech onboarding) +
Good testability +
Handle complex client-side logic -
Tools
Supercharge 26
• Build schemes– 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
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
• 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/
Related Documents
