В 2008 году мы решили перейти из сферы продажи мобильных приложений к их разработке, и в качестве отправной точки был выбран Qt, так как по спецификациям он охватывал сразу Symbian, Maemo (потом Nokia MeeGo) и Windows Mobile. Плюсами была возможность разработки напрямую в Linux, зрелость самого фреймворка, а также наличие исходных кодов. На Qt писать было приятно: архитектура, логика самого фреймворка и его компонентов, C++, удобная среда разработки. Но когда дело дошло до запуска на различных мобильных ОС, то приходилось еще очень долго работать с нюансами. Для Windows Mobile собирать и пересобирать библиотеки, разбираться в API от Symbian, прописывать зависимости и конфиги для Maemo/Meego. 

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

 Потом наш выбор упал на HTML5. Результаты были не то, чтобы плохими, но явно не достаточными для создания пользовательских приложений. Потом перешли к разработке на Objective C для iOS и на Java для Android. Результаты были отличные, но один и тот же функционал приходилось реализовывать 2 раза. 

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

 В 2014 году появился Xamarin.Forms (далее XF). После двух лет непрерывного использования XF в реальных проектах, сейчас мы можем с уверенностью сказать, что после XF 2.0 продукт дорос до массового использования при создании бизнес-приложений. Именно поэтому мы и выбрали его в качестве основы для создания MVP сервиса Order King. 

 На хабре уже были полезные статьи про Xamarin.Forms, поэтому в подробности вдаваться не будем. Если коротко, то Xamarin.Forms позволяет создавать мобильные приложения для iOS/Android и Windows (Phone, Store, Universal). Основан он на базе классических Xamarin.iOS и Xamarin.Android, давая дополнительный уровень абстракции при разработке мобильных приложений. 

 Пользовательский интерфейс описывается на XAML (предпочтительнее) или в C#-коде (при необходимости). И если в версиях XF 1.x то и дело возникали мелкие нюансы, устраняемые с усилиями, то в 2.х все стало работать стабильно и хорошо из коробки. 

 Ключевое отличие XF 2.х от 1.х – возможность компиляции XAML (в 1.х был парсинг и интерпретация “на лету”), что сильно ускорило интерфейс и сделало его таким же быстрым, как и при использовании Swift/Java. Сразу добавим, что «из коробки» таких отличных результатов добиться все равно не получится и надо знать много тонкостей, о которых мы расскажем в следующих статьях. 

 Использование Xamarin.Forms не отменяет необходимость изучения целевых платформ (iOS/Android), а даже наоборот, повышает требования к уровню специалистов, так как возникает много интересных моментов именно на стыке XF <-> целевая ОС. Более того, правильным будет переход на XF только после наличия существенного опыта разработки приложений на Objective C/Swift и Java. 

 Из нашей практики, в зависимости от проекта, необходимость спускаться на уровень Xamarin.iOS/Xamarin.Android возникает для реализации 10% функциональности, а на Objective C/Java – 1%-2% (обычно это адаптация и подключение сторонних библиотек). 

 Начнем мы с разработки Backend (API-сервис), ведь ни один современный мобильный сервис не обходится без серверной инфраструктуры. Здесь нам долго выбирать не пришлось, так как всем нашим требованиям (скорость разработки и разворачивания, возможность масштабирования, низкие затраты на сопровождение) удовлетворяет платформа Azure. Без лишних комментариев отметим, что для наших задач она подошла идеально, предоставляя большое количество готовых модулей. 

 На схеме ниже показана верхнеуровневая архитектура Backend-сервиса. 

 Если рассматривать те возможности, которыми должен обладать современный Backend для мобильных приложений, помимо предоставления данных и механизмов авторизации, то можно выделить также: отправку Push-уведомлений, отправку Email-уведомлений и отправку SMS-сообщений (критические уведомления и временные коды/пароли). 

 Вот как легко и просто реализовать отправку Push-уведомлений в Azure Mobile Services на Android (iOS и Windows по аналогии). Подробнее: ссылка 

 А вот отправка Email-уведомлений через SendGrid. Подробнее: ссылка 

 И при необходимости можно подключить Twilio для отправки SMS: Подробнее: ссылка 

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

 Для быстрого разворачивания Backend (актуально для MVP) мы используем следующий подход: 

 Описываем классы с данными (Code First)

 Обновляем MobileServiceContext

 Создаем контроллеры для работы с данными и авторизации

 Публикуем в Azure Mobile Services

 Автоматически создается структура базы данных и запускается Backend, к которому можно уже подключать клиентов. В целом на создание и разворачивание типового Backend (работа с данными, авторизация, уведомления) может уйти от нескольких часов до пары дней в зависимости от необходимой функциональности. 

 Чтобы минимизировать задержки при взаимодействии между компонентам (SQL Database, Mobile Services, Web Site, BLOB Storage), потребители и поставщики должны находиться в одном дата-центре. 

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

 Завершим мы нашу сегодняшнюю статью маленькими практическими твиками о том, как ускорить передачу данных в ваших мобильных приложениях на Xamarin и облачных сервисах Azure Mobile Serivces. 

 По умолчанию Azure Mobile Services при использовании .NET не поддерживает GZIP-сжатие передаваемых данных. Для того, чтобы его включить можно использовать библиотеку Microsoft.AspNet.WebApi.MessageHandlers.Compression: 

 Ставим ее из Nuget 

 Активируем сжатие в файле \App_Start\WebApiConfig.cs Публикуем изменения на сервере 

 На стороне клиента в библиотеках Azure Mobile Services по умолчанию используется стандартный для .NET клиент HttpClient. Это, конечно, замечательный программный модуль, но для iOS и для Android есть гораздо более эффективные решения: NSURLSession и OkHttp. Для их использования в Xamarin.Forms нужно подключить библиотеку ModernHttpClient: 
 Теперь у нас сервер сжимает данные, а клиент использует быстрые библиотеки для их загрузки. 

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

 Эксперт по стратегическим технологиям