L
а как это касается контролов?
Ну я так понял, что пришлось переписать bindTo именно из-за этого
Size: a a a
2019 April 07
DG
Как решили проблему того, что вьюшка заново рендерится при повторном бинде после каждого onResume?
Есть идеи как это сделать без расширения границ биндинга до onCreateView/onDestroiView ?
DG
Ну новых идей, помимо тех, что я уже предлагал, у меня, к сожалению, нет 😔
Я думал насчет буфера при биндинге к стейту, но тогда нужно вводить новые состояния ЖЦ пм-ки onPause и onResume
DG
Их жц отличается от фрагмента и активити
и да и нет, если фрагмент уходит в фон, то пм-ки вьюхолдеров тоже нужно останавливать.
DG
Ну это при условии, что мы согласны, что unbind пмке нужен. Я же имел в виду ситуацию со скроллом и ресайклом вьюшек.
без unbind особых проблем не должно быть, на каждый вьюхолдер создаем чайлд пм-ку атачим ее к парент пм-ке и биндим ко вьюхолдеру.
DG
но это вариант с рециклом чайлд-пм-ок
DG
создавать на каждый итем пм-ку мне кажется перебор, боюсь что производительность просядет
DG
А проблему я вижу в том, когда вьюшка отпишется от стейта в пмке
при рециклинге вьюхолдеров нужно будет привязываться к другой пм-ке, в этом месте может просесть отрисовка на вьюхолдере
DG
То есть сам bindTo медленный?
Не замерял, но может быть если стейтов много. В любом случае это создание объектов, которое рекомендуется избегать при бинде итема.
DG
+ при обновлении списка, если элементов тысячи, то нужно их мапить на пм-ки и атачить к паренту