Часть 4 — Работа с несколькими платформами

Работа с разными платформами: различия и особенности

Различия это не просто «кроссплатформенная» проблема.  Устройства на разных платформах имеют различные возможности (особенно широкий спектр устройств на Android). Наиболее очевидное и основное – это размер экрана, но другие атрибуты устройства могут варьироваться и требуют от приложения проверку некоторых возможностей. Они и ведут себя по-разному исходя из наличия возможностей (или их отсутствия).
Это означает, что все приложения должны иметь дело с корректируемым  ухудшением функциональности или же представлять набор непривлекательных функций «наименьшего общего знаменателя».  Глубокая интеграция Xamarin с родными пакетами SDK для каждой платформы позволяет приложениям воспользоваться преимуществами функциональности каждой платформы, так что имеет смысл использовать эти функций при разработки приложений.

Примеры различия платформ

Основные элементы, которые существуют на разных платформах

Есть некоторые характеристики мобильных приложений, которые являются универсальными. Это концепции высокого уровня , которые корректно выполняются на всех устройствах и поэтому могут быть основой для дизайна вашего приложения:

  • Выбор функций с помощью вкладок или меню
  • Списки данных и прокрутка
  • Единичное представление данных
  • Редактирование единичного представления данных
  • Возврат в навигации

При проектировании  экранов хода выполнения на высоком уровне, вы можете основывать общее пользовательское восприятие (user experience) на этих понятиях.

Платформоспецифичные атрибуты

В дополнение к основным элементам, которые существуют на всех платформах, необходимо учитывать ключевые различия между платформами в вашем дизайне. Вам необходимо будет учитывать (и писать специальный код для обработки) эти различия:

  • Размер экрана – Некоторые платформы (например, iOS и Windows Phone) имеют стандартизированные размеры экрана, на которые относительно просто ориентироваться. Android устройства имеют различные размеры экрана, которые требуют гораздо больше усилий для поддержки приложения.
  • Метафоры навигации — Отличаются на разных платформах (например, аппаратные кнопки «назад»,  элемент управления UI – «Панорама») и в пределах платформ (Android 2 и 4, iPhone и iPad).
  • Клавиатуры — Некоторые Android устройства имеют физические клавиатуры, а другие имеют только программные клавиатуры. Необходим код, который определяет, когда программная клавиатура заслоняет часть экрана. Необходимо учитывать эти различия.
  • Технологии Touch и жесты – Поддержка операционной системы для распознавания жеста варьируется, особенно в более старых версиях каждой операционной системы. Более ранние версии Android имеют очень ограниченную поддержку сенсорных операций, что означает, что для поддержки старых устройств может потребоваться отдельный код.
  • Push-уведомления — Существуют различные возможности / реализации на каждой платформе (например, живой плитки в Windows Phone).

Особенности конкретных устройств

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

  • Камера – Функциональность отличается на разных устройствах: некоторые устройства не имеют камеру, другие имеют как передние, так и задние перед камерами. Также некоторые камеры способны записывать видео, а некоторые нет.
  • Геолокация и карты – Поддержка GPS или Wi-Fi местоположения есть не на всех устройствах. Приложения также должны различать различные уровни точности, которая поддерживается различными методами.
  • Акселерометр, гирокомпас и компас – Эти функции часто встречаются только на некоторых устройствах на каждой платформе, поэтому приложению почти всегда нужно предоставить запасной вариант, когда оборудование не поддерживается .
  • Twitter и Facebook –«встроены» только на iOS5 и iOS6 соответственно. На более ранних версиях и других платформах вам необходимо предоставить свои собственные функции аутентификации и взаимодействия непосредственно с каждыми API-службами.
  • Near Field Communications (NFC) – Только некоторые Android телефоны (на момент написания).

Работа с дивергенциями (вариантами реализации) платформы

Есть два различных подхода к поддержке нескольких платформ на одной и той же кодовой базе, каждая со своим собственным набором преимуществ и недостатков.

  • Абстрактная платформа – Модель бизнес-фасада, которая обеспечивает унифицированный доступ на разных платформах и абстрагирует конкретные реализаций платформы в единый, унифицированный API..
  • Вариативная реализация — Вызов специфических функций платформы с помощью нескольких вариантов реализаций с помощью архитектурных инструментов, таких как интерфейсы и наследование или условной компиляции.

Абстрактная платформа

Класс абстракции

Использование базовых классов или интерфейсов заключенных в общем коде и реализованых или расширенных в платформе конкретных проектов. Написание и расширение общего кода с абстрактными классами особенно подходит для портативных библиотек классов (PCL) потому, что они имеют ограниченное подмножество доступных для них фреймворков и не могут содержать директивы компилятора для поддержки ветви кода платформы.

Интерфейсы

Использование интерфейсов позволяет реализовать платформоспецифичные классы, которые могут быть переданы в ваши общие библиотеки, чтобы воспользоваться преимуществами общего кода.

Интерфейс заключается в общем коде и передается в общую библиотеку в качестве параметра или свойства.

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

Наследование

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

Преимущества и недостатки интерфейсов в равной степени на наследование, с дополнительным преимуществом, что базовый класс может содержать код реализации (возможно всей платформы агностик реализация, которая может быть дополнительно продлен).

Xamarin.Forms

Смотрите документацию по Xamarin.Forms

Плагины кроссплатформенной функциональности

Можно также расширить кроссплатформенные приложения последовательно, с помощью плагинов.

Большинство плагинов github, это open-source проекты (обычно доступны для установки через Nuget),  которые помогут вам реализовать множество функций платформы от состояния аккумулятора до Настроек с помощью общего API, которые легко использовать в приложениях Xamarin и Xamarin.Forms.

Другие кроссплатформенные библиотеки

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

Вариативная реализация

Условная компиляция

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

В Xamarin проектах всегда указывается __MOBILE__ что верно для iOS и Android приложений проектов (символы выделены пре- и пост-фиксом из двойных подчеркиваний).

iOS

Xamarin.iOS определяет __IOS__ который можно использовать для обнаружения устройств iOS.

Есть также  Watch- и TV- символы:

Android

Код, который должен быть скомпилирован только в Xamarin.Android приложении должен использовать следующее:

Каждая версия API также определяет новую директиву компилятора. Ниже представлен код позволяющий вам добавлять функции, предназначенные для новые API-интерфейсов. Каждый уровень API включает в себя все «нижние» уровни символов (уровни API). Эта функция не является очень полезной для поддержки нескольких платформ; обычно символа __ANDROID__ будет достаточно.

Mac

В настоящее время нет встроенных символов для Xamarin.Mac, но вы можете добавить свой собственный в Mac проект приложения через Options > Build > Compiler  в поле Define symbols  или изменить CSPROJ-файл и добавить там (например __MAC__)

Windows Phone

Windows Phone 7 определяет два символа – WINDOWS_PHONE  и SILVERLIGHT – которые могут быть использованы для кода этой платформы. Они не имеют подчеркиваний окружающих их, как это у символов платформы Xamarin.

Использование условной компиляции

Простой пример условной компиляции Установка местоположения файла для файла базы данных SQLite. Три платформы имеют несколько различных требования для указания местоположения файла:

  • iOS –  Apple предпочитает не-пользовательские (non-user) данные размещать в определенном каталоге (каталог Library), но нет никакой системы константы для данного каталога. Платформеннозависимый код требуется для создания правильного пути.
  • Android –. Системный путь, возвращаемый Environment.SpecialFolder.Personal является приемлемым местом для хранения файла базы данных.
  • Windows Phone –  Механизм изолированного хранилища не позволяет указать полный путь, только относительный путь и имя файла.

Следующий код использует условную компиляцию для обеспечения DatabaseFilePath правильным для каждой платформы:

Результатом будет является класс, который может быть построен и использоваться на всех трех платформах, поместив файл базы данных SQLite в разные места на каждой платформе.


Оригинал статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *