Over the last year there has been a lot of buzz about Clean Architecture in the Android community, but what is Clean Architecture? How does it work? And should I be using it? Recently at Badoo we decided to rewrite our messenger component.   Over the years this core piece of functionality in our app has become large and unwieldy.  We wanted to take a fresh approach to try and prevent this from happening again.  We choose to use Clean Architecture to achieve our goal.   This talk intends to share our journey from theory to implementation in an application with over 100 million downloads.  By the end, you should not only understand what Clean Architecture is, but how to implement it, and whether you should.

1. Keeping it Clean:
Clean code, for dirty developers
- Rich King -
Senior Android Developer

2. 100+ million installs
190 countries
100K+ lines of code
185 Activities
23 Services

4. Architecture

5. Start of development
ActivitiesLoadersNetwork

6. Some time passes
Services
ActivitiesLoadersNetwork Global
Cache

7. And then…..
Services
ActivitiesEvent BusNetwork Global
Cache
GCM
Global
Listener
DB

9. Technical Debt
Time
Debt

10. So, what is Clean Architecture?

11. “ A GOOD ARCHITECTURE
EMPHASIZES THE USE-CASES
AND DECOUPLES THEM FROM
PERIPHERAL CONCERNS
— Robert C. Martin

12. Clean Architecture
• Coined by Robert C. Martin
• Combination of various ideas
- Hexagonal Architecture (a.k.a. Ports and Adapters)
- Onion Architecture
- Screaming Architecture
- Data, context and interaction paradigm
- Boundary, controller entity objects
- Single responsibility principle
https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html

13. Clean Architecture
Key points:
1. Use cases
2.Structure
3.Dependancies
4.Models
5.Testable

14. Use cases
• Use cases capture business rules
Send
Message
Bob Alice

15. What does it do?
• Structure should indicate what the application is, not how it
does it.

16. What does it do?
• Structure should indicate what the application is, not how it
does it.
com.myapp
activities
services
presenters
content providers
views

17. What does it do?
• Structure should indicate what the application is, not how it
does it.
chat
conversations
com.myapp

18. Dependencies
UI
Business Logic
Data
Infrastructure

19. Dependencies
Use Cases
PresentersU
I
H
TTP
D
B
C
ontrollers
Services
Dependencies

20. Inversion of Control
Class A Class B
Dependency

21. Inversion of Control
Class A Class B
Injected

22. Inversion of Control
Send
Message
Injected

23. Inversion of Control
Send
Message
Carrier
Pigeon
Injected

24. Inversion of Control
Send
Message
HTTP
Injected

25. Why different models?

26. Why different models?
Use Case Model
•message
•id
•from
Data Model
•message
•id
•from
•cacheTime
View Model
•message
•id
•from
•itemSpacing

27. Clean Architecture
Presenter
View
Gateway
Impl
Memory
Cache
Disk
Cache
Network
Gateway
<I>
Use Case
Entity
Entity
Entity

28. Clean Architecture
Gateway
Use Case
Entity
Entity
Entity
<I>

29. Clean Architecture
Presenter
View
Gateway
Impl
Memory
Cache
Disk
Cache
Network
Gateway
<I>
Use Case
Entity
Entity
Entity

30. Clean Architecture
Presenter
View
Model

31. Clean Architecture
Presenter
View
Gateway
Impl
Memory
Cache
Disk
Cache
Network
Gateway
<I>
Use Case
Entity
Entity
Entity

32. Clean Architecture
Gateway
Impl
Memory
Cache
Disk
Cache
Network

33. Clean Architecture
Presenter
View
Gateway
Impl
Memory
Cache
Disk
Cache
Network
Gateway
<I>
Use Case
Entity
Entity
Entity

34. Clean Architecture
List of
Messages
Open
Conversation
Presenter
View
Gateway
Impl
Memory
Cache
Disk
Cache
Network
Gateway
<I>
Use Case
Entity
Entity
Entity
Bob

35. Implementation Details

36. interface MessageGateway {
List<Message> get(String conversationId);
int send(String conversationId, String to, String from,
String message);
boolean delete(String messageId);
void subscribe(Callback callback);
}
Gateway

37. class GetMessages {
...
List<M> execute(conversationId) {
return mMessageGateway.get(conversationId);
}
}
Use cases

38. class SendMessage {
...
int execute(conversationId, ...) {
int result = mMessageGateway.send(...);
if(result == SUCCESS)
mConversationGateway.update(conversationId);
return result;
}
}
Use cases

39. class SendMessage {
...
int execute(conversationId, ...) {
int result = mMessageGateway.send(...);
if(result == SUCCESS)
mConversationGateway.update(conversationId);
return result;
}
}
Use cases

40. class SendMessage {
...
int execute(conversationId, ...) {
int result = mMessageGateway.send(...);
if(result == SUCCESS)
mConversationGateway.update(conversationId);
return result;
}
}
Use cases

41. class MessageScreenPresenter {
...
void onSendMessage(message) {
int result = mSendMessage.execute(...);
switch (result) {
case ERROR:
mView.displayError(...)
...
}
}
Presentation

42. MainThread

43. RxJava
• Simple to switch threads
• Transformations are convenient
• Comes with a cost
https://github.com/ReactiveX/RxJava

44. mExecutor.post(new Runnable() {
void run() {
// do something
mHandler.post(new Runnable() {
void run() {
// publish result
}
});
}
});
!RxJava

45. mExecutor.post(() -> {
// do something
mHandler.post(() -> {
// publish result
}
}
}
}
!RxJava with lambdas

46. doSomething()
.observeOn(AndroidSchedulers.mainThread())
.subscribe(result -> /* Handle Result */)
RxJava

47. Rx, Very Nice

48. interface MessageGateway {
Single<List<M>> get(...);
Single<Integer> send(...);
Single<Boolean> delete(...);
Observable<Update> subscribe(...);
}
Gateway

49. class GetMessages {
...
Single<List<M>> execute(conversationId) {
return mMessageRepo.get(conversationId);
}
}
Use cases

50. class SendMessage {
...
Single<Integer> execute(conversationId, ...) {
return mMessageGateway.send(…)
.doOnNext(r -> if(r == SUCCESS)
mConversationGateway.update(conversationId);)
}
}
Use cases

51. class MessageScreenPresenter {
...
void onStart() {
mSendMessage.execute(mConversationId)
.observeOn(AndroidSchedulers.mainThread())
.filter(result -> result == ERROR)
.subscribe(mView::displayError);
...
}
}
Presentation

52. class SomeGatewayImpl {
Single<Result> load(…) {
return loadFromMemory()
.flatMap(r -> r != null ?
Single.just(r) : loadFromDB());
}
}
Caching simplified

53. class SomeGatewayImpl {
Single<Result> load(…) {
return loadFromMemory()
.flatMap(r -> r != null ?
Single.just(r) : loadFromDB());
}
}
Caching simplified

54. class SomeGatewayImpl {
Single<Result> load(…) {
return loadFromMemory()
.flatMap(r -> r != null ?
Single.just(r) : loadFromDB());
}
}
Caching simplified

55. class SomeGatewayImpl {
Single<Result> load(…) {
return loadFromMemory()
.flatMap(r -> r != null ?
Single.just(r) : loadFromDB());
}
}
Caching simplified

56. class SomeGatewayImpl {
Single<Result> load(…) {
return loadFromMemory()
.flatMap(r -> r != null ?
Single.just(r) : loadFromDB());
}
}
Caching simplified

58. Was it worth it?
• Boilerplate
• Learning curve
• Testing
• Everything has a place
• Decisions can be postponed
• Implementations are replaceable

59. How can you do it?
• Start small
• Discuss and experiment
• Tech Talks
• Code reviews

61. Cheers!
github.com/badoo/Chateau
techblog.badoo.com
github.com/kingamajick
@kingamajick