Як ми реалізували крос­платформенну розробку мобільного додатку на Xamarin

Якщо вам дістався класний проект на довготривалий термін, ви хочете його грамотно реалізувати з застосуванням шаблонів проектування, сучасними методологіями та відповідно до всіх канонів, що описані в SWEBOK та ISO 12207, або ж хочете розробляти крос­платформені мобільні додатки — тоді вам точно сюди. Представляємо наш «case study» aka «real­life story» — розробка крутого проекту зі встановленням та впровадженням Scrum в команді нашої компанії WebKate.

Отже, я розповім про технологічну сторону й частково торкнуся команди, проінформую про наші три помилки, яких можна було б уникнути та зберегти дорогоцінний час. З цього приводу пригадується цитата: «Як можна збільшити продуктивність в два рази? Треба збільшити кількість помилок удвічі!».

Проект: соціальна мережа для спортсменів, тренерів, вболівальників з усіма витікаючими можливостями значення соціальної мережі.

Платформа використання додатку: iOS та Android.

Головні питання, які ми ставили на етапі збору вимог та початковій стадії проектування:
— Аналіз мокапів та розбивка їх до реальних екранів;
— Прототипування (Axure);
— Technical Specification, API Documentation;
— Підтримка двох широко використовуваних мобільних платформ;
— Amazon EC2 — платформа серверу (Как задеплоить на Symfony2);
— Шифрування даних.

Перша помилка — застосування Corona SDK

Для початку шукаємо, які технології може нам запропонувати сучасний світ. Маю на увазі такі:
— Corona — Lua;
— QT (Widget, QML) — С++;
— Xamarin — С#.

Оскільки в команди був досвід розробки ігор (Corona SDK), в основному на iOS (Objective­C), то не виникало й питання, що інше можна застосувати. В цьому і була перша помилка.

Corona SDK — засіб крос­платформенної розробки, призначений насамперед для розробки ігор, але у ньому можна писати й бізнес­додатки. В нашому випадку все почалося з Corona. Скажу відразу — це було не досить вдале рішення для побудови UI­елементів. Це двигун для розробки ігор, і цим все сказано!

Дві основні проблеми, з якими ми зіткнулися, що призвели до зміни технології:
— проблеми з багатопоточністю, асинхронними запитами на сервер;
— «пластмасовий» інтерфейс, відсутність UI­редактора. В більшості випадків елементи будувалися за допомогою коду й встановленням навмання за принципом «Скомпілював — о, норм! Кнопка стоїть. А не треба на 1 піксель здвинути?». Такі елементарні функції, як обрізання тексту в текст інпуті чи дроп­листи ставали дійсно проблемними. Елементи інтерфейсу не здавалися нативними, а були начебто пластмасовими. Не було відчуття, що це дійсно гарний додаток, і коли взаємодієш з UI, то боїшся, щоб він не зламався і не «поплив».

Це ще не кажучи про забагованість окремих елементів UI, що призводило до пошуку сторонніх рішень та їх подальшого доопрацювання. Детальніше про технологію можна почитати тут.

Друга помилка — вибір методу розробки додатку

Спочатку будуємо всі екрани (повірте, їх було чимало, перевалило за півсотні), а потім думаємо про інше. Це рішення було обране не випадково, не через нашу некваліфікованість, а через те, що ще не було реалізовано API сервер, про котрий поговоримо дещо згодом. Можна сказати, що це був прототип, який можна було запустити на кінцевій платформі, з частковими працюючими UI­функціями (перехід по екранах, вибір фото, локалізація та інше). З точки зору розробки це правильно, але на це пішло багато часу, щоб далі усвідомити, що не підходить під конкретну задачу. Даний метод можна використати після прорахунку можливого функціоналу та побудови нормальної архітектури додатку та реалізації мінімального функціоналу. Утім, я все ж переконаний, що краще будувати більш­менш закінчений функціонал і далі його нарощувати.

Qt — крос­платформенний інструментарій розробки ПЗ мовою програмування C++. Дозволяє запускати написане за його допомогою ПЗ на більшості сучасних ОС, шляхом простої компіляції тексту програми для кожної ОС без зміни сирцевого коду.

Включає всі основні класи, які можуть бути потрібні при розробці прикладного ПЗ, починаючи з елементів графічного інтерфейсу й закінчуючи класами для роботи з мережею, базами даних, OpenGL, SVG і XML. Бібліотека дозволяє керувати нитями, працювати з мережею, і забезпечує крос­платформенний доступ до файлів.

Qt також може бути використаний у багатьох інших мовах програмування: Ada (QtAda), C# (Qyoto/Kimono), Java (Qt Jambi), Qt Jambi, Pascal, Perl, PHP (PHP­Qt), Ruby (QtRuby) та Python (PyQt, PySide).

Знаю, що це дійсно класна технологія, хоча я особисто «не подружився» з нею ще зі студентських років. Найголовніше, що мені в ній не подобається — це їх Qt Creator IDE, котра надто незручна в порівнянні зі стандартними VS, Eclipse та IDE компанії JetBrains. Другим фактором було те, що не досить комфортні деякі елементи С++, мені зручніше писати на C# і Java. О, якби так сталося, щоб вони покращили свою IDE і розширили якимось магічним способом підтримку технології в мові C#! ;)

Чого варта лише їх декларативна мова QML?!

Приклад:

import QtQuick 1.0

Rectangle { 
    id: canvas
    width: 200
    height: 200
    color: "blue"

    Image {
        id: logo
        source: "pics/logo.png"
        anchors.centerIn: parent
        x: canvas.height / 5
    }
}

Нарешті, я зустрів великого Xamarin’a, що використовує мою улюблену мову програмування С#.

Xamarin — це фреймворк для крос­платформенної розробки мобільних додатків (iOS, Android, Windows Phone). Ідея дуже проста: ви пишете код із застосуванням всіх звичних для вас мовних фіч (LINQ, лямбда­виразів, Generic, async тощо) і при цьому маєте повний доступ до всіх можливостей SDK платформи й рідного механізму створення UI, отримуючи на виході додаток. В цілому це нічим не відрізняється від нативних і не поступається їм у продуктивності.

Наведу декілька посилань на інші джерела, що допомогли в освоєнні даної технології:
— developer.xamarin.com
— xamarin.com/faq
— xamarin.com/university
— blog.xamarin.com
— blog.pluralsight.com/xamarin­
— habrahabr.ru/post/188130/

Розпочавши в повній мірі етап проектування й обравши технології, на яких будемо розробляти — починаємо шукати, в якій же є плюшки. Насамперед це:

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

Xamarin.Forms — крос­платформенний інструментарій, який дозволяє розробникам легко створювати користувацькі інтерфейси, які можуть бути розділені таким чином: Android, iOS і Windows Phone. Інтерфейси відображаються за допомогою вбудованих елементів керування на цільовій платформі, що дозволяє зберегти відповідний зовнішній вигляд для кожної платформи (guides).

Цей інструмент в перспективі є настільки могутнім, що його можна порівняти з WPF. Інтерфейс описується в XAML. На даному етапі розвитку немає графічної побудови в creator та звичних можливостей елементів керування. До того ж, їх кількість обмежена. На нашому проекті ми не застосовували даний інструмент, тому що він є досить сирим. Якщо вам не дуже важливий інтерфейс і не вимагається точного співпадіння екранів з дизайном (pixel perfect), то можете його використовувати.

Для побудови UІ ми використали стандартні засоби розробки інтерфейсу для iOS — storyboard, xib; а для Android — axml. Якщо ви переходите розробляти на дану платформу зі стандартних засобів розробки мобільних додатків, то для вас не буде ніякої складності в розумінні, оскільки засоби майже аналогічні.

Найбільш незручним для мене при розробці під iOS було те, що кожного разу коли щось змінював в storyboard­і, XCode закривався після синхронізації. Це виникло після чергового оновлення SDK, яке в них досить часте, і далі доводилося спочатку відкривати storyboard в xCode через Xamarin Studio.

Також не треба забувати про могутність .NET та його ком’юніті. Наприклад, про такі гіганти, як Telerik та DevExpress, що також підтримують дану технологію.

Архітектурні рішення та CASE засоби

Тепер прийшов час поговорити про самий смак — наші архітектурні рішення, CASE засоби та команду.

Засоби розробки та штуки, які ми використали:
— PM Methodology: Waterfall з переходом на Scrum;
— PM Tool: Atlassian JIRA з переходом на Pivotal Tracker. Не знаю, чим Pivotal кращий за JIRA, і наскільки це було потрібно — однак це було резонним рішенням при переході на Scrum.
— Prototype: Axure;
— OS: OS X Mavericks;
— IDE: Xamarin Studio, XCode. Дехто з нас ще на віртуалці юзав Visual Studio + resharper, бо ця зв’язка надає більше функціональності для кодування. (Коли вже Microsoft почне підтримувати всі платформи технології .NET і JetBrains напише нам нормальну IDE? Ех...);
— SCM: Git — SourceTree (у жодному разі не радив би використовувате SVN, порівняно з гітом — це «дрова»!) Під час розробки була ситуація з конкретно різними гілками, починаючи зі зміни назви проекту (папки) до перебудови структури. Після мерджу приблизно в двохсот файлах були примітивні конфлікти з namespace, які швидко потім вирішили. Git сам визначив, що файли були переміщені, перейменовані та ін. зі збереженям історії комітів файлів (тобто не вийшло так, що я став творцем всіх файлів), SVN у цьому випадку би подумав, що файли видалилися і створилися нові. Можна ще було використати TFS, але оскільки ми на маках всі сиділи й досвіду у використані не було, то цей варіант не розглядався;
— Simulator: iOS Simulator, Genymotion.

Як я згадував раніше, у нас був сервер, реалізований за допомогою фреймворка Symfony2. Зв’язок відбувається на основі REST. Формат даних — JSON, також може буде досить швидко сконфігурований для передачі XML-­даних. API aвтентифікація виконана на основі WSSE. Детальніше про це розписано в окремій статті.

Додаток побудований за архітектурним шаблоном MVC. Дехто тут, можливо, скаже, що можна було використати MVVC, це б дало... бла­бла­бла. Але оскільки ми не використовуємо Xamarin.Forms, то для команди це було не досить зручно, тому що більша її частина прийшла з розробки iOS на Objective C, і ще — бо так історично склалося :)

Проектне рішення було розділено на три основні проекти + декілька проектів для різних додаткових компонентів, наприклад, SlidingMenu та ін. Також проекти для тестування під кожну з платформ.

В основному, ми дотримувалися такої схеми:

Core був створений на основі Shared Projects. Альтернативою є PCL, але вона не дозволяє використовувати директиви компілятора (наприклад #if __ANDROID__) та ін. Детальніше ви можете ознайомитися в документі. Також тут розмістилися бізнес моделі, що заповнювалися за допомогою RestSharp відповідями від сервера, різні менеджери для роботи з сервером, даними, сервіси, елементи валідації (constraints), івенти, локалізація (застосований Extension для класу string) та ін.

Інші основні два проекти — це вже реалізації під конкретну платформу (Android, iOS).

Третя помилка — порушення темпу розробки

Відтак, ми впритул підійшли до команди, а саме нашого становлення та переходу на Scrum (це тема для окремої статті) в процесі етапу конструювання.

І тут якраз і сталася наша третя помилка: початковий темп, в якому починалася розробка на другому етапі, зміни, що вносились без погляду наперед, щоденні мітинги, на яких треба було показати результати роботи (це тримало нас в якомусь незрозумілому стані), а також нові й нові правки клієнта. Це призвело до недосконалої перевірки якості коду кожного із розробників, виснаження команди та нестачі часу для тестування.

Але не дивлячись на це, усвідомивши все, ми виправили становище і увійшли в нормальне русло розробки. Як?

Для початку ввели pull request і сode review (це покращило якість коду, кожен міг написати свій коментар, а також підвищити свої знання в Xamarin, оскільки ця технологія була нова для нас), перейшли на методологію ведення проекту Scrum (змінилося деяке уявлення — наше та клієнта, зменшилося навантаження на команду), провели рефакторинг та ввели деяку ієрархію у веденні гілок в гіту (перший рівень — master, dev; другий рівень по підпапках застосування: feature/..., fix/... та ін., під конкретну платформу). Написали декілька інструкцій для входження нових людей в команду, наприклад, для деплою на AWS EC2.

Далі ми перейшли на інший етап ЖЦ ПЗ, але це вже інша історія.

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

Я вважаю, що ми повністю це довели! Команда, що зовсім не мала досвіду в даній технології, змогла за кілька місяців реалізувати досить складний крос­платформенний додаток.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU