Xamarin Forms, MVVMCross и SkiaSharp: святая троица кроссплатформенной разработки приложений

Говорите о завышенных ожиданиях. Святая троица, не иначе!

Правда в том, что разработка мобильных приложений обходится дорого, если вы ориентируетесь на несколько платформ, потому что нет общего кода. Apple требует, чтобы вы программировали на Objective-C или Swift, Android требует, чтобы вы кодировали на Java, а WinPhone требует, чтобы вы занимались разработкой на .NET, часто на C#. Добавьте к этому множество библиотек, которые каждая платформа предоставляет для работы с картами, чертежами, изображениями или GPS — для создания одного мобильного приложения требуется огромное количество времени и знаний.

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

В этой статье вы узнаете, как Xamarin Forms в сочетании с MVVMCross и SkiaSharp могут стать жизнеспособным способом создания кроссплатформенных мобильных приложений без ущерба для привычности, производительности и уникальности. В статье будут рассмотрены эти три технологии и то, как они могут снизить стоимость разработки за счет максимального повторного использования кода на нескольких мобильных платформах.

Важная проблема

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

Что касается приложений, то за эти годы было предпринято несколько попыток возглавить этот кроссплатформенный рынок. Многие потерпели неудачу и были потеряны в бездне, но пара из них все еще выживает спустя несколько лет. Среди них — Xamarin, единственное решение .NET, предлагающее поддержку всех трех мобильных платформ.

Родной или нет, вот и я

Итак, идет война между различными решениями, и кто говорит, что война означает пропаганду!

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

При выборе кросс-платформенного фреймворка все «родные» варианты не равны, поэтому будьте осторожны, возможно, вы сравниваете яблоки с апельсинами. Для некоторых речь идет о языке программирования, для других — о возможности использования аппаратных функций, третьи думают, что речь идет об использовании API / пользовательского интерфейса платформы, и часто речь идет только о том, чтобы не быть веб-приложением.

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

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

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

Отец, Сын и Святой Дух

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

Отец: Хамарин

Как упоминалось ранее, Xamarin — это решение .NET для разработки мобильных и настольных приложений. Он был куплен Microsoft в 2016 году, но датирован примерно четыре года назад с проектом Mono. В настоящее время в нем представлены три решения: Xamarin.iOS, Xamarin.Android и Xamarin.Mac. Другие платформы уже поддерживают приложения .NET по умолчанию, являясь решениями Microsoft. Короче говоря, Xamarin предлагает прямую ссылку на API-интерфейсы платформы в .NET. Таким образом, вы можете использовать собственные функции из приложения .NET. Существует также модуль расширения для Xamarin под названием Forms, который обеспечивает уровень абстракции для пользовательского интерфейса.

Сын: СкиаШарп

SkiaSharp — это оболочка .NET над библиотекой векторной графики Google Skia. Skia — это собственный движок рендеринга для Android, Chrome, ChromeOS и Firefox. С помощью SkiaSharp вы можете использовать библиотеку в своем приложении .NET, чтобы сделать его кроссплатформенным. Это означает, что аккуратная тень, которая, по словам вашего дизайнера, «сделает ваше приложение намного лучше», может быть закодирована только один раз, а не повторяться для каждой целевой платформы. Лично я считаю, что его лучшей особенностью является возможность рендеринга SVG-графики таким образом, который позволяет предотвратить дублирование различных форм-факторов, сохраняя при этом четкую рендеринг с точностью до пикселя.

Святой Дух: MVVMCross

Чтобы все было хорошо отделено и слабо связано, наше освященное решение будет опираться на MVVMCross. Эта структура реализует инфраструктуру MVVM (Model-View-ViewModel), чтобы все можно было сохранить независимым. Не вдаваясь в технические подробности, приложения обычно делятся на три части:

1. Модель: представление наших данных в памяти.
2. Представление: наш пользовательский интерфейс, представляющий данные и действия пользователям.
3. ViewModel: слой, который связывает нашу модель с нашим представлением и наоборот.

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

Что волнует конечных пользователей

Напомним, что есть разные вещи, которые отличают успешные приложения от плохих. Успешное приложение:

1. Решает реальную жизненную проблему
2. Предлагает приятный опыт

Пункт №1 явно не имеет ничего общего с выбранным вами фреймворком. Итак, давайте сосредоточимся на пункте номер 2. Есть три основных аспекта, которые способствуют получению удовольствия от вашего приложения:

1. Знакомство
2. Представление
3. Уникальность

Знакомство

Знакомство связано с простотой использования и быстрым поиском пути в приложении.

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

Привычность — главное слабое место веб-приложений или фреймворков, основанных на веб-интерфейсе. С другой стороны, Xamarin Forms обеспечивает кросс-платформенные сопоставления с элементами пользовательского интерфейса, предоставляемыми поставщиком.

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

Представление

Откровенно говоря, упоминание «нативного» в вашей маркетинговой пропаганде ничего не значит. Возьмем, к примеру, Jasonette, которая «нативна по HTTP». Пользовательский интерфейс хранится на веб-сервере… здравствуйте, круговые поездки и замедления, поэтому мы видим, что нативный не обязательно предполагает лучшую производительность!

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

Я пришел к выводу, что ваш выбор реализации может замедлить ваше приложение, а не Xamarin против родного языка. Другие варианты находятся в явном невыгодном положении с точки зрения производительности.

Уникальность

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

Во многих случаях уникальность подразумевает создание нестандартных элементов управления, анимации или жестов. Когда это недоступно в Xamarin, вы можете использовать SkiaSharp (оболочку для библиотеки рендеринга векторной графики Skia от Google) и воспользоваться концепцией пользовательского рендерера Xamarin Forms, чтобы максимально приблизиться к аппаратному обеспечению, при этом всегда кодируя в одном язык, что другие решения не могут предложить.

Что вас волнует как бизнес

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

1. Цена и стоимость разработки
2. Повторное использование кода
3. Доступность компонентов
4. Поддержка и сообщество

Цена и затраты на разработку

Давайте избавимся от этого. С начала этого года Xamarin является бесплатным для фрилансеров и малых предприятий, таких как стартапы (с Visual Studio Community Edition). Для крупных организаций он поставляется «бесплатно» с лицензией Visual Studio, которая у вас уже может быть. Xamarin Forms, MVVMCross и SkiaSharp также бесплатны и имеют открытый исходный код в довершение всего!

Как я уже упоминал, переход по маршруту .Net с Xamarin позволяет разрабатывать приложения на одном языке от начала до конца. Для большинства других решений требуется, чтобы ваши программисты знали разные языки. В случае Cordova, например, вам нужно свободно владеть не только HTML, Javascript, CSS, но также, возможно, Objective-C, Java и/или C#, если вам нужен доступ к API-интерфейсам поставщиков, у которых нет доступного плагина. .

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

Хотя это не связано напрямую с Xamarin, вы также получаете множество функций C#, которые ускоряют разработку, выбрав решение .Net. А именно, вы получаете выгоду от замечательных функций C# 4.5+, таких как простая многопоточность с асинхронным/ожиданием, замыканиями и отражением, которые, как было показано, повышают эффективность.

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

Вы, вероятно, думали о повторном использовании кода и, скорее всего, считаете, что все решения в этом отношении в чем-то эквивалентны. Извини, дружище, но ты не прав!

Программисты среди вас, возможно, задавались вопросом, с какой стати я предлагаю использовать MVVMCross вместо уровня MVVM, встроенного в Forms? Что ж, вот что нужно учитывать: вы действительно создаете только мобильные приложения?

Изолируя логику приложения с помощью MVVMCross и используя инверсию управления, которую он обеспечивает, вы можете повторно использовать максимальное количество кода на мобильных устройствах, а также в Windows и Mac (поскольку Xamarin.Mac — ваш друг).

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

Доступность компонентов

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

Выбор Xamarin и MVVMCross предлагает вам два варианта выбора существующих компонентов. Во-первых, для Xamarin доступно все больше и больше компонентов с формами или без них. Xamarin имеет хранилище компонентов, интегрированное в Visual Studio, где вы можете найти различные решения распространенных проблем с приложениями, а другие компании продают их напрямую, поэтому обязательно выполните поиск, прежде чем начинать писать свои собственные компоненты (или рассмотрите возможность продажи их после их создания).

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

Если вы уже имеете опыт работы с C#, у вас, вероятно, есть предпочитаемые компоненты. Конечно, отпускать их не хочется, настолько им комфортно. Будьте уверены, вы можете создавать привязки C# для существующих компонентов, а затем использовать их, как если бы они были связаны с Xamarin, даже в формах с небольшой помощью пользовательских средств визуализации.

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

Поддержка и сообщество

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

Поиск информации в Google обычно дает достаточное количество ответов (совет: также попробуйте выполнить поиск по monotouch и monodroid, предкам Xamarin), и Xamarin предлагает множество примеров и отличную документацию на своем веб-сайте.

Более того, поскольку Xamarin на самом деле является просто привязкой к API-интерфейсам поставщиков, документация Apple и Google всегда актуальна и ответит на многие ваши вопросы. Затем вы можете создать свой собственный сервис MVVMCross, чтобы абстрагировать API поставщиков внутри вашего общего кода.

Что касается будущего Xamarin, с его приобретением Microsoft в марте прошлого года, я уверен, что он никуда не денется, кроме как вперед. После этой продажи и соответствующего перехода на бесплатную модель сообщество только выросло, поддержка улучшилась, а продукт продолжал улучшаться, возможно, даже более быстрыми темпами!

Будущее Xamarin выглядит светлым.

Давайте приготовимся к грохоту!

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

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

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