@hitherejoe hitherejoe joebirch.co
Joe Birch - Android Engineer @ Buffer
Slide 3
Slide 3 text
@buffer buffer.com
Slide 4
Slide 4 text
Greenfield projects
Slide 5
Slide 5 text
No content
Slide 6
Slide 6 text
- High-level of technical debt
- Extremely tightly coupled concepts
- No unit or UI tests
- Difficult to know what is going on and where
No longer lean
Slide 7
Slide 7 text
- YOU know what is what
- YOU know where class X is
- YOU know where logic for Y is
- But what about along the line…
No longer lean
(for now)
(for now)
(for now)
Slide 8
Slide 8 text
25
50
75
100
Output
Debt
Slide 9
Slide 9 text
25
50
75
100
Output
Debt
Slide 10
Slide 10 text
For the sake of yours and future
developers sanity - have
empathy. Be mindful of the
consequences and think before
you craft.
Slide 11
Slide 11 text
Buffer for Android
Slide 12
Slide 12 text
No content
Slide 13
Slide 13 text
No content
Slide 14
Slide 14 text
No content
Slide 15
Slide 15 text
- Lack of architecture
- Bloated activities with multiple responsibilities
- Difficult to test
- Difficult to extend and maintain
- Duplication of concepts == no reuse
Slide 16
Slide 16 text
Moving to MVP
- Fear of changing too much
- Helped separate presentation logic
- DataManagers to house data operations
- Increased test coverage
Slide 17
Slide 17 text
No content
Slide 18
Slide 18 text
No content
Slide 19
Slide 19 text
Not enough.
- Bloated DataManager classes
- Future changes, offline - where?
- Presentation linked to specific data source
- No clear line between responsibilites
- Buffer is a big app. Data types, features, sources
Slide 20
Slide 20 text
Architecture
“The art of planning, designing and
constructing buildings”
Slide 21
Slide 21 text
Architecture
“The art of planning, designing and
constructing buildings concepts”
Slide 22
Slide 22 text
No content
Slide 23
Slide 23 text
No content
Slide 24
Slide 24 text
No content
Slide 25
Slide 25 text
No content
Slide 26
Slide 26 text
No content
Slide 27
Slide 27 text
Think outside of your team.
Slide 28
Slide 28 text
Clean Architecture
Slide 29
Slide 29 text
No content
Slide 30
Slide 30 text
Separation of Concerns
Slide 31
Slide 31 text
- Layers are independent of frameworks
- Code becomes more testable
- Inner layers independant of UI
- Inner layers independant of external parties
Separation of Concerns
- Bugs more isolated
Slide 32
Slide 32 text
No content
Slide 33
Slide 33 text
Layer Models
- Each layer has own Model classes
- Removes dependancy on external models
- Easily map with Mapper classes
Slide 34
Slide 34 text
ModelA
Mapper
Model
Mapper
Model
Slide 35
Slide 35 text
Enterprise Business Rules
- Application Business Objects (Entities)
- Unaffected by operational change
- Can create before touching any UI
Slide 36
Slide 36 text
public class TournamentModel {
public String id;
public String name;
@SerializedName("full_name")
public String status;
@SerializedName("date_start")
public String dateStart;
@SerializedName("date_end")
public String dateEnd;
public int size;
}
Slide 37
Slide 37 text
Application Business Rules
- Application specific business rules
- Uses Cases
- Affected by operational change
- Isolated from external concerns
Slide 38
Slide 38 text
public class GetSchedules extends UseCase {
private final SchedulesRepository schedulesRepository;
@Inject
public GetSchedules(SchedulesRepository schedulesRepository) {
this.schedulesRepository = schedulesRepository;
}
@Override
public Single buildUseCaseObservable() {
return schedulesRepository.getSchedules();
}
}
Slide 39
Slide 39 text
No content
Slide 40
Slide 40 text
Use Case
Interface
Interface Impl
Activity
Application
Business
Rules
Interface
Adapters
Slide 41
Slide 41 text
Interface Adapters
- Contains MVP architecture of our app
- Presenters contain ‘callbacks’
- Views define contract for implementation
- Mapper converts data from external form
Slide 42
Slide 42 text
public class UpdatesPresenter extends BasePresenter
implements SingleObserver> {
@Override
public void onSubscribe(Disposable d) {
…
}
@Override
public void onSuccess(List matches) {
…
}
@Override
public void onError(Throwable e) {
…
}
}
Layer Boundaries
- Communication via abstractions (interfaces)
- No direct name references in inner layers
- Instead, inner layer provides this interface
- aka, The Dependancy Inversion Principle
Slide 48
Slide 48 text
Not limited to these layers
Layer 1
Layer 2
Layer 3
Layer 4
Slide 49
Slide 49 text
Not limited to these layers
Layer 1
Layer 2
Layer 3
Slide 50
Slide 50 text
Not limited to these layers
Layer 1
Layer 2
Layer 3
Layer 4
Layer 5
Layer 6
Slide 51
Slide 51 text
Test Coverage
Slide 52
Slide 52 text
No content
Slide 53
Slide 53 text
Learnings
Slide 54
Slide 54 text
Advantages.
- High percentage of code coverage
- Incredibly easy to navigate package structure
- Easier to maintain
- Allows us to move faster
- Focused classes and test classes
Slide 55
Slide 55 text
- Seperation of concerns
- Define, Test, Stabilise before UI
- Futureproof implementations
- Clear discipline, good practice
- and more…
Slide 56
Slide 56 text
Disadvantages
- Adds initial overhead
- Takes time to get used to
- Can feel overkill for some tasks
- Difficult to make decisions
- Conversion of models between layers
Slide 57
Slide 57 text
Winston
Enterprise
Business
Rules
Application
Business
Rules
Interface
Adapters
Mobile
UI
TV
UI
Wear
UI
Frameworks &
Drivers
Slide 58
Slide 58 text
Winston
Enterprise
Business
Rules
Application
Business
Rules
Interface
Adapters
Mobile
UI
TV
UI
Wear
UI
Frameworks &
Drivers
@hitherejoe hitherejoe joebirch.co
Slide 59
Slide 59 text
Resources
https://overflow.buffer.com/2016/12/22/rebuild-
android-composer/
https://github.com/googlesamples/android-
architecture
Clean Architecture: A Craftsman's Guide to Software
Structure and Design (Robert C. Martin)