Полная архитектура

При работе с NSXPCConnection- основанные вспомогательные приложения, и главное приложение и помощник имеют экземпляр NSXPCConnection. Главное приложение создает свой объект соединения сам, заставляющий помощника запускаться. Когда соединение установлено, метод делегата в помощнике передается его объект соединения. Это проиллюстрировано на рисунке 4-1.

Каждый NSXPCConnection объект обеспечивает три главных особенности:

• exportedInterface свойство, описывающее методы, которые должны быть сделаны доступными для противоположной стороны соединения.

• exportedObject свойство, содержащее локальный объект для обработки вызовов метода, входящих с другой стороны соединения.

• Возможность получить объект прокси для вызывающих методов с другой стороны соединения.

Когда главное приложение вызывает метод на объекте прокси, служба XPC NSXPCConnection вызовы объектов, которые метод на объекте сохранил в exportedObject свойство.

Точно так же, если служба XPC получает объект прокси и вызывает метод на том объекте, главное приложение NSXPCConnection вызовы объектов, которые метод на объекте сохранил в exportedObject свойство.

Разработка интерфейса

NSXPCConnection API использует в своих интересах протоколы Objective C для определения программируемого интерфейса между вызывающим приложением и службой. Любой метод экземпляра, который Вы хотите вызвать от противоположной стороны соединения, должен быть явно определен в формальном протоколе. Например:

@protocol FeedMeACookie

    - (void)feedMeACookie: (Cookie *)cookie;

@end

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

@protocol FeedMeAWatermelon

    - (void)feedMeAWatermelon: (Watermelon *)watermelon

        reply:(void (^)(Rind *))reply;

@end

Метод может иметь только один блок ответа. Однако, потому что соединения двунаправлены, помощник службы XPC может также ответить вызывающими методами в интерфейсе, предоставленном главным приложением при желании.

Каждый метод должен иметь тип возврата void, и все параметры к методам или блокам ответа должны быть также:

• Арифметические типы (int, char, float, double, uint64_t, NSUInteger, и т.д.)

• BOOL

• Струны до

• C структуры и массивы, содержащие только типы, упоминается выше

• Objective C возражает что реализация NSSecureCoding протокол.

Соединение с и Используя интерфейс

Как только Вы определили протокол, необходимо создать интерфейсный объект, описывающий его. Чтобы сделать это, вызовите interfaceWithProtocol: метод на NSXPCInterface класс. Например:

NSXPCInterface *myCookieInterface =

    [NSXPCInterface interfaceWithProtocol:

        @protocol(FeedMeACookie)];

Как только Вы создали интерфейсный объект в главном приложении, необходимо сконфигурировать соединение с ним путем вызова initWithServiceName: метод. Например:

NSXPCConnection *myConnection =    [[NSXPCConnection alloc]

     initWithServiceName:@"com.example.monster"];

myConnection.remoteObjectInterface = myCookieInterface;

[myConnection resume];

Рисунок 4-2 показывает основные шаги в этом процессе. Обратите внимание на то, что только первые четыре шага описаны в этом разделе.

В этой точке главное приложение может вызвать remoteObjectProxy или remoteObjectProxyWithErrorHandler: методы на myConnection объект получить объект прокси. Этот объект действует как прокси для объекта, который служба XPC установила как ее экспортируемый объект (путем установки exportedObject свойство). Этот объект должен соответствовать протоколу, определенному remoteObjectInterface свойство.

Когда Ваше приложение вызывает метод на объекте прокси, соответствующий метод вызывают на экспортируемом объекте в службе XPC. Когда вызовы метода службы блок ответа, значения параметров сериализированы и переданы обратно приложению, где значения параметров десериализовываются и передаются блоку ответа. (Блок ответа выполняется в адресном пространстве приложения.)

Принятие соединения в помощнике

Как показано на рисунке 4-2, когда NSXPCConnection- основанный помощник получает первое сообщение от соединения, делегат слушателя listener:shouldAcceptNewConnection: метод вызывают с объектом прослушивателя и объектом соединения. Этот метод позволяет Вам решить, принять ли соединение или нет; это должно возвратиться YES принять соединение или NO отказаться от соединения.

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

• exportedInterface— интерфейсный объект, описывающий протокол для объекта, который Вы хотите экспортировать. (Создающий этот объект был описан ранее в Соединении с и Используя Интерфейс.)

• exportedObject— локальный объект (обычно в помощнике), которому должны быть поставлены вызовы метода удаленного клиента. Каждый раз, когда противоположный конец соединения (обычно в приложении) вызывает метод на объекте соединения прокси, соответствующий метод вызывают на объекте, указанном exportedObject свойство.

После установки тех свойств это должно вызвать объект соединения resume метод перед возвратом YES. Несмотря на то, что делегат может задержать вызов resume, соединение не получит сообщений, пока оно не сделает так.

Отправка сообщений

Отправка сообщений с NSXPC так же проста как создание вызова метода. Например, учитывая интерфейс myCookieInterface (описанный в предыдущих разделах) на объекте соединения XPC myConnection, можно вызвать feedMeACookie метод как это:

Cookie *myCookie = ...

[[myConnection remoteObjectProxy] feedMeACookie: myCookie];

При вызове того метода соответствующий метод в помощнике XPC вызывают автоматически. Тот метод, в свою очередь, мог использовать объект соединения помощника XPC так же для вызова метода на объекте, экспортируемом главным приложением.

Ошибки из-за неправильного обращения

В дополнение к любым методам обработки ошибок, определенным для задачи данного помощника, и служба XPC и главное приложение должны также обеспечить следующие блоки обработчика ошибок XPC:

• Когда процесс на другом конце соединения разрушил или иначе закрыл свое соединение, обработчик прерывания — вызвал.

  Объект локального соединения обычно все еще допустим — любой будущий вызов автоматически породит новый экземпляр помощника, если не будет невозможно сделать так — но Вы, возможно, должны сбросить любое состояние, которое иначе сохранил бы помощник.

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

• Обработчик аннулирования — вызвал, когда лишить законной силы метод вызывают или когда не мог быть запущен помощник XPC. Когда этот обработчик вызывают, объект локального соединения больше не действителен и должен быть воссоздан.

  Это всегда - последний обработчик, обратился к объекту соединения. Когда этот блок вызывают, объект соединения был разъединен. Не возможно отправить дальнейшие сообщения на соединении в той точке, ли в обработчике или в другое место в Вашем коде.

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

Работа с пользовательскими классами

NSXPCConnection класс ограничивает, какие объекты могут быть переданы по соединению. По умолчанию это позволяет только известный - безопасные классы — классы набора Основы, NSString, и т.д. Можно идентифицировать эти классы тем, соответствуют ли они NSSecureCoding протокол.

Только классы, соответствующие этому протоколу, могут быть отправлены в NSXPCConnection- основанный помощник. Если необходимо передать собственные классы как параметры, необходимо гарантировать, чтобы они соответствовали NSSecureCoding протокол, как описано ниже.

Однако это не всегда достаточно. Необходимо выполнить дополнительную работу в двух ситуациях:

• Если Вы передаете объект в наборе (словарь, массив, и т.д.).

• Если необходимо передать объект по доверенности вместо того, чтобы копировать объект.

Все три случая описаны в следующих разделах.

Приспосабливание NSSecureCoding

Все объекты, переданные по соединению NSXPC, должны соответствовать NSSecureCoding. чтобы сделать это, Ваш класс должен сделать следующее:

• Объявите поддержку безопасного кодирования. Переопределите supportsSecureCoding метод, и заставляет его возвратиться YES.

• Декодируйте экземпляры singleton-класса безопасно. Если класс переопределяет initWithCoder: метод, при декодировании любой переменной экземпляра, свойства или другого значения, содержащего объект класса ненабора (включая пользовательские классы) всегда, использует decodeObjectOfClass:forKey: гарантировать, что данные имеют ожидаемый тип.

• Декодируйте классы набора безопасно. Любой класс ненабора, содержащий экземпляры классов набора, должен переопределить initWithCoder: метод. В том методе, при декодировании объекта коллекции или объектов, всегда использование decodeObjectOfClasses:forKey: и обеспечьте список любых объектов, которые могут появиться в наборе.

При генерации списка классов для разрешения в декодируемом классе набора необходимо знать о двух вещах.

Во-первых, классы набора Apple не автоматически whitelisted decodeObjectOfClasses:forKey: метод, таким образом, необходимо включать их явно в массив типов классов.

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

Например, если у Вас есть массив словарей, и один из тех словарей мог бы содержать экземпляр пользовательского вызванного класса OuterClass, и OuterClass имеет переменную экземпляра типа InnerClass, необходимо включать OuterClass в списке классов, потому что это - прямой элемент дерева набора. Однако Вы не должны перечислять InnerClass потому что существует необъект коллекции между ним и деревом набора.

Рисунок 4-3 показывает некоторые примеры того, когда белый список требуется и показывает, когда классы должны обеспечить переопределенный initWithCoder: методы.

@interface FrenchFry

...

@end

@protocol FeedMeABurgerAndFries

    - (void)feedMeFries: (NSArray *)pommesFrites;

    - (void)feedMeABurger: (Burger *)aBurger;

@end

// Create the interface

NSXPCInterface *myBurgerInterface =

    [NSXPCInterface interfaceWithProtocol:

        @protocol(FeedMeABurgerAndFries)];

// Create a set containing the allowed

// classes.

NSSet *expectedClasses =

    [NSSet setWithObjects:[NSArray class], [FrenchFry class], nil];

[myBurgerInterface

      setClasses: expectedClasses

     forSelector: @selector(feedMeFries:)

   argumentIndex: 0  // the first parameter

         ofReply: NO // in the method itself.

];

@protocol FeedSomeone

    - (void)feedSomeone:

        (id <FeedMeACookie>)someone;

@end

...

NSXPCInterface *myFeedingInterface =

    [NSXPCInterface interfaceWithProtocol:

        @protocol(FeedSomeone)];

// Create an interface object that describes

// the protocol for the object you want to

// pass by proxy.

NSXPCInterface *myCookieInterface =

    [NSXPCInterface interfaceWithProtocol:

        @protocol(FeedMeACookie)];

// Create an object of a class that

// conforms to the FeedMeACookie protocol

Monster *myMonster = ...

[myFeedingInterface

     setInterface: myCookieInterface

      forSelector: @selector(sendOtherProxy:)

    argumentIndex: 0  // the first parameter of

          ofReply: NO // the feedSomeone: method

];