В данном случае получается доступ к полю "mListener" у объекта OnPropertyChangedCallback. Это поле используется в DataBinding'е, так что вряд ли будет выпилено ProGuard'om. Но если и перестраховаться, то придется добавить одно правило только — на этот класс конкретный или просто на все классы датабайндинга
<android.support.constraint.ConstraintLayout
xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res-auto"
android:layout_width="match_parent"
android:layout_height="match_parent">
<!-- тут еще можно добавить bias=0, если элементы по левому краю должны быть выровнены -->
<ImageView
app:layout_constraintHorizontal_chainStyle="packed"
android:id="@+id/logo"
android:layout_width="wrap_content"
android:layout_height="0dp"
app:layout_constraintHeight_default="wrap"
app:layout_constraintBottom_toBottomOf="parent"
app:layout_constraintLeft_toLeftOf="parent"
app:layout_constraintRight_toLeftOf="@+id/texts"
app:layout_constraintTop_toTopOf="parent"
android:src="@drawable/logo"/>
<LinearLayout
android:id="@+id/texts"
android:layout_width="wrap_content"
android:layout_height="0dp"
android:orientation="vertical"
app:layout_constraintBottom_toBottomOf="parent"
app:layout_constraintHeight_default="wrap"
app:layout_constraintLeft_toRightOf="@+id/logo"
app:layout_constraintRight_toRightOf="parent"
app:layout_constraintTop_toTopOf="parent">
<TextView
android:id="@+id/count"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="COUNT"/>
<TextView
android:id="@+id/price"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="PRICE"/>
</LinearLayout>
</android.support.constraint.ConstraintLayout>
Это ваш модифицированный вариант — обе вьюхи по вертикали привязываются к верхним сторонам констрейнта и им ставится высота match_constraint_wrap. По умолчанию bias=0.5, так что они отцентрируются по вертикали.
Если попробовать избавиться от LinearLayout'a, то, к сожалению, можно напороться на багу
Интересно. Пользуюсь похожим подходом последние года 1.5, основные проблемы возникали именно с правильным хранением/изменением состояния и с навигацией.
Насчет состояния — для экранов храню его в saveState, но, по-хорошему, его нельзя изменять после onSaveInstanceState, так что надо отписываться в правильных местах, грубо говоря.
Насчет навигации, если делать на фрагментах/вьюхах — тоже нельзя ей пользоваться после onSaveInstanceState, иначе ее состояние не сохранится. Если на активити, то связать между собой 2 активити будет проблематично, если одна активити меняет состояние PM другой активити.
В двух словах не ответите, как примерно решаете такие проблемы?
Очевидные баги самого ConstraintLayout большинство пофикшены, я еще в октябре с ним разбирался — было очень много багов, сейчас явных не замечал. Во всяких странных кейсах типа «привязать view с внешней стороны контейнера, а к ней привязать другую view» скорее всего будут проблемы)
При работе с ConstraintSet точно есть баги еще. Например, изменить веса у меня нормально не получилось в цепи через него.
Насчет производительности — это отдельная тема, тут надо исходники смотреть подробно.
К примеру, я точно знаю, что если view сама вызвала requestLayout (например, у нее стояла ширина any_size и был изменен текст), то ConstraintLayout полностью перестроит граф зависимостей, а это может занимать много времени. Это из кейсов изменения графа в рантайме.
Другой тип кейсов — если сам граф зависимостей будет сложный, то расчет размеров может занимать много времени. Я подозреваю, что такое часто получается, если связывать горизонтальные и вертикальные зависимости (например, через dimensionRation).
В общем, я бы не стал просто брать рядом LinearLayout и ConstraintLayout, смотреть, сколько занимает onMeasure+onLayout и делать из этого какие-то выводы)
Все так, но раньше не было и этого
В данном случае получается доступ к полю "mListener" у объекта OnPropertyChangedCallback. Это поле используется в DataBinding'е, так что вряд ли будет выпилено ProGuard'om. Но если и перестраховаться, то придется добавить одно правило только — на этот класс конкретный или просто на все классы датабайндинга
да, WPF изначально под MVVM проектировался, а тут скорее попытка воспроизвести что-то похожее и привести к этому
Хотя про багу это я погорячился — это просто очень крутое не очевидное поведение)
Это ваш модифицированный вариант — обе вьюхи по вертикали привязываются к верхним сторонам констрейнта и им ставится высота
match_constraint_wrap
. По умолчанию bias=0.5, так что они отцентрируются по вертикали.Если попробовать избавиться от LinearLayout'a, то, к сожалению, можно напороться на багу
Насчет состояния — для экранов храню его в saveState, но, по-хорошему, его нельзя изменять после onSaveInstanceState, так что надо отписываться в правильных местах, грубо говоря.
Насчет навигации, если делать на фрагментах/вьюхах — тоже нельзя ей пользоваться после onSaveInstanceState, иначе ее состояние не сохранится. Если на активити, то связать между собой 2 активити будет проблематично, если одна активити меняет состояние PM другой активити.
В двух словах не ответите, как примерно решаете такие проблемы?
При работе с ConstraintSet точно есть баги еще. Например, изменить веса у меня нормально не получилось в цепи через него.
Насчет производительности — это отдельная тема, тут надо исходники смотреть подробно.
К примеру, я точно знаю, что если view сама вызвала requestLayout (например, у нее стояла ширина any_size и был изменен текст), то ConstraintLayout полностью перестроит граф зависимостей, а это может занимать много времени. Это из кейсов изменения графа в рантайме.
Другой тип кейсов — если сам граф зависимостей будет сложный, то расчет размеров может занимать много времени. Я подозреваю, что такое часто получается, если связывать горизонтальные и вертикальные зависимости (например, через dimensionRation).
В общем, я бы не стал просто брать рядом LinearLayout и ConstraintLayout, смотреть, сколько занимает onMeasure+onLayout и делать из этого какие-то выводы)