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

Thank you, any questions?

Balazs KovacsSupercharge

balazs.kovacs@supercharge.io // www.supercharge.io

• 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/