Clean Architecture в Android для начинающих
Feb 17 · 7 min read
Даже до того, как я начал специализироваться на Android, меня, как разработчика, всегда восхищал хорошо структурированный, чистый и понятный в целом код.
“Задача архитектуры программного обеспечения — минимизация человеческих ресурсов, необходимых для создания и обслуживания требуемой системы”
Однако не всегда просто написать такой код, который легко тестировать и поддерживать, который облегчает всей команде совместную работу.
Теоретически обосновал достижение этих целей Robert Martin (он же Uncle Bob). Он написал три книги о применении «чистого» подхода при разработке программного обеспечения (ПО). Одна из этих книг называется «Чистая архитектура, профессиональное руководство по структуре и дизайну программного обеспечения (ПО )», она и явилась источником вдохновения при создании этой статьи.
Кто-то скажет, это так, но меня это не касается, ведь в моем приложении уже есть архитектура MVVM?
Что ж, возм о жно, Clean Architecture может показаться излишней в том случае, если вы работаете над простым проектом. Но как быть, если нужно разделить модули, протестировать их изолированно и помочь всей команде в работе над отдельными контейнерами кода? Подход Clean Architecture освобождает разработчиков от дотошного изучения программного кода, пытаясь понять функции и логику функционирования.
Немного теории
Вероятно, вы много раз видели эту послойную диаграмму. Правда, мне она не очень помогла понять, как преобразовать эти слои в подготовленном проекте Android. Но сначала разберемся с теорией и определениями:
· Сущности ( Entities): инкапсулируют наиболее важные правила функционирования корпоративного уровня. Сущности могут быть объектом с методами или набором из структур данных и функций.
· Сценарии использования ( Use cases): организуют поток данных к объектам и от них.
· Контроллеры, сетевые шлюзы, презентеры ( Controllers, Gateways, Presenters): все это набор адаптеров, которые наиболее удобным способом преобразуют данные из сценариев использования и формата объектов для передачи в верхний слой (обычно пользовательский интерфейс).
· UI, External Interfaces, DB, Web, Devices: самый внешний слой архитектуры, обычно состоящий из таких элементов, как пользовательские и внешние интерфейсы, базы данных и веб-фреймворки.
После прочтения этих определений я всегда оказывался в замешательстве и не был готов реализовать «чистый» подход в своих Android проектах.
Прагматичный подход
Типичный проект Android обычно требует разделения понятий между пользовательским интерфейсом, логикой функционирования и моделью данных. Поэтому, учитывая «теорию», я решил разделить свой проект на три модуля:
· Домен: содержит определения логики функционирования приложения, модели данных сервера, абстрактное определение репозиториев и определение сценариев использования. Это простой, чистый модуль kotlin (независимый от Android).
· Данные: содержит реализацию абстрактных определений доменного слоя. Может быть повторно использован любым приложением без модификаций. Он содержит репозитории и реализации источников данных, определение базы данных и ее DAO, определения сетевых API, некоторые средства преобразования для конвертации моделей сетевого API в модели базы данных и наоборот.
· Приложение (или слой представления): он зависит от Android и содержит фрагменты, модели представления, адаптеры, действия и т.д. Он также содержит указатель служб для управления зависимостями, но при желании вы можете использовать Hilt.
Практическая часть — небольшое приложение для книжного каталога
Чтобы применить на практике все эти “абстрактные” понятия, я разработал простое приложение, которое демонстрирует список книг, написанных дядей Бобом, и которое дает пользователям возможность помечать некоторые из них как “избранные”.
Модуль домена
Чтобы получить список книг, я использовал API Google книги. Это API возвращает список книг, отфильтрованных по параметру строки запроса:
В доменном слое мы определяем модель данных, сценарии использования и абстрактное определение репозитария книг. API возвращает список книг или томов с определенной информацией, такой как названия, авторы и ссылки на изображения.
data class Volume(val id: String, val volumeInfo: VolumeInfo)
Простая сущность класса данных:
Абстрактное определение репозитария книг
Сценарии использования “Get books”
Модуль домена
Чтобы получить список книг, я использовал API Google книги. Это API возвращает список книг, отфильтрованных по параметру строки запроса:
В доменном слое мы определяем модель данных, сценарии использования и абстрактное определение репозитария книг. API возвращает список книг или томов с определенной информацией, такой как названия, авторы и ссылки на изображения.
Простой объект (entity) класса данных:
data class Volume(val id: String, val volumeInfo: VolumeInfo)
Абстрактное определение репозитария книг:
Сценарии использования “Get books”:
Слой данных
Как уже отмечалось, слой данных должен реализовывать абстрактное определение слоя домена, поэтому нам нужно поместить в этот слой конкретную реализацию репозитория. Для этого мы можем определить два источника данных: «локальный» для обеспечения устойчивости и «удаленный» для извлечения данных из API.
Поскольку мы определили источник данных для управления постоянством (persistence), на этом уровне нам также необходимо определить базу данных (можно использовать Room) и ее объекты. Кроме того, рекомендуется создать несколько модулей (mappers) для сопоставления ответа API с соответствующим объектом базы данных. Помните, нам нужно, чтобы доменный слой был независим от слоя данных, поэтому мы не можем напрямую аннотировать объект доменного тома ( Volume ) с помощью аннотации @Entity room . Нам определенно нужен еще один класс BookEntity , и мы определим маппер (mapper) между Volume и BookEntity .
Слой презентации или приложения
В этом слое нам нужен фрагмент для отображения списка книг. Мы можем сохранить наш любимый подход MVVM. Модель представления принимает сценарии использования в своих конструкторах и вызывает соответствующий сценарий использования соответственно действиям пользователя (get books, bookmark, unbookmark).
Каждый сценариё использования вызывает соответствующий метод в репозитории:
Этот фрагмент только наблюдает за изменениями в модели представления и обнаруживает действия пользователя в пользовательском интерфейсе:
Теперь посмотрим, как мы выполнили связь между слоями:
Как видите, каждый слой обменивается данными только с ближними к нему, сохраняя независимость внутренних слоев от нижних. Таким образом, легче правильно определять тесты в каждом модуле, а разделение проблем поможет разработчикам совместно работать над различными модулями этого проекта.
Источник
Use case android kotlin
Kotlin Coroutines — Use Cases on Android
🎓 Learning Kotlin Coroutines for Android by example.
🚀 Sample implementations for real-world Android use cases.
🛠 Unit tests included!
This repository is intended to be a «Playground Project». You can quickly look up and play around with the different Coroutine Android implementations. In the playground package you can play around with Coroutines examples that run directly on the JVM.
Every use case is using its own Activity and JetPack ViewModel . The ViewModel s contain all the interesting Coroutine related code. Activities listen to LiveData events of the ViewModel and render received UiState s.
This project is using retrofit/okhttp together with a MockNetworkInterceptor . This lets you define how the API should behave. Everything can be configured: http status codes, response data and delays. Every use case defines a certain behaviour of the Mock API. The API has 2 endpoints. One returns the names of the most recent Android versions and the other one returns the features of a certain Android version.
Unit Tests exist for most use cases.
🍿️ Related Videos
- Kotlin Coroutines Fundamentals Playlist
- Kotlin Coroutines Exception Handling explained
✍️ Related blog posts
- 7 Common Mistakes you might be making when using Kotlin Coroutines
- Why exception handling with Kotlin Coroutines is so hard and how to successfully master it!
- Kotlin Coroutines exception handling cheat sheet
- Understanding Kotlin Coroutines with this mental model
- Do I need to call suspend functions of Retrofit and Room on a background thread?
- Comparing Kotlin Coroutines with Callbacks and RxJava
- How to run an expensive calculation with Kotlin Coroutines on the Android Main Thread without freezing the UI
Sign up to my newsletter to never miss a new blog post. I will publish new blog posts about Coroutines on a regular basis.
This project is the foundation of a comprehensive Online Course about Mastering Kotlin Coroutines for Android Development
📢 Sharing is Caring
If you like this project, please tell other developers about it! ❤️
If you like, you can follow me on Twitter @LukasLechnerDev.
1. Perform single network request
This use case performs a single network request to get the latest Android Versions and displays them on the screen.
2. Perform two sequential network requests
This use case performs two network requests sequentially. First it retrieves recent Android Versions and then it requests the features of the latest version.
There are also 2 alternative implementations included. One is using old-school callbacks. The other one uses RxJava. You can compare each implementation. If you compare all three implementations, it is really interesting to see, in my opinion, how simple the Coroutine-based version actually is.
3. Perform several network requests concurrently
Performs three network requests concurrently. It loads the feature information of the 3 most recent Android Versions. Additionally, an implementation that performs the requests sequentially is included. The UI shows how much time each implementation takes to load the data so you can see that the network requests in the concurrent version are actually performed in parallel. The included unit test is also interesting, as it shows how you can use virtual time to verify that the concurrent version really gets performed in parallel.
4. Perform variable amount of network requests
Demonstrates the simple usage of map() to perform a dynamic amount of network requests. At first, this use case performs a network request to load all Android versions. Then it performs a network request for each Android version to load its features. It contains an implementation that performs the network requests sequentially and another one that performs them concurrently.
5. Perform network request with timeout
This use case uses the suspending function withTimeout() from the coroutines-core library. It throws a TimeoutCancellationException if the timeout was exceeded. You can set the duration of the request in the UI and check the behaviour when the response time is bigger than the timeout.
General networking timeouts can also be configured in the okhttp client.
6. Retrying network requests
Demonstrates the usage of higher order functions together with coroutines. The higher order function retry() retries a certain suspending operation for a given amount of times. It uses an exponential backoff for retries, which means that the delay between retries increases exponentially. The behavior of the Mock API is defined in a way that it responses with 2 unsuccessful responses followed by a successful response.
Unit tests verify the amount of request that are performed in different scenarios. Furthermore they check if the exponential backoff is working properly by asserting the amount of elapsed virtual time.
7. Network requests with timeout and retry
Composes higher level functions retry() and withTimeout() . Demonstrates how simple and readable code written with Coroutines can be. The mock API first responds after the timeout and then returns an unsuccessful response. The third attempt is then successful.
Take a look at the included callback-based implementation to see how tricky this use case is to implement without Coroutines.
I also implemented the use case with RxJava.
8. Room and Coroutines
This example stores the response data of each network request in a Room database. This is essential for any «offline-first» app. If the View requests data, the ViewModel first checks if there is data available in the database. If so, this data is returned before performing a network request to get fresh data.
9. Debugging Coroutines
This is not really a use case, but I wanted to show how you can add additional debug information about the Coroutine that is currently running to your logs. It will add the Coroutine name next to the thread name when calling Thread.currentThread.name() This is done by enabling Coroutine Debug mode by setting the property kotlinx.coroutines.debug to true .
10. Offload expensive calculation to background thread
This use case calculates the factorial of a number. The calculation is performed on a background thread using the default Dispatcher.
Attention: This use case does not support cancellation! UseCase#11 fixes this!
In the respective unit test, we have to pass the testDispatcher to the ViewModel, so that the calculation is not performed on a background thread but on the main thread.
11. Cooperative cancellation
UseCase#10 has a problem. It is not able to prematurely cancel the calculation because it is not cooperative regarding cancellation. This leads to wasted device resources and memory leaks, as the calculation is not stopped and ViewModel is retained longer than necessary. This use case now fixes this issue. The UI now also has a «Cancel Calculation» Button. Note: Only the calculation can be cancelled prematurely but not the toString() conversion.
There are several ways to make your coroutines cooperative regarding cancellation: You can use either use isActive() , ensureActive() or yield() . More information about cancellation can be found here
12. Offload expensive calculation to several Coroutines
The factorial calculation here is not performed by a single coroutine, but by an amount of coroutines that can be defined in the UI. Each coroutine calculates the factorial of a sub-range.
13. Exception Handling
This use case demonstrates different ways of handling exceptions using try/catch and CoroutineExceptionHandler . It also demonstrates when you should to use supervisorScope<> : In situations when you don’t want a failing coroutine to cancel its sibling coroutines. In one implementation of this use case, the results of the successful responses are shown even tough one response wasn’t successful.
14. Continue Coroutine execution when the user leaves the screen
Usually, when the user leaves the screen, the ViewModel gets cleared and all the coroutines launched in viewModelScope get cancelled. Sometimes, however, we want a certain coroutine operation to be continued when the user leaves the screen. In this use case, the network request keeps running and the results still get inserted into the database cache when the user leaves the screen. This makes sense in real world application as we don’t want to cancel an already started background «cache sync».
You can test this behavior in the UI by clearing the database, then loading the Android version and instantly close the screen. You will see in LogCat that the response still gets executed and the result still gets stored. The respective unit test AndroidVersionRepositoryTest also verifies this behavior. Check out this blogpost for details of the implementation.
15. Using WorkManager with Coroutines
Demonstrates how you can use WorkManager together with Coroutines. When creating a subclass of CoroutineWorker instead of Worker , the doWork() function is now a suspend function which means that we can now call other suspend functions. In this example, we are sending an analytics request when the user enters the screen, which is a nice use case for using WorkManager.
16. Performance analysis of dispatchers, number of coroutines and yielding
This is an extension of use case #12 (Offload expensive calculation to several coroutines). Here it is possible to additionally define the dispatcher type you want the calculation to be performed on. Additionally, you can enable or disable the call to yield() during the calculation. A list of calculations is displayed on the bottom in order to be able to compare them in a convenient way.
17. Perform expensive calculation on Main Thread without freezing the UI
This example shows how you can perform an expensive calculation on the main thread in a non-blocking fashion. It uses yield() for every step in the calculation so that other work, like drawing the UI, can be performed on the main thread. It is more a «showcase» rather than a use case for a real application, because of performance reasons you should always perform expensive calculations on a background thread (See UseCase#10). See [this blog post] for more information!
You can play around and check the performance of different configurations!
I am currently learning Coroutines myself. So if you have any ideas for or improvements or other use cases, feel free to create a pull request or an issue.
Licensed under the Apache License, Version 2.0 (the «License»). You may obtain a copy of the License at
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an «AS IS» BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
You agree that all contributions to this repository, in the form of fixes, pull-requests, new examples etc. follow the above-mentioned license.
Источник
