Управление состояниями UI при разработке под Windows Phone

[jeremejevs]

Резко сказано, конечно, но интерфейс у вас действительно не Metro, а чёрт знает что.

[StrangeAndr]

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

Спасибо за ваш комментарий.

[StrangeAndr]

Загрузка сделана так, как вы говорите. Будем рабы комментариям, если вы попробуете приложение.
По иконкам, не для всех них есть сейчас аналоги в бесплатных библиотеках, поэтому пока в разработке.

Спасибо за замечания, учтем.

[StrangeAndr]

Извиняюсь за опечатку.
Будем рады комментариям, если вы попробуете приложение.

[renny]

1) пост ни о чем, чисто пиар продукта, уровень самых новичков
2) тут правильно написали, увольте дизайнера и заодно XAML верстальщика, они даже не удосужились гайдлайны почитать, и наймине меня, но стою я дорого
3) задача решается проще в разы

[Funbit]

4) и за параметры, названные от балды (a,b), тоже нужно наказать…

[Sequd]

Достаточно в самом xaml просто повесить биндинг на Visibility нужного элемента и нужного свойства и даже не пытаться тратить время на открытие проекта в Бленде. Быстрее, удобнее, понятнее.

[HomoLuden]

Насчет Blend согласен — все это можно реализовать и без него не особо утруждаясь.
Про Visibility не согласен. Лучше использовать связку DataTemplate + DataTrigger. Тогда не будет тратиться память на невидимый элемент.

[HomoLuden]

public const string MessageTextPropertyName = "MessageText";
...
public string MessageText
{
...
set
{
...
RaisePropertyChanged(MessageTextPropertyName);
}
Какой смысл выносить в константу имя, если при ренейминге свойства константа вверху все равно не переименуется автоматом. Я бы понял, если б вы через рефлексию эту стрингу получали, а так бессмысленно.

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

[HomoLuden]

Извините… хотел в основную ветку ответить.

[StrangeAndr]

Спасибо за комментарии.
Буду отвечать по порядку.

1. Имя храниться в константе, так как свойство создавалось через стандартный сниппет MVVM Light «mvvminpc», который сразу подставляет всю конструкцию. По поводу использования рефлексии спасибо за совет.

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

[HomoLuden]

Конечно есть минус того, что другой разработчик может не сразу понять

Да вы и сами по прошествии времени запамятовать можете. Но главная проблема, на мой взгляд — производительность. Сделайте теже стринги, по сути, но в виде enum => сравниваться будут int. И еще бы комментариями снабжать.

Тут сделано скорее для скорости и удобства разработки

Если перебороть лень/страх и начать делать «правильно», то очень скоро времени на нормальные решения будет тратиться даже меньше.

[StrangeAndr]

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

Пример был нацелен показать реализацию. Использовать состояния нужно действительно с умом.

Спасибо за комментарий.

[Sequd]

Но в более сложных страницах, количество меняющихся элементов в зависимости от состояния может быть гораздо больше.

Не сталкивался и не могу придумать пример с более чем 2-3 элементами меняющими свое стояние одновременно.
Попробуйте привести пример.

Для анимации согласен, ну или для более сложных контролов как чек бокс, да нужен Бленд.

[StrangeAndr]

Даже если у вас 3 элемента, у которых нужно изменить состояние, вам необходимо писать функции изменения состояния элементов; вам нужно следить за изменением контекста самому в коде и вызывать в нужное время функцию обновления состояния. А представьте, что у вас 3 состояния у страницы (при разработке были такие случаи) и вам вручуню нужно этим всем управлять.

Метод, предложенный в статье, позволяет не писать ни строчки кода и логики. Встроенные механизмы (DataStateBehaviour, который переключает State) сами следят за контекстом (в реальности за некими свойствами объектов) и сами переключают состояния.

Меньше кода, быстрее разработка, меньше ошибок.

[Sequd]

3 состояния у страницы

у страниц??? OMG
может все же у контролов или все таки каких то свойств данных находящихся в контроле?
Прекрасно навешиваются биндинги, при необходимости пишутся конвертеры.

Руками не нужно управлять не чем)

Даже если, как вы сказали, у чего то есть 3 разных состояния, то оно где то хранится. В свойстве? Вот и вешаешь биндинг)

[StrangeAndr]

Обсуждение перешло в разряд, что кому удобней и понятней.

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

[StrangeAndr]

Спасибо, учтем.