вы явно сделали не так

Создал область, добавил туда индикатор, закинул область в контент

код можно?

MakePage должна быть независима от await Indicator

вызови свой Indicator в констркторе своей страницы с Task.Run(Indicator);

ну и там скорее всего будет ошибка с изменением состояния индикатора не на UI потоке, потому нужны баиндинги, но хотя бы до этого момента надо дойти %)

и MakePage не нужен будет async, её тоже прямо в констрктор засунь

Индикатор работает и пропадает, как я понимаю, в нужный момент

но stacklayout начальный остаётся и новый не появляется

То есть пустой экран получается

а как выглядит Indicator метод?

ээ, так ты хочешь, чтобы индикатор крутился пока грузится другая вьюшка?

так нельзя

я думал, там данные какие-то прогружаюся

Совсем нельзя?

Лучше почитайте на msdn

Мне все равно не до конца понятен mvvm. Действия в случае нажатия на кнопку сохранения, получения данных и т д нужно вынести в view model? А если есть кнопка, при нажатии на которую появляется картинка или меняется цвет элемента на странице, это надо куда-то выносить?

да если это требуется на всех платформах но картинка же из VM запросится, как и цвет

Реализация логики фичи - в model. Внешний вид во view. Связывание UI и логики в VM. Она не размазывается, она структурируется чтоб не стать нетестируемой спагетиной

Про это в доке написано, спасибо) Т.е. если я правильно понял, то можно под каждую фичу создавать папку FeatureName и там уже Model, View, ViewModel, так?

Совсем нельзя?

в этом случае нельзя

Model не должна отражать ViewModel, там свой мир

Про это в доке написано, спасибо) Т.е. если я правильно понял, то можно под каждую фичу создавать папку FeatureName и там уже Model, View, ViewModel, так?

У меня обычно 3 папки. Все вьюхи в одной, все VM в другой. Бизнес логику можно вообще по разным class library растащить

ViewModel это такой слой-конвертер где собираются все сырые данные с Model и компонуются под передачу в UI идеальная ViewModel это когда она может работать и тестироваться без подключённого UI в принципе поэтому когда пишешь код VM можно постоянно задавать себе вопрос "а сможет ли это работать без UI? а смогу ли я подключить ещё одну платформу сюда?" чтобы понимать не "течёт" ли VM во View

Model же состоит из запросов в сеть, БД, там нет ни намёка на UI и структуру аппа

(и опять же, правильно спроектированная Model может работать и тестироваться без подключённой ViewModel)

да если это требуется на всех платформах но картинка же из VM запросится, как и цвет

Зачем вообще тогда обработчики событий нужны?

Если везде command использовать

слабо знаю XF (пишу MvvmCross + native), но согласно этой статье и не особо нужны знатоки XF поправят ) https://blog.xamarin.com/simplifying-events-with-commanding/

Мне все равно не до конца понятен mvvm. Действия в случае нажатия на кнопку сохранения, получения данных и т д нужно вынести в view model? А если есть кнопка, при нажатии на которую появляется картинка или меняется цвет элемента на странице, это надо куда-то выносить?

ViewModel канонический - это по сути Interactor из VIPER содержащий не UseCase(детализация, описание действия, которое может совершить пользователь системы, т.е часть бизнес-логики) как это принято, а набор состояний вью. Неканоничной она становится обычно тогда когда в ViewModel смешивают состояния с usecase чтобы “не плодить сущности, ну и так тупо удобнее”, т.е смешивают бизнес-логику и состояния экрана в единое, описывают делегаты команд во вьюмодели, хотя это чистый usecase, который надо выносить отдельно, но для удобства он пишется там же. Что касается картинки которую надо показывать на вью - то конечно тут двойственная ситуация потому как с одной стороны картинки это данные, которые надо закачать от куда-то и показать и в тоже время на каждой платформе свои классы для bitmap-изображений. Тем не менее есть 2 пути - либо у контрола отображающего картинки свой доступ к http-клиенту который по сути является провайдером данных и вы скармливаете контролу просто url по которому лежит изображение и контрол сам скачивает его, кэширует итд(так делает XF), либо вы делаете так чтобы из ViewModel к ImageView через ваш gateway-механизм(Repository, API) прилетал byte[] и ImageView сам этот массив преобразовывал в те платформо-зависимые классы в которые надо на конкретной платформе

> Interactor из VIPER не самый простой пример новичкам ?

слабо знаю XF (пишу MvvmCross + native), но согласно этой статье и не особо нужны знатоки XF поправят ) https://blog.xamarin.com/simplifying-events-with-commanding/

Посоветуй что - нибудь почитать про native)

доки Apple, доки Android, но что-то одно я знаю первый, второй делаю впервые – просто заглядываю в доки и гуглю туториалы по андроиду

ViewModel канонический - это по сути Interactor из VIPER содержащий не UseCase(детализация, описание действия, которое может совершить пользователь системы, т.е часть бизнес-логики) как это принято, а набор состояний вью. Неканоничной она становится обычно тогда когда в ViewModel смешивают состояния с usecase чтобы “не плодить сущности, ну и так тупо удобнее”, т.е смешивают бизнес-логику и состояния экрана в единое, описывают делегаты команд во вьюмодели, хотя это чистый usecase, который надо выносить отдельно, но для удобства он пишется там же. Что касается картинки которую надо показывать на вью - то конечно тут двойственная ситуация потому как с одной стороны картинки это данные, которые надо закачать от куда-то и показать и в тоже время на каждой платформе свои классы для bitmap-изображений. Тем не менее есть 2 пути - либо у контрола отображающего картинки свой доступ к http-клиенту который по сути является провайдером данных и вы скармливаете контролу просто url по которому лежит изображение и контрол сам скачивает его, кэширует итд(так делает XF), либо вы делаете так чтобы из ViewModel к ImageView через ваш gateway-механизм(Repository, API) прилетал byte[] и ImageView сам этот массив преобразовывал в те платформо-зависимые классы в которые надо на конкретной платформе

Что касается Model, то это не Entity как это принято считать и не POCO. Это система классов которая описывает и DataProviderы (http, localDB) и маппинг POCO в Entity и кэширование данных если надо, и сам usecase, т.е пользовательский сценарий, который работает в итоге с Entity и её внутренней бизнес-логикой.

ViewModel канонический - это по сути Interactor из VIPER содержащий не UseCase(детализация, описание действия, которое может совершить пользователь системы, т.е часть бизнес-логики) как это принято, а набор состояний вью. Неканоничной она становится обычно тогда когда в ViewModel смешивают состояния с usecase чтобы “не плодить сущности, ну и так тупо удобнее”, т.е смешивают бизнес-логику и состояния экрана в единое, описывают делегаты команд во вьюмодели, хотя это чистый usecase, который надо выносить отдельно, но для удобства он пишется там же. Что касается картинки которую надо показывать на вью - то конечно тут двойственная ситуация потому как с одной стороны картинки это данные, которые надо закачать от куда-то и показать и в тоже время на каждой платформе свои классы для bitmap-изображений. Тем не менее есть 2 пути - либо у контрола отображающего картинки свой доступ к http-клиенту который по сути является провайдером данных и вы скармливаете контролу просто url по которому лежит изображение и контрол сам скачивает его, кэширует итд(так делает XF), либо вы делаете так чтобы из ViewModel к ImageView через ваш gateway-механизм(Repository, API) прилетал byte[] и ImageView сам этот массив преобразовывал в те платформо-зависимые классы в которые надо на конкретной платформе

Просто не будет ли намного проще и естественнее использовать обработчики событий? Хотя бы для простейших действий, ничего не тянуть из vm просто поменять свойство какого - нибудь элемента страницы (скрыть его например)

> Неканоничной она становится обычно тогда когда в ViewModel смешивают состояния с usecase чтобы “не плодить сущности, ну и так тупо удобнее”, т.е смешивают бизнес-логику и состояния экрана в единое, описывают делегаты команд во вьюмодели, хотя это чистый usecase, который надо выносить отдельно, но для удобства он пишется там же. @ptytz разнести можно, но много ли выгоды с этого? особенно когда экраны простые и команда 1-3 человека?

> Interactor из VIPER не самый простой пример новичкам ?

ну может быть. Короче это просто “таблица состояний” у которой есть доступ к router(navigation service) и юзкейсам(командам)

> Неканоничной она становится обычно тогда когда в ViewModel смешивают состояния с usecase чтобы “не плодить сущности, ну и так тупо удобнее”, т.е смешивают бизнес-логику и состояния экрана в единое, описывают делегаты команд во вьюмодели, хотя это чистый usecase, который надо выносить отдельно, но для удобства он пишется там же. @ptytz разнести можно, но много ли выгоды с этого? особенно когда экраны простые и команда 1-3 человека?

конечно если проект маленький и недолгоиграющий то игра не стоит свеч

Надо безусловно разделять проекты по времени их жизни

Просто случается так что сделав что-то по простому этот же подход тащят в уже сложное, хотя его очевидно не достаточно

Просто не будет ли намного проще и естественнее использовать обработчики событий? Хотя бы для простейших действий, ничего не тянуть из vm просто поменять свойство какого - нибудь элемента страницы (скрыть его например)

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

про смешивание напомнило вот этот цикл статей (если лень читать всё, то выводы в пятой части) https://ericlippert.com/2015/04/27/wizards-and-warriors-part-one/

про разделение команд и состояний

Что касается Model, то это не Entity как это принято считать и не POCO. Это система классов которая описывает и DataProviderы (http, localDB) и маппинг POCO в Entity и кэширование данных если надо, и сам usecase, т.е пользовательский сценарий, который работает в итоге с Entity и её внутренней бизнес-логикой.

теперь понял. т.е. ViewModel это презентер, а Model - interactor если переводить на viper. Получается что ViewModel подписывается на Model если хочет получать какие-то уведомления из энтити?

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

И получается нужно в vm передавать ссылки на все элементы страницы, в которых нужно какие-то свойства поменять?

теперь понял. т.е. ViewModel это презентер, а Model - interactor если переводить на viper. Получается что ViewModel подписывается на Model если хочет получать какие-то уведомления из энтити?

не совсем так. такое сравнение некоректно

ровно по той причине что viewmodel реализует главный интерфейс без которого ничего бы не вышло - INotifyPropertyChange

Тогда как презентер точно и 100% “знает” о View

а vm не знает о view?

Вьюмодель ничего не знает, хранит состояния и нотифицирует об изменении данных тех кто “подписан” на неё

фишка в том что вот это подписание и обработка эвента PropertyChange оно происходит за кулисами. Обычно программисту ничего об этом неизвестно. Он создал страницу, дал ей биндинг-контекстом вьюмодель и написал биндинги либо кодом либо в разметке - и оно заработало, “магия” случилась

ViewModel - это абстрактная такая штука, которую мы делаем таким образом, как хотим, чтобы View выглядела общие свойства и команды View реализует ViewModel

если можно так объяснить о_.

правильно понимаю что vm должна подписаться на модель чтобы оповестить ui когда что-то поменялось?

правильно понимаю что vm должна подписаться на модель чтобы оповестить ui когда что-то поменялось?

ну обычно конечно модель не живет сама по себе в воздухе и не обновляет данные сама. Запрос данных это часть сценария. Соответственно обычно поход за данными это какой-то Task, который можно подождать) Дождался завершения работы таска после await и можешь брать результат выполнения этого таска и всобачивать его в проперть и менять таким образом состояние и как следствие автоматически оповещать вью для того чтобы она заново зачитала проперть

ViewModel грузит Model, потом ViewModel загруженные данные присваивает свойствам а так как наша View привязала свои свойства соответствующие к свойствам ViewModel, то View изменяется внешне

получается при нажатии на кнопку происходит как-то так var res = await Model.GetResult(); ? т.е. такой минимум логики?

если глубже идти, то есть двухсторонняя привязка (текстовое поле, например) когда привязанные свойства View обновляют свойства ViewModel

Так чтобы менять в vm свойства элементов страницы, нужно их передать в эту vm?

да

получается при нажатии на кнопку происходит как-то так var res = await Model.GetResult(); ? т.е. такой минимум логики?

типа того, да.

да

с чего это?

про vm<->view все понятно) не понятно именно как логика пишется. Кто-то фигачит прям во viewmodel, но это ж получается потом видимо massive vm.

с чего это?

а как изменить свойства страницы, которая к VM привязана?

Так чтобы менять в vm свойства элементов страницы, нужно их передать в эту vm?

важно чтобы свойства вью и свойства вьюмодели совпадали по типам. Если они не совпадают то пишутся конвертеры

а как изменить свойства страницы, которая к VM привязана?

биндинг же

важно чтобы свойства вью и свойства вьюмодели совпадали по типам. Если они не совпадают то пишутся конвертеры

так она же не это спросила

так она же не это спросила

а что? может я недопонял

про некоторое абстрактное свойство страницы, которое нужно обновить оно привязано к некоторому абстрактоному свойство VM, и, соответственно, чтобы обновить свойство страницы, мы обновляем свойство VM

а про проблемы соответствия типов свойств никто не спрашивал

про некоторое абстрактное свойство страницы, которое нужно обновить оно привязано к некоторому абстрактоному свойство VM, и, соответственно, чтобы обновить свойство страницы, мы обновляем свойство VM

“Так чтобы менять в vm свойства элементов страницы, нужно их передать в эту vm?”

теперь я сам не пойму

можно перефразировать вопрос?

ну я и ответил что в эту VM ничего не передается. Просто страница держит список биндингов(привязок) и важно чтобы 1 проперти вью по типу совпадала с пропертью вьюмодели(а если не совпадает то конвертер добавить). И при этом чтобы вьюмодель работала с платформо-независимыми типами

биндинг же

эм, вопрос был риторический

а что? может я недопонял

У нас есть элемент на странице, который нужно скрыть при нажатии на кнопку. Сейчас у меня на есть обработчик события click в коде страницы.

ну я и ответил что в эту VM ничего не передается. Просто страница держит список биндингов(привязок) и важно чтобы 1 проперти вью по типу совпадала с пропертью вьюмодели(а если не совпадает то конвертер добавить). И при этом чтобы вьюмодель работала с платформо-независимыми типами

аа, понял

click привязывается к команде в VM, команда меняет некоторое булево свойство, отвечающее за видимость элемента на странице свойство видимости элемента на странице в свою очередь привязано к этому булеву свойству в VM

ViewModel канонический - это по сути Interactor из VIPER содержащий не UseCase(детализация, описание действия, которое может совершить пользователь системы, т.е часть бизнес-логики) как это принято, а набор состояний вью. Неканоничной она становится обычно тогда когда в ViewModel смешивают состояния с usecase чтобы “не плодить сущности, ну и так тупо удобнее”, т.е смешивают бизнес-логику и состояния экрана в единое, описывают делегаты команд во вьюмодели, хотя это чистый usecase, который надо выносить отдельно, но для удобства он пишется там же. Что касается картинки которую надо показывать на вью - то конечно тут двойственная ситуация потому как с одной стороны картинки это данные, которые надо закачать от куда-то и показать и в тоже время на каждой платформе свои классы для bitmap-изображений. Тем не менее есть 2 пути - либо у контрола отображающего картинки свой доступ к http-клиенту который по сути является провайдером данных и вы скармливаете контролу просто url по которому лежит изображение и контрол сам скачивает его, кэширует итд(так делает XF), либо вы делаете так чтобы из ViewModel к ImageView через ваш gateway-механизм(Repository, API) прилетал byte[] и ImageView сам этот массив преобразовывал в те платформо-зависимые классы в которые надо на конкретной платформе

Неканоничной ViewModel становится, когда забывают, что это не сущность, а слой, куда входит как видимое пользователю состояние системы, так и доступные пользователю команды для его изменения

Неканоничной ViewModel становится, когда забывают, что это не сущность, а слой, куда входит как видимое пользователю состояние системы, так и доступные пользователю команды для его изменения

согласен

click привязывается к команде в VM, команда меняет некоторое булево свойство, отвечающее за видимость элемента на странице свойство видимости элемента на странице в свою очередь привязано к этому булеву свойству в VM

Теперь начинаю понимать) и таким образом можно вынести в vm обработку всех действий пользователя и бизнес-логику (если проект небольшой)?

прям всех вряд ли получится, но большинство да

А сама страница просто содержит определённый набор элементов, ссылку на vm? Без каких-либо обработчиков

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

А сама страница просто содержит определённый набор элементов, ссылку на vm? Без каких-либо обработчиков

Да. Если и есть обработчики - то тупые, вызывающие методы вью-модели

Спасибо) стало намного понятнее ))

А такой еще вопрос - если у нас страница и на ней много независимых компонентов со своими model/view/vm, как это все работает? Родительский vm держит vm потомков?

да

спасибо

А такой еще вопрос - если у нас страница и на ней много независимых компонентов со своими model/view/vm, как это все работает? Родительский vm держит vm потомков?

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

в MvvmCross кстати есть Presenter уже готовый, но у них документация конечно ...непростая

в MvvmCross кстати есть Presenter уже готовый, но у них документация конечно ...непростая

То что они его так назвали он от этого презентером не стал XD

Это не Presenter у них а Controller(но не чистый). Разницу прочувствовать может только познавший дзен) В итоге mvvmCross на самом деле предлагает паттерн MVCVM (не путать с MVVMC ?)

публикую приложение Xamarin.Android в Play market, в debug и release google maps работают, подпись приложения одно и тоже sha-1 верный, но если скачиваю с маркета не работает, сталкивался кто? подскажите в каком направлении смотреть, а то уже не знаю, что делать

публикую приложение Xamarin.Android в Play market, в debug и release google maps работают, подпись приложения одно и тоже sha-1 верный, но если скачиваю с маркета не работает, сталкивался кто? подскажите в каком направлении смотреть, а то уже не знаю, что делать

Cобери подписанные APK и перед тем как заливать в Google Play, проверь на устройстве, подключи к ПК и через Device Log смотри что выдает приложение при запуске, возможно там Google Maps пишет ошибку или предупреждение

Cобери подписанные APK и перед тем как заливать в Google Play, проверь на устройстве, подключи к ПК и через Device Log смотри что выдает приложение при запуске, возможно там Google Maps пишет ошибку или предупреждение

На устройстве все работает. Проблему я решил, оказалось, что Гугл даёт свою подпись приложению, я нашел ее в консоли разработчика