нативні засоби розробки UI і нативні елементи користувальницького інтерфейсу. Для Android створення UI може відбуватися безпосередньо в коді або ж за допомогою декларативного підходу з описом інтерфейсу в XML. Для iOS це також або код, або використання нативних засобів проектування інтерфейсу - окремі xib-файли або ж один великий Storyboard. Редагування цих файлів відбувається у звичній для iOS-розробника середовищі XCode.
Переносимість коду , за словами розробників, є засіб мкроссплатформенной розробки, тобто очікувано, що додаток, написаний один раз, може бути запущено на різних мобільних платформах. Але, в цьому випадку виникає конфлікт з попереднім пунктом. (рис 10)
Рис. 10 Перенесення коду
Насправді ситуація йде таким чином. Для кожної з платформи потрібно реалізувати власний шар UI. Т.е код, який відповідає за зовнішній вигляд програми, доведеться написати для кожної платформи окремо. Це ціна за можливість використання нативних механізмів роботи з UI. Якщо розбивати додаток на шари, то виходить така схема:
- DataLayer (DL) - Сховище даних, наприклад, база SqlLite або xml-файли;
Data Access Layer (DAL) - Обгортка над сховищем для здійснення CRUD-операцій;
Business Layer (BL) - Шар, що містить бізнес-логіку програми; Access Layer (SAL) - Шар, що відповідає за взаємодію з віддаленими сервісами (Rest, Json, WCF);
Application Layer (AL) - Шар, що містить платформозавісімий код, іншими словами, це код, який залежить від бібліотек monotouch.dll або monodroid.dll;
UserInter face Layer (UI) - Шар користувача інтерфейсу.
кроссплатформенную є всі шари, розташовані вище ApplicationLayer. Частка стерпного коду досить сильно залежить від самого додатка, але, на мій погляд, вона навряд чи може перевищити 50-60%. Інженери Xamarin це розуміють, тому прагнуть до збільшення цієї частки. В якості досягнень у вирішенні цієї проблеми можна розглядати бібліотеку Xamarin.Mobile. Вона надає єдиний для різних платформм API для роботи з камерою, контактами та гео-локацією. Але використання цієї бібліотеки ніяк не обмежує вас у застосуванні платформозавісімого API, наприклад, за допомогою механізму делегатів.
Сторонні компоненти
У Xamarin існує власний магазин сторонніх компонентів Xamarin Components. Він інтегрується в IDE і дозволяє в кілька кліків підключати до вашого проекту різні компоненти, написані як інженерами Xamarin, так і сторонніми розробниками. Кількість компонентів зростає щодня. Є як платні, так і безкоштовні (на даний момент їх більшість). Всі компоненти можна розділити на дві частини. Одні надають додаткові елементи інтерфейсу, інші є бібліотеками класів. Наприклад, варіант для Mono відомої бібліотеки для роботи з Json- Json.NETілі ж бібліотека для взаємодії з Rest-сервісами - RestSharp. Не всі компоненти Кросплатформені, багато доступні тільки для конкретної платформи. Xamarin використовує механізм Біндінг для зв'язування з нативними бібліотеками класів, що дозволяє перенести на C # будь нативні бібліотеки класів. Крім того, для Xamarin.iOS, наприклад, існує спеціальна утиліта, яка вміє генерувати такі Біндінг автоматично. Власне це дозволяє інженерам Xamarin встигати за всіма нововведеннями iOS. Так, зокрема, в Xamarin.iOS практично відразу після виходу з'явилася можливість використовувати Dropbox API, а так само нові функцііiOS 7.
Документація і ком'юніті
Xamarin має відмінну документацію, що містить докладні керівництва, сніппети, а також значну базу прикладів. Документація безпосередньо по всіх класах бібліотек Monotouch і Monodroid є частиною загальної документації Mono. Але, на жаль, цього все одно недостатньо, щоб покрити весь список питань, які можуть виникати в процесі розробки. У Xamarin існує ком'юніті розробників, яка сконцентрована на офіційному форумі і на StackOverlow. Активністю і ініціативністю людей в ком'юніті похвалитися не можу. У цьому плані неоціненну допомогу надала приватна тех. підтримка з інженерами по електронній пошті, доступна в business-ліцензії. Відповідають, як правило, протягом декількох годин і не стандартними відписками «спробуйте вимкнути і включити», а дійсно розбираються в проблемі і допомагають її вирішити. Слід розуміти, що база питань і відповідей, накопичена для нативної розробки набагато ширше, ніж для Xamarin, тому, як би ви не хотіли, доведеться розібратися в специфічному синтаксисі objective-c (c Java проблем бути не повинно), щоб розуміти приклади коду на тому ж StackOverflow. Крім того, це відкриє доступ до прочитання і розуміння офіційної документації для платформи, що на певному етапі може стати дуже важливо. З іншого боку, в цьому є і позитивний момент: от...
