ОА
чтобы ты ответил так как он хочет, а не так как ты придумал
Size: a a a
2021 September 22
IS
прикольно, я просто вообще не понял тот метод что ты написал, как он поможет
L
Имхо вы делаете что-то странное.
Вью должна быть тупая, ее состояние кто-то должен всегда обновлять извне.
Я не имею ввиду случай интерактивного вью, типа чекбокса или EditText.
Вью должна быть тупая, ее состояние кто-то должен всегда обновлять извне.
Я не имею ввиду случай интерактивного вью, типа чекбокса или EditText.
ОА
тогда мне нечего тебе предложить
ℕ
конкретно с сахаром нет проблем. но я бы разделил на несколько строк
I
Привязывай данные через LiveData, она их отдаст только после достижения определенной готовности экрана
IS
все через LD и работает
IS
есть стейт вьюхи, ВМ вообще не зачем про него знать
I
Вот кстати к сожалению андроид так до сих пор и лезет иногда со своим savedState во вью, и отключить это проблематично(
L
ВМ хранит состояние и говорит вью, как себя показать.
IS
согласен, но тут есть большая кастомка, которая в зависимости от своего внутрненнего стейта как-то отображает переданнае вм данные
AS
L
android:saveEnabled="false
View.setSaveEnabled (boolean enabled)
?
View.setSaveEnabled (boolean enabled)
?
I
Тебе надо определиться с одним источником состояния. Ты сейчас пытаешься опереться на два разных независимых источника состояний
v
понял
I
Кстати да, хороший поинт. Можно даже воткнуть это в корне разметки и должно порезать все
L
Всё внутренне состояние какой угодно большой custom view должен кто-то контролировать снаружи.
В том смысле, что кто-то снаружи устанавливает свойства у вью, а оно это только исполняет.
В том смысле, что кто-то снаружи устанавливает свойства у вью, а оно это только исполняет.
I
Можно и наоборот делать без внешнего вмешательства с инкапсуляцией всего во вью, но это экзотический случай
IS
ну тут я просто напрямую работаю со вью и то что в ней происходит бизнес логике прям совсем не нужно
L
Да можно вообще как угодно делать, пока код компилируется и не падает 😁