Open Alex009 opened 3 years ago
В текущем тексте гайда есть недоработка:
есть код:
val _isLoading = MutableLiveData<Boolean>(false)
val isLoading: LiveData<Boolean> = _isLoading.readOnly()
val isButtonEnabled: LiveData<Boolean> = listOf(
loginValidationError.map { it == null },
passwordValidationError.map { it == null },
isLoading.map { it.not() }
).all(true)
но предоставлен в гайде без импортов, из-за чего при написании проходящий путается и вместо dev.icerock.moko.mvvm.livedata.all
использует all
от коллекций котлина. Нужно пометить что тут нужен импорт
import dev.icerock.moko.mvvm.livedata.all
и вообще стоит этот экстеншен переименовать видимо :(
от @FelixFalkovsky
Пишем ViewModel
Очень сложно сориентироваться за мыслью автора и того что происходит. Удобнее было бы разбить на этапы как это было сделано в разделе "Разворачивание проекта" . И хотелось бы прям с заведения папок для фичи , что бы построить цепочки логики действий на проекте.
Так же полноценные скриншоты .
Пишем логику для AuthViewModel
сначала добавляем Import
потом заводим переменные для полей и уж потом liveData
не показано где и как должен быть создан class Validation
далее после того как вынесли в отдельный класс Validation, в AuthViewModel добавляем import org.example.library.feature.auth.model.Validation и не делать их приватными
для следующего шага нам нужен эти импорты import dev.icerock.moko.mvvm.livedata.all import dev.icerock.moko.mvvm.livedata.*
для следующего шага нужен import kotlinx.coroutines.launch
не показано создание где и как создается AuthRepository! P.S - видел AuthRepository в папках id и mode иl т.д что не есть хорошо. Далее после создания добавляем import org.example.library.feature.auth.model.AuthRepository private val repository: AuthRepository
не мало важный момент разделять импорты import dev.icerock эти отдельно от этих import org.example а не в куче .
Добавить в конце ссылку на итоговое рабочее состояние кодлабы
Про eventsDispatcher отразить:
про EventsDispatcher вопрос: он как то привязан к ЖЦ активити/фрагмента? Обычно в таких случаях используется SingleEventLiveData который завязан на lifecycleOwner что в свою очередь ограждает от получения событий когда экран не активен и их постдоставке при возврате на экран
EventsDispatcher как раз является заменой SingleEventLiveData с четким интерфейсом взаимодействия. жизненный цикл контролится точно также как и у лайвдат. https://github.com/icerockdev/moko-mvvm/blob/master/mvvm-core/src/androidMain/kotlin/dev/icerock/moko/mvvm/dispatcher/EventsDispatcher.kt#L34 вот реализация
Концепт приложения:
https://developers.google.com/maps/documentation/places/web-service/supported_types
-про IBAction'ы и прочие нативные вещи подробнее пояснять, чтобы разработчики любой мобильной платформы смогли повторить это. Нужно чтобы проходя кодлабу разработчик понимал как общий код применяется к обеим платформам, чтобы понимал зачем так -Добавить в статью про SharedFactory и на примере графов показать как это связано и как было. концепт фабрик описать в статье
Адрес Codelab
Состав
Флоу
Тест флоу
Используем
ViewModel, livedata, eventsDispatcher, multiplatform-settings, Napier, ViewBinding.
Подходы
Не забыть
Чему научимся
Делать простой экран с вводом данных, асинхронной загрузкой и сохранением данных.
Шаги