The 3h workshop version of the 3d Advanced Architectures training (http://canonicalexamples.com/courses_android/#androidArch). I have delivered this one or the iOS counterpart in more than 20 cities of Europe and America. This is the latest version that shared in Minsk.
4. #AndroidArch
Agenda
★ Goals
★ Before Clean Architecture
★ Clean Architecture Concepts
★ Implementation rules
★ Example App: RealProgrammers
★ Implement 1st User Story
★ References
5. #AndroidArch
Full Version: 3d
★ MVX
• Learn
• Extract MVP
★ 1st User Story
• Use Case
• Presenter
• View
• Entity Gateway
• Initial connection
★ Connectors
• Memory
Management
• Reuse
★ 2nd user story: add
• Navigation: Modal
vs Push
• Command pattern
• Immutables
• Observation
★ 3rd user story: detail
• Identity
• Use case factories
• 2nd use case in the
same view
★ Other use cases: just
logic
★ Forward flow
synchronization
★ Dependency Injection
★ Asynchrony
• Async entity
gateway
• Other tasks
6. #AndroidArch
LIVE Online Training
★ 3 days (same weekday 3 continuous weeks)
★ 10 people max
★ Live coding shared via video conference
★ Chat running all the time
★ Complete repo with many commits and Tests> 95%
★ Additional exercises
★ Ask as much as you want!
14. – Martin Fowler
“Different people reading about MVC in
different places take different ideas from it and
describe these as 'MVC'. If this doesn't cause
enough confusion you then get the effect of
misunderstandings of MVC that develop
through a system of Chinese whispers.”
15. #AndroidArch
Tricky question
★ If [Model] + [View] + [Controller /
Presenter / View Model] = [TheApp]
★ How can Controller != Presenter != View
Model?
★ Responsibilities matter!
★ Other components (patterns) might be
involved.
16. #AndroidArch
The goal
★ Separation of responsibilities into roles. Is
it? Not historically. Other motivations.
Solving problem d’jour.
★ Now why?
• Testability
• Reusability
• Extensibility
17. #AndroidArch
MVC: The early days
★ Separated presentation: Model <->
Presentation (= V+C)
★ Observer originated from MVC, but
observing full object (properties = scalars)
★ Variations: Passive model, i.e. model cannot
send updates (for example HTTP)
18. #AndroidArch
Android’s MVC
★ View
• Only View subclasses
• Show information and handle
events to controller
• Fully reusable library of views.
Consistent L&F
★ Controller
• Listeners+Watchers+Adapters
control what’s displayed
• Receive the events and
converts them into calls to the
model
• Observe the model and update
what is displayed on the view
• Implement presentation logic
★ Model
• Implements domain
knowledge / business logic.
Provides data and commands
• Can be observed
• No references to the UI
•Flow synchronization vs
Observer synchronization
20. #AndroidArch
MVC: testability
★ The views are somebody else's (Google’s)
problem.
★ Model is easy to test.
★ Controller is huge & has dependencies on the
model and on the views => Complex to test.
★ Too many levels of abstraction, only a few
methods exposed.
★ Some stuff in activity that it is usually not tested.
30. #AndroidArch
Rules
★ We are going to develop one module at a
time
★ Follow the dependency rules
★ YAGNI
★ No early optimization applied
★ It is easy to add tests, but no TDD in 3h
OK??
32. #AndroidArch
Features
★ Add potential candidates (Name, email, and important skills)
★ Show list of programmers with relative interview date
★ Remove candidates from list
★ Edit the data of any candidate
★ Contact candidate by email
★ Sync between devices
★ Universal app (Fragments)
★ Eye candy
★ Android/Android Wear/Android TV/Google Glasses
★ Credits
33. #AndroidArch
MVP Features
★ Add potential candidates (Name, email, and important skills)
★ Show list of programmers with relative interview date
★ Remove candidates from list
★ Edit the data of any candidate
★ Contact candidate by email
★ Sync between devices
★ Universal app (Fragments)
★ Eye candy
★ Android/Android Wear/Android TV/Google Glasses
★ Credits
38. #AndroidArch
Interactor
★ Grab data from the entity gateway
★ Convert it to what is needed to be
presented
★ Pass the results to the presenter
★ Start by defining the interfaces
40. #AndroidArch
Presenter
★ Direction: only from interactor to view
★ Configure the (dumb) view with the data
provided to it
★ Create the interface for the view (Simplest
wins!)
42. #AndroidArch
View
★ Combination of Views + Activity
★ Make it dumb (passive), but useful
★ Tell the presenter about the relevant events
★ Keep them decoupled
44. #AndroidArch
Back to the Presenter
★ Implement responses to the user events.
★ Use the interactor
★ Add presentation logic to the presenter part
45. #AndroidArch
Presentation Logic
★ Date should be relative (“Today”, “1d ago”,
“2w ago”)
★ That means current date is a dependency
that we want to control for tests
★ Use lazy instantiation for the current date
47. #AndroidArch
Entity Gateway
★ Basic
★ Defer the decision of the persistence
framework for later.
★ Implement the minimum functionality in a
basic object.
★ Implications of the repository pattern.