Независимо от того какие используются платформы, проекты Xamarin все используют один и тот же формат файла решения (формат файла Visual Studio «.sln»). Решения могут быть общими для всех сред разработки, даже когда отдельные проекты не могут быть загружены (например, для Windows Phone проект в Xamarin Studio).
При создании нового кроссплатформенного приложения первый шаг заключается в создании пустого решения. В этом разделе о том, что произойдет дальше: создание проектов для построения кроссплатформенный мобильных приложений.
Совместное использование кода
Обратитесь к документу Параметры совместного использования кода для подробного описания того, как реализовать обмен кода между платформами.
Общие (Shared Asset) проекты
Самый простой подход совместного доступа к файлам кода является использование Общего проекта.
Этот метод позволяет совместно использовать один и тот же код в проектах различных платформ, а также использовать директивы компилятора для включения различного, специфичные для каждой платформы кода.
Библиотеки переносимых классов (Portable Class Libraries — PCL)
Исторически файлы проекта .NET (и полученная сборка) были ориентированы на конкретные версии фреймворка. Это защищает проект или сборку от использования в разных фреймворках.
PCL — особый тип проекта, который может использоваться на разнородных платформах CLI например Xamarin.iOS и Xamarin.Android, так как Silverlight, WPF, Windows Phone и Xbox. Библиотека может использоваться полным подмножеством платформы .NET и ограничивается только целевой платформой.
Вы можете прочитать больше о поддержке PCL в Xamarin и следовать описанным инструкциям, чтобы посмотреть как это работает — пример TaskyPortable.
Наполнение решения
Независимо от того, какой метод используется для совместного использования кода, общая структура решения должна реализовать многоуровневую архитектуру, которая поощряет совместное использование кода. Подход Xamarin состоит в разделении кода на два типа проектов:
- Базовый (Core) проект — Пишется повторно используемый код в одном месте, для совместного использования на различных платформах. Используйте принципы инкапсуляции, чтобы скрыть детали реализации, где это возможно.
- Платформоспецифичный прикладной проект — Потребление повторного используемого кода с минимальным соединением, насколько это возможно. На этом уровне добавляются зависимые от платформы функции, построенные на компонентах, экспонированные в Базовый проект.
Базовый (Общий) проект
В общем коде проектов следует ссылаться только на сборки, которые доступны на всех платформах – т.е. общие пространства имен такие как System, System.Core и System.Xml.
В общих проектах следует реализовывать функционал без пользовательского интерфейса настолько, насколько это возможно, который обычно включает следующие слои:
- Уровень данных – код, который физически заботится о хранении данных. SQLite-NET, альтернативные базы данных такие, как CoolStorage или даже XML-файлы. Классы уровня данных, как правило, используется только на уровне доступа к данным.
- Уровень доступа к данным – определяет интерфейс API, который поддерживает необходимые операции с данными для функционирования приложения, такие как методы для получения списка доступа к данным, элементы личных данных и прочие.
- Уровень доступа к сервисам — Дополнительный слой для предоставления облачных услуг приложению. Содержит код, который имеет доступ к удаленным сетевым ресурсам (веб-сервисы, загрузки изображений и т.д.) и, возможно, кэширование результатов.
- Уровень бизнес-логики — Определение классов Модели и Фасада или классов Диспетчера, которые предоставляют функционал для платформоспецифичным проектам приложения.
Платформоспецифичный проект приложения
Платформоспецифичный проект должны ссылаться на узлы, необходимые для связывания с SDK каждой платформы (Xamarin.iOS, Xamarin.Android или Windows Phone), а также на совместно используемого код Базового (Общего) проекта.
Платформоспецифичный проект должен обеспечивать:
- Уровень приложения – конкретную функциональность платформы и привязки/преобразования между объектами бизнес-слоя и пользовательским интерфейсом.
- Уровень пользовательского интерфейса – экраны, элементы управления пользовательского интерфейса, презентация логических проверок.
Пример
Архитектура приложения изображена на этой диаграмме:
Этот схема показывает установку решения с общим Основным (Core) проектом, iOS и Android прикладными проектами. Общий проект (Shared Code) содержит код, относящиеся к каждому из архитектурных уровней (Бизнес, Сервисов, Данных и Доступа к данным):
Ссылки проекта
Ссылки проекта отражают зависимости для проекта. Основные (Core) проекты ограничивают свои ссылки на общие сборки, так что код можно легко использовать совместно. Платформоспецифичные проекты приложения имеют ссылки на общий код, а также на другие платформоспецифичные сборки, которые они должны использовать для целевой платформы.
Каждый проект приложения имеет ссылки на Общий (Shared) проект и содержит код пользовательского интерфейса, необходимый для функционирования пользователя, как показано на этих скриншотах:
В тематических исследованиях приводятся конкретные примеры структурирования проектов.
Оригинал статьи
| <= Часть 2 — Архитектура приложения | Часть 4 — Работа с несколькими платформами => |
Я бы не советовал при выборе учитывать результаты голосования, так как и так уже отобраны самые популярные решения. При выборе решения есть несколько разных аспектов сильно влияющих на результат. Для потребительских приложений, если они сложны и массовы, на мой взгляд, лучше вообще отказаться от кроссплатформенности. Все эти(кросс-платформенные) решения наиболее массово применяются в корпоративной сфере, так что считайте все написанное далее касается только корпоративной сферы.