правда WPF MVVM

в Ксамарине он тоже юзается да?

Если нет понимания MVVM паттерна то ты долго будешь копаться

У меня каждый элемент в списке сейчас это не ViewModel , а Model. Мне сейчас надо создать отдельно ViewModel под каждый Answer что ли и передавать List<ViewModel> в ресайклер?

У меня каждый элемент в списке сейчас это не ViewModel , а Model. Мне сейчас надо создать отдельно ViewModel под каждый Answer что ли и передавать List<ViewModel> в ресайклер?

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

в mvp все гораздо легче)

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

Пробовал я так, с POCO object намного проще и нет путаницы

в mvp все гораздо легче)

нужно что бы модель наследовала MvxNotifyPropertyChanged

Пробовал я так, с POCO object намного проще и нет путаницы

это мб проще но не по гайдлайнам паттерна

нужно что бы модель наследовала MvxNotifyPropertyChanged

то что реализует NotifyPropertyChanged то уже и является вьюмоделью

Может и так, но у меня рука не поднимается назвать такой класс *ViewModel

Может и так, но у меня рука не поднимается назвать такой класс *ViewModel

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

А это самая настоящая вью-модель. Просто отвечает за маленькую часть представления

у нас тоже для списков не ViewModel. А тоже почти POCO. Данные они сами не подтягивают, дейсвтия тоже не обрабатывают - это всё делает ViewModel для страницы. POCO содержат данные для отображения (ну и еще какие-нибудь необходимые). Так вся логика по экрану получается в одном месте.

А это самая настоящая вью-модель. Просто отвечает за маленькую часть представления

Тут совсем пофиг как он это назовет и от чего наследуется(NotifyPropertyChanged или ViewModel), для его задачи оба варианта подходят

у нас тоже для списков не ViewModel. А тоже почти POCO. Данные они сами не подтягивают, дейсвтия тоже не обрабатывают - это всё делает ViewModel для страницы. POCO содержат данные для отображения (ну и еще какие-нибудь необходимые). Так вся логика по экрану получается в одном месте.

“почти POCO” - ну вот ни то ни се. Надо уже давно набраться смелости называть это вьюмоделями. Вьюмодели к страницам, к части страниц, к элементам в списках - какая разница? Может быть парент-вьюмодель которая держит в себе 2 и более вьюмоделей в каждой из которых могут быть списки вью-моделей. Вот например скрин из старого аппстора https://fthmb.tqn.com/waLYCgIKl3JjSKE4C3KMr3MYZxk=/2048x1536/filters:no_upscale():fill(FFCC00,1)/app-store-ipad-56a533963df78cf77286e136.png

Я вижу здесь FeaturedViewModel, которая держит список вьюмоделей, каждая из которых имеет название категории, команду для “See all” и список из вьюмоделей в которых есть ссылка на картинку, название категорию и цену и если я тапаю по иконке с приложением, то тап прокидывается во вьюмодель из списка приложений, от куда я беру роутер и делаю навигацию на страницу с полной информацией о приложении, которая сама подгрузит всю дополнительную инфу по id, которую передала мне предыдущая вьюмодель.

Все правильно, элементы списка это вьюмодели.

“почти POCO” - ну вот ни то ни се. Надо уже давно набраться смелости называть это вьюмоделями. Вьюмодели к страницам, к части страниц, к элементам в списках - какая разница? Может быть парент-вьюмодель которая держит в себе 2 и более вьюмоделей в каждой из которых могут быть списки вью-моделей. Вот например скрин из старого аппстора https://fthmb.tqn.com/waLYCgIKl3JjSKE4C3KMr3MYZxk=/2048x1536/filters:no_upscale():fill(FFCC00,1)/app-store-ipad-56a533963df78cf77286e136.png

Ну у нас принято так, что Вью Модели только для страниц. Для listview используется список из Business Object, или, если необходим Notification Property Changed, то используется Model.

Ну у нас принято так, что Вью Модели только для страниц. Для listview используется список из Business Object, или, если необходим Notification Property Changed, то используется Model.

ну вот поэтому в Xamarin никто и не приходит из native разработки

ну не только поэтому конечно

но одна из причин

Ну, значит у нас не чистая MVVM

Потому что если в android разработке Clean architecture по крайней мере ясна и понятна и +- у всех одинакова, то у нас в Mvvm кто во что горазд

ну вот поэтому в Xamarin никто и не приходит из native разработки

Я пришел)

Я пришел)

аха. Исключение из правил)

аха. Исключение из правил)

И таких много)

Ну у нас принято так, что Вью Модели только для страниц. Для listview используется список из Business Object, или, если необходим Notification Property Changed, то используется Model.

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

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

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

Ведь даже microsoft говорит - бизнес-логика вся в Модели. А модель это что? Это репозиторий с Entity или Business Object. Модель это не модельные данные. Это нечто большее. А вы сразу к вьюшкам считайте прокидываете бизнес-объекты которые не должны вообще близко к вьюшкам подходить.

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

Потом будет пример, посмотришь. Понять легко и масштабировать

Потом будет пример, посмотришь. Понять легко и масштабировать

да я знаю как вы делаете

ну судя по описанию

тоже давно ещё так же писали

Привет всем! Уже что-то пару дней вожусь, может кто подскажет: появилась в проекте ошибка "error CS0103: The name 'InitializeComponent' does not exist in the current context" . До этого все хорошо собиралось. Теперь в конструкторе каждой Page компилятор на неё ругается. VS2017 v.15.5.2, Windows10, Xamarin.Forms v.2.5.0.121934

Можно попробовать открыть проект от имени администратора, почистить его и переслать. У меня такое было, вроде, при ошибке в xaml разметке

Пересобрать*

да я знаю как вы делаете

Ну в теории знаешь) у нас своя архитектура получилась, похожая на MVVM.

Просто потому что плодятся сущности - вью, вьюмодель, бизнес-объект простой, бизнес-объект сложный, в одном месте так в другом месте сяк. И если баги прилетают на какой-то функционал то где брать начальную точку поиска бага? Или вот джун приходит и на него фикс багов скидывается, а он не знает от куда начать - все везде по-разному или есть одна супер-вьюмодель из которой все рулится - он разберется? Если любой частью представления всегда управляет вьюмодель то ты точно знаешь что нужно искать нужную вьюмодель в папке с вьюмоделями, ставить бряки на set в пропертях и отлаживать конкретный участок кода. А если одна огромная вьюмодель, которая все держит как бы в одном месте то сколько там строк кода обычно? 200? 300? 400? как оно отлаживается? Мне допустим не очень приятно с таким классом работать. А если в процессе фикса бага я затрону и поломаю другой функционал? Есть Single Responsibility Principle и его надо придерживаться

Ну в теории знаешь) у нас своя архитектура получилась, похожая на MVVM.

я об этом и говорю. У каждого свое. Кто в лес кто по дрова. Приду я допустим к вам в команду и сяду работать с проектом - сколько времени я буду рабираться в абстракциях?

В MVP у слоя презентейшена например - фрагментов бывает и больше строк кода. )

В MVP у слоя презентейшена например - фрагментов бывает и больше строк кода. )

ну поэтому вообще-то большую часть кода выводят в UseCase или Interactors что и является прообразом вьюмодели кстати

да Presentor- UseCase - Service - Repo

И вот тут хотябы все проекты на джаве примерно схожи .

Просто потому что плодятся сущности - вью, вьюмодель, бизнес-объект простой, бизнес-объект сложный, в одном месте так в другом месте сяк. И если баги прилетают на какой-то функционал то где брать начальную точку поиска бага? Или вот джун приходит и на него фикс багов скидывается, а он не знает от куда начать - все везде по-разному или есть одна супер-вьюмодель из которой все рулится - он разберется? Если любой частью представления всегда управляет вьюмодель то ты точно знаешь что нужно искать нужную вьюмодель в папке с вьюмоделями, ставить бряки на set в пропертях и отлаживать конкретный участок кода. А если одна огромная вьюмодель, которая все держит как бы в одном месте то сколько там строк кода обычно? 200? 300? 400? как оно отлаживается? Мне допустим не очень приятно с таким классом работать. А если в процессе фикса бага я затрону и поломаю другой функционал? Есть Single Responsibility Principle и его надо придерживаться

На каждую страницу своя ViewModel. Строк кода не много, ибо не часто мобильных в приложениях должна быть сложная логика. Если она есть, то в отдельных классах. Сколько разбираться- если человек с каким-то опытом уже, то максимум час, ибо все просто.

Но тут уже есть загвостка. На одном экране не будет одной ViewModel если у тебя на экране есть какой-нибудь лист вью или ресайклер

на одном экране может быть много вьюмоделей

>загвостка why god

один экран может для планшета показывать 2 страницы сразу, тогда как смартфон каждую страницу по очереди

один экран может для планшета показывать 2 страницы сразу, тогда как смартфон каждую страницу по очереди

Ну, если 2 страницы, то 2 вью модели

Я с ваших слов понял что у вас нет Model - Entity как в джава, правильно? Вы сразу же используете ViewModel и в нем все поля Модели?

Так?

Я с ваших слов понял что у вас нет Model - Entity как в джава, правильно? Вы сразу же используете ViewModel и в нем все поля Модели?

есть Entity

и DTO есть

Просто используется маппер

когда я прошу репозиторий дать мне данные он отдает мне например List<Entity>. Через маппер он становится например List<EntityViewModel> и уже этот лист летит биндинг-контекстом в датасорс рецайклера

Я думал вы прям из репо тяните EntityViewModel. Просто зачем это лишнее действие

Я думал вы прям из репо тяните EntityViewModel. Просто зачем это лишнее действие

репо знает только то что ей надо получить DTO и вернуть наверх Entity

Таким образом слои в этой длинной цепочке не зависят друг от друга

изменения в одном слое не затрагивают работу других

Для многих задач это возможно избыточно. Но если надо тащить данные с одного сервера и частично с другого - по-другому никак. И единожды применив этот подход для связи с particle.io и сервером кастомера одновременно, стали применять его повсеместно и в других проектах. И главное решили проблему фикса багов. Они реально стали фикситься быстрее. Смотришь в описание бага и сразу понимаешь в каком слое проблема ещё до того как что-то начинаешь фиксить. Все знают что условно говоря бизнес логика в Entity или как его называют Busines Object, логика представления точно в viewmodel, данные для трансфера с сервером в DTO и если надо нафичевать фичу, то пишется бизнес-логика отдельно, логика представления отдельно, DTO для сервака и клиента отдельно. И оценка задач по другому происходит уже. Задача делится на подзадачу написания DTO, бизнес логики и логики вьюмодели и верстки и главное, что подзадачи могут шариться между участниками команды и они не будут мешать друг другу вообще никак и нигде. Profit очень серьезный

привет, никто в xamarin.forms на андроиде не сталкивался с тем что contentpage внизу обрезанная?

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

Подскажите, нужно сделать приложение для платформ Windows xp, 7,8, 10, Android и iPhone. Смотрю в сторону xamarin как универсальной платформы. Программа будет представлять из себя мобильный клиент для сайта поддержки, соответственно никакой магии и никаких специальных визуальных эффектов или чего то ещё не нужно.

Знаю c# по этому и смотрю на xamarin

ERROR: S client not available

XP бы выбросить

И было бы ок

Знаю c# по этому и смотрю на xamarin

А в чем вопрос?

XP бы выбросить

60-70% парка это дебильный xp

Wpf тогда нам не взлетит, насколько я помню

А в чем вопрос?

Да я не знаю, почитал переписку тут и так и не понял на чем именно делать. Есть аналог в виде xamarin form как я понял а есть что то ещё... Что выбрать?

Можно на windows.forms для XP + 7 сделать

И xamarin.forms для 8, 10 и мобилок

Логику общую сделать (data access layer, model или что там у вас по архитектуре внизу)

А вот ui - в зависимости от платформы

Но их хотя бы будет 2 по большому счету

А не 6

Wpf тогда нам не взлетит, насколько я помню

Взлетит, на xp net 4.0 последний, а там уже есть wpf

+ не было бы WinXP...

я бы писал WPF на 4.7 фреймворке а не 4.0...

Но увы, xp есть. Это ладно для сайта есть ещё обязанность по совместимости с ie 8. :)

Можете посоветовать книжку или сайт по xamarin.form?

Можете посоветовать книжку или сайт по xamarin.form?

Офф документация

могу этот сайт посоветовать если на русском

https://metanit.com/sharp/xamarin/

вообще не учил XAmarin Forms но как сайт он годный, я по нему моногейм и wpf учил

Подскажите, нужно сделать приложение для платформ Windows xp, 7,8, 10, Android и iPhone. Смотрю в сторону xamarin как универсальной платформы. Программа будет представлять из себя мобильный клиент для сайта поддержки, соответственно никакой магии и никаких специальных визуальных эффектов или чего то ещё не нужно.

в мастере лежит xamarin forms для wpf и gtk я бы попробовал поиграться со вторым под ХР

Метанит... Ну разве что названия того, что нужно прочитать в доках

Всегда останавливало от использования ксамарин - отсутствие модуля оплаты от банков под эту платформу. и оказывается тиньков успел ее таки сделать: https://github.com/amalsher/Tinkoff.Xamarin

Привет всем, кто-нибудь сталкивался с проблемой, когда AbsoluteLayout вставляешь в ScrollView, привязываешься к событие scrollView.Scrolled, а там ничего не меняется при скролле?

Всегда останавливало от использования ксамарин - отсутствие модуля оплаты от банков под эту платформу. и оказывается тиньков успел ее таки сделать: https://github.com/amalsher/Tinkoff.Xamarin

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

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

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

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

Ну что есть официальная версия, это беспорно плюс. Но подключить таки можно было. Порой не "с пол пинка" но можно)

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

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

Есть плагин который замечательно делает 90% работы. Бывает так что нужно ручками править биндинги, да. Процесс может стать не быстрым и решение не очевидным. Но не невозможным

Никто не сталкивался, что в релиз моде в Иосе не вызывается ReceivedRemoteNotification когда приложение активно? Если свернуто - все ок - вижу пуш нотификацию В дебаге тоже работает iOS 11