Разработка крупных приложений на Xamarin: в чем выгода

Рассказывает Павел Кузнецов, руководитель мобильной разработки DD Planet

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

Несколько слов о Xamarin

Xamarin — это современный кроссплатформенный фреймворк разработки мобильных приложений на языке C# для устройств на iOS, Android и Windows.

Американская компания Xamarin основана в 2011 году. Ее разработчики адаптировали платформу .NET Framework, изначально рассчитанную на работу с Microsoft Windows, под другие мобильные платформы. В 2016 году компанию купил Microsoft и инструментарий стал бесплатным.

Он ориентирован на разработчиков, которые:

  • хотят переиспользовать код, тесты и бизнес-логики на различных платформах;
  • пишут кроссплатформенные приложения на C#.

Преимущества фреймворка:

  1. Это инструмент .NET, поэтому он подходит тем, кто специализируется именно на .NET разработке. Например, DD Planet: мы работаем на этой платформе уже 17 лет и стали использовать Xamarin одними из первых на российском рынке.
  2. Позволяет использовать большое количество .NET библиотек. У .NET огромный репозиторий библиотек. Разработчику там трудно чего-то не найти.
  3. В разработке используется язык C#, он позволяет строить объектно-ориентированную модель и изолировать уровни. Это значит, что можно выстраивать архитектуру с упором на переиспользование кода.
  4. UI настраивается для каждой платформы по отдельности нативными инструментами.
  5. В целом на базе Xamarin можно выстроить любое архитектурное решение. Игры на нем особо не попишешь, но некоторые делают и это.

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

Давайте посмотрим, за счет чего это происходит.

Ценность для крупных приложений

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

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

В среднем с его помощью до 90% общего кода приложения без изменений программисты могут переиспользовать на разных платформах. Разработку можно вести под Windows или MacOS и компилировать в нативные пакеты приложений: в.apk для Android или .ipa для iOS.

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

Использование Xamarin в разработке приложения «Вместе.ру»

Один из ярких примеров — наш крупный интеграционный проект, который мы реализуем совместно с клиентом уже более трех лет. Это экосистема для соседей по всей России «Вместе.ру» — мобильное приложение на Android и iOS, созданное с помощью Xamarin.

Сервисом пользуются десятки тысяч человек, подключены управляющие компании и много разных партнеров. В нем доступны:

  • Регистрация недвижимости, подтверждение права владения через Росреестр и личности через Госуслуги.
  • Высоконагруженный мессенджер с тремя уровнями чатов: контекстными, групповыми и личной перепиской. Важная часть приложения, ежедневно обрабатывает тысячи сообщений.
  • Новостная лента, уведомления и группы по интересам.
  • Сервисы для оплаты ЖКУ и связи с управляющей компанией.
  • Интеграция с сервисами: Госуслуги, Росреестр, ГИС ЖКХ, ФИАС, 2 Gis, DaData. Совсем недавно подключили сервис «Добродел», мы передаем им из нашей системы жалобы жильцов.
  • Управление парковочными местами и шлагбаумами.

Приложение огромное — реализовано больше 200 экранных форм: кабинеты пользователей и партнеров, множество разных новостных лент, сервисов оплаты и прочее.

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

Принципы разработки проекта:

  • Мы работаем с Xamarin.Native — оберткой над нативными SDK, позволяющей писать код на C#. Но мы также продолжаем использовать нативные инструменты для описания UI так, как это было задумано платформой, и проводим четкую линию между UI и бизнес-логикой.
  • У нас есть как отдельные проекты для Android и iOS, так и общие, которые переиспользуются на каждой платформе — всего таких проектов 15.
  • Эти проекты мы изолируем друг от друга в том числе с помощью паттерна проектирования архитектуры приложения MVVM. Это и дает нам возможность быстро перетаскивать их с одного решения на другое, с одного экрана на другой.
  • Приложение самостоятельно инспектирует работу с API — это позволяет нам быстро замечать неполадки или сбои. Также в него встроены инструменты тестирования и отладки, у тестировщиков прямо в приложении есть доступ к служебным экранам для диагностики.
  • Мы выстраиваем архитектуру таким образом, чтобы код приложения был разбит на переиспользуемые модули, которые можно использовать отдельно друг от друга и собирать новый функционал из готовых модулей «по кирпичикам».

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

Мы написали всего 250 тысяч строк чистого кода. Из них:

  • Core: 110 тысяч;
  • iOS: 80 тысяч;
  • Android: 60 тысяч.

Без применения Xamarin пришлось бы дважды писать Core: Core iOS (110 тысяч) и Core Android (110 тысяч). В нашем случае Core написан единожды и используется и для Android и для iOS. Таким образом, мы сэкономили 40% кода.

Рецепт успеха

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

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

0
19 комментариев
Написать комментарий...
Икс Маска

3 года назад отказался от Xamarin в пользу Flutter и не жалею. Xamarin – прошлый век.

Ответить
Развернуть ветку
DD Planet
Автор

А какого рода проекты вы делаете на Flutter? Он не очень подходит для сложных приложений, где нужно разрабатывать серьезный функционал.

Ответить
Развернуть ветку
Икс Маска

Применение Flutter-а никак не связано с «серьезностью» приложений! И Flutter – это только UI и ничего больше! Причем такие мощные UI, что иногда бывает сложно себе представить, что оказывается, что так «можно было» :)). Все остальное остается в нативе.
Почему именно Flutter, а не другие фреймворки и даже не «натив»?

Единая база исходного кода для iOS и Android платформ – это огромный «плюс» в пользу использования любых кроссплатформенных фреймворков (четкая организация кода и поддержка в разы дешевле).
WEB- и JS- кроссплатформенные фреймворки типа: Ionic, ReactNative, Xamarin, Cordova (PhoneGap), Qt. работают через WebView-мост, что делает такие приложения очень «медленными» и «негибкими» для реализации нестандартного функционала!
Flutter – это принципиально другой подход в кроссплатформенной мобильной разработке. Если кратко, то можно сказать, что отрисовка UI на Flutter работает без всяких WebView-мостов и вся отрисовка UI происходит средствами операционной системы. Т.е. UI обычных приложений на Flutter-е даже на Android-е работают напрямую с видеоускорителем (как работают игры), что делает их такими же быстрыми, какими всегда были приложения для iOS.
Flutter — это SDK, который предназначен для создания самых высокопроизводительных UI для мобильных приложений под iOS и Android из единой кодовой базы, с открытым исходным кодом, созданный Google. Также Flutter является пока единственным инструментом для создания приложений для новейшей OS от Google – Fuchsia.

Совет: Многие современные мобильные приложения (в том числе с натива) уже переписаны или активно переписываются на Flutter, поэтому, чтобы в будущем вам не пришлось переписывать UI ваших мобильных приложений на Flutter, рекомендую вам изначально планировать разработку UI ваших мобильных приложений для iOS и Android платформ на Flutter SDK.
Сегодня начинать разработку ваших приложений на других фреймворках или даже в «нативе» - это обречь себя на технологическое отставание на старте. Рекомендую подробнее изучить этот вопрос для себя :).
—--—--—--—--—--—-
ПС. Не буду приводить примеры своих приложений на Flutter-е в Сторах (у меня их около 20), т.к. там уже около 50% всех приложений для iOS и Android переписаны на Flutter.
Интересно, что Flutter начал активно развиваться в сторону Web, Win, Mac –приложений, все это еще очень «сырое», но уже работоспособное. Тут https://clck.ru/RKhpQ набросал простой демо-пример небольшого Web-приложения на Flutter (анонимного мессенджера), через которое вы уже сейчас можете из браузера написать мне в мобильное приложение или связаться со мной по голосовой или видео связи из своего браузера (для входа в мессенджер используйте кнопку «Анонимный вход». Для осуществления аудио- и видео- звонков ваш браузер должен быть обновлен до последней версии).
Т.е. на Flutter-е уже сегодня легко можно создавать приложения одновременно для 3-х платформ: Web, iOS и Android. Вот еще один пример использования этого же WEB-приложения онлайн-чата для организации онлайн-консультаций на сайте можно потестить тут: https://freedirect.ru/ (красная кнопка онлайн-консультанта внизу справа).
На Flutter-е все это делается быстро и просто.

Ответить
Развернуть ветку
Dmitry Khalin

qt через webview? Вы ничего не перепутали?

Ответить
Развернуть ветку
Икс Маска

За «Qt» простите – backspace-ом не доработал :).
Qt — собственная эффективная система отрисовки пользовательского интерфейса либо на базе растрового движка (например, CoreGraphics в iOS), либо на базе Open GL (ES). Именно это и делает Qt -фреймворк портируемым. То есть в Qt используются свои механизмы отрисовки UI — приложение будет выглядеть нативным настолько, насколько вы его сами стилизуете.
В Qt на iOS используются стандартные модули CoreGraphics и UIKit для отрисовки пользовательского интерфейса. В Android ситуация чуть посложнее, так как Qt использует механизмы NDK для отрисовки UI, а для доступа к Java API и управления приложением используется мост JNI. Также в iOS и Android может использоваться Open GL ES для отрисовки QML или работы с 3D.

Ответить
Развернуть ветку
Сергей Чамкин

Статья от любителей легаси. Куда уж Гуглу, который переписывает свои приложения на флаттер, тягаться с ХАМАРИНОМ))) в 2020 то. У флаттера же core достигает 98+%. Мертвая технология, должна умереть.

Ответить
Развернуть ветку
Dmitry Khalin

Яндекс пишет свою супер Апу для своих сервисов на флаттере. Есть некоторые безумцы, которые делают банкинг. Это достаточно сложные приложения?

Ответить
Развернуть ветку
...

Xamarin в 2020? Серьезно?...

Ответить
Развернуть ветку
DD Planet
Автор

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

Ответить
Развернуть ветку
Сергей Чамкин

А специалистов тоже столько же как и на нативе ? А библиотек?)

Ответить
Развернуть ветку
Павел Кузнецов

Особого дискомфорта в поиске специалистов нет, все как и везде. Xamarin позволяет достаточно легко влиться людям как со знаем натива, так и .Net разработчикам. Одни подтянут C# и .Net, другие - знание SDK. У нас в командах есть примеры и таких, и таких. 

Ответить
Развернуть ветку
Икс Маска

Специалистов – меньше, т.к. чтобы писать под Flutter нужно быть прежде всего хорошим нативщиком под iOS и Android. Библиотек – больше. 

Ответить
Развернуть ветку
Панда Ву

Хоть я только им из всей кроссплатформы не пользовался, с виду Xamarin выглядит адекватным решением. Вопрос в том, почему Kotlin Multiplatform позиционируется как первый такой, ведь концепция та же...

Ответить
Развернуть ветку
Artem Sovetnikov

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

Ответить
Развернуть ветку
Павел Кузнецов

Если говорить о переиспользовании кода, то любой фреймворк, позволяющий делить код между платформами и вести разработку на одном языке, даст возможность выстроить архитектуру, направленную на переиспользование и экономию кода. Но Xamarin помимо этого дает возможность работать с нативом так, как это задумано на платформе: использовать xib и storyboard, например. Обращение к нативному SDK в xamarin отличается только используемым языком, что позволяет разработчику получать опыт не только работы с фреймворком, но и с голым SDK. Ну а опыт работы с SDK, в свою очередь, позволяет без особых проблем читать и разбирать нативные референсы и библиотеки. За все время моей работы с Xamarin наиболее значимое ограничение - количество готовых библиотек. Но даже тут все не так страшно: Xamarin дает возможность создавать Binding Library (обертка к нативной библиотеке, позволяющая работать с ней через xamarin), ну а знание SDK позволяет без особых проблем переписать нативные библиотеки на C#.
О каком взаимодействии натива с Core вы спрашиваете?
Если на уровне кода, то все как в обычных решениях. В нативный проект подключен Core.
Если речь о реалтайме - mono прослойка транслирует обращения. 

Ответить
Развернуть ветку
Сергей Чамкин

Посмотрите лучше на тренд среди кроссплатформенных фреймворков. Хамарин уже года 3 как не актуален 

Ответить
Развернуть ветку
Artem Sovetnikov

Вечно можно смотреть на воду, огонь и рейтинги блин!
Тут вам практику рассказали :)
Это на микро-фриланс-сейчас-бабах проектах можно по рейтингам скакать и пробовать одно, потом не пошло, затем другое

Ответить
Развернуть ветку
Сергей Чамкин

Ваша практика закончится мертвой поддержкой от сообщества

Ответить
Развернуть ветку
Artem Sovetnikov

Что вы, что вы, я не люблю технологии от Microsoft в разработке, они с легкостью хоронят всё хотят :)
Вы не поняли смысл статьи

Ответить
Развернуть ветку
16 комментариев
Раскрывать всегда