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

Если вам дістався класний проект на довготривалий Термін , ві хочете его грамотно реалізуваті з ЗАСТОСУВАННЯ шаблонів проектування , сучасности методологіямі та відповідно до всіх канонів , что опісані в SWEBOK та ISO 12207 , або ж хочете розробляті кросплатформені мобільні Додатки - тоді вам точно сюди . Представляємо наш « case study » aka « reallife story » - розробка крутого проекту зі встановлення та впровадження Scrum в команді Нашої Компанії WebKate .

Отже , я розповім про технологічну сторону й частково торкне команди, проінформую про наші три помилки , якіх можна Було б унікнуті та Зберегти дорогоцінний час . З цього приводу прігадується цитата: « Як можна збільшити Продуктивність в два рази ? Треба збільшити Кількість помилок удвічі ! ». Проект:соціальна мережа для спортсменів , тренерів, вболівальників з усіма вітікаючімі можливости Значення соціальної мережі . Платформа использование додатка :iOS та Android. Головні питання , які ми ставили на етапі збору вимогта початковій Стадії проектування :
- Аналіз мокапів та розбівка їх до реальних екранів ;
- прототипування ( Axure ) ;
- Technical Specification , API Documentation ;
- Підтримка двох широко вікорістовуваніх мобільніх платформ ;
- Amazon EC2 - платформа сервера ( Як задеплоіть на Symphony2 ) ;
- шифрування Даних .

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

Для качана шукаємо , Які технології может нам Запропонувати сучасний світ . Маю на увазі Такі :
- Corona - Lua ;
- QT ( Widget , QML ) - С ++ ;
- Xamarin - С # . Оскількі у командіровку БУВ досвід розробки ігор ( Corona SDK ) , в основному на iOS ( ObjectiveC ) , то чи не вінікало ї питання , что інше можна застосуваті . У Авторитети и булу перша помилка . 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 ( PHPQt ) , 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 ТОЩО ) i при Авторитети маєте повний доступ до всіх можливости 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 - Це вже й достатньо розвинено технологія щоб використовуват его и створюваті гарні продукти . Я вважаю, що ми Повністю це довели! Команда , что зовсім НЕ мала досвіду в даній технології , змогла за кілька місяців реалізуваті й достатньо складаний міжплатформенних додаток .

Опубліковано: 14/01/15 @ 11:53
Розділ Різне

SEO Блог