Обсуждение перешло в разряд, что кому удобней и понятней.
В пользу метода описанного в статье скажу лишь, что во время верстки у элементов сразу можно определить все нужные визуальные состояния, а когда дело дойдет до кода, ты знаешь где их искать.
Даже если у вас 3 элемента, у которых нужно изменить состояние, вам необходимо писать функции изменения состояния элементов; вам нужно следить за изменением контекста самому в коде и вызывать в нужное время функцию обновления состояния. А представьте, что у вас 3 состояния у страницы (при разработке были такие случаи) и вам вручуню нужно этим всем управлять.
Метод, предложенный в статье, позволяет не писать ни строчки кода и логики. Встроенные механизмы (DataStateBehaviour, который переключает State) сами следят за контекстом (в реальности за некими свойствами объектов) и сами переключают состояния.
Загрузка сделана так, как вы говорите. Будем рабы комментариям, если вы попробуете приложение.
По иконкам, не для всех них есть сейчас аналоги в бесплатных библиотеках, поэтому пока в разработке.
Действительно в данном примере из двух объектов, быстрее переключать Visibility.
Но в более сложных страницах, количество меняющихся элементов в зависимости от состояния может быть гораздо больше. Плюс если вдруг решите сделать анимацию между состояниями, то это будет делаться намного проще в Бленде нежели в коде.
Пример был нацелен показать реализацию. Использовать состояния нужно действительно с умом.
1. Имя храниться в константе, так как свойство создавалось через стандартный сниппет MVVM Light «mvvminpc», который сразу подставляет всю конструкцию. По поводу использования рефлексии спасибо за совет.
2. Тут сделано скорее для скорости и удобства разработки, так как написав одну строчку, какое будет сообщение, оно сразу же показывается, не переводясь в какие либо действительно обычно применимые числа, которые потом будут обрабатываться как состояния.
Конечно есть минус того, что другой разработчик может не сразу понять, что если он поменяет строку у него измениться состояние на экране.
Иконки действительно пока в разработке.
А по поводу загрузки, я так понял, вы предлагаете показывать более конкретные этапы загрузки, чем то, что она просто идет. Идея текущего бара подсмотрена из приложения Marketplace, т.к. размер контента передается примерно равный. Думаю то, что вы предлагаете, более подходит в случаях загрузки пользователем конкретных модулей или файлов.
Когда вы находитесь в самом приложение, и переключаете с помощью UVC, то благодаря методу Instance_PlayStateChanged и секции PlayState.Playing при переключение треков, выделение в списке будет менять на нужный трэк.
Но тут есть одна действительно не решенная задача, если мы переключили трэк когда приложение было в фоне.
То, чтобы корректно отобразить текущий трэк при возобновление приложения, надо просто в метод OnNavigatedTo(который срабатывает при переходе на страницу) вставить такой же switch, что и в Instance_PlayStateChanged.
В пользу метода описанного в статье скажу лишь, что во время верстки у элементов сразу можно определить все нужные визуальные состояния, а когда дело дойдет до кода, ты знаешь где их искать.
Метод, предложенный в статье, позволяет не писать ни строчки кода и логики. Встроенные механизмы (DataStateBehaviour, который переключает State) сами следят за контекстом (в реальности за некими свойствами объектов) и сами переключают состояния.
Меньше кода, быстрее разработка, меньше ошибок.
Будем рады комментариям, если вы попробуете приложение.
По иконкам, не для всех них есть сейчас аналоги в бесплатных библиотеках, поэтому пока в разработке.
Спасибо за замечания, учтем.
Но в более сложных страницах, количество меняющихся элементов в зависимости от состояния может быть гораздо больше. Плюс если вдруг решите сделать анимацию между состояниями, то это будет делаться намного проще в Бленде нежели в коде.
Пример был нацелен показать реализацию. Использовать состояния нужно действительно с умом.
Спасибо за комментарий.
Буду отвечать по порядку.
1. Имя храниться в константе, так как свойство создавалось через стандартный сниппет MVVM Light «mvvminpc», который сразу подставляет всю конструкцию. По поводу использования рефлексии спасибо за совет.
2. Тут сделано скорее для скорости и удобства разработки, так как написав одну строчку, какое будет сообщение, оно сразу же показывается, не переводясь в какие либо действительно обычно применимые числа, которые потом будут обрабатываться как состояния.
Конечно есть минус того, что другой разработчик может не сразу понять, что если он поменяет строку у него измениться состояние на экране.
А по поводу загрузки, я так понял, вы предлагаете показывать более конкретные этапы загрузки, чем то, что она просто идет. Идея текущего бара подсмотрена из приложения Marketplace, т.к. размер контента передается примерно равный. Думаю то, что вы предлагаете, более подходит в случаях загрузки пользователем конкретных модулей или файлов.
Спасибо за ваш комментарий.
Действительно если начать работать с плеером не с выбора трэка, а с кнопок, то плеер падает.
Для того, чтобы он корректно работал необходимо в классе AudioPlayer в методе OnUserAction в самом начале его добавить такую строчку:
Она определит первый трек текущим, если еще не был выбран трэк.
Данное решение добавлю в статью в ближайшее время.
А по поводу того, как хранить список музыки, считать индекс или нет, зависит от конкретной задачи. В данном случае, я думаю, что это не принципиально.
Но тут есть одна действительно не решенная задача, если мы переключили трэк когда приложение было в фоне.
То, чтобы корректно отобразить текущий трэк при возобновление приложения, надо просто в метод
OnNavigatedTo(который срабатывает при переходе на страницу) вставить такой же switch, что и в Instance_PlayStateChanged.
Теперь можно сразу посмотреть код.