Архитектура приложения построена с использованием Clean Architecture c разделением на три слоя (App, Data, Domain), Ui часть app слоя использует MVVM в взаимодействие с стандартными средствами Android архитектуры и Single Activity подход, данные методы реализации был выбраны поскольку многие элементы позволяют реализовать безопасное приложение с точки зрения жц и при работе с много поточностью которая в данном случае построена на kotlin корутинах при использование flow, вся работа с потоками происходит внутри ViewModel и не выходит за рамки его корутин scop’a.
- Kotlinx coroutines
- Retrofit 2
- Gson
- Room
- Android Material Library
- Lifecycle Extensions, ViewModel, LiveData
- Cicerone
- Epoxy
- Dagger 2
- Glide 4
- Event Bus
Поскольку проект реализуется на kotlin, то для работы с много поточностью были выбраны корутины, для добавления реактивности был использован flow.
Для работы с Rest Api применялся Retrofit ввиду того что на данный момент это один из простых и удобных инструментов который позволяет описать все запросы в виде интерфейса и поддерживает работы с корутинами, так же для парсинга данных и конвертации типов в Room используется Gson.
С целью кэширования постов используется Room опять же поскольку он без проблем позволяет составить модели таблиц в виде Сущностей и описать простые запросы на уровне интерфейса, ну и совместим с архитектурными компонентами Android.
При работе с навигацией используется Cicerone, данный подход был выбран поскольку навигация происходит в рамках кода приложения, что позволяет реализовать так называемую динамическую навигацию без явной связи с определенным сценарием, и так как сам Cicerone можно считать как обертку над Fragment Manager’om это позволяет задать без проблем кастомные анимации и прочие условия так если бы использовался fragment manager.
Для построения списка использовался Epoxy, единственное его преимущество в рамках данного приложения — это удобное построение без написание большого адаптера, и DiffUtil под каптом.
При работе с изображением использован Glide v4 который по сравнению с конкурентами не привязан к определенной View те можно использовать стандартную ImageView и реализует кеширование изображения под катом.
Для DI используется Dagger 2, здесь каких-либо явных причин на именно его использования нет, из каких-то объективных это возможность построения более гибкого графа по сравнению с иными di фреймворками и построение графа при компиляции.
EventBus использовался только для синхронизации состояния сохраненных постов между local и network лентой, что как по мне не является каким либо антипатерном и вполне можно использовать в рамках связывания фрагментов, активити итд без привязывания к жц приложения.