IceRock KMM "Делаем экран авторизации" #5 - замечания

[Alex009]

Адрес Codelab

Состав

• [x] Экран сплеша - просто иконка
• [x] Экран входа - по логину и паролю
• [x] Экран главный - просто текст “главная” и кнопка логаут

Флоу

• [ ] открываем приложение, видим сплешскрин, он нас направляет на экран входа (если в sharedpreferences/userdefaults нет токена), либо на главный экран (если токен есть). С главного можем разлогиниться и вернуться на вход.

Тест флоу

• [ ] Харкдод логина и пароля. Если не верный пароль вводим - ошибка. Если логин не верный - другая ошибка.

Используем

ViewModel, livedata, eventsDispatcher, multiplatform-settings, Napier, ViewBinding.

Подходы

• [ ] Репозиторий, навигация координатором и navigation component.
• [ ] Работа с multiplatform-settings оборачивается через класс KeyValueStorage чтобы были именованные свойства и не надо было ключи строковые в разных классах юзать.

Не забыть

• [ ] Не используем Fields, errors.
• [ ] Показываем лоадер при загрузке.
• [ ] Показываем ошибку алертом.
• [ ] Логируем с Napier.
• [ ] Указывать какие импорты нужно делать чтобы использовать классы новые.
• [ ] Указать в итогах ссылку на готовое состояние - на ветку в бойлерплейте где все готово.
• [ ] Не надо автоформатирование включать для маркдауна - лишние переносы строк ломают кодлабу.
• [ ] Делать для новых терминов ссылку на терминологию.
• [ ] исправить нестыковку - в кодлабе используется mvvm-viewbinding, а в самом бойлерплейте подключен mvvm-databinding - нужно поправить чтоб был viewbinding по умолчанию
• [ ] При упоминании eventsdisptacher первый раз - ссылку на терминологию сделать, где надо пояснение зафиксировать, ниже черновик:

он как то привязан к жизненному циклу активити/фрагмента?" Обычно в таких случаях используется SingleEventLiveData который завязан на lifecycleOwner что в свою очередь ограждает от получения событий когда экран не активен и их постдоставке при возврате на экран EventsDispatcher как раз является заменой SingleEventLiveData с четким интерфейсом взаимодействия. Жизненный цикл контролится точно также как и у лайвдат. Реализация

Чему научимся

Делать простой экран с вводом данных, асинхронной загрузкой и сохранением данных.

Шаги

1. Вводная
2. Делаем сплешскрин
   1. Показываем публичный интерфейс общего кода - вьюмодель с листенером
   2. Тут делаем вьюмодель
   3. Делаем роутинг на некоторый пустой экран авторизации
   4. Делаем роутинг на некоторый пустой экран главной
   5. Делаем репозиторий user - пишем там работу с сеттингс
3. Делаем сплеш на андроиде
4. Делаем сплеш на айосе
5. Делаем экран авторизации
   6. Показываем публичный интерфейс общего кода - вьюмодель, лайвдаты, листенер
   7. Тут делаем вьюмодель
   8. Делаем роутинг на главный
   9. Пишем в репозиторий user - сохранем в сетинг и запросы шлем
6. Делаем авторизацию и главный на андроиде
7. Делаем авторизацию и главный на айосе
8. Итоги

[Alex009]

В текущем тексте гайда есть недоработка:

есть код:

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

и вообще стоит этот экстеншен переименовать видимо :(

[Alex009]

от @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 а не в куче .

[kovalandrew]

Добавить в конце ссылку на итоговое рабочее состояние кодлабы

[Alex009]

Про 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 вот реализация

[Alex009]

1. делаем флоу следующий:
   1. вводная (что мы будем делать в этой кодлабе, какой результат будет получен - в идеале картинкой)
   2. делаем общий код (в начале коротко поясняем что будем щас делать, показываем целевой публичный интерфейс с тудухами которые будем в процессе убирать)
   3. делаем платформы (андроид, айос, тоже с пояснением что щас будет)
   4. можно повторить общий + платформы, если постепенная реализация идет (но не больше двух повторов)
   5. итоги (что мы узнали)
2. в каждой кодлабе при вводе нового термина (в пределах кодлабы) делаем ссылку на раздел терминологии - https://kmm.icerock.dev/docs/terminology а последующие упоминания уже без выделения и ссылок
3. не грузить в одной кодлабе сразу всеми актуальными подходами - отдельными кодлабами погружаем постепенно в наши подходы. например сначала делаем вьюмодель с лайвдатами и евентс диспатчером, а потом в другой кодлабе еще докидываем моко филды вместо чистыми лайвдатами и ерроры вместо евентс диспатчеров. также и с юнитами - начинаем просто с юнитов, потом уже отдельной кодлабой про стейт, отдельной про пагинацию
4. не юзать автоформатирование IDE - лишние переносы строк claat'ом криво принимаются
5. в статью "знакомство с проектом" добавить про SharedFactory / AuthFactory и на примере графов показать как это связано и как было (забрать с кодлабы авторизации). концепт фабрик описать в статье
6. про IBAction'ы и прочие нативные вещи подробнее пояснять, чтобы разработчики любой мобильной платформы смогли повторить это. Нужно чтобы проходя кодлабу разработчик понимал как общий код применяется к обеим платформам, чтобы понимал зачем так

Концепт приложения:

1. авторизация (логин, пароль, сплешскрин)
2. настройки - пуши (при выключенном состоянии показываем дополнительный юнит), смена пароля, логаут
3. экран списка категорий мест рядом со мной (без пагинации, но тянется с сервера)
4. экран списка мест рядом со мной по категории (с пагинацией)
5. экран смены пароля - тут филды связанные мжеду собой
6. делаем пуши
7. отображение на карте мест рядом со мной по выбранной категории
8. заливка медиа (фото с камеры или галереи)

https://developers.google.com/maps/documentation/places/web-service/supported_types

[kramlex]

-про IBAction'ы и прочие нативные вещи подробнее пояснять, чтобы разработчики любой мобильной платформы смогли повторить это. Нужно чтобы проходя кодлабу разработчик понимал как общий код применяется к обеим платформам, чтобы понимал зачем так -Добавить в статью про SharedFactory и на примере графов показать как это связано и как было. концепт фабрик описать в статье