..ля, как просто то, оказывается

Всем привет, я так понимаю вместе с телеграммом в РФ решили ещё и nuget заблокировать?

https://www.nuget.org/api/v2

2 версия должна работать

..ля, как просто то, оказывается

Как бы ну, это все равно надо разбирать сильно глубоко, ибо нормальные ребята юзают свои реализации, ибо Fody генерит слишком много кода

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

Как бы ну, это все равно надо разбирать сильно глубоко, ибо нормальные ребята юзают свои реализации, ибо Fody генерит слишком много кода

Уж не преждевременная ли оптимизизация это?

Уж не преждевременная ли оптимизизация это?

Ну последнее время у меня паранойя по этому поводу, так что мнение более чем субъективное

И с Fody немного дольше сборка идет=)

Сборка дольше - понятно. Но вот насчет слишком много кода есть сомнения. Руками человек в таких случаях обычно пишет слишком мало, а потом ловит баги.

И с Fody немного дольше сборка идет=)

Для вейверов реалма у меня 1-2 секунды

Посоны, напомните, если я хочу подружить UITapGestureRecognizer и RelayCommand в MVVM Light, куда мне смотреть?

Для вейверов реалма у меня 1-2 секунды

поэтому и сказал: Немного.

Сборка дольше - понятно. Но вот насчет слишком много кода есть сомнения. Руками человек в таких случаях обычно пишет слишком мало, а потом ловит баги.

Главное понять суть PropertyChanged и когда надо вызывать его, тогда человек будет писать достаточно и без багов.

Посоны, напомните, если я хочу подружить UITapGestureRecognizer и RelayCommand в MVVM Light, куда мне смотреть?

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

Главное понять суть PropertyChanged и когда надо вызывать его, тогда человек будет писать достаточно и без багов.

Понимание сути приводит к использованию Fody вместо рукопирастии

Понимание сути приводит к использованию Fody вместо рукопирастии

дебажить сложнее

Дебаг нагенеренного нужен при проблемах с обновлением, которых с Fody меньше или нет совсем

Понимание сути приводит к использованию Fody вместо рукопирастии

Наоборот. Чем больше опыта, тем меньше библиотек) Как раз со своей реализацией все понятнее, и как Кита сказал - сложнее с fody дебажить, порой приходилось IL смотреть даже, что бы понять где проблема.

Дебаг нагенеренного нужен при проблемах с обновлением, которых с Fody меньше или нет совсем

С Fody меньше проблем, чем со своей реализацией? да ну

Наоборот. Чем больше опыта, тем меньше библиотек) Как раз со своей реализацией все понятнее, и как Кита сказал - сложнее с fody дебажить, порой приходилось IL смотреть даже, что бы понять где проблема.

NIH - это не опыт

Посоны, напомните, если я хочу подружить UITapGestureRecognizer и RelayCommand в MVVM Light, куда мне смотреть?

типа так view.AddGestureRecognizer(new UITapGestureRecognizer(()=> { ViewModel.Command.Execute(); }));

Дебаг нагенеренного нужен при проблемах с обновлением, которых с Fody меньше или нет совсем

ну допустим самое распространенное - понять почему не работают биндинги. Нужно вообще посмотреть а приходит ли значение во вьюмодель. С Fody это затруднительно сделать) Тратишь больше времени. А типа сэкономил на написании пары строк

NIH - это не опыт

Ок, скажем так - с опытом приходит понимание, для каких вещей лучше библиотеки, а для каких - своя реализация. Для инкремента подключать огромную библиотеку с 1кк функций - крайне не разумно. Fody - как раз комбайн.

Каким местом Fody комбайн? NullGuard отдельно, PropertyChanged отдельно, пользуешься ровно тем, что нужно

Каким местом Fody комбайн? NullGuard отдельно, PropertyChanged отдельно, пользуешься ровно тем, что нужно

Ок, продолжу аналогиями: шасси комбайна ради стеклоомывателей) PropertyChanged реализуется 1 простым классом

> PropertyChanged реализуется 1 простым классом Плюс необходимость наследоваться от него, плюс необходимость райзить ручками для каждой зависимости, плюс код вида SetAndRaiseIfChanged, за которым собственно логики вью-модели не видно

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

вот за это отдельное спасибо, почитаю

> PropertyChanged реализуется 1 простым классом Плюс необходимость наследоваться от него, плюс необходимость райзить ручками для каждой зависимости, плюс код вида SetAndRaiseIfChanged, за которым собственно логики вью-модели не видно

наследоваться - да. Райзить - все внутри. Вызывать только в редких случаях зависимостей. SetAndRaiseIfChanged - нет такого. У нас такая реализация: public string Notes { get => Get<string>(); set => Set(value); } Просто проперти, а внутри уже OnPropertyChanged вызывается и тд. И логика VM остается чистой.

> У нас такая реализация Как различаются разные свойства одного типа?

> У нас такая реализация Как различаются разные свойства одного типа?

По названию Property очевидно.

> У нас такая реализация Как различаются разные свойства одного типа?

зачем их различать?

В частности, если есть зависимая проперти, то можно так set { if (Set(value)) NotifyOfPropertyChanged(nameof(ButtonText)); }

какую это задачу решает?

По названию Property очевидно.

В приведенном вызове метода Get нет имени Property - используется caller member name?

В приведенном вызове метода Get нет имени Property - используется caller member name?

Да

Но можно и передать название)

Да

Т.е. магии не меньше, чем в Fody, церемониал ручного вызвова в ряде случаев (как раз самых сложных) сохранен, добавлено обременение наследованием. Разумеется, вы вправе считать, что вам оно дешевле, чем Fody. Мне всегда было наоборот.

то есть, логика такая: 1. создается модель 2. логикой приложения модель заполняется 3. в представлении осуществляется привязка к св-вам модели 4. в модели реализуется INotify… и все это начинает “само обновляться” при изменении значений полей в модели, верно?

Т.е. магии не меньше, чем в Fody, церемониал ручного вызвова в ряде случаев (как раз самых сложных) сохранен, добавлено обременение наследованием. Разумеется, вы вправе считать, что вам оно дешевле, чем Fody. Мне всегда было наоборот.

А с Fody расслабляешься и все равно для сложных сценариев нужно вручную вызывать событие, а для этого опять же надо добавлять свою реализацию.

то есть, логика такая: 1. создается модель 2. логикой приложения модель заполняется 3. в представлении осуществляется привязка к св-вам модели 4. в модели реализуется INotify… и все это начинает “само обновляться” при изменении значений полей в модели, верно?

да

теперь понятно, благодарю

то есть, логика такая: 1. создается модель 2. логикой приложения модель заполняется 3. в представлении осуществляется привязка к св-вам модели 4. в модели реализуется INotify… и все это начинает “само обновляться” при изменении значений полей в модели, верно?

Пункты 1 и 2 лучше объединить

Sergey попрошу без мата

Пункты 1 и 2 лучше объединить

почему? если по mvvm, то модель не должна содержать логику

вроде бы

для тех, кто не хочет использовать Fody и не хочет писать INotifyPropertyChanged ручками, рекомендую тоненькую библиотеку от James Montemagno - https://github.com/jamesmontemagno/mvvm-helpers

почему? если по mvvm, то модель не должна содержать логику

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

Вью-модель может взять данные только из модели или параметров конструктора - в других местах их нет.

для тех, кто не хочет использовать Fody и не хочет писать INotifyPropertyChanged ручками, рекомендую один класс от Xamarin University https://github.com/xamarinhq/xamu-infrastructure/blob/master/src/XamU.Core/Mvvm/SimpleViewModel.cs

Вью-модель может взять данные только из модели или параметров конструктора - в других местах их нет.

т.е. запрос к API должен быть реализован в модели?

Модель сама ничего передать вью-модели не может, так как о ней ничего не знает. А никакой "логики приложения" вне модели и вью-модели по MVVM нет.

т.е. запрос к API должен быть реализован в модели?

в Data Layer

Который в модели. да

т.е. запрос к API должен быть реализован в модели?

Если у тебя клиент, который должен обращаться к серверу - да

UrhoSharp переедет на Net Standart 2.0, если да, то как скоро?

UrhoSharp переедет на Net Standart 2.0, если да, то как скоро?

руки до него не доходят :(

руки до него не доходят :(

А там много работы в этом направлении?

не особо

просто много муторной работы)

Если у тебя клиент, который должен обращаться к серверу - да

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

Похоже что Azure и App Center тоже заблокировали - вчера без VPN не работало. Ну и nuget, как выше писали. У кого-нибудь ещё были проблемы с доступом в App Center?

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

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

тесты отсутствуют, верно. а их надо бы делать. суть уловил, спасибо.

Похоже что Azure и App Center тоже заблокировали - вчера без VPN не работало. Ну и nuget, как выше писали. У кого-нибудь ещё были проблемы с доступом в App Center?

Потдтверждаю AppCenter не работает без VPN

Коллеги, у кого-о есть подобная проблема: https://stackoverflow.com/questions/49877191/running-xamarin-uitest-on-macos-for-ios-deviceagent-start-session-failed ?

https://github.com/aspnet/Docs/issues/5832

UrhoSharp переедет на Net Standart 2.0, если да, то как скоро?

Оно же вроде и так работало когда я проверял последний раз. Цепляло сборку под 4.6 но работало

Оно же вроде и так работало когда я проверял последний раз. Цепляло сборку под 4.6 но работало

Вот не цепляло бы... конкретно тестировал UrhoSharp.Forms (пока только 1 баг видел, но там скорее просто обновление сцены надо), очень удобная штука, если нужно отображать 3D с формами. Сам порог вхождения низкий, примеров просто куча.

Формс у меня и обычные не сработали

Всё остальное после нескольких дней перестаёт работать как надо

Например, собрал проект, залил его на девайс, протестил, потом какое-то время он просто был на телефоне, через какое-то время (недели 2) запускаю - краш.

а оно случаем не в конфиге Debug было?

а оно случаем не в конфиге Debug было?

В дебаге, да. Краш при запуске именно Urho страницы, само приложение нормально запускается

попробуйте отрубить Fast Deployment в Debug , и всё будет работать

это норма

угу. и Shared Runtime

оно какие-то там shared object чистит

this

надо походу в дебажные билды впиливать мессадж бокс/алерт с текстом "ДЕБАГ с шаред рантаймом"

Хочу описать как воспроизвести баг с черным экраном на UrhoSharp.Forms: если приложение сворачивать и разворачивать - все ок, если сделать скрин, - все ок, но если сделать скрин и перейти по нему в библиотеку изображений через выпадающее по свайпу меню Android, а потом вернуться в приложение - будет черный экран поверхности отрисовки 3D, сами же кнопки Xamarin.Forms поверх неё нормально отображаются.

Ребят, не подскажете почему не вызывается метод OnDetachingFrom() в Behavior, который я вешаю на страницу?

Не подскажете как ускорить запуск xamarin forms приложения на андроид? И как отследить время запуска программно

Не подскажете как ускорить запуск xamarin forms приложения на андроид? И как отследить время запуска программно

logcat и сыпать мессаджами в Application классе на OnCreate OnStart итд

Не подскажете как ускорить запуск xamarin forms приложения на андроид? И как отследить время запуска программно

Но запуск формсов не ускорить никак.

@Alex_Relov нужно чуть-чуть подождать https://blog.xamarin.com/visual-studio-2017-version-15-7-preview-3/

ага. Это слышно 2 года уже. Ну-ж-но-нем-но-го-по-тер-пе-ть

ахах

справедливости ради, forms побыстрее вроде стали ?

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

я не использую их в работе, визуально примеры смотрю

В общем я бы советовал не ждать когда станет лучше перфоманс формсов. Не станет. Все равно он не достигнет показателей типа “старт за 1-1,5с на не самых топовых телефонах”

А вот Xamarin Сlassic так может при использовании правильного подхода

Извиняюсь за нубский вопрос, а что такое перформанс?