В настоящее время я разрабатываю приложение OS X, которое должно работать в фоновом режиме. Это приложение должно иметь возможность запрашивать некоторую информацию, отображая ввод GUI для пользователя.
Возможности:
Прямо сейчас я использую одно приложение, являющееся агентом, установив для ключа «Приложение — агент (UIElement)» в info.plist значение true. Он отображает элемент в строке состояния системы и может отображать мои настройки (это возможно с помощью метода
activateIgnoringOtherApps
appDelegate
). Использование Агента работает, но проблема в том, что любое окно, запущенное этим приложением, считается самостоятельным. Таким образом, cmd-q-ing окно закрывает все приложение. И использование этого методаactivateIgnoringOtherApps
кажется не очень законным.Так что еще одна возможность, которую я пробовал, заключалась в использовании подпроекта. При сборке приложение копирует файл .app из подпроекта в ресурсы содержащего проекта. Теперь эти приложения полностью разделены, и cmd-q-ing просто закрывает приложение просмотра конфигурации. Но у этого метода есть некоторые проблемы: поскольку приложения являются отдельными, они вообще не могут обмениваться данными. Кроме того, отладка раздражает и возможна лишь частично.
Другой метод, который я рассматривал, — использование расширения приложения. Это решило бы проблему с обменом данными, потому что расширения приложений и содержащие их приложения могут иметь общий контейнер данных. Но будут и другие проблемы, также нажатие cmd-q, вероятно, приведет к закрытию приложения, которое вызывает расширение.
Затем я прочитал об сервисах XPC, и это, вероятно, правильный способ сделать это. Я считаю, что XPC должен иметь возможность передавать данные из приложения в приложение.
Также существуют «наборы приложений» (также используемые расширениями), в которых несколько приложений могут совместно использовать одни и те же данные. Я еще не пробовал этот метод.
Итак, в основном мой вопрос:
Каков рекомендуемый способ запуска фонового приложения, позволяющего запрашивать данные у пользователя с помощью графического интерфейса?
Требования:
- Cmd-q не завершает фоновый процесс
- Данные могут быть возвращены графическим интерфейсом или сохранены в месте, где фоновое приложение может получить к ним доступ.
- Никаких читерских методов, я бы хотел использовать рекомендуемый способ
- Отладка вполне возможна
Не хотеть:
- Использование пользовательских настроек по умолчанию (у меня есть веские причины)
Любая помощь будет оценена
Спасибо
ОБНОВИТЬ:
Поэтому я много читал о XPC и его возможностях. На objc.io есть отличная современная статья от Дэниел Эггерт с примером.
Я думаю, что я иду по этому пути:
Когда основное приложение получает запрос на отображение окна конфигурации, оно сначала запускает приложение с графическим интерфейсом (которое пока не отображает графический интерфейс). Затем он создаст двунаправленное соединение XPC с только что открытым приложением, используя анонимный прослушиватель. Когда пользователь вводит ввод, приложение с графическим интерфейсом отправляет ввод через соединение XPC обратно в основное приложение.
Но я понятия не имею, как это сделать. Мне удалось только создать соединение с сервисом XPC. Мне бы очень хотелось пример проекта с использованием двунаправленного соединения, потому что я просто не могу понять это (хотя я продолжу попытки).
2 ответа
Публикация в App Store — это совсем другая история, и я об этом не знаю.
Я думаю, что простой способ сделать это ваш тип sub-project
.
Один создает объекты NSConnection и продает сервисы, другой подключается к продаваемым сервисам и получает удаленные объекты, с помощью которых другой может выполнять обычную отправку сообщений Obj-C (вызовы функций).
Что касается проблем отладки, предотвращение Cmd-Q действительно обманчиво. Мы должны гарантировать, что пользователь может выйти из программы без проблем. Таким образом, я думаю, что запуск другого фонового процесса является самым безопасным и законным способом.
приложение OS X, которое должно работать в фоновом режиме
Это приложение-демон, которое может быть Запустить демон или агент запуска.
Приложение Launch Daemon запускается при запуске системы и существует только одно. Напротив, Launch Agent существует для каждого сеанса и запускается, когда пользователь входит в систему.
Приложение-демон не должно и не может отображать пользовательский интерфейс. Однако для достижения ваших требований демон может использовать IPC, например XPC, TcpIP, локальные сокеты или любой другой желаемый метод для связи со вторым приложением, которое предоставляет пользователю требуемый пользовательский интерфейс и передает его демону. , как требуется.
Никаких читерских методов, я бы хотел использовать рекомендуемый способ
Если метод работает и безопасен, он не будет определяться как «мошенничество». Что касается рекомендуемого метода, Apple предлагает XPC в качестве простого метода IPC (общения между двумя приложениями), но использование другого механизма IPC не является неправильным.
Что касается использования активацииIgnoringOtherApps, если ваш графический интерфейс является предупреждением для пользователя и должен быть обработан пользователем без промедления, я не вижу проблемы с использованием этого здесь. В качестве альтернативы приложение с графическим интерфейсом может быть агентом запуска, который настроен на перезапуск при выходе.
Наконец, вы можете создать демон с Приложение XPC Helper для работы с графическим интерфейсом, хотя я его не пробовал.
Похожие вопросы
Новые вопросы
xcode
Xcode - интегрированная среда разработки Apple (IDE). ПРИМЕЧАНИЕ. ИСПОЛЬЗОВАНИЕ: используйте этот тег только для вопросов о самой IDE Xcode, но не для общих тем программирования для Mac или iOS. Используйте [какао] для вопросов программирования на Mac и [какао-касание] или [iOS] или [Swift] для вопросов программирования на iOS.