Предпочтительное поведение при переходе от заполненного к прикрепленному визуальному состоянию

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

Когда я перетаскиваю свое приложение из заполненного состояния в привязанное состояние, существует период примерно 1–1,5 секунды, когда старое «заполненное» представление все еще отображается в привязанном пространстве просмотра. Не выглядит хорошо! Я бы предположил, что здесь должно быть применено стандартное поведение. Показывать заставку? Нужно ли анимировать элементы (и если да, то какое событие следует прослушивать)?

Спасибо за помощь!

Редактировать: вот немного упрощенного кода из одного из моих представлений, которые испытывают это отставание - страница результатов поиска:

<Grid x:Name="LayoutRoot">
  <Grid x:Name="FullViewGrid">
    <!-- Two GridViews containing up to 27 items each (not very advanced) -->
  </Grid>
  <Grid x:Name="SnappedViewGrid">
    <!-- Two ListViews doing the same thing, with different item templates -->
  </Grid>
</Grid>

По сути, я реализую собственный вариант стандартного шаблона контракта поиска, представленного в VS2012. У меня есть ощущение, что процессор слишком сильно нагружается при рендеринге этих изменений в пользовательском интерфейсе, и поэтому все идет не так гладко.


person Kris Selbekk    schedule 04.03.2013    source источник
comment
Мне кажется, что самое обычное - это 1-1,5-секундный вид старого вида... Но это не значит, что нельзя сделать что-то лучше :). Вы можете обработать событие SizeChanged окна и, возможно, скрыть текущий вид... См. stackoverflow.com/questions/10362566/ для получения более подробной информации об обнаружении изменений состояния просмотра, таких как переход на Snapped.   -  person Peter Ritchie    schedule 04.03.2013
comment
Хороший ответ - и спасибо :) Однако, когда я узнаю, когда смогу снова анимировать вещи? Есть ли что-то вроде события RenderingFinished?   -  person Kris Selbekk    schedule 04.03.2013


Ответы (1)


Да, значит, ты что-то делаешь не так. У SnapView такой задержки нет. Если вам интересно, вы можете ознакомиться с моим пошаговым руководством по SnapView: http://blog.jerrynixon.com/2012/12/walkthrough-implementing-snapview-in.html

Без примера кода из вашего приложения это лучшее, что я могу предложить прямо сейчас. Но, надеюсь, это все, что вам нужно, чтобы выбрать правильный путь для SnapView. Удачи!

person Jerry Nixon    schedule 04.03.2013
comment
Хотя я очень открыт для предположения, что мой код далек от совершенства, я вижу много приложений, имеющих такое поведение, в том числе некоторые из Microsoft. Ваш видеоблог был познавательным, но я уже делаю то же самое. Моя проблема в том, что он не переключается сразу - вероятно, из-за основной проблемы в коде рендеринга, используемом MS. Я добавил некоторый код в свой исходный пост, чтобы лучше объяснить мою ситуацию. - person Kris Selbekk; 05.03.2013
comment
Итак, я бы порекомендовал вам извлечь раскадровку из вашего состояния просмотра и попытаться запустить ее снаружи, проверяя, есть ли задержка в самой раскадровке. ОЧЕНЬ возможно, что причиной является ваша раскадровка (но маловероятно, что причиной является переход состояния просмотра, поскольку он не является причиной в других приложениях). Это также хорошая практика для улучшения производительности вашего приложения на ARM (для внешнего тестирования ваших раскадровок). Если это супер быстро за пределами состояния просмотра, то... тьфу. Будем надеяться, что вы нашли что-то очевидное. - person Jerry Nixon; 05.03.2013