Поделиться через

Часть 3. Настройка кроссплатформенного решения Xamarin

  • Статья

Независимо от того, какие платформы используются, проекты Xamarin используют один и тот же формат файла решения (формат файла .sln Visual Studio). Решения можно совместно использовать в средах разработки, даже если отдельные проекты не могут быть загружены (например, проект Windows в Visual Studio для Mac).

При создании кроссплатформенного приложения первым шагом является создание пустого решения. В этом разделе объясняется, что происходит дальше: настройка проектов для создания кроссплатформенных мобильных приложений.

Общий доступ к коду

Дополнительные сведения о реализации совместного использования кода на разных платформах см. в документе "Параметры общего доступа к коду".

.NET Standard

Проекты .NET Standard предоставляют простой способ совместного использования кода на разных платформах, создавая сборки, которые можно использовать на платформах Windows, Xamarin (iOS, Android, Mac) и Linux. Это рекомендуемый способ совместного использования кода для решений Xamarin.

Другие варианты

Исторически Xamarin использовали переносимые библиотеки классов (PCLs)] и общие проекты. Ни для новых проектов не рекомендуется; и следует рассмотреть возможность переноса существующих приложений для использования .NET Standard.

Заполнение решения

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

  • Основной проект (или "Общий") — запись повторно используемого кода в одном месте для совместного использования на разных платформах. Используйте принципы инкапсуляции, чтобы скрыть сведения о реализации везде, где это возможно.
  • Проекты приложений для конкретной платформы — использование повторного использования кода с минимальными зависимостями, как это возможно. Функции для конкретной платформы добавляются на этом уровне, созданные на основе компонентов, предоставляемых в проекте Core.

Основной проект

Основные проекты, которые совместно используют код, должны быть .NET Standard и только эталонные сборки, доступные на всех платформах— т. е. общие пространства имен платформы, такие как System, System.Core и System.Xml.

Основные проекты должны реализовать как можно больше функциональных возможностей, отличных от пользовательского интерфейса, которые могут включать следующие уровни:

  • Уровень данных — код, который заботится о физическом хранилище данных, например. SQLite-NET или даже XML-файлы. Классы слоев данных обычно используются только уровнем доступа к данным.
  • Уровень доступа к данным — определяет API, поддерживающий необходимые операции данных для функциональных возможностей приложения, таких как методы для доступа к спискам данных, отдельным элементам данных, а также созданию, редактированию и удалению.
  • Уровень доступа к службе — необязательный уровень для предоставления облачных служб приложению. Содержит код, который обращается к удаленным сетевым ресурсам (веб-службам, скачиваниям изображений и т. д.) и, возможно, кэшированию результатов.
  • Бизнес-уровень — определение классов модели и классов Façade или Manager, которые предоставляют функциональные возможности приложениям для конкретной платформы.

Проекты приложений для конкретной платформы

Проекты, относящиеся к платформе, должны ссылаться на сборки, необходимые для привязки к пакету SDK для каждой платформы (Xamarin.iOS, Xamarin.Android, Xamarin.Mac или Windows), а также к проекту .NET Standard.

Проекты, относящиеся к платформе, должны реализовывать следующие:

  • Уровень приложений — определенные функциональные возможности платформы и привязка и преобразование между объектами бизнес-слоя и пользовательским интерфейсом.
  • Уровень пользовательского интерфейса — экраны, пользовательские элементы управления пользовательским интерфейсом, представление логики проверки.

Ссылки на проекты

Ссылки на проекты отражают зависимости для проекта. Основные проекты ограничивают их ссылки на общие сборки, чтобы код был простым для совместного использования. Проекты приложений для конкретной платформы ссылаются на проект .NET Standard, а также любые другие сборки для конкретной платформы, которые они должны воспользоваться преимуществами целевой платформы.

Конкретные примеры того, как следует структурировать проекты, приведены в примерах.

Добавление файлов

Действие при сборке

Важно задать правильное действие сборки для определенных типов файлов. В этом списке показано действие сборки для некоторых распространенных типов файлов:

  • Все файлы C# — действие сборки: компиляция
  • Изображения в Xamarin.iOS и Windows — действие сборки: содержимое
  • XIB и раскадровки файлов в Xamarin.iOS — действие сборки: InterfaceDefinition
  • Изображения и xml-макеты в Android — действие сборки: AndroidResource
  • XAML-файлы в проектах Windows — действие сборки : страница
  • Xamarin.Forms XAML-файлы — действие сборки: EmbeddedResource

Как правило, интегрированная среда разработки обнаружит тип файла и предложит правильное действие сборки.

Учет регистра

Наконец, помните, что некоторые платформы имеют файловые системы с учетом регистра (например, iOS и Android), поэтому обязательно используйте стандарт согласованного именования файлов и убедитесь, что имена файлов, используемые в коде, точно соответствуют файловой системе. Это особенно важно для изображений и других ресурсов, на которые вы ссылаетесь в коде.