Pull to refresh
15
0
Сергей Шустов @sshustoff

Android Development

Send message

Бэк обычно покрыт тестами и задокументирован, плюс любые изменения в апи делаются максимально осторожно без отламывания старой версии эндпоинта или с обратной совместимостью, а тут все это внутри клиента.

Кажется что в большом проекте такой подход очень даже может выстрелить ногу

Если оно идёт через сериализацию, то не приходится ли писать один и тот же класс 2 раза в котлине и дарте? И не будет потом проблем с поддержкой 2х вариантов класса? Есть какая-то валидация консистентности этих дубликатов во время компиляции?

А как данные передаются между flutter и kotlin кодом? Имхо самый интересный аспект, как получить данные в UI с этим подходом и как вызвать методы kotlin слоя.

У Гугла часто бывает печально со случаями отличными от туториалов, это не только Даггер и вьюмодели.

Тут не про прям любые данные. Сущность для которой сделали клик можно передать в соответствующем методе, а вот ид задачи на экране задачи или что-то ещё такое используемое по всей вьюмодели и при инициализации всякого внутри - уже сложнее.

Можно передать в метод, можно передать в lateinit поле. Но тогда при инициализации вьюмодели у нас этих данных нет и внутри они могут храниться или разрешая null или креша приложение при доступе до получения данных из фрагмента (lateinit).

И да и нет. Сама View Model не зависит напрямую и может быть вытащена в мультиплатформ, а уже на других платформах надо будет как-то иначе разбираться с тем как она сохраняется если там вообще это требует каких-то дополнительных действий. Где-то всегда будет необходимость склеивать логику с платформенные кодом, но так это можно оставить ближе к ui

Information

Rating
Does not participate
Location
Россия
Registered
Activity