Управление пользовательскими настройками
Предпочтительная платформа Областей определяет интерфейс, через который приложение взаимодействует с предпочтительным объектом области, но приложение ответственно только за отображение предпочтительного пользовательского интерфейса области. Предпочтительный объект области ответственен за обработку самих предпочтений. В этом разделе описываются методы, которыми предпочтительная область может сохранить и передать предпочтения к целевому приложению.
Поскольку предпочтительные области подвергаются внезапному завершению SIGKILL когда пользователь закрывает устройство, предпочтения должны быть отправлены в целевое приложение или сохранены к предпочтительному файлу каждый раз, когда пользователь вносит изменение, если практично. Вы не должны ожидать области, которая будет отклонена для сохранения предпочтений. Если у Вас есть сложные наборы предпочтений, нуждающихся к сохраненному как группа, сохраняющих изменения в интерактивном режиме во временном файле и обеспечивающих кнопку Apply для копирования настроек в предпочтительный файл и/или целевое приложение, так, чтобы устройство могло быть закрыто без области или проигрывающие данные или блокирование завершения работы.
Preference Services
В основе Mac OS X системой пользовательской настройки является Core Foundation Preference Services. Этот набор подпрограмм определяет ряд доменов согласно имени пользователя, имени хоста и идентификатору приложения, к которому применяется данное предпочтительное значение. Каждый компонент домена указан CFString. Предопределенные постоянные строки доступны для простого выбора экземпляра «Current» компонента (такого как текущее приложение или текущий пользователь) или совместно используемый компонент, доступный «Любому» экземпляру.
Эти константы объединяются для формирования восьми предпочтительных доменов, показанных в Таблице 1.
Имя пользователя |
Идентификатор приложения |
Имя хоста |
|---|---|---|
Текущий |
Текущий |
Текущий |
Текущий |
Текущий |
Любой |
Текущий |
Любой |
Текущий |
Текущий |
Любой |
Любой |
Любой |
Текущий |
Текущий |
Любой |
Текущий |
Любой |
Любой |
Любой |
Текущий |
Любой |
Любой |
Любой |
Путем обеспечения собственной строки Вы можете домены доступа кроме определенных текущим контекстом. Доступ к предпочтениям других пользователей, тем не менее, требует специальных полномочий.
Предпочтения, расположенные в доменах выше в списке в Таблице 1 (другими словами, более определенных доменах), имеют приоритет по расположенным в более низких доменах (более общие домены).
Класс NSUserDefaults, который является частью платформы Основы Какао, используется приложениями Какао для управления их пользовательскими настройками. Поскольку это пишет предпочтения во второй домен, перечисленный в Таблице 1, с помощью «Текущего» домена приложения, это не может использоваться предпочтительной областью в предпочтительном приложении. Это записало бы любые измененные предпочтения в предпочтительный предпочтительный файл приложения, вместо к файлу целевого приложения. Если предпочтительная область встраивается в целевое приложение, работы NSUserDefaults, но это тогда повреждает модульный и допускающий повторное использование проект предпочтительной области.
Для получения дополнительной информации о том, как считать и записать предпочтения в предпочтительный файл, посмотрите Using Preference Services. Для получения дополнительной информации о Предпочтениях, посмотрите, что Предпочтения Программируют Темы для Базовой Основы.
Конфигурационные файлы
При контакте с межплатформенным целевым приложением, таким как типичные демоны BSD, не может использоваться Core Foundation Preference Services. Вместо этого необходимо управлять файлами пользовательской конфигурации. Для приложений BSD файл обычно является файлом простого текста, но определенный формат варьируется от межпрограммного. Ваша предпочтительная область должна включать свой собственный код, чтобы считать, проанализировать, изменить, и сохранить эти файлы, а не использовать Preference Services.
Межпроцессное взаимодействие
Когда изменение применяется к запущенному приложению или интегрированной части операционной системы, хранение новых предпочтений на диске не достаточно; необходимо сообщить цели изменения, если это должно сразу вступить в силу вместо того, чтобы ожидать перезапуска. Вы достигаете этого путем отправки сообщения от предпочтительной области до целевого приложения. В некоторых случаях сообщение может быть простым вызовом функции к подпрограмме операционной системы.
В Mac OS X существует распространенность способов связаться с другими процессами; каждый уровень и платформа имеют свои собственные предпочтительные методы. Несмотря на то, что предпочтительные области записаны с помощью платформы Objective C Какао, Вы не ограничиваетесь ее определенной реализацией обмена сообщениями — использование, что является лучшим для ситуации. Когда целевое приложение не является объектом Вашего управления, Ваш выбор ограничивается теми методами, понятыми к установленному сроку.
Вы могли предшествовать сохранению предпочтений в предпочтительной области в целом, если изменения передаются непосредственно к вездесущей части системы, управляющей ее предпочтениями самой. Предпочтительная область могла просто отправить обновленные предпочтения в цель, и цель возьмет на себя ответственность за хранение их в персистентном расположении (обычно файл на диске).
Если цель, как гарантируют, всегда не будет работать, предпочтительная область должна обновить сам предпочтительный файл. Используйте следующие способы связи только для вспомогательной информации или уведомлять цель, если это в настоящее время работает, что изменились ее предпочтения.
События Apple
На высшем уровне межпроцессного взаимодействия события Apple, долговременный стандарт для межсвязи приложений в Mac OS. Событие Apple является высокоуровневым сообщением, что приложение может отправить к себе, другим приложениям на том же компьютере или приложениям на удаленном компьютере. Объекты-события Apple имеют четко определенную структуру данных с поддержкой расширяемых, иерархических типов данных. Четко определенный набор событий Apple может предоставить поддержку для богатого интерфейса сценариев через AppleScript.
Распределенные объекты
Поддержка во время выполнения языка Objective C межпроцессное решение для обмена сообщениями, вызванное “, распределила объекты”. Этот механизм позволяет приложению Какао вызвать объект в различном приложении Какао. Вызовы могут быть синхронными, означая, что процесс отправки блокируется при ожидании ответа от получателя, или асинхронный, означать, что никакой ответ не ожидается, и отправитель не блокируется.
Приложение получения «продает» или обнародовало, объект, с которым могут соединиться другие приложения. Вызов одного из методов продаваемого объекта тогда имеет место, как будто объект существовал в Вашем собственном приложении — синтаксис не изменяется. Система во время выполнения обрабатывает необходимую передачу данных между приложениями.
Если Ваша предпочтительная область должна использоваться для управления безликим приложением Какао, это - очень простой метод для межсвязи приложений. Так как это позволяет двухстороннюю связь, можно обеспечить большее взаимодействие между пользователем и приложением. Предпочтительное приложение может получить текущие настройки непосредственно из целевого приложения вместо предпочтительного файла. Это может тогда надеть непосредственную обратную связь, приняты ли модификации пользователя к установленному сроку.
Для получения дополнительной информации о том, как использовать распределенные объекты в предпочтительной области, посмотрите Используя Распределенные Объекты. Для получения дополнительной информации о распределенных объектах посмотрите В Mac OS X: Язык программирования Objective C и NSConnection и NSDistantObject описания класса в Ссылке Платформы Основы.
Распределенные уведомления
Альтернатива прямой и двунаправленной связи распределенных объектов и событий Apple является односторонним распределенным уведомлением. Распределенное уведомление является сообщением, добавленным любым приложением к центру уведомления на машину, поочередно широковещательно передающему сообщение к любым приложениям, заинтересованным получением его. Включенный с уведомлением идентификатор отправителя, и, дополнительно, словарь, содержащий дополнительную информацию. Получатель уведомления не может передать информацию назад к отправителю. Рисунок 2 иллюстрирует эту архитектуру.
Распределенный механизм уведомления доступен через Базовую Основу объект CFNotificationCenter и через Какао класс NSDistributedNotificationCenter. Приложение Какао, такое как Ваше предпочтительное приложение, может использовать любой интерфейс. Приложение Углерода, возможно целевое приложение, может использовать только интерфейс Core Foundation. Отправленное использование уведомления одного интерфейса может быть получено также.
Преимущество распределенной модели уведомления является one-many возможностями модели. Если у Вас есть комплект инструментов, совместно использующих единый набор предпочтений, каждый рабочий инструмент может зарегистрироваться для и получить те же уведомления для предпочтительных изменений. Распределенные уведомления также отправляются асинхронно. Ваша предпочтительная область может сразу отправить уведомление и возврат; Вы не должны ожидать целевого приложения, чтобы получить уведомление и закончить обрабатывать его.
Далее, целевое приложение не должно работать. Если никакое приложение не прислушивается к уведомлению, ничто не происходит. Из-за этого распределенные уведомления особенно полезны для уведомления приложения измененного предпочтительного файла. Предпочтительная область может изменить предпочтительный файл и отправить уведомление об изменении, не будучи зависящей от того, слушает ли кто-то его.
Распределенные уведомления являются ресурсом в масштабе всей системы, совместно использованным всеми приложениями. Для предотвращения конфликтов имен выберите имена уведомления, которые несомненно будут уникальны для приложения. Посмотрите Предотвращение Конфликтов имен для подробных данных.
Для получения дополнительной информации о том, как использовать распределенные уведомления в предпочтительной области, посмотрите Используя Распределенные Уведомления. Для получения дополнительной информации о распределенных уведомлениях посмотрите NSDistributedNotificationCenter описание класса в Ссылке Платформы Основы.
Сокеты и порты
Межплатформенные приложения не могут использовать вышеупомянутые специфичные для Mac OS X методы для межпроцессного взаимодействия. Однако Mac OS X поддерживает сокеты BSD, стандартный способ связи для платформ BSD. Можно использовать стандартный сокет POSIX APIs или использовать в своих интересах высокоуровневые абстракции в классе Какао NSSocketPort или Базовая Основа объект CFSocket. Производство и парсинг потока необработанных данных, отправленного по сокетам, являются ответственностью предпочтительного объекта области и целевого приложения.
Сигналы
Сигналы BSD также доступны в Mac OS X. Сигналы являются программными прерываниями, которые могут быть отправлены в определенное приложение. По умолчанию сигнал завершает приложение получения, но приложение может переопределить это путем установки сигнального обработчика, работающего, когда получен определенный сигнал. Единственной информацией, переданной сигналом, является единственное целое число, идентифицирующее сигнал.
Традиционные службы BSD (такой как inetd) часто используйте предопределенный сигнал SIGHUP (сигнал зависания) для сброса себя. При изменении предпочтений одной из этих служб запишите обновленные настройки в предпочтительный файл приложения и отправьте SIGHUP сигнализируйте к приложению. В ответ приложение может перечитать свои предпочтения.