Как проверить «первое присваивание» привязки в MVVMCross

Question

У меня есть пользовательский MvxConvertingTargetBinding, который выполняет анимацию (исчезает/исчезает) на видимость связанного UIView. Я использую эту привязку на некоторых кнопках на UITableViewCell. Цель состоит в том, что пользователь нажимает кнопку, некоторые правила изменяются в режиме, и кнопка исчезает (и на ее место появляется другая кнопка).

Связывание фиксирует при присвоении значению привязки элементу управления - независимо от того, является ли это «первым раз» привязкой. Если это первый раз, то я НЕ ДОЛЖЕН оживить видимость. Это хорошо работает, потому что я не хочу видеть, что мои ячейки таблицы отображаются в сетке, а затем все их кнопки затухают - точка на привязке заключается в постепенном исчезновении кнопок при изменении базовой модели во время взаимодействия с пользователем. Это прекрасно работает.

Проблема возникает, когда моя ячейка «повторно используется» с помощью TableViewSource. Связывание повторно используется, и оно больше не считается «первым разом» - поэтому кнопки становятся анимированными. Это приводит к тому, что при прокрутке вверх и вниз в списке все кнопки «затухают», когда они просматривают вид ... как вы можете себе представить, это выглядит ужасно.

Как я могу решить эту проблему чистым способом?

Я подумал о том, чтобы поместить некоторый код в TableViewSource, проверить повторное использование, затем на повторно используемую ячейку, получить доступ к набору привязок и попытаться «сбросить» все привязки ... но есть нет доступа к коллекции привязок из определения MvxFluentBindingDescriptionSet.

Любые идеи?

Благодаря

Answer 1

Ok - Я починил решение ...

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

К счастью, MVVMCross присваивает NULL MvxTableViewCell.DataContext в конце его жизни - поэтому я могу использовать это, чтобы указать, что привязка ячейки должна быть «сброшена». Я также обойти неспособность получить доступ к списку целевых привязок в наборе привязки с использованием статического свойства (вроде бы грубой я знаю, но эй, это довольно очевидно, когда вы смотрите на код, что происходит, и это UI все еще так . не имеет большое значение для модульного тестирования)

Это идея (псевдо-код):

MyMvxConvertingTargetBinding.SetValueImpl: 
    if 'is_first_time' then 
    // don't animate the first-time binding of a view. Simple. 
    set view value, clear 'is_first_time' and return. 
    if 'ISRESETTING' then 
    // this is to ensure the View has the correct value, 
    // but is not animated when the table-view-cell is 
    // being removed from the table. It also resets the first-time state 
    // so that when a new DataContext is assigned, it will perform 
    // clean 'first-time' behavior. 
    reset 'is_first_time' to TRUE, set view value, and return 
    if is_first_time 
    then set view value and return 
    otherwise, animate setting of view value 

MvxTableViewCell.DataContext.Set: 
    if current DataContext is not null and new DataContext is null: 
    // This allows the TargetBinding to capture the fact that 
    // the source data-model is being disconnected 
    static MyMvxConvertingTargetBinding.ISRESETTING = TRUE 
    Assign base.DataContext 
    finally static MyMvxConvertingTargetBinding.ISRESETTING = FALSE 

Наконец, идея будет в любом MvxTableViewCell, когда вы используете одну из ваших особых «анимированных привязок» , убедитесь, что вы переопределите DataContext и завершите 'base.set; в try/catch, который переключает «ISRESETTING», как и в псевдокоде. Это хорошо работает.

Другая проблема, которая на самом деле исправляется, заключается в том, что повторно используемый элемент table-view-cell все еще оживляет дочерний вид в состоянии «hiddden», когда ячейка повторно используется и, следовательно, повторно анимируется в «видимое» состояние. Это вызывает конфликтующие анимации, которые могут привести к тому, что ячейка появится в таблице, а ее дочерний вид скрыт, когда он станет видимым!

Что было бы неплохо, было бы услугой, которая позволяла MvxTargetBinding регистрировать изменения в DataContext модели, относящиеся к данной привязке. Тогда нам не нужен подход статического поля, используемый здесь.