Xamarin

В статье представлены обобщённые подходы применения конвертеров значений при написании XAML-кода.

IValueConverterData BindingXAMLWPFUWPXamarin FormsUISwitchConverterKeyToValueConverterInlineConverterAggregateConverterResourceDictionary

Конвертеры значенийсовместно с механизмом привязки данных являются важными компонентами в разработке пользовательских интерфейсов на основеXAML. Конвертеры значений подразумевают наличие логики, помещенной в отдельный класс, реализующий интерфейсIValueConverter. Обычно имя класса отражает функциональное назначение, а сами экземпляры декларируются в разметке.

Switch Converter & Key To Value Converter

На практике многие конвертеры значений имеют тривиальную логику схожую по структуре стернарным оператором (?:)или конструкциямif-else,switch-case-default. Однако существуют обобщенные шаблоныKeyToValueConverterиSwitchConverter, которые позволяют избежать добавления в проект однотипных по структуре классов путём декларирования логических значений и ветвлений непосредственно в разметке.

Концепция

<KeyToValueConverterKey="KeyForMatching"Value="ValueIfKeyMatched"ByDefault="ValueIfKeyNotMatched" /><SwitchConverterByDefault="ValueZ"><CaseKey="KeyA"Value="ValueA" /><CaseKey="KeyB"Value="ValueB" /><CaseKey="KeyC"Value="ValueC" /></SwitchConverter>

Применение

<KeyToValueConverterx:Key="TrueToVisibleConverter"Key="True"Value="Visible"ByDefault="Collapsed" /><ProgressBarVisibility="{Binding IsBusy, Converter={StaticResource TrueToVisibleConverter}}" />

<SwitchConverterx:Key="CodeToBackgroundConverter"ByDefault="White"><CaseKey="R"Value="Red" /><CaseKey="G"Value="Green" /><CaseKey="B"Value="Blue" /></SwitchConverter><ControlBackground="{Binding Code, Converter={StaticResource CodeToBackgroundConverter}}" />

KeyToValueConverter- проверяет входное значение на соответствие со значением из свойстваKey, если соответствие выполнено, то в качестве выходного берётся значение из свойстваValue, в противном случае из свойстваByDefault.

SwitchConverter- выполняет поиск первого соответствующегоCaseиз списка по его ключу из свойстваKey, если соответствующийCaseнайден, то берётся заданное в нём значение из свойстваC31C, в противном случае из свойстваC90CC32C, заданного в самом конвертере значений.

Если свойствоValueилиByDefaultявно не задано, но выполняется соответствующее ему условие, то в таком случае происходит обыкновенный проброс входного значения в качестве выходного.

Также уKeyToValueConverterиногда полезно задавать ключ вConverterParameterчерез свойствоKeySource

<KeyToValueConverterx:Key="EqualsToHiddenConverter"KeySource="ConverterParameter"Value="Collapsed"ByDefault="Visible" /><ControlVisiblity="{Binding Items.Count, ConverterParameter=0, Converter={StaticResource EqualsToHiddenConverter}}" /><TextBlockVisiblity="{Binding Text, ConverterParameter='Hide Me', Converter={StaticResource EqualsToHiddenConverter}}" />

Для особых случаев уKeySourceвозможны четыре режима работы:

Manual(by default) - в качестве ключа при проверке соответствия всегда используется значение из свойстваKeyлибо выполняется проброс значения, когда оно не задано

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

PreferManual- еслиmanual Keyявно задан, то он имеет приоритет передConverterParameter

PreferConverterParameter- еслиConverterParameterявно задан, то он имеет приоритет перед manualKey

Стоит также отметить, что уSwitchConverterпомимо обычныхCaseдоступны такжеTypedCase, основное отличие которых в проверке на соответствие по типу значения

<SwitchConverterByDefault="Undefined value"><TypedCaseKey="system:String"Value="String value" /><CaseKey="0"Value="Zero" /><CaseKey="1"Value="One" /><TypedCaseKey="system:Int32"Value="Int32 value" /></SwitchConverter>

Иногда возникает необходимость продебажить работу конвертера значений. Для этой цели уSwitchConverterпредусмотрено свойствоDiagnosticKey, если оно задано, то при срабатывании привязки данных вTraceбудут выводится диагностические сообщения следующего формата

var diagnosticMessage = matchedCase.Is()? $"{DiagnosticKey}: '{matchedValue}' matched by key '{matchedCase.Key}' for '{value}' and converted to '{convertedValue}'": $"{DiagnosticKey}: The default value '{matchedValue}' matched for '{value}' and converted to '{convertedValue}'";Trace.WriteLine(diagnosticMessage);

<SwitchConverterDiagnosticKey="UniqDiagnosticKey"x:Key="CodeToBackgroundConverter"ByDefault="White">...</SwitchConverter>

Dependency Value Converter

Также свойства Key, Value и ByDefault полезно объявлять в качестве свойств зависимости (Dependency Properties), то есть наследовать конвертеры и Cases от класса DependencyObject. Хотя конвертеры значений обычно не являются элементами визуального дерева, что отчасти ограничивает работу механизма привязки данных, тем не менее остаётся возможность производить привязку к статическим ресурсам или наследникам класса Binding, например

<KeyToValueConverterKey="AnyKey"Value="{Binding MatchedValue, Source={StaticResource AnyResource}}"ByDefault="{Binding DefaultValue, Source={StaticResource AnyResource}}" /><KeyToValueConverterKey="AnyKey"Value="{Localizing MatchedTitle}"ByDefault="{Localizing DefaultTitle}" />

Inline Converter

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

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

Для этого необходимо добавить декларацию конвертера в разметку, а code-behind классе определить обработчики для соответствующих событий Converting и ConvertingBack

<Grid><Grid.Resources><InlineConverterx:Key="ComplexInlineConverter"Converting="InlineConverter_OnConverting"ConvertingBack="InlineConverter_OnConverting" /></Grid.Resources><TextBlock Text="{Binding Number, Converter={StaticResource InlineConverter}}"/></Grid>

private void InlineConverter_OnConverting(object sender, ConverterEventArgs e){// e.Value - access to input value// this.DataContext - access to Data Context or another properties of the view// access to child visual elements of this root viewe.ConvertedValue = // set output value$"DataContext: {DataContext}, Converter Value: {e.Value}";}private void InlineConverter_OnConvertingBack(object sender, ConverterEventArgs e){// ...}

Aggregate Converter

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

<AggregateConverter><StepAConverter /><StepBConverter /><StepCConverter /></AggregateConverter>

App.xaml

Обобщённые конвертеры значений полезно помещать в отдельный Resource Dictionary, а затем мержить их в качестве глобальных ресурсов в файл App.xaml. Это позволяет переиспользовать конвертеры значений в различных представлениях без их повторного декларирования.

<Applicationxmlns="http://personeltest.ru/away/xamarin.com/schemas/2014/forms"xmlns:x="http://personeltest.ru/away/schemas.microsoft.com/winfx/2009/xaml"x:Class="Any.App"><Application.Resources><ResourceDictionary><ResourceDictionary.MergedDictionaries><ResourceDictionary Source="AppConverters.xaml" />...</ResourceDictionary.MergedDictionaries></ResourceDictionary></Application.Resources></Application>

Ace Framework

Примеры реализации представленных конвертеров можно найти в библиотеке Ace Framework gitlab bitbucket

С благодарностью за внимание и интерес!

Когда речь заходит о разработке сразу для Android и iOS, начинаются холивары и гадания на кофейной гуще. Что перспективнее, Flutter или Kotlin Multiplatform? За этими технологиями будущее, или завтра их обе забудут?

Уверенно делать прогнозы по принципу я так вижу занятие весёлое, но бессмысленное. Как подойти конструктивнее? Как известно, кто забывает об истории, обречён на её повторение. Поэтому я решил вспомнить, какими были предыдущие решения Android+iOS, и посмотреть, что с ними стало. Тогда вместо голых спекуляций будут суровые факты. И эти факты из прошлого полезны для понимания будущего: они показывают, где разложены грабли.

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

Оглавление

• Web / PWA

• PhoneGap / Apache Cordova

• Qt

• Xamarin

• React Native

• Выводы

Web / PWA

В 2007-м, представляя разработчикам первый iPhone, Стив Джобс объяснял, что нативные приложения не нужны: В iPhone есть полный движок Safari. Так что можете писать потрясающие Web 2.0 и Ajax-приложения, которые выглядят и действуют на iPhone именно как приложения.

Android на тот момент ещё даже не был анонсирован. Но получается, что исторически первым единым решением для iOS и Android стал веб.

Вот только разработчики тогда не разделили энтузиазма Джобса (неудивительно, учитывая тогдашнее состояние мобильного интернета). И годом позже всё-таки появился App Store для нативных приложений. А его комиссия в 30% стала новым денежным потоком для компании. В итоге её позиция сменилась на противоположную: теперь Apple считает, что правильный подход это натив (и предпочитает не вспоминать, что там её лидер говорил в 2007-м, Океания всегда воевала с Остазией).

Однако идея веб-приложений не исчезла, а продолжила развиваться. И в 2015-м новое поколение таких приложений назвали Progressive Web Apps. Они могут хранить данные локально, работать в офлайне, а ещё их можно установить на домашний экран смартфона. Чем это тогда не настоящие мобильные приложения? Что ещё для счастья надо?

Ну, например, для счастья нужны push-уведомления. По состоянию на 2021-й iOS не поддерживает их у PWA, и это мощнейший стопор для распространения подхода. Получается, компания, которая первой хвалила веб-приложения, позже сама поставила главное препятствие на их пути. На change.org есть даже петиция, обращённая к Apple: мы всё понимаем, вы дорожите своими 30%, но эта ситуация должна измениться.

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

PhoneGap/Apache Cordova

Это решение тоже связано с вебом, но подход другой так называемый гибридный. Тут предложили использовать знакомую троицу HTML/CSS/JS, но результат не публиковать в виде сайта, а упаковать в контейнер нативного приложения. В таком случае не сталкиваешься с ограничениями веба и можешь реализовать те же push-уведомления.

PhoneGap появился в 2009-м благодаря компании Nitobi, а в 2011-м Adobe купила её и создала также опенсорсный вариант Apache Cordova. У проекта модульная архитектура, позволяющая подключать плагины. И в сочетании с опенсорсностью это означает, что если Cordova не умеет чего-то нужного (например, взаимодействовать с акселерометром смартфона), сообщество может научить. Вроде как прекрасно, да?

На практике что-то не очень. В своё время некоторая популярность у проекта была, те же плагины появлялись, но масштабного захвата рынка не произошло. А затем всё и вовсе пошло на спад.

Почему так? Среди главных причин называют UX, уступающий нативным приложениям. Всё хуже и с производительностью, и с плавностью. Но основное отличие даже не измерить числами: пользователю попросту заметна разница между гибридным приложением и нативным, они производят разное впечатление. Для людей через WebView ощущения не те.

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

Интересно, что авторы проекта сами предвидели такое развитие событий и ещё в 2012-м написали, что итоговая цель PhoneGap прекратить своё существование. И недавно эта цель была достигнута: в 2020-м Adobe заявили о прекращении разработки, ссылаясь на то, что нишу закрыли PWA.

Что в итоге: разработка прекращена.

Qt

Проект Qt помогал людям заниматься кроссплатформенной разработкой ещё с 90-х, когда речь шла о десктопных ОС, а не мобильных. При этом он завязан на C++, который для Android и iOS не совсем чужой: даже нативные разработчики на этих платформах могут обращаться к плюсам. Так что, казалось бы, поддержка iOS/Android со стороны Qt просто напрашивалась.

Но поначалу дело осложнялось тем, что в 2008-м проект купила Nokia. Компания тогда делала ставку на Symbian и не горела желанием помогать конкурентам. В 2010-м возможностью запускать Qt-приложения на Android занимались энтузиасты, и на Хабре об этом писали:

В 2011-м Nokia отказалась от Symbian в пользу Windows Phone, а часть проекта Qt продала компании Digia. И тогда началась работа над поддержкой одновременно Windows 8, Android и iOS. Ну вот теперь-то счастье? Спустя 10 лет ясно, что тоже нет.

Вакансии по мобильной разработке на Qt сейчас единичные. Хабрапосты о ней появляются очень редко и не свидетельствуют об успехе: в одном причиной использования Qt стала ОС Аврора (экс-Sailfish), в другом попросту у меня уже был большой опыт с ним.

Что помешало? Я встречал жалобы на то, что недостаточно было использовать сам Qt и писать на С++/QML. Потому что средствами Qt многое было не реализовать, и приходилось-таки иметь дело с конкретной платформой (например, на Android работать с Java, увязывая это с плюсовой частью через JNI). Всё это очень неудобно и подрывает исходную идею бодренько запилим два приложения по цене одного.

При этом здесь пользователь тоже ощущает не-нативность. А к IDE Qt Creator есть нарекания, рантайм Qt увеличивает размер приложения, бесплатный вариант Qt подходит не всегда и может понадобиться недешёвый коммерческий. Кроме того, мне лично кажется, что ещё сказался язык. Кроссплатформенной разработке желательно быть такой, чтобы нативным разработчикам было попроще перекатиться туда, а с языком C++ слово попроще не ассоциируется.

И хотя случаи использования Qt встречаются до сих пор, это скорее исключения из правил, у которых могут быть какие-то особые исходные условия: например, хотим перетащить на телефоны с десктопа уже имеющуюся кодовую базу на C++.

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

Xamarin

Мигель де Икаса ещё в проекте Mono занимался тем, что притаскивал .NET на несвойственные ему платформы (начав с Linux). А когда в 2011-м он вместе со всей командой Mono попал под сокращение, основал новую компанию Xamarin, собрал прежних коллег там, и сосредоточился на мобильных платформах: мол, давайте писать мобильные приложения для них на C#, вот инструмент для этого.

Надо понимать контекст того времени. Годом ранее компания Microsoft выпустила Windows Phone и стремилась стать третьим большим игроком на мобильном рынке. И даже большая Windows лезла на мобильный рынок: готовилась к выходу Windows 8, оптимизированная для планшетов.

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

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

Ещё порой вызывали недовольство и то, что после появления новых фич в Android/iOS приходилось ждать их поддержки в Xamarin, и стоимость лицензии, и общее состояние экосистемы (документация, поддержка, библиотеки).

А тем временем компания Microsoft возлюбила опенсорс и сторонние платформы вроде Linux, так что идеи де Икасы оказались ей близки, и в итоге она купила Xamarin. Теперь его наработки вошли в .NET 5, и в прошлом году представили .NET MAUI (Multi-platform App UI) развитие тулкита Xamarin.Forms. В общем, не забросили купленное.

Что в итоге: пока всё остаётся в странноватом статусе, когда и масштабного взлёта не получилось, и полностью не прекращено.

React Native

Наконец, самое свежее. В 2013-м в Facebook выпустил React, ставший очень успешным во фронтенде, а в 2015-м за ним последовал React Native, приносящий подход в мобильную разработку.

Писать предлагается на JavaScript, поэтому кому-то может показаться, что это реинкарнация PhoneGap и его HTML-подхода, но нет. Когда-то Facebook действительно полагался для мобильных устройств на HTML, но ещё в 2012-м Цукерберг назвал это ошибкой. И у React Native идея не в том, чтобы с помощью HTML/CSS городить что хочешь, а в том, чтобы с помощью JSX использовать нативные элементы UI так что пользователь ощущал себя прямо как с нативным приложением.

Насколько это получилось? Шероховатости и срезанные углы существуют с ними сталкиваются и разработчики, и пользователи. Для кого-то они оказываются критичными: особенно нашумел пост Airbnb, где после React Native решили вернуться к нативной разработке. Но какие-то другие компании (вроде самой Facebook) эти ограничения не остановили, использование в индустрии есть.

Поскольку нативной отполированности не достичь, это решение часто рекомендуют для случаев, где она и не требуется. Если пользователь залипает в приложении часами (как в соцсетях), то любая неаккуратная мелочь будет бросаться ему в глаза но вот если юзкейс приложения такой, что его включают на минуту в неделю, то эти мелочи просто никто не заметит.

Если зайти на HeadHunter и сравнить число вакансий по React Native с нативной разработкой, то их немного. Но вот если сравнивать с Qt/Xamarin/PhoneGap то вакансий окажется больше, чем у них всех, вместе взятых, это наиболее успешный вариант.

Что в итоге: React Native не стал так успешен, как его фронтендовый старший брат, но определённую нишу занял.

Выводы

Обычно в холиварах занимают крайние позиции: эта крутая штука всех победит или все эти глупости скоро отомрут. А у меня по итогам всех вариантов позиция получается сдержанной:

• Победит и умрёт не единственные варианты. Есть ситуации, когда технология занимает небольшой сегмент рынка и не претендует на мировое господство, но приносит кому-то пользу.

• Кроссплатформа это всегда компромисс. Выдержать планку качества, заданную нативом, не получалось нигде. Везде что-то вытарчивает и пользователи могут заметить разницу, и разработчикам приходится возиться со сложностями. И далеко не для всего кроссплатформа годится одинаково хорошо: если бизнес-логика между платформами шарится хорошо, то с UI всё сложнее.

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

И всё это приводит меня к такому выводу про Flutter: вместо обсуждений выиграет он или проиграет надо обсуждать в каких конкретно юзкейсах он выигрывает. По-моему, он хорош для определённой ниши, поэтому вряд ли угрожает будущему всей нативной разработки, но закрепиться в этой нише вполне может. Вопрос в том, каковы её размеры и попадает ли в неё ваш проект.

А вот про Kotlin Multiplatform сделать выводы по прошлому у меня не получилось, потому что у него нетипичная ситуация, отличающаяся от предшественников. Во-первых, идея кроссплатформа годится не для всего тут заложена прямо в фундамент: а мы и не предлагаем объединять всё, реализуйте общую бизнес-логику, а остальное на Android и iOS делайте раздельно. А во-вторых, тут играет на руку родной для Android язык: он уже знаком половине мобильных разработчиков, и такого в кроссплатформе раньше не возникало. Так что опыт предыдущих технологий тут непоказателен остаётся смотреть, что покажет время.

На последнем Mobius было сразу несколько кроссплатформенных докладов (три про Flutter, один про Kotlin Multiplatform) мы уже выложили все видеозаписи конференции на YouTube, так что можете сами их посмотреть. А мы тем временем вовсю работаем над следующим Mobius: он пройдёт 13-16 апреля в онлайне, и там без освещения кроссплатформы тоже не обойдётся. Так что, если вас заинтересовал этот пост, то вам будет интересно и там.

Деревья выражений System.Linq.Expressions дают возможность выразить намерения не только самим кодом, но и его структурой, синтаксисом.

Их создание из лямбда-выражений это, по сути, синтаксический сахар, при котором пишется обычный код, а компилятор строит из него синтаксическое дерево (AST), которое в том числе включает ссылки на объекты в памяти, захватывает переменные. Это позволяет манипулировать не только данными, но и кодом, в контексте которого они используются: переписывать, дополнять, пересылать, а уже потом компилировать и выполнять.

Run-time компиляция порождает производительные делегаты, которые часто быстрее тех, что компилируются во время сборки (за счет меньшего оверхеда). Однако сама компиляция происходит до десятков тысяч раз дольше, чем вызов результата компиляции.

Это особенно обидно, когда выражение простое, например содержит только доступ к свойству (в библиотеках для маппинга, сериализации, дата-байндинга), вызову конструктора или метода (для IoC/DI решений).

Скомпилированные делегаты обычно кэшируют, чтобы переиспользовать, но это не спасает в сценариях, когда первый доступ происходит к большому количеству за раз. В таких случаях время run-time компиляции выражений становится значимым и оттягивает запуск приложения или отдельных окон.

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

• Встроенную интерпретацию.
  Необходимость использования интерпретатора вместо компилятора указывается соответствующим флагом:

  Expression.Compile(preferInterpretation: true)
  

  Происходит через рефлексию, но с накладными расходами на формирование стека инструкций.

  Для платформ Xamarin.iOS, Xamarin.watchOS, Xamarin.tvOS, Mono.PS4 и Mono.XBox стандартная компиляция через генерацию IL (System.Reflection.Emit) долгое время была недоступна и на данный момент под капотом всегда откатывается к этому варианту.

• FastExpressionCompile от @dadhi.
  Ускоряет компиляцию за счет оптимизиpованной генерации IL и с меньшим количеством проверок совместимости.

  На платформах без поддержки JIT компиляции может использоваться только с включенным Mono Interpreter.

• Ручную интерпретацию.
  Используется для оптимизации вызовов рефлексии под специальные сценарии использования, например для добавления кэширования отдельных вызовов.

  Интерпретируя вручную, уже можно воспользоваться способами ускорения рефлексии. Самые эффективные из них, например Fasterflect, используют System.Reflection.Emit и на некоторых платформах так же могут требовать включения Mono Interpreter.

Для случаев, когда производительности указанных методов недостаточно, напрашивается решение:

Компилировать выражения или какие-то их части во время написания кода (design-time) или сборки (compile-time).

Для compile-time компиляции делегатов к фрагментам деревьев выражений требуется сгенерировать соответствующий код.

API доступа к делегатам не стоит генерировать вместе с ними, лучше держать его в отдельной сборке. Причина заключается в том, что анализ и использование деревьев выражений часто происходит в проектах, отдельных от их инициализации. Фреймворки для дата-байндинга и DI это сторонние библиотеки, да и сами программы часто разбиваются на несколько сборок из соображений архитектуры.

От самого API требуется только давать нужный делегат по ключу, как в словаре. У интересующих нас фрагментов кода: методов, конструкторов и свойств на стыке run-time и compile-time естественный идентификатор это сигнатура. По ней генерируемый код будет класть делегаты в словарь, а клиенты забирать.

Например, для класса со свойством

namespace Namespace{  public class TestClass  {    public int Property { get; set; }  }}

используемым внутри System.Linq.Expressions.Expression<T> лямбды

Expression<Func<TestClass, int>> expression = o => o.Property;

делегатами чтения и записи в общем виде являются

Func<object, object> _ = obj => ((Namespace.TestClass)obj).Property;Action<object, object> _ => (t, m) => ((Namespace.TestClass)t).Property  = (System.Int32)m;

и генерируемый код для их регистрации будет примерно таким:

namespace ExpressionDelegates.AccessorRegistration{  public static class ModuleInitializer  {    public static void Initialize()    {      ExpressionDelegates.Accessors.Add("Namespace.TestClass.Property",        getter: obj => ((Namespace.TestClass)obj).Property,        setter: (t, m) => ((Namespace.TestClass)t).Property = (System.Int32)m);    }  }}

Генерация

Наиболее известные решения для кодогенерации, на мой взгляд, это:

• Microsoft.CodeDom,

• T4,

• PostSharp,

• Fody,

• Roslyn Source Generators.

Отдельная область применения есть у каждого решения, и только Roslyn Source Generators умеет анализировать исходный C# код даже в процессе его набора.

Кроме того, именно Roslyn Source Generators видятся более или менее стандартом для кодогенерации, т. к. были представлены как фича основного компилятора языка и используют Roslyn API, используемый в анализаторах и code-fix.

Принцип работы Roslyn Source Generators описан в дизайн-документе (местами не актуален!) и гайде.

Вкратце: для создания генератора требуется создать реализацию интерфейса

namespace Microsoft.CodeAnalysis{  public interface ISourceGenerator  {    void Initialize(GeneratorInitializationContext context);    void Execute(GeneratorExecutionContext context);  }}

и подключить ее к проекту как анализатор.

Метод Initialize пригодится для выполнения какой-либо единоразовой логики. GeneratorInitializationContext на данный момент может быть полезен только для подключения посетителя узлов синтаксиса кода.

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

Для каждого файла исходного кода Roslyn предоставляет синтаксическое дерево в виде объекта SyntaxTree:

GeneratorExecutionContext.Compilation.SyntaxTrees

а так же семантическую модель:

semanticModel =  GeneratorExecutionContext.Compilation.GetSemanticModel(SyntaxTree)

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

Среди всех узлов синтаксических деревьев сборки нам нужно найти только интересующие нас лямбда-выражения типа System.Linq.Expressions.Expression<T> и отобрать из их узлов-потомков выражения, описывающие доступ к членам классов, создание объектов и вызов методов:

По семантике узла, так называемому символу (Symbol), можно определять:

• типы, используемые выражением;

• область видимости;

• IsStatic, IsConst, IsReadOnly и другие характеристики.

На основе такой информации и будем генерировать подходящий код.

В Roslyn API (Microsoft.CodeAnalysis) построить сигнатуру намного проще, чем c API рефлексии (System.Reflection). Достаточно сконвертировать символ в строку при помощи методаISymbol.ToDisplayString(SymbolDisplayFormat) c подходящим форматом:

Зная сигнатуры свойства/поля, его типа и обладателя формируем строки для добавления делегатов:

Оформляем код добавления делегатов в класс и отдаем компилятору:

var sourceBuilder = new StringBuilder(@"namespace ExpressionDelegates.AccessorRegistration{  public static class ModuleInitializer  {    public static void Initialize()    {");      foreach (var line in registrationLines)      {        sourceBuilder.AppendLine();        sourceBuilder.Append(' ', 6).Append(line);      }      sourceBuilder.Append(@"    }  }}");GeneratorExecutionContext.AddSource(  "AccessorRegistration",  SourceText.From(sourceBuilder.ToString(), Encoding.UTF8));

Этот код обязательно будет добавлен в сборку ...если генератор сможет отработать :)

Дело в том, что хоть Source Generators технически и не фича языка, поддерживаются они только в проектах с C# 9+. Позволить такую роскошь без костылей и ограничений на данный момент могут только проекты на .NET 5.

Совместимость

Поддержку Roslyn Source Generators API для .NET Standard, платформ .NET Core, .NET Framework и даже Xamarin поможет организовать Uno.SourceGeneration.

Uno.SourceGeneration предоставляет собственные копии интерфейса ISourceGenerator и атрибута [Generator], которые при миграции на С# 9 меняются на оригинальные из пространства имен Microsoft.CodeAnalysis простым удалением импортов Uno:

using Uno.SourceGeneration;using GeneratorAttribute = Uno.SourceGeneration.GeneratorAttribute;using ISourceGenerator = Uno.SourceGeneration.ISourceGenerator;

<ItemGroup>  <SourceGenerator Include="PATH\TO\GENERATOR.dll" /></ItemGroup>

Инициализация

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

Для этих целей отлично подходит Module Initializer. Это конструктор сборки (а точнее ее модуля), который запускается сразу после ее загрузки и до вызовов к остальному коду. Он давно есть в CLR, но к сожалению, в C# его поддержка c атрибутом [ModuleInitializer] добавлена только в 9 версии.

Решение по добавлению конструктора в сборку с более широкой поддержкой платформ есть у Fody плагин Fody.ModuleInit. После компиляции добавляет классы с именами ModuleInitializer в конструктор сборки. В такой класс и будем оборачивать инициализацию сгенерированных делегатов.

Подключение Fody.ModuleInit через MSBuild свойства вместо FodyWeavers.xml исключит конфликты с другими Weaver-ами Fody в проекте клиента.

Использование

Таким образом, при сборке проекта:

1. Source Generator добавит в сборку код, регистрирующий делегаты для деревьев выражений, в обертке класса ModuleInitializer.

2. Fody.ModuleInit добавит ModuleInitializer в конструктор сборки.

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

Проверяем:

Expression<Func<string, int>> expression = s => s.Length;MemberInfo accessorInfo = ((MemberExpression)expression.Body).Member;Accessor lengthAccessor = ExpressionDelegates.Accessors.Find(accessorInfo);var length = lengthAccessor.Get("17 letters string");// length == 17

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

Бенчмарки

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

Полный вариант таблицы, с бенчмарками интерпретации.

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

Идеи насчёт оптимизации построения сигнатур по System.Reflection.MemberInfo приветствуются. Реализация на момент написания.

Заключение

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

Полный код можно посмотреть на: github/ExpressionDelegates, а подключить через nuget.

Для тех, кто будет пробовать Source Generators хотелось бы отметить несколько полезностей:

• Source Generator Playground (github).
  Позволяет экспериментировать с Roslyn Source Generators в браузере, онлайн.

• Окно визуализации синтаксиса для Visual Studio.
  Удобный инструмент для знакомства с Roslyn Syntax API на собственном коде.

• Отлаживается Source Generator вызовом отладчика из его кода. Пример.
  Для этого нужен компонент Visual Studio Just-In-Time debugger и включенная настройка Tools -> Options -> Debugging -> Just-In-Time Debugging -> Managed.

• В сгенерированных *.cs файлах срабатывают брейкпоинты, проверено в Visual Studio16.8.
  При генерации через Uno.SourceGeneration файлы размещаются по пути: \obj\{configuration}\{platform}\g\.
  С Roslyn Source Generators их появление включается через MSBuild свойство EmitCompilerGeneratedFiles.
  Стандартный путь: \obj\{configuration}\{platform}\generated\, переопределяется в свойстве CompilerGeneratedFilesOutputPath.

• Source Generators можно конфигурировать свойствами MSBuild.
  При использовании Uno.SourceGeneration значение получают вызовом

  GeneratorExecutionContext.GetMSBuildPropertyValue(string)
  

  Для Roslyn Source Generators требуемые свойства необходимо сперва отдельно обозначить в MSBuild группе CompilerVisibleProperty и только после вызывать:

  GeneratorExecutionContext.AnalyzerConfigOptions.GlobalOptions  .TryGetValue("build_property.<PROPERTY_NAME>", out var propertyValue)
  

• Из генератора можно кидать предупреждения и ошибки сборки.

  //Roslyn Source GeneratorsGeneratorExecutionContext.ReportDiagnostic(Diagnostic)//Uno.SourceGeneration:GeneratorExecutionContext.GetLogger().Warn/Error().
  

С чего все началось

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

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

Первые шаги к улучшению ситуации

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

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

public class EmptyStateViewModel : ViewModel{    public EmptyStateViewModel(string image, string title, string description)    {        Image = image;        Title = title;        Description = description;    }    public string Image { get; }    public string Title { get; }    public string Description { get; }}

Следующим шагом на платформах(или в xaml в случае для Xamarin Forms) нужно прописать Bindings на проперти вью модели, в зависимости от того, какой mvvm-фреймворк используется.

А что дальше?

А далее возник вопрос - что делать, если по каким-то причинам наш запрос на бекенд фейлится. И тут пришла мысль - переиспользовать уже готовый EmptyStateView, но добавить внизу кнопку Retry, для возможности повторной отправки запроса. Потому мы просто наследовались от EmptyStateViewModel, но добавили поля с текстом кнопки, и командой на клик.

public class ErrorStateViewModel : EmptyStateViewModel{    public ErrorStateViewModel(string image, string title, string description, string actionTitle, Command actionCommand)        : base(image, title, description)    {        ActionTitle = actionTitle;        ActionCommand = actionCommand;    }    public string ActionTitle { get; }    public Command ActionCommand { get; }}

И как все это использовать?

После этого пришло время задуматься - как это менеджить. И тут неплохим показался вот такой вариант. Создаем фабрику, которая будет нам возвращать нужную вью-модель. А так же метод None, который будет возвращать null.

public static class OverlayFactory{    public static T None<T>()        where T : EmptyStateViewModel    {        return null;    }    public static EmptyStateViewModel CreateCustom(string image, string title, string description)    {        return new EmptyStateViewModel(image, title, description);    }    public static ErrorStateViewModel CreateCustom(string image, string title, string description, string actionTitle, Command actionCommand)    {        return new ErrorStateViewModel(image, title, description, actionTitle, actionCommand);    }}

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

public class SomeViewModel : BaseViewModel{    private IItemsLoadingService _itemsLoadingService;        public SomeViewModel(IItemsLoadingService itemsLoadingService)    {        _itemsLoadingService = itemsLoadingService;    }    public ObservableCollection<ItemViewModel> Items { get; } = new ObservableCollection<ItemViewModel>();    public EmptyStateViewModel EmptyState { get; protected set; }    public ErrorStateViewModel ErrorState { get; protected set; }    public override async Task InitializeAsync()    {        await base.InitializeAsync();        await LoadItemsAsync();    }    private async Task LoadItemsAsync()    {        try        {            var result = await _itemsLoadingService.GetItemsAsync();            var items = result.ToList();            ErrorState = OverlayFactory.None<ErrorStateViewModel>();            if (items.Count == 0)            {                EmptyState = OverlayFactory.CreateCustom("img_empty_state", "Title", "Description");            }            else            {                EmptyState = OverlayFactory.None<ErrorStateViewModel>();                // Add items to list            }        }        catch        {            ErrorState = OverlayFactory.CreateCustom("img_error_state", "Title", "Description", "Retry", new Command(() => LoadItemsAsync));        }    }}

На платформах же нам необходимо прописать кастомный Binding для EmptyState/ErrorState вьюх на соответствующие вью модели, в зависимости от используемого mvvm-фреймворка, и проверять, если у нас EmptyStateViewModel/ErrorStateViewModel null, то скрывать соответствующую вьюху. Для этого в нашем случае использовался простой метод SetViewModel.

Для андроида тут все просто, при задании для View ее ViewModel мы установим View уже существующий ViewState из коробки. Если ViewModel null - тогда попросту задаем ViewState Gone, если существует - то Visible:

public void SetViewModel(EmptyStateViewModel viewModel){    ViewModel = viewModel;    View.Visibility = viewModel != null ? ViewStates.Visible : ViewStates.Gone;}

Для iOS немного сложнее - необходимо деактивировать constraints для вьюхи, а только потом - прятать ее. Для начала добавим enum, аналогичный стандартному из Android.

public void SetViewModel(EmptyStateViewModel viewModel){    ViewModel = viewModel;    View.SetVisibility(viewModel != null ? ViewStates.Visible : ViewStates.Gone);}

Нам потребуется несколько extension методов

public static void SetVisibility(this UIView view, ViewVisibility visibility){    var constraints = GetViewConstraints(view) ?? new NSLayoutConstraint[] {};    if (visibility == ViewVisibility.Gone)    {        SaveViewConstraints(view, constraints);        NSLayoutConstraint.DeactivateConstraints(constraints);        view.Hidden = true;        return;    }      if (visibility == ViewVisibility.Visible)    {        SaveViewConstraints(view, null);        NSLayoutConstraint.ActivateConstraints(constraints);        view.Hidden = false;        return;    }}

Тут мы в случае установки ViewVisibility.Gone предварительно сохраняем constraints нашей view и деактивируем их, а при включении видимости - наоборот достаем предварительно сохраненные constraints, обнуляем сохранение, а затем активируем их.

private static NSLayoutConstraint[] GetViewConstraints(UIView view){    return view.GetAssociatedObject<NSMutableArray<NSLayoutConstraint>>(Key)?.ToArray() ??           view.Superview?.Constraints               .Where(constraint => (constraint.FirstItem?.Equals(view) == true) || constraint.SecondItem.Equals(view))               .ToArray();}private static void SaveViewConstraints(UIView view, NSLayoutConstraint[] constraints){    NSMutableArray<NSLayoutConstraint> viewConstraints = null;    if (constraints.Length > 0)    {        viewConstraints = new NSMutableArray<NSLayoutConstraint>();        viewConstraints.AddObjects(constraints);    }    view.SetAssociatedObject(Key, viewConstraints, AssociationPolicy.RetainNonAtomic);}

Первый метод позволяет достать предварительно сохраненные constraints, если такие есть, либо же, если нет, получить текущие. Если же родительский view отсутствует, то вернется null.

Второй метод сохранит текущие constraints, чтоб затем их можно было восстановить.

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

PS - первая статья на Хабре, потому не судите строго. Но нужно же с чего-то начать.

В календаре 8 марта, а я пишу эту статью.
Почему? - Потому, что WinUI 3 - это важно!

Предыстория

Для того, что бы понять, что из себя представляет WinUI 3 и какую глобальную проблему он решает, предлагаю окунуться в историю десктопной разработки под Windows:

• Итак, на дворе 1995 год, и мы начинаем писать наш калькулятор на C++ и Win32. Win32 - самый низкоуровневый системный API, для работы с визуальным интерфейсом. Ниже только Windows Driver Model для драйверов.

• 2002 год - наш калькулятор уже может быть написан на более высокоуровневой оболочке - WinForms (Windows Forms). Она создаёт обёртку над Win32 для более простого и удобного взаимодействия с системой. А за счёт .NET Framework и CLR, которые так же вышли в 2002 году, мы можем использовать целый букет из различный языков для разработки. В их числе были C#, С++, VB.Net, J# и другие.

• WPF - наш ответ устаревшим технологиям. В конце 2006 года Microsoft презентуют WPF - обширный API-интерфейс для создания настольных графических программ, имеющих насыщенный дизайн и интерактивность. Новый подход включал в себя совершенно другую модель построения пользовательских приложений, основывающуюся на .NET Framework и DirectX. Вместе с выходом WPF у нас появляются следующие возможности: WEB-подобная модель компоновки, богатая модель рисования, анимации, поддержка аудио и видео, стили и шаблоны, декларативный пользовательский интерфейс, подход MVVM, и язык разметки XAML.

• 2012 год - выход Windows 8. Очень много споров и дискуссий было на тему свежей ОС. Но самое интересное изменение, которое с ней случилось - выход WinRT или же Windows Runtime. Это именно то, почему у Windows присутствует 2 меню настроек: новое и панель управления. WinRT по существу является API, основанное на технологии COM. COM, в свою очередь, предполагал использование одних и тех же компонентов системы во многих местах одновременно. Например, PrintDialog - теперь единый компонент, к реальному состоянию которого можно получить доступ из любого места системы. Нам теперь не нужно загружать информацию о нём каждый раз при использовании, как это было с Win32.

• 2016 - Universal Windows Platform или же UWP. Апогей унификации Windows. Продолжающая идею WinRT, UWP активно объединяет системные функции и компоненты под единым программным интерфейсом, который теперь может работать на всех устройствах с Windows 10 без изменений в коде! Но, это касается не только программных функций, но и визуальных компонентов. Так и появляется на свет WinUI 2 - единый визуальный интерфейс для всех приложений на Windows.

Что мы в итоге получаем?

Как результат - у нас есть мощная платформа, с унифицированным программным и визуальным интерфейсом. Наш стандартный калькулятор уже построен как UWP приложение ( Исходный код Windows калькулятора можно найти в открытом доступе на github). Но, что-то всё равно не так

Опрос от компании Telerik за 2016 год показал, что сообщество разработчиков без явного энтузиазма брались использовать UWP, как основную платформу в своих новых проектах. Что же не так? А всё дело в унификации приложений для Windows. За счёт оборачивания их в различные новые API и Windows Runtime, разработчики потеряли возможность работать со старыми добрыми Win32 напрямую. Они, в свою очередь, предоставляют огромнейшие возможности для тонкой работы с системой. И тот список системных API, которые сейчас доступны из UWP приложений, кажется просто смешным. Ознакомиться с ним более детально можно здесь: Список системных API, доступных через UWP приложение

WinUI 3

Именно проблему недоступности системных API и будет решать новая версия WinUI. WinUI 3 Preview 4 уже находится в пре-релизе, а официальный релиз намечен на март. Но каким образом удастся получить доступ к системным API приложению, которое изначально задумывалось как работающее на WinRT и UWP API?

Всё просто: Необходимо оделить визуальную часть и среду выполнения. Ключом к этому стала платформа .NET:

Что такое .NET?

• Из блока предыстории можно узнать, что в 2002 году вышла Windows-ориентированная платформа для разработки ПО - .NET Framework. Она развивалась в плоть до 2019 года, когда была выпущена последняя версия - 4.8

• Параллельно, с 2016 года начала развиваться новая модульная платформа для разработки программного обеспечения с открытым исходным кодом - .NET Core. Кроме того, она была кроссплатформенная.

• И наконец - .NET 5. Это, выпущенная в 2020 году, единая платформа для разработки ПО. Она объединила в себе все преимущества .NET Framework, .NET Core и некоторых похожих платформ.

По заявлениям Microsoft, теперь это единственная платформа, в сторону которой будет развиваться компания.

И теперь, имея единую программную платформу - .NET 5, компания Microsoft может воплотить идею с использованием унифицированного интерфейса, но при этом оставить возможность использовать удобные API: будь-то UWP API или Win32.

Это и является той золотой срединой, когда мы можем использовать современные, производительные визуальные компоненты вместе с функциональностью системных API.

Перспективы WinUI 3

По заявлениям самих Microsoft, на WinUI 3 и его последующие версии, у компании огромные планы. Для начала, уже в осеннем обновлении Windows мы сможем увидеть переход многих частей операционной системы на WinUI 3.

Xamarin, MAUI and WinUI 3?

MAUI (Multi-platform App UI) - кроссплатформенная библиотека графического интерфейса. Является эволюцией Xamarin.Forms. Для Windows она будет работать именно через компоненты WinUI 3. Больше информации о MAUI: devblog.microsoft, github.

Uno Platform and WinUI 3?

Uno Platform - это кроссплатформенный графический пользовательский интерфейс с открытым исходным кодом, который позволяет запускать код на основе WinUI и универсальной платформы Windows на iOS, macOS, Linux, Android и WebAssembly.

Команда разработчиков Uno Platform с первых дней анонсировала свою нацеленность на WinUI 3. А спустя 12 часов после выпуска WinUI 3 Preview 4, его поддержка уже была добавлена в Uno Platform. Больше информации об Uno Platform: platform.uno, github.

Будущее системных API

Что касается системных API, Microsoft не оставляют идею их унификации. Поэтому, сейчас в активной разработке находится Project Reunion. Это универсальная модульная оболочка, которая должно предоставить быстрый доступ ко всем Win32 и UWP API.

Project Reunion будет очень тесно связан с WinUI 3. И уже сейчас находится в превью версии.

Больше информации о Project Reunion: docs.microsoft.com, github

Кросс-платформенные решения - тренд в мобильной разработке. Уже есть различные технологии от PWA до Flutter и Kotlin Multiplatform. Как выбрать среди них?

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

Познакомимся с Женей

Евгения солюшн-архитектор. Она должна решить, как построить новое мобильное приложение для изучения английского языка не носителями: людьми из Турции, Италии или России. Давайте посмотрим, как Женя подходит к этой задаче.

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

В компании владельце приложения также ожидают, что разработкой будет заниматься единая команда как для Android- и iOS-приложений, чтобы свести к минимуму усилия по передаче знаний и максимизировать скорость команды. В будущем также планируют запустить веб-приложения. А еще в компании хотели бы упростить будущий найм.

Прогрессивные веб-приложения

Женя начинает свои исследования. Она гуглит мобильные веб-приложения и находит статью. В ней упоминаются Прогрессивные веб-приложения (PWA). Что это такое?

Прогрессивные веб-приложения это, по сути, веб-сайты, которые используют специальные API для доступа к определенным возможностям устройства. Эти API позволяют получить доступ к памяти на устройстве, интегрируются с Push Notifications (на Android) и, что самое важное, работать в отдельной вкладке браузера. Еще их можно установить на устройство иконкой, как настоящее приложение. Звучит неплохо! Давайте посмотрим на плюсы и минусы PWA:

Плюсы:

• Всем занимается одна команда.

• Достаточно навыков веб-разработки.

• Легко обслуживать.

• Все работает сразу из коробки.

Минусы:

• Нет пушей на iOS.

• Неудобный UX.

• Ограниченная поддержка.

• Трудно найти пользователи скачивают приложение в сторах.

А вот и хорошая табличка, показывающая доступность PWA в разных браузерах:

Гибридные приложения

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

Она обнаруживает гибридный подход: давайте поместим наш сайт в WebView в реальном нативном приложении. Оказывается, можно поместить свой мобильный сайт со всем его HTML, CSS и JS-кодом в ресурсы приложения. Затем вы помещаете WebView в корневой ViewController/Activity приложения и указываете на эти ресурсы.

Пользователи смогут найти приложение в Google Play и AppStore, чего не было в случае с PWA. А еще, если вам нужны дополнительные возможности, вы можете легко добавить их ведь у вас настоящее приложение, для этого уже есть необходимые фреймворки.

Плюсы:

• Высокая скорость работы.

• Настоящая кросс-платформенность.

• Можно пользоваться практически всеми преимуществами нативных приложений.

Минусы:

• UX не очень (ведь перед нами по-прежнему сайт в шкуре приложения).

• Небольшое сообщество разработчиков.

Примеры таких приложений: Appcelerator, Ionic, Apache Cordova.

Нативные кросс-платформенные приложения

Большой недостаток гибридных приложений плохой UX. Поскольку это все еще браузер в мобильном приложении, он подтормаживает.

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

Xamarin

Xamarin это решение на основе .NET от Microsoft.

Xamarin (или NET 5.0) помогает кросс-платформенное приложение на C# и .NET в мобильном приложении. Xamarin Forms (или MAUI) это библиотека для построения пользовательского интерфейса в таких приложениях. Теперь они оба переименованы:

Плюсы:

• Легко разрабатывать в компаниях с сильной экспертизой в технологиях Microsoft.

• Полностью кросс-платформенное.

• Потенциально можно сделать его и веб-приложением.

Минусы:

• 2 виртуальные машины в приложении на Android - JVM и Mono

• Мало инструментов и библиотек

• Долгое время исправления багов в Xamarin

• Растет размер бандлов

React Native

React Native создан для того, чтобы привнести React в мобильные технологии. И это действительно хорошо сработало! Согласно статистике Bitrise, React Native занимает 13% рынка. Его также используют более 500 тысяч репозиториев на Гитхабе.

React Native использует языки Javascript или TypeScript для разработки приложений и транслирует компоненты React Native в компоненты платформы. Так, превращается в TextView на Android.

Приложение включает в себя JavaScript VM для выполнения JS-кода логики и пользовательского интерфейса приложения. React Native также умеет работать с API платформы. С такой архитектурой можно создать любое приложение, даже мобильную игру.

Плюсы:

• Большое сообщество.

• Пользуются в Skype, Discord, Shopify, Tesla, Artsy.

• Доступны нативные возможности приложений.

• Можно писать на React.

Минусы:

• Долгое время запуска.

• Экстеншены и работа в фоне требует написания нативного кода.

• Проходит ре-архитектуризацию.

Flutter

Flutter это кросс-платформенный фреймворк с открытым исходным кодом от Google, основанный на языке Dart. В отличие от React Native, Flutter использует свой собственный 2D-движок для отрисовки пользовательского интерфейса в нативном виде. Такой подход обеспечивает независимость от версии ОС, на которой работает приложение. Flutter приложение также компилирует Dart в нативный для платформы код в релизной сборке, таким образом в рантайме Dart VM становится не нужна. Советую нашей Жене мое подробное сравнение Flutter и React Native.

Flutter привлек к себе большое внимание, собрал более 100 000 звезд, а количество приложений, собранных с его помощью, продолжает стремительно расти. Согласно той же статистике Bitrise, уже 9% билдов в прошлом году собраны на Flutter. Это очень много для такой молодой технологии.

Плюсы:

• Хорошая производительность

• Декларативный UI

• Поддерживает веб

Минусы:

• Ненативный UI

• Малопопулярный язык Dart.

• Недостаток некоторых инструментов (например, в плане контроля безопасности).

Kotlin Multiplatform

Xamarin, Flutter и React Native позволяют вам написать практически весь код единожды и запускать его и на iOS, и на Android.

Kotlin Multiplatform делает иначе. KMP считает, что пользовательский интерфейс сильно зависит от платформы и самого устройства (скажем, планшета или веб-сайта). Однако бизнес-логика остается практически неизменной. Почему бы не переиспользовать прежде всего ее?

Итак, с KMP у вас все еще есть два нативных приложения, которые пользуются одной бизнес-логикой. Вы можете использовать все, что угодно в пользовательском интерфейсе: будь то родной Android Views, JetPack Compose или Swift UI для iOS. Вы даже можете использовать Flutter или React Native для вашего пользовательского интерфейса! Он все равно будет прекрасно работать с Kotlin Multiplatform. Вот несколько примеров.

Плюсы:

• Родной язык для разработчиков Android.

• iOS разработчикам нетрудно читать Kotlin код.

• Единая среда разработки для Android и iOS.

• Подходит для реализации веб-приложений.

Минусы:

• Молодое решение, все еще в альфа-версии.

• Нельзя переиспользовать UI.

Что же выбрать?

Итак, наша Женя собирается выбрать свое решение. Вот что мы ей посоветуем:

• Согласна на мобильный сайт вместо приложения, несмотря на ограничения в UI? Тогда PWA.

• В компании все пишут на .NET? Значит, Xamarin.

• Основной стек это JS/TypeScript? Выбираем React Native.

• Будем шарить между приложениями не UI, а только бизнес-логику? Значит, Kotlin Multiplatform.

Конечно, это не все критерии: например, мы не рассмотрели доступность разработчиков на рынке или темы поддержки новых версий OS. Но основной алгоритм - выше :)

Удачи, Женя!

Есть вопрос, который мне постоянно задают в Твиттере: как создавать приложения с крутым дизайном с помощью Xamarin.Forms? Это отличный вопрос, ведь любой может создавать красивые приложения, немного вдохновившись и поработав над стилем. Я не дизайнер и не претендую на звание дизайнера, но есть много отличных источников вдохновения для дизайна приложений, включая Dribbble, Uplabs и другие. Эти дизайны от талантливых людей со всего мира могут повлиять на внешний вид ваших собственных приложений.

Встроенные возможности Xamarin.Forms

В Xamarin.Forms есть несколько функций, которые можно использовать, чтобы воплотить важные проекты в жизнь. Зачем вам что-то, кроме нового Shapes API для рисования фигур, линий, многоугольников и многого другого. Хотите, чтобы ваши собственные элементы управления были единообразными? Как насчет добавления Material Design с помощью одной строчки кода. А еще сгруппируйте свои коллекции с помощью CarouselView в сочетании с IndicatorView и, конечно же, CollectionView.

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

Xamarin Community Toolkit добавляет отличные элементы управления, включая DockLayout, Shield, TabView и другие. Но есть еще более потрясающие элементы управления от сообщества, включая потрясающие Magic Gradients, PancakeView, MaterialFrame, CardView, Shadows и многие другие. Наконец, мы не можем забыть SkiaSharp, систему 2D-графики общего назначения для .NET.

Компонентная экосистема

Переиспользуемые компоненты пользовательского интерфейса от ведущих поставщиков компонентов, таких как Telerik, UX Divers, GrapeCity и Syncfusion, помогут вам быстро повысить продуктивность. Обязательно ознакомьтесь с множеством вариантов, когда будете готовы начать работу.

Вдохновляйтесь

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

И есть еще очень много прекрасных дизайнов. Вы даже можете добавить свой собственный, просто создав pull request в репозитории Хавьера на GitHub.

Adobe XD Exporter

Многие дизайны, которые вы найдете в интернете или получите от вашего дизайнера, могут быть созданы с помощью таких инструментов, как Adobe XD. Вы можете легко импортировать цвета и стили в свое приложение Xamarin.Forms благодаря экспортеру XD в Xamarin.Forms (его автор -- наш коллега Kym Phillpotts).

Создавайте красивые приложения

Расскажите нам о своих приложениях, оставив комментарии ниже или отправив pull request в репозиторий Хавьера на GitHub.