На одном уровне предложение Microsoft о включении ApplicationBar
в App.xaml
замечательно, так как на него можно ссылаться отовсюду, и, по-видимому, это поощряет повторное использование кода: однако этот вопрос подчеркивает ограничение этого подхода.Панель приложения обычно используется для предоставления действий, относящихся к текущей странице (или элементу поворота), и только потому, что кнопки одинаковы, может не потребоваться, чтобы в каждом случае выполнялся один и тот же код.
Вв этом случае я думаю, что было бы лучше создать фабричный метод, который создает ваш общий ApplicationBar
с обработчиками щелчков, которые вы указываете конкретно для вашей страницы / сводного элемента.Для получения бонусных баллов поместите метод в новый класс (не App
), чтобы он не терялся во всем коде шаблона.Вызовите этот метод фабрики в конструкторе страниц и запомните свой ApplicationBar
в своем классе.Для нескольких панелей приложений создайте их все сразу, и вы можете легко переключаться между этими панелями приложений в своем коде Pivot SelectionChanged.
Альтернатива создания панели приложений в App.xaml
и последующего извлечения ее из App.xaml.cs
"Ресурсы" ResourceDictionary
в коде, модифицирующие обратные вызовы кликов, на мой взгляд, более сложны.
Хотелось бы, чтобы они проделали лучшую работу по реализации ApplicationBar
, чтобы люди не захотелисделай это.Я обнаружил, что использование ApplicationBar заставляет вас добавлять код в Page.xaml.cs
, даже если вы используете такую среду, как MVVM Light.Это все еще нормально в MVVM, поскольку это специфичный для пользовательского интерфейса код, который принадлежит представлению, но это делает вещи непоследовательными, если вы используете ICommand
везде.В прошлый раз я решил, что лучше всего создать ApplicationBar
в коде, чем взламывать подобные вещи с помощью App.xaml.cs
.
Обновление: Есть запрос UserVoiceдля привязываемых данных ApplicationBar .