Size: a a a

Android Architecture

2020 July 29

VP

Vitaly Peryatin in Android Architecture
Igor
> Получается что поля дважды заполняются одними и теми же данными

а когда происходит первый и второй раз?
Первый раз поля заполняются системой при вводе данных (мы ничео для этого не делаем)
Второй раз поля заполняются при обновлении состояния
источник

AC

Arsen CeH9 in Android Architecture
вешай стейт обсерер до назначения слушателей на изменения (текст вочеров)
источник

I

Igor in Android Architecture
Vitaly Peryatin
Первый раз поля заполняются системой при вводе данных (мы ничео для этого не делаем)
Второй раз поля заполняются при обновлении состояния
ну по идеи первого раза (с системой) не должно вообще выть
в модель должны прилетать события о изменение текста и она уже будет решать что делать

в рамках текущего андроид это плохо реализуемо, а вот compose так и работает
источник

VP

Vitaly Peryatin in Android Architecture
Igor
ну по идеи первого раза (с системой) не должно вообще выть
в модель должны прилетать события о изменение текста и она уже будет решать что делать

в рамках текущего андроид это плохо реализуемо, а вот compose так и работает
То есть в Compose при вводе текста ничего не отображается, верно? До тех пор пока мы извне программно не обновим текст
источник

AC

Arsen CeH9 in Android Architecture
в композе нету "в" и "вне", есть стейт, на основе которого генерится отображение. Это в андроиде виджет - независимый компонент
источник

I

Igor in Android Architecture
Vitaly Peryatin
То есть в Compose при вводе текста ничего не отображается, верно? До тех пор пока мы извне программно не обновим текст
https://foso.github.io/Jetpack-Compose-Playground/cookbook/textfield_changes/

Вот есть TextField с двумя аргументами
- текст
- колбек о изменение

сохранять/обновлять надо самому снаружи
источник

AC

Arsen CeH9 in Android Architecture
сейчас система сама запоминает текст из edittext-ов и восстанавливает его при пересоздании фрагмента (вроде бы при условии, что у вью ид проставлен).  Чтобы не эмитить лишние изменения нужно вешать слушатели после первого считывания стейта. К примеру в лайвдате ,если значение есть, то оно сразу схавается в момент .observe()
источник

AC

Arsen CeH9 in Android Architecture
+ нужно избегать цикличных обновлений
источник

VP

Vitaly Peryatin in Android Architecture
Arsen CeH9
сейчас система сама запоминает текст из edittext-ов и восстанавливает его при пересоздании фрагмента (вроде бы при условии, что у вью ид проставлен).  Чтобы не эмитить лишние изменения нужно вешать слушатели после первого считывания стейта. К примеру в лайвдате ,если значение есть, то оно сразу схавается в момент .observe()
Да, это я понимаю
Но если у нас MVI, то у нас единый стейт на весь экран
Правильно ли что мы вешаем обзервер который обновляет весь стейт и изменяет весь экран при изменении одного значения в EditText?
источник

VP

Vitaly Peryatin in Android Architecture
В теории MVI красиво выглядел, а на практике дичь какая-то получается
источник

I

Igor in Android Architecture
Vitaly Peryatin
В теории MVI красиво выглядел, а на практике дичь какая-то получается
Ну для этого и придуманы positional memoization в композе и реконсиляция в реакте
В текущем ведре можно взять библиотечку https://github.com/inkremental/inkremental
источник

VP

Vitaly Peryatin in Android Architecture
Igor
Ну для этого и придуманы positional memoization в композе и реконсиляция в реакте
В текущем ведре можно взять библиотечку https://github.com/inkremental/inkremental
Спасибо
источник

AC

Arsen CeH9 in Android Architecture
эдиттекст получил символ от юзера -> уведомил слушатель -> мы обновили стейт -> он полетел в .observe -> эдит.setText    (цикл)

Пока композа нету я сохраняю во вью ссылку на последний стейт:
private var mLastConsumedState: MyState? = null

обновляю его в конце каждого .observe
очищаю в onDestroyView()

Благодаря этому могу дифать , сравнивая новый  и старый. примитивы обычным сравнением ==, а объекты референс чеками ===.
Это работает только потому, что стейт полностью иммутабельный.

п.с.  кешировать стейт нужно именно мембером класса (ссылкой), без всяких hashmap, т.к. референс может меняться при шаманстве сборщика мусора.

п.с. в РХ есть оператор .scan
источник

AD

Aleksey D. in Android Architecture
Arsen CeH9
эдиттекст получил символ от юзера -> уведомил слушатель -> мы обновили стейт -> он полетел в .observe -> эдит.setText    (цикл)

Пока композа нету я сохраняю во вью ссылку на последний стейт:
private var mLastConsumedState: MyState? = null

обновляю его в конце каждого .observe
очищаю в onDestroyView()

Благодаря этому могу дифать , сравнивая новый  и старый. примитивы обычным сравнением ==, а объекты референс чеками ===.
Это работает только потому, что стейт полностью иммутабельный.

п.с.  кешировать стейт нужно именно мембером класса (ссылкой), без всяких hashmap, т.к. референс может меняться при шаманстве сборщика мусора.

п.с. в РХ есть оператор .scan
референс будет меняться при любом обновлении стейта, т.к. живем с иммутабельным состоянием
источник

AC

Arsen CeH9 in Android Architecture
диффы полей, а не стейта целиком
источник

AC

Arsen CeH9 in Android Architecture
кста избегание хеша не столько из-за ссылок, сколько ради перфоманса, дефолтный хешкод ведь никто не будет юзать, тут скорее речь про высчитывание датакласовского хешкода на большом стейте
источник

AC

Arsen CeH9 in Android Architecture
а так просто рефчеком бахнул и все
источник

AC

Arsen CeH9 in Android Architecture
как-то так выглядит диф на список для ресайклера
источник

AC

Arsen CeH9 in Android Architecture
вроде нигде нет лоигческих дыр, пока все работает
источник

AC

Arsen CeH9 in Android Architecture
ждем композ офк, а то убого выглядит
источник