company_banner

Быстрое создание MVP (minimum viable product) на базе Microsoft Azure и Xamarin.Forms

    Друзья! Мы открываем в нашем блоге колонку на тему разработки мобильных приложений на Xamarin. И первая публикация от Вячеслава Черникова — руководителя отдела разработки компании «Binwell» затрагивает нюансы кроссплатформенной разработки, а также быстрого создания MVP (minimum viable product) мобильного сервиса на базе Xamarin.Forms и Azure Mobile Services. Все статьи из колонки можно будет найти и прочитать по ссылке #xamarincolumn

    Путь от Qt до Xamarin.Forms, или особенности кросс-платформенной разработки


    В 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 после 2 лет использования


    На хабре уже были полезные статьи про 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% (обычно это адаптация и подключение сторонних библиотек).

    Azure Mobile Services для быстрой разработки API-сервиса


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

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


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

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



    var gcmMessage = new GooglePushMessage(new Dictionary {{ "message", "You got a new message"}}, TimeSpan.FromHours(1));
    var result = await Services.Push.SendAsync(gcmMessage);
    

    Подробнее: ссылка

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



    var message = new SendGridMessage();
    message.AddTo("Customer <customer@example.com>");
    message.From = new MailAddress("no-reply@yourservice.com", "Notification Service");
    message.Subject = emailSubject;
    message.Html = "<b>You got a new message</b>";
    message.Text = "You got a new message";
    var credentials = new NetworkCredential(SENDGRID_USERNAME, SENDGRID_PASSWORD);
    var transportWeb = new Web(credentials);
    await transportWeb.DeliverAsync(message);
    

    Подробнее: ссылка

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



    var client = new TwilioRestClient(TWILIO_SID, TWILIO_TOKEN);
    var result = client.SendMessage("YourSender", "+71234567890", "New message for you");
    

    Подробнее: ссылка

    Вместо 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



        public static class WebApiConfig
        {
            public static void Register()
            {
                var options = new ConfigOptions();
                var config = ServiceConfig.Initialize(new ConfigBuilder(options));
                config.MessageHandlers.Insert(0, new ServerCompressionHandler(new GZipCompressor(), new DeflateCompressor()));
            }
        }
    

    Публикуем изменения на сервере

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

    1. Устанавливаем ее из Nuget для всех проектов в Solution.
    2. Активируем при создании клиента к Azure Mobile Services

    var _client = new MobileServiceClient(API_BASE_URL, API_KEY, new NativeMessageHandler());
    

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

    Выводы


    1. Использование кросс-платформенных фрейморков требует хороших знаний каждой из платформ для создания качественных мобильных приложений.
    2. На базе Azure Mobile Services можно за пару часов развернуть полноценный Backend со всем необходимым функционалом.
    3. Xamarin.Forms позволяет создавать качественные мобильные приложения, сокращая время вывода продукта на рынок.

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

    Об авторах



    Вячеслав Черников — руководитель отдела разработки компании Binwell. В прошлом — один из Nokia Champion и Qt Certified Specialist, в настоящее время — специалист по платформам Xamarin и Azure. В сферу mobile пришел в 2005 году, с 2008 года занимается разработкой мобильных приложений: начинал с Symbian, Maemo, Meego, Windows Mobile, потом перешел на iOS, Android и Windows Phone.

    Мы с удовольствием анонсируем, что Вячеслав выступит в качестве эксперта на мастер-классе по Xamarin на конференции DevCon 2016, где поделится опытом разработки приложений для Apple Watch и Google Wear.

    Другие статьи автора:


    Полезные ссылки


    Microsoft 260,95
    Microsoft — мировой лидер в области ПО и ИТ-услуг
    Поделиться публикацией
    Похожие публикации
    Комментарии 29
    • 0
      спасибо за статью, после недавней новости о том, что ксамарин теперь условно бесплатный подумывая о переходе на него и писать софт для мобильных на нём
      • 0
        Почему условно бесплатный? Сейчас есть ограничения на использования xamarin?
        • 0
          ну, на странице pricing что-то ещё есть про pro версии, или я ошибаюсь?
          • +1
            Сейчас Xamarin доступен бесплатно при использовании Visual Studio Community Edition: Магазин Xamarin, Сравнение редакций Visual Studio для Xamarin
            • –2
              VS Community — та же Visual Studio Professional, только на ней нельзя писать коммерчиские программы
              • +1
                Можно, вообще-то. По крайней мере для индивидуальных разработчиков и маленьких независимых команд (до 5 человек вроде) таких ограничений нет.
                • 0
                  О, не знал. Спасибо! Это очень хорошо :)
                • 0
                  Нет, это не так. Использовать VS Community запрещается только «Предприятиям»:
                  Если вы являетесь предприятием, вашим сотрудникам и подрядчикам запрещено использовать данное программное обеспечение для разработки или тестирования приложений, за исключением разработки по программам с открытым исходным кодом и разработки для образовательных целей в соответствии с предоставленным выше разрешением. «Предприятие» — это любая организация и ее аффилированные лица, которые совместно имеют (а) более 250 компьютеров или пользователей либо (б) годовой доход более 1 млн долларов США (или эквивалент в другой валюте), а «аффилированные лица» — это лица, контролирующие (через контрольный пакет акций) организацию, контролируемые ею или находящиеся под общим контролем с организацией.

                  www.visualstudio.com/support/legal/mt171547
        • 0
          дел
          • 0
            Интересная статья.

            Где то можно подробнее почитать о взаимосвязях между блоками в схеме из раздела «Архитектура мобильного приложения»?
            • 0
              Планируем описать подробнее аспекты разработки на Xamarin.Forms в следующих статьях. В одной из них глубже рассмотрим аспекты, связанные с архитектурой.
            • 0
              Вот все хотелось узнать, а тут как раз в тему:
              С опытом разработки для встраиваемых систем, пайтоном и c# для win forms стоит ли вообще в Xamarin соваться или и правда надо сначала подучить нативную разработку на обеих главных плотформах? В 80 процентах случаев апликашка то должна быть простой, без всяких наворотов на низких уровнях, или я не прав?
              И может подскажите хорошую литературу по Xamarin русском или английском?
              Спасибо!
              • 0
                На русском языке материалов по Xamarin.Forms немного, поэтому лучше начать со следующих полезных ресурсов

                Книга Creating Mobile Apps with Xamarin.Forms (Eng)
                Xamarin.Forms Kickstarter (Eng)

                Также будем подробнее рассказывать о различных аспектах Xamarin в будущих статьях
                • 0
                  А насчет первого вопроса? ;)
                  • 0
                    Если приложения будут простые на базе стандартных контролов, то можно обойтись готовыми библиотеками и модулями (Xamarin Forms Plugins), при необходимости обращаясь к StackOverflow ;)

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

                    А вот стоит связываться или нет, это уже решать вам :)
              • 0
                Подскажите, пожалуйста. Вот вторую неделю изучаю Xamarin. Больше с уклоном в первую очередь на разработку приложений под iOS. Нужно ли сразу и с перспективой изучать Xamarin.Forms и разрабатывать приложения уже сейчас на нем, или все же достаточно копаться в более «нативном» Xamarin.iOS?
                • +2
                  Все зависит от задач, которые вы планируете решать. Если вам необходимо разрабатывать бизнес-приложения для iOS+Android (+Windows), то Xamarin.Forms несомненно стоит рассматривать как один из лучших вариантов. Если же вас интересует iOS и приложения с большим количеством нативных фич, то Xamarin.iOS — то, что нужно :)
                • 0
                  По поводу «Ускоряем клиент-серверное взаимодействие», а не хотели бы вы использовать ServiceStack + Protobuf (все есть под Xamarin)? В таком случае вы получите гораздо большую кроссплатформеность ваших DTO объектов + по скорости и трафику будет выигрыш значительней.
                  • 0
                    ServiceStack + Protobuf не пробовали, спасибо за наводку! Из практики GZIP JSON бывает вполне достаточно для ускорения работы с небольшими и средними объемами данных, а вот для большого количества данных решение ServiceStack + Protobuf может быть очень интересным. Надо будет поэкспериментировать.
                    • 0
                      Согласно тестам у ServiceStack'a и JSON сериализатор шустрее работает.
                  • +1
                    Нечестно сравнивать текущий ксамарин и Qt из 2008 года. Вы уж сравните что ли с 5.6, где есть почти все необходимые мобильные контролы, а то получается «вот это все херня, а ксамаринчик рулез».
                    • +1
                      Прошу заметить, что я не сравниваю Qt и Xamarin, а написал о той смене технологий, которую мы проделали. В свое время плотно занимался Qt (имею статус Qt Certified Specialist) и очень люблю этот фреймворк. Пробовали его использовать несколько лет назад для мобильных платформ, но выбрали Xamarin.
                      • 0
                        А на завлекающей картинке как раз Qt и Xamarin, и кто будет быстро читать может не заметить что речь идет о Qt тех времен когда Nokia была топовым производителем на равне с Apple. Получается довольно черно-пиарная фраза «Вот _продуктN1_ с ним были траблы и вообще это геморой, зато _продуктN2_ решение всех проблем». Вам не кажется, что здесь что-то не так ?) Сколько Вам заплатили за пиар Xamarin ?))
                        • 0
                          Ох. Траблы есть всегда и везде :)
                    • 0
                      Что, формы уже допилили до рабочего состояния?
                      • 0
                        Да, вполне :)
                        • 0
                          А это уже MS дал ресурсы или они уже давно все сделали своими силами? Год назад все было печально.
                          • 0
                            МС денег давал примерно год назад.
                            • 0
                              Допилили до хорошего состояния до покупки Майкрософтом. И постоянно развивается и еще есть куда стремиться, но прогресс, как говорится — на лицо.

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

                        Самое читаемое