Ставлю курсу твердую четверку.
Что понравилось:
1) понравились некоторые интересные технические тонкости, которые интересно было "пощупать" через реальный код + вариант реализации паттерна Outbox
2) примеры с VM-фабриками были тоже очень познавательными.
3) примеры с combine да, очень хорошие - в коммерческих приложениях это главная "рабочая лошадка" :)
Что не понравилось:
1) В паре мест автор дает идею и тут же отказывается от нее. Если идти по курсу последовательно, то в коде остаются ошибки, которые нужно исправлять самостоятельно.
Так, например, было в SyncWorker, где автор попала в тупик собственного подхода - отказа от DI + хранения основных data-классов приложения (репозиториев) в MainActivity.
Как мне кажется, курс смотрелся более выигрышно, если бы репозитории, БД и классы сетевого слоя хранились бы в отдельном Application-классе с ленивой инициализацией, а SyncWorker получал бы нужную ссылку через отдельный SyncWorkerFactory, например, так:
class SyncWorkerFactory(
private val repository: SyncRepository,
) : WorkerFactory() {
override fun createWorker(
appContext: Context,
workerClassName: String,
workerParameters: WorkerParameters
): ListenableWorker? {
return when (workerClassName) {
SyncWorker::class.java.name -> {
SyncWorker(appContext, workerParameters, repository)
}
else -> null
}
}
}
а Application-класс определили бы как Configuration.Provider и добавили бы туда код:
val syncRepository by lazy {
SyncRepository(
db = db,
api = api,
)
}
override val workManagerConfiguration: Configuration
get() = Configuration.Builder()
.setWorkerFactory(SyncWorkerFactory(syncRepository))
.build()
Ну и в целом, собирать конгломерат классов с ЖЦ уровня приложения внутри MainActivity - это не очень хороший пример. Учитывая, что курс могут проходить начинающие разработчики, я бы все-таки переработал код курса, чтобы плохие практики не перенимали ученики.
2) В проекте сделана не очень хорошая штука - классы распределяются по пакетам по типам, а не по функциональности.
Например, VM-ки - в отдельный пакет "viewModel", dao-классы - в DAO и т.д.
В крупных коммерческих приложениях так не делают никогда, потому что:
а) Код пишут несколько команд и за каждым пакетом закрепляется свой оунер. Все кодоунеры перечислены в классе CODOWNERS и на код-ревью при изменении кода, закрепленного за отдельной командой, бот будет "тегать" именно того человека, который имеет отношение к измененном пакету в проекте.
Если все VM-ки будут в одном пакете, начнется хаос - бот будет тегать всех подряд, включая людей из совсем других команд.
б) фича не всегда пишется "на века". Например, сегодня в приложку добавили таблицу "leaderboard", а завтра у менеджмента зачешется левая пятка и скажут, что фича не востребована пользователями и ее нужно выпилить. Конкретно в случае этого проекта весь код удаляемой фичи нужно будет собирать по разным пакетам и удалять. А если фича хранится в отдельном модуле или пакете, то удаление для остальных команд будет максимально простым - просто дропнули нужный каталог и все.
3) В коде в нескольких местах есть ошибки + нет импортов, что делает менее удобным добавление кода - приходится тратить дополнительное время на ненужную работу.
