Плюсы и минусы разбиения приложения-какао на вспомогательный двоичный файл + основной двоичный файл приложения? - PullRequest
0 голосов
/ 02 декабря 2018

Я модернизирую и помещаю в песочницу старую утилиту Cocoa и обдумываю подходы.Приложение находится в строке меню и работает в фоновом режиме, но при нажатии на значок отображается значок Dock и окно конфигурации.

Существует два подхода:

A.Один двоичный файл с LSUIElement=YES, использующий TransformProcessType для отображения и скрытия иконки док-станции при необходимости.

B.Вспомогательный инструмент выполняет реальные функции приложения, управляет значком меню и всегда работает в режиме LSUIElement в фоновом режиме.Основное приложение представляет пользовательский интерфейс конфигурации и запускается только при необходимости.

Приложение в настоящее время выполняет A. Я заметил, что многие долго работающие служебные приложения имеют отдельные вспомогательные двоичные файлы и в основном имеют B. Примеры на моем Macвключают в себя Paste Helper, TimingHelper, Discord Helper, CCC Helper (для клонирования копий), 1Password Extension Helper.

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

Итак:

  1. Каковы плюсы и минусы A и B, то есть, почему некоторые выбирают B вместо A?Требуется ли в наши дни получить какую-то функциональность?

  2. Можно ли даже использовать вспомогательный инструмент для выживания основного приложения в изолированном приложении Mac App Store?

  3. Какой API используется для создания такого помощника?Старые API авторизации выглядят устаревшими, а XPC не позволяет запускать вспомогательное приложение при запуске (и даже переживание основного приложения может быть взломанным)?

1 Ответ

0 голосов
/ 04 декабря 2018

Я подозреваю, что причина, по которой многие разработчики выбирают вариант B, заключается в том, что эта схема теперь встроена в macOS с помощью средства «Элементы входа».

В двух словах, ваше основное приложение встраивает второе (вспомогательное) приложение.и это приложение настроено как «Элемент входа».macOS обнаруживает это и автоматически добавляет ваше вспомогательное приложение к элементам входа пользователя.Вы можете управлять этим программным способом, используя SMLoginItemSetEnabled(...).

. В результате вы получаете обычное приложение, с которым знакомы пользователи, и вспомогательное приложение, которое автоматически запускается при входе в систему и может работать в фоновом режиме.Я также уверен, что это включает в себя бесплатное подключение XPC, которым вы можете воспользоваться.

Узнайте все об этом в разделе Добавление элементов входа в систему печально известного Руководства по программированию демонов и служб .

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

Один из недостатков варианта A (на основе отзывов пользователей из моих собственных приложений) заключается в том, что основное приложение не будет работать как обычное приложение.Используя подход A, ваши пользователи либо не могут выйти из приложения (потому что для этого потребуется автоматический перезапуск), либо вам нужен способ скрыть его в доке, а затем нет (очевидного) способа запустить его снова.Это просто сбивает с толку.Если вы разрешите своим пользователям выйти из приложения, фоновая функциональность исчезнет, ​​и это создаст другие проблемы.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...