Не по советуете группы каналы по uwp xamarin разработке?

Не по советуете группы каналы по uwp xamarin разработке?

https://channel9.msdn.com/Series/Windows-10-development-for-absolute-beginners/UWP-039-Adaptive-Layout-with-Device-Specific-Views

так можно дойти до вопроса "зачем может понадобится написать код try { /*пустой*/ } finally { code(); }

Чтобы запутать коллегу, очевидно

Вкратце обозреть framework's и подытожить тем, что они не нужны

Ну вот. Ты же вроде выкатился из велосипедов и вкатился в ReactiveUI и Fody? :)

Ну вот. Ты же вроде выкатился из велосипедов и вкатился в ReactiveUI и Fody? :)

Fody тут не нужен. ReactiveUI сойдет, но тоже не нужен

Оно очень удобно, но чисто в колено себе выстрелить боюсь

А Elmish.Xamarin кто-то уже ковырял? Он только для Forms или для Android отдельно можно сделать?

Fody тут не нужен. ReactiveUI сойдет, но тоже не нужен

Почему это не нужен? Лучше ручками геттеров и сеттеров понаписать?

А Elmish.Xamarin кто-то уже ковырял? Он только для Forms или для Android отдельно можно сделать?

Только Forms.

Почему это не нужен? Лучше ручками геттеров и сеттеров понаписать?

да

Есть некоторая проблема с хранением этих значений в неком своем поле и сохранении на устройство, в случае необходимости

Например, чтобы восстановить состояние

Тут как бы все немного (много) сложнее, чем бахать в WPF

Ну вот. Ты же вроде выкатился из велосипедов и вкатился в ReactiveUI и Fody? :)

Как бы еще раз, я ничего против этого не имею, но Fody тут не нужен, как по мне

Например, чтобы восстановить состояние

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

Вообще я игрался с Xamarin.Forms и там с Фоди было норм. В Xamarin.Native наверно есть свои нюансы, действительно (на самом деле было бы интересно послушать доклад на эту тему)

Вообще я игрался с Xamarin.Forms и там с Фоди было норм. В Xamarin.Native наверно есть свои нюансы, действительно (на самом деле было бы интересно послушать доклад на эту тему)

Как я понял, у них там получается недобор спикеров, как таковых.

И если вдруг наберем, то возможно выступим тут http://techtrain.ru/ , в отдельном треке по Xamarin

Вообще я игрался с Xamarin.Forms и там с Фоди было норм. В Xamarin.Native наверно есть свои нюансы, действительно (на самом деле было бы интересно послушать доклад на эту тему)

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

Для Android - это +- критично, ведь твоя Shared выполняется в своем рантайме на ведре

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

Да и есть ограничение на количество методов (хотя, это легко обходится, но все же)

Чисто из-за размера даже выходит, что лишний кодоген тебе не нужен

Чисто из-за размера даже выходит, что лишний кодоген тебе не нужен

Там можно ему запрещать кодгенить ненужные свойства. Будет кодгенить только там, где без Fody ты бы сам квасил backing field и OnPropertyChange. Всяко почище.

Там можно ему запрещать кодгенить ненужные свойства. Будет кодгенить только там, где без Fody ты бы сам квасил backing field и OnPropertyChange. Всяко почище.

Да, я понимаю это

Или ты про кеширование PropertyChangedEventArgs?

Только Forms.

Спасибо

Или ты про кеширование PropertyChangedEventArgs?

+

+

Ну тут да. Но! Можно посмотреть историю коммитов и вытащить из нугета версию, где эти кеши ещё не ввели :D

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

Ну тут да. Но! Можно посмотреть историю коммитов и вытащить из нугета версию, где эти кеши ещё не ввели :D

Ну это уже не очень прикольно. Хотя весьма рабочая тема, для Xamarin в целом

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

Чисто для Xamarin было-бы не плохо написать что-то вроде обертки для хранения даже самих значений пропертей. В условной SQLite, например

Чисто для Xamarin было-бы не плохо написать что-то вроде обертки для хранения даже самих значений пропертей. В условной SQLite, например

Накидаешь пример?

и подключения к фуди

Накидаешь пример?

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

И вот ты уже получил веретено из непонятно чего

Что решается стандартной записью в Properties приложения, обернутой в OnPropertyChanged()

Так что я думаю когда ты пишешь продакшон, мейби не стоит мудрить

Там можно ему запрещать кодгенить ненужные свойства. Будет кодгенить только там, где без Fody ты бы сам квасил backing field и OnPropertyChange. Всяко почище.

Можно и без фоди красивый код получить без ручного вызова OnPropertyChange и создания backing field. Конечно не 1 строчка {get;set}, а { get => Get<string>(); set => Set(value); } Но тоже неплохо, зато всё понятно что происходит, без тёмной магии.

И чуть дописав логику как раз можно сделать хранение пропертей, сейчас в моей реализации они все банально в ConcurrentDictionary<string, object>

И чуть дописав логику как раз можно сделать хранение пропертей, сейчас в моей реализации они все банально в ConcurrentDictionary<string, object>

Ну, это тоже магия. И она тормозит, в отличие от Fody. Вообще в таких вещах C# конечно сильно проигрывает Javascript-у. Там поддержка декораторов на уровне языка, а у нас с зависимостью от Fody/MrAdvice/PostSharp, которых, почему-то, все боятся (хотя причин на это я не вижу никаких).

Ну, это тоже магия. И она тормозит, в отличие от Fody. Вообще в таких вещах C# конечно сильно проигрывает Javascript-у. Там поддержка декораторов на уровне языка, а у нас с зависимостью от Fody/MrAdvice/PostSharp, которых, почему-то, все боятся (хотя причин на это я не вижу никаких).

почему тормозит то? Ну да, работает чуть медленнее из-за записи/чтения из Dictionary, но это экономия на спичках.

Про сохранение стейта конечно интересные аргументы, надо будет поискать решение. Надо стремиться в противоположную бойлерплейту сторону, 2018 год же на дворе :)

почему тормозит то? Ну да, работает чуть медленнее из-за записи/чтения из Dictionary, но это экономия на спичках.

потому что boxing/unboxing

Зачем использовать библиотеки с черной магией для таких простых задач, когда можно без них?)

потому что boxing/unboxing

Проверял же и тебе о результатах отпиисывался. Кучу раз писал в Dictionary<string, object> разного типа объекты и примитивы, и в кучу разных словарей в зависимости от типа - разницы никакой не заметил. то один способ быстрее, то другой. На уровне статистической погрешности работает. Так что не вижу смысла усложнять логику. И прям много Binding Property в приложении, что критичны теоретические миллисекунды на эти операции, когда есть задержка на сетевые запросы, отрисовку и тд, которые на порядки дольше выполняются?

Проверял же и тебе о результатах отпиисывался. Кучу раз писал в Dictionary<string, object> разного типа объекты и примитивы, и в кучу разных словарей в зависимости от типа - разницы никакой не заметил. то один способ быстрее, то другой. На уровне статистической погрешности работает. Так что не вижу смысла усложнять логику. И прям много Binding Property в приложении, что критичны теоретические миллисекунды на эти операции, когда есть задержка на сетевые запросы, отрисовку и тд, которые на порядки дольше выполняются?

в xf это вообще капля в море, согласен

на такие мелочи можно забить

Ну сам попробуй протестить - я не нашел задержек на boxing/unboxing даже на миллионах операций

в xf это вообще капля в море, согласен

даже в нативе можно)

Ну сам попробуй протестить - я не нашел задержек на boxing/unboxing даже на миллионах операций

ну да, это экономия на спичках.

Н-да, однако, на WPF/UWP проект без Fody я бы, конечно, не сел. Вьюмодели многократно раздуваются и усложняются, отнимая на себя много времени, Fody значительно упрощает код. Насчёт XF с вами спорить не буду, возможно, у него пока особый путь :)

Н-да, однако, на WPF/UWP проект без Fody я бы, конечно, не сел. Вьюмодели многократно раздуваются и усложняются, отнимая на себя много времени, Fody значительно упрощает код. Насчёт XF с вами спорить не буду, возможно, у него пока особый путь :)

А ты не создавай супер-вьюмодели

Это равнозначно проблеме супер-вьюконтроллера на нативном iOS и которую решают дроблением

Н-да, однако, на WPF/UWP проект без Fody я бы, конечно, не сел. Вьюмодели многократно раздуваются и усложняются, отнимая на себя много времени, Fody значительно упрощает код. Насчёт XF с вами спорить не буду, возможно, у него пока особый путь :)

А какую именно на WPF/UWP логику скрывает Fody?

А ты не создавай супер-вьюмодели

У меня обычно много не-супер-вьюмоделей. И желание бойлерплейтить от этого сильнее не становится.

А какую именно на WPF/UWP логику скрывает Fody?

Ровно ту же самую.

Ровно ту же самую.

Binding Property?

Binding Property?

INPC :)

После бэкграунда на Ангуляре предпочитаю не видеть мусор типа INPC в своём коде.

а ещё нужно бывает завязать одну преперти на другу. Set может возвращать bool значение изменилась проперти или нет. Если да - то какая-то логика изменения другой проперти. И у той тоже в сеттере какая-то логика

INPC :)

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

а ещё нужно бывает завязать одну преперти на другу. Set может возвращать bool значение изменилась проперти или нет. Если да - то какая-то логика изменения другой проперти. И у той тоже в сеттере какая-то логика

На самом деле для таких кейсов есть божественный ReactiveUI — WhenAnyValue и мапишь связи между свойствами в fluent стиле. Ещё можно дёргать команды и запускать таски.

ERROR: S client not available

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

Ну, у меня на проектах данные в риалтайме отображать нужно, так что проблема. И лучше бы лишний раз её не решать

На самом деле для таких кейсов есть божественный ReactiveUI — WhenAnyValue и мапишь связи между свойствами в fluent стиле. Ещё можно дёргать команды и запускать таски.

ну реактивщина, да, спасает. Но не все сразу могут въехать в неё

Вместо написания 2 строк добавлять 2 библиотеки. Ну такое себе..))

именно

При этом во многом от бойлерплейта ты избавляешься и за собой кучу всего что тебе не нужно и может выстрелить в ногу - не тащишь.

А уитывая что каждая библиотека добавляет времени к времени сборки/деплоя, размеру приложению, возможным багам.. Поэтому такие простые вещи, которые легко сделать без библиотек - предпочитаю сам делать)

Извечный, конечно, холивар. Таскать за собой замарин размером в 20 мегабайт и зажимать 100 килобайт для библиотек, которые жизнь спасают.

Если мне будет важен размер бинарника, я возьму плюсы или котлин. :) В общем это всё скорее вопрос религии либо конкретно Замарина. В Uwp и Wpf-мирах с Fody проблем нет.

как-то передёргиваете на плюсах сложно будет кроссплатформу с нативными вьюшками написать

Извечный, конечно, холивар. Таскать за собой замарин размером в 20 мегабайт и зажимать 100 килобайт для библиотек, которые жизнь спасают.

в каком месте 20мб?

Есть предложение проголосовать за бесплатный профайлер: https://xamarin.uservoice.com/forums/144858-xamarin-platform-suggestions/suggestions/32298319-xamarin-profiler-s-huge-paywall-propagates-low-qua

Извечный, конечно, холивар. Таскать за собой замарин размером в 20 мегабайт и зажимать 100 килобайт для библиотек, которые жизнь спасают.

Ну блин, не тащить библиотеку (кстати с Fody и сборка дольше немного идет из-за кодо генерации), что бы написать public string Name {get; set;} вместо public string Name { get => Get<string>(); set => Set(value); } Учитывая что есть темплейты.. И это при условии, что нет кастомных сеттеров, а с ними разница еще меньше) Да еще и при первом способе добавляется backing field, а во втором - нет =)

Если мне будет важен размер бинарника, я возьму плюсы или котлин. :) В общем это всё скорее вопрос религии либо конкретно Замарина. В Uwp и Wpf-мирах с Fody проблем нет.

Вот есть тезис: “В Uwp и Wpf-мирах с Fody проблем нет.” Самое важное что должны понять ВСЕ. Мобайл мир андроида и айос это другой мир и в него подходы из .Net тащить категорически не рекомендуется

Вот есть тезис: “В Uwp и Wpf-мирах с Fody проблем нет.” Самое важное что должны понять ВСЕ. Мобайл мир андроида и айос это другой мир и в него подходы из .Net тащить категорически не рекомендуется

Соглашусь. Рассудили :)

в каком месте 20мб?

А насколько там сейчас можно ужать сборку? Года 2-3 назад вроде были какие-то такие цифры

Я не понимаю только если все dll aotятся то зачем упаковывать ещё этих dll на 10мб, но если не упаковать - ничего работать не будет. Благо они сжимаются хорошо

На флагманах просто моментальный запуск. Даже нет необходимости делать какой-то сплэш) но не на флагманах 1сек все же показывать что-то надо как мне кажется)

Круто. ???

Годный тутор и опенсорс для вкатывания в реактивность, кстати https://github.com/kentcb/WorkoutWotch

Есть предложение проголосовать за бесплатный профайлер: https://xamarin.uservoice.com/forums/144858-xamarin-platform-suggestions/suggestions/32298319-xamarin-profiler-s-huge-paywall-propagates-low-qua

а ещё есть предложение голосовать за с++ проекты в Visual Studio for Mac https://visualstudio.uservoice.com/forums/563332-visual-studio-for-mac/suggestions/17141708-support-c-in-visual-studio-for-mac Вообще дохрена чего делать надо. На ios кстати можно пользоваться нативными профайлерами. На андоиде утечки памяти в принципе можно тоже внутренними инструментами поймать

а ещё есть предложение голосовать за с++ проекты в Visual Studio for Mac https://visualstudio.uservoice.com/forums/563332-visual-studio-for-mac/suggestions/17141708-support-c-in-visual-studio-for-mac Вообще дохрена чего делать надо. На ios кстати можно пользоваться нативными профайлерами. На андоиде утечки памяти в принципе можно тоже внутренними инструментами поймать

Наверное больше речь идёт про перфоманс, чем про профайлинг памяти.

плюсы можно и в Xcode открыть так-то

плюсы можно и в Xcode открыть так-то

С++ на маке вообще откровенный шлак

imo VS4Mac должен быть сфокусирован на .NET потому что у нас нет другого выхода а когда гуй можно открыть в нативном, плюсы в каком стороннем редакторе от IntelliJ – ну ок, потерпится

явно мощности ограничены у их команды

вот там в голосованиях просят Node.js и Python когда есть VS Code уже

вот там в голосованиях просят Node.js и Python когда есть VS Code уже

Python и JS не нужны, ни в коем случае. Для этого есть WebStorm и PythonNotebooks

плюсы можно и в Xcode открыть так-то

можно