Как работает функция Sidecar на iPad и Mac
Несколько дней назад Apple показала нам новые iPadOS и macOS Catalina. Среди множества новых функций имеет смысл выделить опцию Sidecar. Данная технология позволяет использовать iPad как внешний монитор для Mac. Функция Sidecar может работать удаленным образом, что, несомненно, даёт фору перед приложениями сторонних разработчиков.
Следует учесть, что опция Sidecar работает только на macOS Catalina и iPadOS. Поэтому, если вы хотите опробовать данную функцию, вам нужно будет установить бета-сборки ОС на оба устройства.
После активации Sideсar на iPad, выводится изображение с Mac — с ним можно взаимодействовать с помощью сенсорного экрана или используя Apple Pencil. Примечательно, что с помощью пера пользователи смогут делать зарисовки или другие дизайнерские проекты без необходимости докупать специальный графический планшет. Вне всяких сомнений, полезная опция.
Пользователь также может продублировать изображение с компьютера, либо настроить функцию таким образом, чтобы планшет выступил в качестве второго, полноценного экрана.
Одна из уникальных особенностей Sidecar — возможность выводить на iPad панель Touch Bar (даже в том случае, если на вашем MacBook его нет). Все программы, в которых есть функциональные сенсорные клавиши, будут выводить соответствующие кнопки прямо на экран планшета.
Активировать опцию очень просто — для этого выбираем новый значок в верхней панели и выбираем нужный iPad (если у вас их несколько). При необходимости на экран можно вывести только одно приложение — для этого необходимо удерживать значок перехода в полноэкранный режим.
К сожалению, функция работает не на всех компьютерах Mac. Минимальные системные требования для приложения Sidecar:
- MacBook 2015 года и новее;
- MacBook Air 2015 и новее;
- MacBook Pro 2015 и новее;
- iMac 2015 и новее;
- Mac mini 2014 и новее;
- Mac Pro 2013 и новее.
Предлагаем подписаться на наш канал в «Яндекс.Дзен». Там вы сможете найти эксклюзивные материалы, которых нет на сайте.
Sidecar паттерн
Разделение функций приложения в отдельный процесс можно рассматривать как шаблон Sidecar. Шаблон Sidecar позволяет добавить ряд возможностей в ваше приложение без дополнительного кода конфигурации для сторонних компонентов.
Проблема и контекст
Для приложений и сервисов часто нужны связанные функции, такие как мониторинг, логирование, конфигурация и др. Эти задачи можно реализовать в качестве отдельных компонентов или сервисов. Если они тесно интегрированы в приложении, то могут выполняться в одном процессе в качестве приложения, за счет чего обеспечивается эффективное использование общих ресурсов. Однако это также означает, что они неэффективно изолированы и сбой в одном из этих компонентов может повлиять на остальные или же на все приложения. Кроме того, они обычно должны быть реализованы на том же языке, что и родительское приложение. В результате компонент и приложение тесно связаны друг с другом. Если приложение делится на сервисы, каждую из них можно создать с использованием разных языков и технологий. При этом обеспечивается дополнительная гибкость, но у каждого компонента есть собственные зависимости, а также ему необходимы языковые библиотеки для доступа к базовой платформе и ресурсам родительского приложения. Кроме того, развертывание этих функций в качестве отдельных сервисов может привести к задержкам в приложении. При управлении кодом и зависимостями для этих языковых интерфейсов операции могут усложниться, особенно размещение, развертывание и управление.
Решение
Разместите набор задач вместе с основным приложением внутри их собственного процесса или контейнера, предоставляя однородный интерфейс для служб на платформе для разных языков (Sidecar pattern). 
Sidecar сервис необязательно входит в приложение, хотя и подключен к нему. Он всегда работает с родительским приложением. Sidecar’ы поддерживают процессы или службы, развернутые с помощью основного приложения. Если говорить про аналогию, возьмем пример с мотоциклом, к мотоциклу можно присоединить лишь одну коляску, и у каждого мотоцикла отдельная коляска. Таким же образом sidecar работает с родительским приложением, как коляска к мотоциклу. Для каждого экземпляра приложения размещен и развернут каждый экземпляр sidecar’a. 
Преимущества использования sidecar:
- Паттерн Sidecar не зависит от среды выполнения и языка программирования основного приложения, поэтому не нужно разрабатывать sidecar для каждого языка.
- Шаблон Sidecar может получить доступ к тем же ресурсам, что и основное приложение. Например, оно может наблюдать за системными ресурсами, используемыми основным приложением и им самим.
- При обмене данными между расширением и основным приложением задержки не возникают, так как они тесно связаны.
- Даже для приложений, которые не предоставляют механизм расширения можно использовать sidecar для расширения функциональных возможностей, подключив его как собственный процесс, в том же узле или вложенном контейнере в качестве основного приложения.
Паттерн Sidecar часто используется с контейнерами и называется «sidecar container» или «sidekick container».
Проблемы и вопросы при реализации
- Определите формат развертывания и упаковки, который будет использоваться для развертывания сервисов, процессов или контейнеров. Контейнеры особенно хорошо подходят для sidecar паттерна.
- При разработке sidecar паттерна тщательно выбирайте механизм межпроцессного взаимодействия. Если это целесообразно в соответствии с требованиями по производительности, попробуйте использовать технологии, независимые от языка или платформы.
- Перед переводом функционала в sidecar, определите оптимальный способ ее работы — в качестве отдельного сервиса или в виде более традиционного подхода.
- Кроме того, определите, можно ли внедрить функциональную возможность в виде библиотеки или же с помощью стандартного механизма экстеншинов. Библиотеки могут иметь более тесный уровень интеграции и меньше нагрузки на сеть.
Когда следует использовать этот шаблон
Используйте этот шаблон, когда:
- В основном приложении используется разнородный набор языков и платформ. Компонент, расположенный в sidecar сервисе, может использоваться приложениями, написанными на разных языках и с использованием различных платформ.
- Компонент принадлежит удаленной команде или другой организации.
- Компонент или функция размещается на том же узле, что и приложение.
- Вам нужен сервис, имеющая тот же жизненный цикл, что и основное приложение, но при этом она должна обновляться независимо от приложения.
- Вам нужен точный контроль над ограничениями ресурсов для конкретного ресурса или компонента. Например, вам может понадобиться ограничить объем памяти, который используют отдельные компоненты. Компонент можно развернуть в качестве расширения и управлять использованием памяти независимо от основного приложения.
Не используйте этот шаблон, когда:
- Если необходимо оптимизировать межпроцессное взаимодействие. Обмен данными между приложением и sidecar сервисами вызывает дополнительные нагрузки, в частности задержки в вызовах. Это неприемлемый компромисс для активных интерфейсов.
- Для небольших приложений, где стоимость ресурса при развертывания sidecar сервиса для каждого экземпляра выше, чем преимущество изоляции.
- Если сервис нужно масштабировать по-другому или независимо от основного приложения, лучше развернуть компонент как отдельный сервис.
Чем Universal Control отличается от Sidecar
О том, как работает экосистема Apple можно слагать легенды. Большинство всех гаджетов настолько круто дополняют друг друга, что отказаться от одного из них уже практически невозможно — не то. Одна из самых крутых фич связки двух устройств — функция Sidecar. Ставишь iPad рядом c Mac, нажимаешь пару кнопок и пользуешься планшетом в качестве второго монитора. Совсем недавно Apple представила нам новую фишку — Universal Control. На первый взгляд совсем непонятно — зачем она вообще нужна, если уже есть Sidecar. Об этом и предлагаю поговорить в статье.
Отличий между Universal Control и правда много. По факту, это две в корне разные фишки.
Я пользуюсь технологией Sidecar уже не первый год. Фишка реально очень полезная. Можно поставить iPad рядом со своим Mac и удобно разделить всю работу на два экрана. Чаще всего на основном мониторе я работаю с текстом, а с помощью iPad взаимодействую с разными изображениями, ибо есть Apple Pencil, рисовать им удобнее. Единственный недостаток, который был замечен — интерфейс приложений macOS на iPad выглядит не очень. Во всем виновато соотношение сторон. Но недавно Apple выкатили фичу, которая полностью решает эту проблему.
Как сделать iPad вторым монитором для Mac
Для начала предлагаю поговорить о Sidecar. Как я уже сказал, функция позволяет дублировать дисплей Mac на экран iPad. По факту, вы получаете второй экран Mac на своем планшете. Можно перетащить сюда некоторые программы и удобно работать с ними. При этом ресурс железа iPad почти не задействуется. Mac — голова этой связки. Для лучшего понимания, представьте, что вы просто подключили к компьютеру второй монитор и увеличили рабочее пространство вширь.
Вот так будет выглядеть связка iPad Mac с помощью Sidecar.
Основное удобство Sidecar в том, что для подключения iPad нужно всего лишь положить его рядом и нажать пару кнопок:
- Войти в одну учетную запись Apple ID на двух устройствах.
- Нажать на значок с двумя тумблерами в верхней панели macOS.
- Далее кликнуть на иконку с надписью Повтор Экрана (AirPlay).
- Выбрать из списка доступных мониторов iPad.
- Готово, теперь iPad будет продолжением экрана Mac.
Вот так выглядит второй монитор Mac. Сбоку есть кнопки для сенсорного управления.
Ранее о Sidecar подробно рассказывал автор AppleInsider.ru Александр Богданов. Коллега расписал все плюсы и минусы фичи и поведал о нюансах ее использования. Рекомендую к прочтению!
Но, друзья, согласитесь, было бы круто видеть такой инструмент, который полностью бы раскрыл возможности самого iPad. Все-таки мощности-то в нем достаточно много. Вы вообще iPad Air 5 видели? Почему планшет должен отрезать весь свой потенциал при такой работе?
Объясню на примере. Я редактирую почти все свои изображения на iPad. Если мне нужно отредактировать картинку, которая находится на Mac, я скидываю ее через AirDrop на iPad и потом обрабатываю на планшете. Но я не хочу ничего дропать, я хочу просто перетащить файл на iPad с помощью курсора на Mac. И Universal Control как раз дарит такую возможность.
Подписывайтесь на нас в Яндекс.Дзен! Там вы найдете много полезной и интересной информации из мира Apple и не только. Плюс, на Дзене каждый день выходит по 2 эксклюзивные статьи, которых нет на сайте. Это наша вам благодарочка за подписку.
Что такое Universal Control
Universal Control — технология, с помощью которой вы можете управлять несколькими устройствами Apple одновременно. Проще говоря, если подключить iPad к Mac, то на планшете практически ничего не изменится. Вы также сможете пользоваться им с помощью нажатий пальцами или Apple Pencil. Однако к этому добавится курсор от Mac и возможность перетаскивать все фото, видео и другой контент с Mac на iPad. Это главное отличие от Sidecar, при подключении которого iPad просто дублирует экран Mac.
С помощью трекпада и клавиатуры Mac можно управлять двумя другими устройствами. При этом каждое работает со своей операционкой.
Если у вас в доме несколько Mac или есть планшет, то это очень удобно. Только представьте: есть главный компьютер, на котором вы постоянно работаете. Далее вам необходимо не отвлекаясь перетащить файл с одного устройства на другое. Вы просто берете трекпад своего компьютера и переносите его на iPad. Далее заходите в Фото, находите нужную картинку на планшете и перетаскиваете ее на рабочий стол компьютера. Круто? Очень!
Какие Mac и iPad поддерживают Universal Control
Техника Apple уже долгие годы славится своей долгой поддержкой. Мне кажется, что было бы настоящим кощунством вырезать Universal Control для старых моделей компьютеров и планшетов. И здесь надо отдать должное ребятам из Купертино. Список поддерживаемых устройств ровно такой же, как и в Sidecar:
- MacBook (2016 и новее);
- MacBook Air (2018 и новее);
- MacBook Pro (2016 и новее);
- iMac (2017 и новее);
- iMac (5K Retina 27 дюймов и новее);
- iMac Pro;
- Mac mini (2018 и новее);
- Mac Pro.
Список поддерживаемых iPad чуть скуднее:
- iPad (6 поколение и новее);
- iPad mini (5 поколение и новее);
- iPad Air (3 поколение и новее);
- iPad Pro (2018 года и новее).
Плюс, учтите, что для работы Universal Control вам понадобиться обновить Mac до macOS Monterey 12.3, а для работы с iPad вам понадобится iPadOS 15.4.
Sidecar тоже подавалась как революционная фича и поддерживали ее далеко не все устройства. Но сейчас эти требования кажутся чем-то естественным. Достаточно лишь накатить iPadOS 13 и macOS Catalina.
Как включить Universal Control
Я тестировал Universal Control на iPad Air 2020 и MacBook Pro 2020. Все завелось очень быстро, проблем не возникло. Хотя, конечно, сама Apple в Настройках этой фишки предупреждает, что все работает в бета-режиме. Подлагиваний замечено не было, но курсор все-таки перетаскивается не так плавно как хотелось бы. Возможно, что на двух Mac все было бы побыстрее.
Чтобы включить функцию Universal Control, вам необходимо:
-
На Mac перейти в Системные настройки, Основные.
Обязательно включите Handoff.
Установите все три галочки. Это обязательно.
Нас интересует только Привязка клавиатуры и мыши. Не спутайте пункт настроек.
Если используете для этих целей iPad, то следуйте инструкции:
- Переходите в Настройки на своем iPad.
- Далее открываете раздел Основные, AirPlay и Handoff.
- Включаете тумблеры напротив Handoff и Курсор и клавиатура.
Включите Handoff на iPad.
Интересно, что Universal Control и Sidecar можно запустить одновременно. Сначала включаете Универсальное управление, а потом переходите в режим Sidecar. Сомневаюсь в том, что это какой-то баг. Просто Sidecar ведь запускается в режиме отдельного приложения, а Универсальное управление просто дополняет возможности двух устройств.
Разница между SideCar и Universal Control
По факту, сравнивать Sidecar с Universal Control не совсем корректно. Это абсолютно разные функции, предлагающие разные возможности. Но если сухо объяснить все отличия, выйдет следующее:
- Universal Control позволяет управлять сразу несколькими устройствами (и Mac, и iPad). Sidecar работает только в связке Mac и iPad.
- Sidecar лишь расширяет экран Mac на iPad, а Universal Control позволяет полноценно работать с iPadOS с помощью мыши и клавиатуры Mac.
- Sidecar работает как при подключении через провод, так и через беспроводную связь. Universal Control работает исключительно через общую Wi-Fi сеть.
- Для работы Universal Control имеет более высокие требования как к железу, так и к версии операционных систем на Mac и iPad.
Фишка и правда очень полезная, однако выглядит уж очень бестолково. Как вы думаете, много ли пользователей нуждается в такой функциональности на постоянной основе? Мне лично кажется, что она не будет слишком уж популярной. А вы как считаете? Дайте обратную связь в нашем Телеграм-чате или в комментариях ниже, будет интересно прочесть.
Шаблон расширения
Чтобы обеспечить изоляцию и инкапсуляцию, развертывайте компоненты приложения в отдельном процессе или контейнере. Этот шаблон также может включать возможность создания приложений, состоящих из разнородных компонентов и технологий.
Он называется расширением, так как напоминает коляску, присоединенную к мотоциклу. В шаблоне расширение присоединяется к родительскому приложению и предоставляет для него вспомогательные функции. Жизненный цикл расширения и родительского приложения один и тот же, так как расширение создается и удаляется вместе с родительским приложением. Иногда шаблон расширения называют шаблоном-компаньоном, который является шаблоном декомпозиции.
Контекст и проблема
Для приложений и служб часто нужны связанные функции, такие как мониторинг, ведение журналов, конфигурация и сетевые службы. Эти периферийные задачи можно реализовать в качестве отдельных компонентов или служб.
Если они тесно интегрированы в приложении, то могут выполняться в одном процессе в качестве приложения, за счет чего обеспечивается эффективное использование общих ресурсов. Однако это также означает, что они неэффективно изолированы и сбой в одном из этих компонентов может повлиять на остальные или же на все приложения. Кроме того, они обычно должны быть реализованы на том же языке, что и родительское приложение. В результате компонент и приложение тесно связаны друг с другом.
Если приложение делится на службы, каждую из них можно создать с использованием разных языков и технологий. При этом обеспечивается дополнительная гибкость, но у каждого компонента есть собственные зависимости, а также ему необходимы языковые библиотеки для доступа к базовой платформе и ресурсам родительского приложения. Кроме того, развертывание этих функций в качестве отдельных служб может привести к задержкам в приложении. При управлении кодом и зависимостями для этих языковых интерфейсов операции могут усложниться, особенно размещение, развертывание и управление.
Решение
Разместите набор задач вместе с основным приложением внутри их собственного процесса или контейнера, предоставляя однородный интерфейс для служб на платформе для разных языков.
Служба-расширение необязательно входит в приложение, хотя и подключена к нему. Она всегда работает с родительским приложением. Службы-расширения поддерживают процессы или службы, развернутые с помощью основного приложения. К мотоциклу можно присоединить лишь одну коляску, и у каждого мотоцикла отдельная коляска. Таким же образом служба-расширение работает с родительским приложением. Для каждого экземпляра приложения размещен и развернут экземпляр расширения.
Преимущества шаблона расширения:
- Расширение не зависит от среды выполнения и языка программирования основного приложения, поэтому не нужно разрабатывать такой шаблон для каждого языка.
- Расширение может получить доступ к тем же ресурсам, что и основное приложение. Например, оно может наблюдать за системными ресурсами, используемыми основным приложением и им самим.
- Из-за близости к основному приложению при обмене данными между ними не возникает существенных задержек.
- Даже для приложений, которые не предоставляют механизм расширяемости, можно использовать дополнительный механизм для расширения функциональности, подключив его в качестве собственного процесса к тому же узлу или вложенному контейнеру, что и основное приложение.
Шаблон расширения часто используется с контейнерами и называется контейнером-расширением или контейнером-компаньоном.
Проблемы и рекомендации
- Определите формат развертывания и упаковки, который будет использоваться для развертывания служб, процессов или контейнеров. Контейнеры особенно хорошо подходят для шаблона расширения.
- При разработке службы-расширения проявите тщательность при выборе механизма межпроцессного взаимодействия. Если это целесообразно в соответствии с требованиями по производительности, попробуйте использовать технологии, независимые от языка или платформы.
- Перед переводом функциональной возможности в расширение определите оптимальный способ ее работы — в качестве отдельной службы или стандартной управляющей программы.
- Кроме того, определите, можно ли внедрить функциональную возможность в виде библиотеки или же с помощью стандартного механизма расширения. Языковые библиотеки могут иметь более тесный уровень интеграции и меньше нагрузки на сеть.
Когда следует использовать этот шаблон
Используйте этот шаблон в следующих случаях:
- В основном приложении используется разнородный набор языков и платформ. Компонент, расположенный в службе-расширении, может использоваться приложениями, написанными на разных языках и с использованием различных платформ.
- Компонент принадлежит удаленной команде или другой организации.
- Компонент или функция размещается на том же узле, что и приложение.
- Вам нужна служба, имеющая тот же жизненный цикл, что и основное приложение, но при этом она должна обновляться независимо от приложения.
- Вам нужен точный контроль над ограничениями ресурсов для конкретного ресурса или компонента. Например, вам может понадобиться ограничить объем памяти, который используют отдельные компоненты. Компонент можно развернуть в качестве расширения и управлять использованием памяти независимо от основного приложения.
Эту схему не стоит применять в следующих случаях:
- Если необходимо оптимизировать межпроцессное взаимодействие. Обмен данными между родительским приложением и службами-расширениями вызывает дополнительные нагрузки, в частности задержки в вызовах. Это неприемлемый компромисс для активных интерфейсов.
- Для небольших приложений, где стоимость ресурса при развертывания службы-расширения для каждого экземпляра выше, чем преимущество изоляции.
- Если службу нужно масштабировать по-другому или независимо от основного приложения, лучше развернуть компонент как отдельную службу.
Пример
Шаблон расширения применяется во многих сценариях. Несколько распространенных примеров:
- API инфраструктуры. Команда разработчиков инфраструктуры создает службу, развертываемую вместе с каждым приложением, а не языковую клиентскую библиотеку для доступа к инфраструктуре. Служба загружается как расширение и предоставляет общий уровень для служб инфраструктуры, включая ведение журнала, данные среды, хранилище конфигураций, обнаружение, проверку работоспособности и контрольные службы. Расширение также отслеживает среду размещения и процесс родительского приложения (или контейнера) и записывает сведения в централизованную службу.
- Управление NGINX и HAProxy. Разверните NGINX с помощью службы-расширения, которая отслеживает состояние среды, а затем обновляет файл конфигурации NGINX и перезапускает процесс, если требуются изменения в состоянии.
- Расширение-посредник. Разверните службу-посредник в качестве расширения. Приложение вызывает посредник, который обрабатывает журнал запросов, маршрутизацию, автоматическое выключение и другие функции, связанные с подключением.
- Разгрузка прокси-сервера. Разместите прокси-сервер NGINX перед экземпляром службы node.js для обработки содержимого статических файлов для службы.