Извините, что долго отвечали:) Честно говоря, в своей практике мы предпочитаем описывать собственные поведения внутри кода класса. Поправьте нас, если мы не правы, но в документации мы не обнаружили средств по расширению новых поведений сосбтвенными параметрами. В случае, если таких средств не предусмотрено, то считаем метод, описанный в данной статье более предпочтительным и гибким. Но если такие срадства предусмотены, то выбор способа зависит от индивидуальных предпочтений, либо от код-стайла принятого на проекте.
Спасибо за хороший вопрос! Вообще у Xamarin.Forms интересная история с Activity Lifecycle в Android. Долгое время известным багом платформы было то, что приложение невозможно было поднять в принципе после того, как оно было убито ОС. После долгих обсуждений на форумах (пример), разработчики все-таки добавили этот баг в свою «internal feature tracking system». Но сейчас все хорошо, причем сервисы даже могут помочь контроллам возвращаться в исходное состояние, если это описать в соответствующих событиях. В данном примере это не предусмотрено, основной упор был сделан именно на взаимодействии 2 контроллов через сервисы.
Мы рады, что материал оказался полезным!
Prism – хорошая библиотека. Просто валидация ввода через присоединенные свойства была по большей части примером, демонстрирующим функциональные возможности и способ применения данного механизма на задаче близкой к читателю.
Следующая часть как раз и будет посвящена теме изменения существующих элементов управления и в частности интересующему вас механизму!
Спасибо за интересный вопрос! В свое время мы также были им озадачены. Ведь в WPF, как и в его предшественнике Windows Forms, представлены средства валидации. Но путь последующих платформ был тернист и в процессе они что-то теряли и приобретали. Так, в частности, были утрачены коробочные средства валидации: класс ValidationRule, свойства NotifyOnValidationError и ValidationRules у привязок. По этой причине в UWP разработчики вынуждены своими силами валидировать и форматировать введенные данные через события TextChanged или TextChanging
МВидео же является дистрибьютором товаров. Указывать на то, что в каком-то телевизоре нет какого-то функционала было бы даже выгоднее, так как рядом лежит другой, дороже, где этот функционал есть, и который выгоднее продать.
А по поводу сравнения — ты не прав. На сайте же можно посмотреть на странице сравнения всю эту разницу.
Спасибо за развернутый комментарий! Мы придерживаемся того же мнения, и именно поэтому не пытались полностью заменить консультанта бездушной машиной, а создали помощника консультанта. В большинстве случаев, консультанты могут обойтись и своими знаниями. Однако, такая информация, как например, количество на складе, требует обращения к терминалу, а планшет помогает консультанту быть более мобильным и не отвлекаться от общения с покупателем.
Поскольку приложение разрабатывалось и тестировалось «в полях», т.е. совместно с настоящими продавцами-консультантами в зале, к нашему удивлению, оказалось, что взгляд продавца фокусируется на привычных им картинках, а не на тексте.
Действительно, при разработке много внимания было уделено тестированию, в том числе и автоматизированному, для обеспечения безотказной работы приложения :)
Да, мы тоже посчитали, что это отличная идея, поэтому такой функционал реализован в приложении. Только сканируется реальный штрих-код товара обычной камерой планшета.
Все эти вещи ситуативны и зависят от конкретных условий, которые не поместятся в один комментарий (в некоторых подходах MVVM во View вообще не должно быть кода, за исключением привязки дата контекста, опять же, ситуативно). Мы поняли, что эта тема актуальна, спасибо вам! Развернем подробнее в следующих статьях.
Речь здесь идет о нативных контроллах (в IOS и Android), которые не поддерживаются в Xamarin.
Решение таких ситуаций заслуживают отдельной статьи.
Но забегая вперед, можно сказать, что если использовать поля для поддержания состояния View на обоих платформах в одной ViewModel, тогда класс ViewModel разрастется.
Со временем приходит осознание того, что проще создать отдельные ViewModel для каждой платформы, а общие поля вынести в отдельный сервис.
Но с замечанием согласен, момент ситуативный.
Prism – хорошая библиотека. Просто валидация ввода через присоединенные свойства была по большей части примером, демонстрирующим функциональные возможности и способ применения данного механизма на задаче близкой к читателю.
Следующая часть как раз и будет посвящена теме изменения существующих элементов управления и в частности интересующему вас механизму!
А по поводу сравнения — ты не прав. На сайте же можно посмотреть на странице сравнения всю эту разницу.
Решение таких ситуаций заслуживают отдельной статьи.
Но забегая вперед, можно сказать, что если использовать поля для поддержания состояния View на обоих платформах в одной ViewModel, тогда класс ViewModel разрастется.
Со временем приходит осознание того, что проще создать отдельные ViewModel для каждой платформы, а общие поля вынести в отдельный сервис.
Но с замечанием согласен, момент ситуативный.