In my talk for DevFestMN, I discuss how to choose a software architecture and why they matter.

1. Android w/ Intent
Acing Architecture
by Colin Lee (@colinmlee)

2. Who IS This Guy?
Lead Engineer: Firefox Fenix @ Mozilla
Past: Amazon, Flipgrid (Microsoft), Cray, Pearson
VUE, When I Work, Colin The Shots LLC
Twin Cities Kotlin User Group organizer
So you now know I have no life

3. What I'll Cover
Why it matters
Choosing an architecture
What the industry is doing
How we decided
What we chose
Making the architecture work

4. Good architecture makes the system easy to
understand, easy to develop, easy to maintain,
and easy to deploy.
The ultimate goal is to minimize the lifetime cost
of the system and to maximize programmer
productivity.
--Robert C. Martin
“
“

5. 1. Why it ma ers

6. If you're afraid to change something it is clearly
poorly designed.
--Martin Fowler
“
“

7. The Point of Architecture
is...?

8. Enterprise FizzBuzz!

9. Design patterns are a form of complexity.
Design patterns are a symptom your language is
broken.
--Jeff Atwood
“
“

10. The Point of Architecture
is...?

11. Change and Risk
Architecture exists to reduce the cost of changes
Software gets seriously complex
Imposing certain rules and structure can reduce
complexity
Reduced complexity prevents signi cant lost
resources from xing bugs and making changes

12. What should you look for?
Separation of concerns:
A good architecture will separate anything that
changes A LOT or which is hard to change
Simplicity:
Is it easy to read and understand for your use?

13. A library or framework is not
an architecture.

14. 2. Choosing an architecture

15. Spot the complexity
What is most likely to change?
What parts will you write and what is a black box?
What code sections hurt the most to change?

16. Mi gate the complexity
Isolate parts that:
change a lot
are hard to understand
hurt the most to change
Try to keep code together that changes together

17. 3. What the industry is doing

18. Model-View-Controller

19. Model-View-Presenter

20. Model-View-ViewModel

21. Model-View-Intent

22. View-Interactor-Presenter-
En ty-Router

23. It's all MV*

24. Corporate Architectures

25. Google Android Architecture
MV* probably closest to MVVM plus the Repository
pattern
Architecture Components are not architecture
some choices not ideal, but they're a good start

26. Airbnb's MvRx
pronounced "mavericks"; is a library that empowers
MVI-like architectures

27. Ne lix Componen za on
Architecture
separate UI elements into components which are
presented together and remixed into your layouts

28. Uber's Router-Interactor-
Builder
a tree-based architecture to structure an app for
many divergent use cases that does NOT revolve
around providing a view
it took more time to create than the McRib was gone

29. Square Reac ve Workflows
their spin on MVI which very few understand
the bulk of it has changed over the past year

30. 4. How we decided

31. Our Goals
1. Single responsbility
2. Easier testing
3. Readable code
4. Useful stack traces
5. Code reuse when desirable
6. Easy A/B layout experimentation

32. Our Wants
1. Unidirectional state ow
2. A/B test all the things! So Components?
3. Activities and Fragments should never be Views
4. Rich animations, so MotionLayouts FTW
5. Use engine and components as single source of
truth

33. 5. What we chose

34. "Ne lix" Component
Architecture
+
Localized MVI
https://github.com/mozilla-
mobile/fenix/wiki/Architecture-Decisions

35. Source Code:
https://github.com/mozilla-mobile/fenix
Look at the architecture folder.

36. 6. Making an architecture
work

37. 1. Seek Input
2. Explain Why
3. Document
4. Prototype
5. Make Changes

38. Summary:
Don't just copy the last conference
architecture talk you saw!

39. 01010111 01001111
QUESTIONS?
01001111 01010100