Separation of Concerns in Clean Architecture on Android
•
18 gefällt mir•5,555 views
Presented at YOW! Connected 2015 by Kamal Kamal Mohamed & Ryan Hodgman As an Android developer, I want to deliver features without making compromises on code quality. Scenario 1 - Given I am dealing with 1000+ line activities, When I have to develop a complicated feature, Then I waste time orienting myself and fixing bugs. Scenario 2 - Given I have integrated a backend API directly into my app logic, When that API changes, Then I have to refactor large segments of unrelated logic in order to utilise the new API. Scenario 3 - Given I have cleanly architected my application, When business/presentation/backend logic changes, Then I can easily update the relevant code without breaking unrelated features! In this talk, two Android developers will present their take on what a cleanly architected app looks like and why it makes our lives easier. A well-defined separation of concerns has benefits not just for our sanity as developers, but also for the project workflow as it allows multiple developers to collaborate on a single feature with ease. We will be exploring how the domain-driven approach can improve code clarity, allow you to easily write tests, and provide a scalable infrastructure for you to quickly iterate on. Join us on our path of discovery as we discuss the advantages, drawbacks and implementation specifics in the context of a small sample project.
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie Separation of Concerns in Clean Architecture on Android
Ähnlich wie Separation of Concerns in Clean Architecture on Android (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (7)
Separation of Concerns in Clean Architecture on Android
- 1. A Separation of Concerns Kamal Kamal Mohamed Android Developer, //TODO Find Better Title @ Outware Mobile Ryan Hodgman Official Despiser of Utils Classes @ Outware Mobile Clean Architecture on Android 18/09/2015 - YOW Connected 2015
- 2. Why are we here? To share with you our journey in applying Clean Architecture to an Android project ...and get some valuable feedback
- 3. Premise Our own interpretation Under development Not a silver bullet Iterating on it on a day to day basis Best suited for medium-big projects Multiple possible implementations
- 5. What are our goals as developers? Easy to refactor on volatile projects Maintainable
- 6. What are our goals as developers? Easy to refactor on volatile projects Maintainable Be confident that the code is reliable Testable
- 7. What are our goals as developers? Easy to refactor on volatile projects Maintainable Be confident that the code is reliable Testable Can increase scope without requiring a rework Scalable
- 8. What are our goals as developers? Easy to refactor on volatile projects Maintainable Be confident that the code is reliable Testable Reduce the difficulty of future development efforts Readable Can increase scope without requiring a rework Scalable
- 10. What is Clean Architecture?
- 11. Robert Martin’s original depiction of Clean Architecture https://blog. 8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html
- 12. The Dependency Rule Source code dependencies can only point inwards
- 13. How many layers? (The answer is three)
- 14. Separation of Concerns Presentation Logic Defines how to display visual information to the user Examples: ● Organize screen layout ● Format text ● Enable user input
- 15. Separation of Concerns Business Logic Implements the business requirements of the application Examples: ● Verify user authorization ● Choose data to be displayed ● Determine if additional user input is required
- 16. Separation of Concerns Data Logic Stores and retrieves data to achieve the business requirements Examples: ● Make an API call ● Query a local database ● Access the local filesystem
- 18. Image Source: Lucasfilm Ltd. All Rights Reserved Architectural Diagram
- 19. Domain Layer
- 20. Domain Layer
- 21. Entity Represents a business object that concerns the application Least likely to change when shifting requirements
- 22. Responsibilities Entity Represents a business object that concerns the application Least likely to change when shifting requirements ● Model the relationships with real-world objects / concepts ● Encapsulate the properties required by the application’s business logic
- 23. Responsibilities Interactions Entity Represents a business object that concerns the application Least likely to change when shifting requirements ● Model the relationships with real-world objects / concepts ● Encapsulate the properties required by the application’s business logic ● May be used directly by all layers of the application ● Likely that they may be mapped from data sources or to presentable view models
- 24. Entity
- 27. Use Case Contains the business logic related to a specific use case Can be run and canceled
- 28. Responsibilities Use Case Contains the business logic related to a specific use case Can be run and canceled ● Execute a piece of business logic ● Define a Callback to provide results ● Inform the Callback of the result ● Interact with the data layer
- 29. Responsibilities Interactions Use Case Contains the business logic related to a specific use case Can be run and canceled ● Execute a piece of business logic ● Define a Callback to provide results ● Inform the Callback of the result ● Interact with the data layer Use Case Use Case Callback Repository Callback Notifies Uses Repository Implements
- 30. Use Case
- 31. Use Case One or more Repository objects
- 32. Use Case May be run and cancelled
- 33. Use Case Contains business logic
- 35. Repository Asynchronous interface to abstract data access to a specific set of data from the data layer
- 36. Responsibilities Repository Asynchronous interface to abstract data access to a specific set of data from the data layer ● Provide methods to store and retrieve data of a specific type ● Define Callback interfaces to return the results of each operation
- 37. Responsibilities Interactions Repository Asynchronous interface to abstract data access to a specific set of data from the data layer ● Provide methods to store and retrieve data of a specific type ● Define Callback interfaces to return the results of each operation Repository Data Manager Use Case ImplementsUses
- 38. Repository
- 41. A Brief Note on Test-Driven-Development
- 45. Presenter Implements presentation logic by directing UI changes and handling user input
- 46. Responsibilities Presenter Implements presentation logic by directing UI changes and handling user input ● Direct UI changes ● Handle user triggered UI events ● Create and trigger Use Case objects ● Define a View Surface interface
- 47. Responsibilities Interactions Presenter Implements presentation logic by directing UI changes and handling user input ● Direct UI changes ● Handle user triggered UI events ● Create and trigger Use Case objects ● Define a View Surface interface Presenter View Surface Use Case Callback Uses Triggers Use Case Implements
- 48. Presenter
- 49. Presenter Systems Surfaces and Use Cases
- 52. View Surface Abstracts away the implementation of the UI logic, and is typically implemented by a View, Activity or Fragment
- 53. Responsibilities View Surface Abstracts away the implementation of the UI logic, and is typically implemented by a View, Activity or Fragment ● Screen layout ● Animations / transitions ● Propagate UI events to the Presenter ● Navigation
- 54. Responsibilities Interactions View Surface Abstracts away the implementation of the UI logic, and is typically implemented by a View, Activity or Fragment ● Screen layout ● Animations / transitions ● Propagate UI events to the Presenter ● Navigation Activity Presenter Presenter View Surface InformsImplements
- 55. View Surface
- 59. System Surface Abstracts away the implementation of various system functionalities
- 60. Responsibilities System Surface Abstracts away the implementation of various system functionalities ● Provide functionality specific to the OS / device ● Gracefully fail in the event of missing functionality
- 61. Responsibilities Interactions System Surface Abstracts away the implementation of various system functionalities ● Provide functionality specific to the OS / device ● Gracefully fail in the event of missing functionality System Surface Used by Presenter
- 62. System Surface
- 63. System Surface Android system dependencies
- 65. Data Layer
- 66. Data Layer
- 67. Data Manager Implements a single Repository interface to handle all the data sources required for a specific set of data
- 68. Responsibilities Data Manager Implements a single Repository interface to handle all the data sources required for a specific set of data ● Provide access to a specific set of data ● Make request on a data source in the form of a Client ● Handle a cache when required
- 69. Responsibilities Interactions Data Manager Implements a single Repository interface to handle all the data sources required for a specific set of data ● Provide access to a specific set of data ● Make request on a data source in the form of a Client ● Handle a cache when required Data Manager Repository Callback Repository NotifiesImplements Client Uses
- 70. Client Encapsulates a particular source of data and exposes an abstracted interface to the Data Managers
- 71. Responsibilities Client Encapsulates a particular source of data and exposes an abstracted interface to the Data Managers ● Make Database queries ● Manage an API connection ● Access Local Storage ● Map data results to domain Entities
- 72. Responsibilities Interactions Client Encapsulates a particular source of data and exposes an abstracted interface to the Data Managers ● Make Database queries ● Manage an API connection ● Access Local Storage ● Map data results to domain Entities Client Data Manager Used by Mapper Uses Handles Data Source
- 73. Mapper Converts a data object (API or DB response) to a domain Entity
- 74. Responsibilities Mapper Converts a data object (API or DB response) to a domain Entity ● Transform data into domain-convenient Entities
- 75. Responsibilities Interactions Mapper Converts a data object (API or DB response) to a domain Entity ● Transform data into domain-convenient Entities Mapper Data Object Entity
- 76. Conclusions
- 77. Pros Workflow improvements Code readability Testability No more 1000+ line Activity classes Isolated business logic Possibility to work on separate layers in parallel
- 78. Cons Hierarchy implementation Developer onboarding Interfaces Increased ramp-up time for new developers Interfaces, interfaces, ... Implementing a feature requires working across all of the layers
- 79. Further thoughts Dagger 2! Can help a lot with keeping the layers clean Dependency injection
- 80. Further thoughts Dagger 2! Can help a lot with keeping the layers clean Dependency injection Where should we split tasks onto a worker thread? Thread management
- 81. Further thoughts Dagger 2! Can help a lot with keeping the layers clean Dependency injection Where should we split tasks onto a worker thread? Thread management RxJava! Helps to reduce callbacks and make flows clearer Functional programming
- 82. Further thoughts Dagger 2! Can help a lot with keeping the layers clean Dependency injection Where should we split tasks onto a worker thread? Thread management RxJava! Helps to reduce callbacks and make flows clearer Functional programming May be useful to model a stateful user flow through the application User narratives
- 83. Next thing you can do! Consider the separation between data, domain, and presentation logic in one of your projects
- 84. References The Clean Architecture [Uncle Bob] https://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html Architecting Android…The clean way? [Fernando Cejas] http://fernandocejas.com/2014/09/03/architecting-android-the-clean-way/ Sample Project [Ryan and Kamal] https://github.com/outware-mobile/android-clean-architecture
- 85. Contact details Kamal Kamal Mohamed kamal.kamalmohamed@outware.com.au Ryan Hodgman ryan.hodgman@outware.com.au