Дело наверное в том, что я в общем то люблю велосипедостроительство, с целью достижения понимания происходящего, но обычно к этому моменту свой велосипед уже не хуже готовых, а местами даже и лучше :)
Да проблема более чем актуальна, когда я знаю, что для определенной сущности понадобится «расширенный» близнец, в ход пускаю авто генерацию кода, часть кода которая реализует обертки для общих членов. А всю уникальную функциональность реализую в рядом лежащем partial классе
Получается, что каждый раз, когда нам понадобится значение нового типа которое напрямую коррелирует с базовым полем IsBusy мы будем вынуждены расширять ViewModel новыми полями. Но подход интересный, буду иметь его ввиду, пригодиться.
Согласен, что с точки зрения тестирования проверка свойства Visibility может быть более лаконична.
Однако по моему мнению свойство типа Visibility в View Model это перенос логики уровня представления на уровень модели представления.
В данном случае модель представления содержит поле, которое описывает ее состояние, например IsBusy. На уровне представления мы можем отобразить надпись «Работаю...», выключить все элементы управления или отобразить/скрыть элемент управления. Используя подход предложенный вами, нам пришлось бы реализовать 6 полей вместо одного, принимая решение о том, что показывать, а что нет за уровень представления.
Может и проще за несколькими но, а именно: дополнительные внешние сборки, в нагрузку получаем BCL, излишняя функциональность приводящая к потере производительности, возврат калбэков в UI поток в реализации WebClient от WP.
Увы R# 8.2 принес полную не совместимость проектов WP8 и PCL, к сожалению пришлось откатиться на 8.1 ее баги не критичны, по сравнению с 8.2. С нетерпением жду обновления 8.2.1.
Пункт 11 опровергаю, у меня никогда не было Hotmail учетки, учетка Микрософта привязана к совершенно левому адресу, который сейчас хостится на PDD от Яндекса. Все работает на ура. Более того в телефон можно добавить больше одной учетки Live ID.
О чем говорить я сам был прижат этим законом, но за бытовой диктофон, который положили в карман ребенку, оказалось что, положив в карман бытовой диктофон я произвел доработку бытовой модели диктофона, превратив ее в спецтехнику, а это карается по закону.
Насчет примера, я постараюсь дома воспроизвести, на работе к сожалению код утерян, так как комит был только после финальной реализации. Точно могу сказать, что с отменой навигации не дружит RadPhoneApplicationFrame от Telerik. Но и после его отключения были проблемы, с навигацией, когда после отмены события в Navigating приходило событие Navigated на ту же страницу. Возможно реальной навигации и не происходило, я не проверял, для нашего приложения события навигации являются критичными. Я долго не разбирался, вынес обработку в кастомизированный класс страницы и все.
В основном проблемы связанны с корректным восстановлением состояния довольно сложного уровня бизнес логики. В общем проблемы больше проектные чем, проблемы технологии.
На собственном опыте убедился, что выставление Cancel в обработчике события Navigating фрейма приложения не всегда приводит к ожидаемому результату. А вот в методе OnNavigatingFrom приложения, работает всегда. Неделю назад неожиданно для себя потратил целый день на борьбу с ошибками и проблемами данного режима работы, конечно больше всего проблем добавило восстановление после выгрузки приложения из памяти.
Однако по моему мнению свойство типа Visibility в View Model это перенос логики уровня представления на уровень модели представления.
В данном случае модель представления содержит поле, которое описывает ее состояние, например IsBusy. На уровне представления мы можем отобразить надпись «Работаю...», выключить все элементы управления или отобразить/скрыть элемент управления. Используя подход предложенный вами, нам пришлось бы реализовать 6 полей вместо одного, принимая решение о том, что показывать, а что нет за уровень представления.
Я и сам бывал причиной факапов :)
Пользоваться R# не перестану, не дождетесь :)