Швидке створення 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, Універсальний). Заснований він на базі класичних 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-сервіс), адже ні один сучасний мобільний сервіс не обходиться без серверної інфраструктури. Тут нам довго вибирати не довелося, так як всім нашим вимогам (швидкість розробки і розгортання, можливість масштабування, низькі витрати на супровід) задовольняє платформа Microsoft. Без зайвих коментарів зазначимо, що для наших завдань вона підійшла ідеально, надаючи велику кількість готових модулів.

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


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

Ось як легко і просто реалізувати відсилання Push-повідомлень в Microsoft 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


Створюємо контролери для роботи з даними і авторизації


Публікуємо в Microsoft Mobile Services

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

Щоб мінімізувати затримки при взаємодії між компонентами (SQL Database, Mobile Services, Web Site, BLOB Storage), споживачі і постачальники повинні знаходитися в одному дата-центрі.

Архітектура мобільного додатка
При розробці мобільних додатку архітектура відіграє важливу роль, так як саме від правильної реалізації модулів і їх зв'язків залежить можливість вилову багів і розвитку системи. Ми намагаємося мінімізувати зв'язку між модулями і дотримуватися класичної моделі MVVM. Ось підхід, який ми використовуємо:


Прискорюємо клієнт-серверне взаємодія
Завершимо ми нашу сьогоднішню статтю маленькими практичними твіками про те, як прискорити передачу даних в мобільних додатках на Xamarin і хмарних сервісах Microsoft Mobile Serivces.

За замовчуванням Microsoft 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. Активуємо при створенні клієнта до Online Mobile Services
var _client = new MobileServiceClient(API_BASE_URL, API_KEY, new NativeMessageHandler());

Тепер у нас сервер стискає дані, а клієнт використовує швидкі бібліотеки для їх завантаження.

Висновки
  1. Використання крос-платформних фрейморков вимагає хороших знань кожної з платформ для створення якісних мобільних додатків.
  2. На базі Microsoft 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.

Корисні посилання



Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.