NSMapTable, обнуляющий слабые изменения

Табличная опция карты NSMapTableZeroingWeakMemory была осуждена. Эта опция была для содержания обнуляющих слабых объектов при сборке «мусора» и несохранила объектные указатели при подсчете ссылки на руководство.

Эта опция была заменена опцией NSMapTableWeakMemory, вызывающей обнуляющее слабое поведение при подсчете ссылки на руководство, автоматическом подсчете ссылок и сборке «мусора». Обратите внимание на то, что это не полностью эквивалентно и совместимо с поведением предыдущей опции: объекты должны быть безопасными от слабой ссылки при ручном и автоматическом подсчете ссылок; не все объекты.

Точно так же 4 метода создания удобства +mapTableWith (Weak|Strong) К (Weak|Strong), Объекты были осуждены, и 4 новых, который использует новую опцию, + (weak|strong) К ObjectsMapTable (Weak|Strong), были созданы.

Однако слабым-к-сильному NSMapTables в настоящее время не рекомендуют, поскольку сильные значения для слабых ключей, выводящих zero'd, не становятся отстраненными (и выпущенный), пока/если таблица карты не изменяет размеры себя.

Обратите внимание на то, что, аналогично к тому, что происходит в сборке «мусора», когда слабое место хранения было считано, и объект таким образом, чтение «оживлено», чтобы не быть забранным в ближайшем будущем, подобная вещь происходит со слабыми ссылками при ручном и автоматическом подсчете ссылок: объект сохраняется и автовыпустил, так, чтобы он продолжал жить для, по крайней мере, текущего объема кода чтения. Это влияет на слабые таблицы карты также, и слабо сохраненные объекты возвращаются с дополнительным, сохраняют и автовыпущенный, в отличие от типичного поведения набора.

NSPointerArray, обнуляющий слабые изменения

Вместе с осуждением опции NSPointerFunctions' NSPointerFunctionsZeroingWeakMemory были осуждены два +pointerArrayWith (Weak|Strong) методы создания удобства Объектов.

Два новых метода, +weakObjectsPointerArray и +strongObjectsPointerArray, были добавлены, которые создают NSPointerArrays с поведением NSPointerFunctionsWeakMemory.

NSHashTable, NSMapTable, NSPointerArray, доступный в iOS 6

NSHashTable, NSMapTable, и классы NSPointerArray, и некоторый NSPointerFunctions APIs, теперь доступны в iOS 6.

Преобразование в нижний индекс возможностей синтаксиса добавило к некоторым наборам

NSArray/NSMutableArray и классы NSOrderedSet/NSMutableOrderedSet получили индексированную поддержку синтаксиса преобразования в нижний индекс. Так, например, можно записать myArray[6] для получения седьмого элемента от массива или упорядоченного набора (по крайней мере с 7 элементами!), вместо того, чтобы использовать-objectAtIndex: метод.

Для массивов и упорядоченных наборов, нижний оператор [] используемый для чтения ведет себя точно так же, как objectAtIndex: и индексы вне диапазона [0... Количество 1] вызывает исключение. Нижний оператор [] используемый для присвоения может только быть применен к непостоянным объектам и ведет себя как NSMutableOrdededSet-setObject:atIndex: метод и индексы вне диапазона [0... количество] вызывают исключение. Когда используется создать l-значение, которое будет присвоено, [], заменяет объект, если индекс является меньше, чем количество (то же поведение как-replaceObjectAtIndex:withObject:), и добавляет элемент до конца набора, увеличивая набор, если индекс равен количеству (то же поведение как-insertObject:atIndex:).

Точно так же классы NSDictionary/NSMutableDictionary получили включенную поддержку синтаксиса преобразования в нижний индекс. Так, например, можно записать myDict [«ключ»] для получения значения для ключа «ключ» из словаря, вместо того, чтобы использовать-objectForKey: метод.

Для словарей нижний оператор [] ведет себя точно так же, как-objectForKey: и-setObject:forKey: методы.

Методы NSDictionary теперь объявляют требование соответствия <NSCopying> для ключей

Методы в NSDictionary и NSMutableDictionary, берущих ключевые аргументы теперь, объявляют, что параметр должен соответствовать протоколу NSCopying. Если это вызывает предупреждение компиляции или ошибку для Вас, необходимо изучить это, поскольку у Вас может быть ошибка, или Вы, возможно, просто должны добавить бросок (чтобы сказать компилятору, что знаете то, что Вы делаете). Одним путем это происходит, когда Объекты класса используются в качестве ключей словаря: язык Objective C не имеет никакого пути к Объектам класса для объявления их соответствия к протоколам, таким образом, Объекты класса не могут формально соответствовать протоколу NSCopying.

Слабо недоступные классы

NSConnection, NSMachPort и классы NSMessagePort были отмечены слабо-недоступные. Экземпляры тех классов не могут быть сохранены в слабые ссылки.

NSRealMemoryAvailable () функция осужден

NSRealMemoryAvailable () функция был осужден. В 32-разрядном его возвращаемое значение не может выразить полный спектр объема памяти, который может фактически быть доступным (т.е. больше, чем 4 ГБ). Используйте-physicalMemory метод NSProcessInfo вместо этого.

NSCopyObject () функция осужден

NSCopyObject () функция был осужден. Это всегда была опасная функция для использования, кроме реализации методов копии, и только тогда с осторожностью. Это не было доступно при автоматическом подсчете ссылок в 10,7, и теперь это было формально осуждено.

NS_RETURNS_INNER_POINTER

Методы, возвращающие указатели (кроме типа объекта Objective C) были украшены objc_returns_inner_pointer атрибута компилятора лязга (при компиляции с лязгом) для предотвращения компилятора от агрессивного выпуска выражения получателя тех сообщений, на которые больше, кажется, не ссылаются, в то время как может все еще использоваться возвращенный указатель.

Новый протокол NSObject дополнительный метод

Объявление-debugDescription дополнительного метода было добавлено к протоколу NSObject. Это позволяет этому методу быть реализованным в классах разработчика, не заставляя проблему быть отмеченным в iOS и хранилищах приложения Mac, где иначе он мог бы быть похож, что разработчик переопределяет закрытый метод в Основе. Помните, что дополнительные методы не требуются, чтобы фактически быть реализованными на любом классе, соответствующем протоколу, таким образом, нужно протестировать это, объект реагирует на дополнительный метод прежде, чем отправить его.

Новые методы NSDateComponents

Два новых метода были добавлены к NSDateComponents,-isLeapMonth и-setLeapMonth:.

Китайскому календарю можно было вставить месяц прыжка после любого регулярного месяца. Другие лунные календари могут также иметь месяцы прыжка, вставленные перед регулярным месяцем, и пропускать регулярные месяцы, также. Нумерация повторений месяцев прыжка (или «предварительные торфа») число регулярного месяца. Так, число месяца «10» неоднозначно - в данном году, это могло возможно означать один из двух различных (смежных) месяцев. Так, интерпретация которого месяц указан NSDateComponents, действительно комбинация числа месяца и состояний isLeapMonth.

Нет никакого «Модуля», постоянного для этого нового состояния. Это будет вычислено и возвращено вместе с месяцем, который требует NSMonthCalendarUnit. Не полезно установить это новое поле в NSDateComponents, также не устанавливая свойство месяца.

Другой аспект китайского календаря - то, что годы пронумерованы от 1 - 60 в повторяющемся цикле. Таким образом две вероятные даты на расстоянии в 60 лет имеют то же число Года. Крайне важно установить поле Era соответственно для китайских календарных вычислений.

NSNumberFormatter, поведение значения по умолчанию NSDateFormatter

Изменение в классах NSNumberFormatter и NSDateFormatter означает что экземпляры теперь значение по умолчанию к 10,4 поведениям (NSNumberFormatterBehavior10_4).

Разработчики могут гарантировать, чтобы средства форматирования имели 10_0 поведение при желании при помощи: [theFormatter setFormatterBehavior:NSNumberFormatterBehavior10_0];

Тот метод был доступен с тех пор 10.4.

NSXPCConnection

NSXPCConnection является новой функцией в платформе Основы для межпроцессного взаимодействия (IPC) между приложениями, службами XPC, демонами и агентами. Это создает поверх XPC для упрощения IPC в приложениях Какао. NSXPCConnection заботится о подробных данных удаленного обмена сообщениями, маршалинга параметра, безопасной десериализации, отгрузки сообщения и обработки ответа.

Начало работы NSXPCConnection

Проект NSXPCConnection базируется вокруг идеи определить определенные интерфейсы, которые приложение или демон реализуют от имени удаленной вызывающей стороны. Интерфейс составлен из методов с дополнительными аргументами и дополнительным ответом. Все методы в интерфейсе вызывают асинхронно, и параметры копируются (превращение параметра в прокси поддерживается, посмотрите Усовершенствованные Темы ниже). Интерфейс формализован при помощи Objective C @protocol и обернут с Основой объект NSXPCInterface.

Например, служба XPC, сжимающая данные от имени приложения, может иметь интерфейс как это:

    @protocol CompressingServer

    - (oneway void)compressData:(NSData *)data withReply:(void (^)(NSData *compressedData))reply;

    @end

Реализация метода на сервере получила бы объект NSData с данными для сжатия, и когда это закончено, это вызвало бы блок ответа с получающимися сжатыми данными. Данные отправляются по соединению, и блок ответа, предоставленный клиентским приложением, будет вызван с результатом. Коммуникация является реверсивной, таким образом, клиент может реализовать ее собственный интерфейс, который может вызвать сервер.

Как только интерфейсы определяются, канал коммуникации должен быть открыт между этими двумя приложениями. Одна сторона должна прислушиваться к новым соединениям, и другой соединится с ним. В нашем примере CompressingServer является службой XPC, прислушивающейся к новым соединениям. Это может реализовать свой основной метод как это:

    NSXPCListener *listener = [NSXPCListener serviceListener];

    listener.delegate = [ListenerDelegate new];

    [listener resume]; // does not return

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

    @interface ListenerDelegate : NSObject <NSXPCListenerDelegate, CompressingServer>

    @end

    ...

    - (BOOL)listener:(NSXPCListener *)listener shouldAcceptNewConnection:(NSXPCConnection *)newConnection {

        newConnection.exportedObject = self;

        newConnection.exportedInterface = [NSXPCInterface interfaceWithProtocol:@protocol(CompressingServer)];

        [newConnection resume];

        return YES;

    }

Затем, клиентское приложение соединится со службой. Это ищет его по имени и устанавливает несколько свойств:

    NSXPCConnection *connection = [[NSXPCConnection alloc] initWithServiceName:@"com.yourcompany.CompressingServer"];

    connection.remoteObjectInterface = [NSXPCInterface interfaceWithProtocol:@protocol(CompressingServer)];

    [connection resume];

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

    id <CompressingServer> proxy = [c remoteObjectProxy];

    [proxy compressData:bigData withReply:^(NSData *compressedData) {

        [compressedData writeToURL:myURL atomically:YES];

    }];

Таким образом, для создания основного соединения между двумя приложениями:

1. Создайте NSXPCInterface для определения интерфейса, который реализует каждая часть

2. Создайте NSXPCListener на одной стороне для прислушиваний к новым соединениям

3. Соединитесь со службой с помощью NSXPCConnection

4. Отправьте сообщения в объект прокси

Обработка ошибок NSXPCConnection

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

    id <CompressingServer> proxy = [c remoteObjectProxyWithErrorHandler:^(NSError *err) {

        // handle error

    }];

    [proxy compressData:bigData withReply:^(NSData *compressedData) {

        [compressedData writeToURL:myURL atomically:YES];

    }];

Иногда, удобно вложить эти методы:

    [[c remoteObjectProxyWithErrorHandler:^(NSError *err) {

        // handle error

    }] compressData:bigData withReply:^(NSData *compressedData) {

        [compressedData writeToURL:myURL atomically:YES];

    }];

Параметры объекта NSXPCConnection

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

Много Фундаментальных классов уже принимают NSSecureCoding. Если Вы хотите отправить свои собственные объекты по проводу, они должны принять его также.

1. Примите протокол NSSecureCoding, включая реализацию-initWithCoder: и-encodeWithCoder:. В Вашем-initWithCoder используйте новые методы NSCoder, например:-decodeObjectOfClass:forKey:.

2. Реализация + (BOOL) supportsSecureCoding на Вашем классе и возврате YES.

Мы расширили метаданные, сгенерированные компилятором лязга, и поняли ко времени выполнения Objective C о методах в @protocols. Это позволяет NSXPCInterface автоматически whitelist любые классы объектов, указанные как параметры. Однако, если параметром является набор (например, NSArray или NSDictionary), безопасный протокол кодирования запрашивает еще некоторую информацию об ожидаемых классах объектов в том наборе. Например, для этого протокола:

    @protocol SpellChecker

    - (oneway void)spellCheckWord:(NSString *)word withReply:(void (^)(NSArray *suggestions))reply;

    @end

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

    NSXPCInterface *ifc = [NSXPCInterface interfaceWithProtocol:@protocol(SpellChecker)];

    [ifc setClasses:[NSSet setWithObject:[NSString class]] forSelector:@selector(spellCheckWord:withReply:) ofReply:YES];

NSXPCConnection усовершенствованные темы

Дополнительные объекты прокси

По умолчанию все объектные параметры Вашим методам отправляются ‘копией’ по соединению. Это обычно - лучший подход для производительности, потому что тогда сторона получения имеет график абсолютно локального объекта для использования. Иногда, однако, можно хотеть объект стать дополнительным объектом прокси (как корень remoteObjectProxy предоставленный NSXPCConnection). Это возможно путем простого сообщения NSXPCInterface, что определенным параметром метода в его протоколе должен быть объект прокси путем обеспечения NSXPCInterface для того нового прокси.

NSUserNotification и NSUserNotificationCenter

NSUserNotification и NSUserNotificationCenter является новый APIs для взаимодействия с Центром Уведомления в масштабе всей системы. Ваше приложение может использовать этот API, чтобы сразу поставить уведомления или запланировать их для появления в некоторое время в будущем. Уведомления могут быть сконфигурированы во многих отношениях, включая повторные интервалы, пользовательские заголовки и имена кнопки. Когда пользователь щелкнет по уведомлению, Ваше приложение будет уведомлено. Если Ваше приложение не будет работать, то оно будет запущено и дано возможность реагировать на пользовательское действие.

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

Простое уведомление, поставленное сразу, может быть похожим на это:

    NSUserNotification *note = [[NSUserNotification alloc] init];

    note.title = @"Hello";

    [[NSUserNotificationCenter defaultUserNotificationCenter] deliverNotification:note];

Простое уведомление, запланированное какое-то время в будущем, может быть похожим на это:

    NSUserNotification *note = [[NSUserNotification alloc] init];

    note.title = @"Hello";

    note.deliveryDate = [NSDate dateWithTimeIntervalSinceNow:5];

    [[NSUserNotificationCenter defaultUserNotificationCenter] scheduleNotification:note];

Это запланирует уведомление, которое будет представлено через 5 секунд. Обратите внимание на то, что, если Ваше приложение будет frontmost, когда уведомление поставлено или когда запланированное время наступит, то это не будет показано в пользовательском интерфейсе с анимацией. Это вызвано тем, что, если Ваше приложение будет frontmost, то ожидается, что Ваше приложение представит любой UI, является надлежащим. Это все еще появится в списке поставленных уведомлений в Центре Уведомления, как бы то ни было. Если Вы хотите переопределить это поведение, посмотрите раздел по делегату NSUserNotificationCenter ниже.

Очень важно использовать надлежащий календарь, дату, и время APIs при вычислении даты доставки. Отказ правильно создать ценность NSDate для deliveryDate приведет к неожиданному поведению. Консультируйтесь с Руководством по программированию Даты и времени для получения дополнительной информации о расчетных датах.

NSUserNotificationCenter ведет два списка уведомлений для Вашего приложения. Первый список является запланированными уведомлениями. Запланированные уведомления будут поставлены центру уведомления в некоторый момент в будущем. Можно запланировать уведомления индивидуально или увеличить объем уведомлений расписания путем установки scheduledNotifications свойства NSUserNotificationCenter.

Второй список поставлен уведомления. Это уведомления, уже появляющиеся в Центре Уведомления. Можно поставить уведомление центру сразу с помощью deliverNotification: метод. Удалить методы позволяют Вашему приложению управлять списком поставленных уведомлений. Является надлежащим удалить старые поставленные уведомления, когда они больше не полезны, вместо того, чтобы требовать, чтобы Ваш пользователь вручную очистил список.

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

NSUserNotificationCenter будет чаще всего сконфигурирован с делегатом. Когда центр уведомления поставит уведомление, с помощью метода делегата userNotificationCenter:didDeliverNotification: этот делегат будет уведомлен.

Делегат будет также уведомлен, когда пользователь активирует уведомление путем щелчка по нему. Когда уведомление активируется, реализация Вашим делегатом userNotificationCenter:didActivateNotification, если работает Ваше приложение: будет вызван. В это время необходимо принять соответствующие меры, включая отображение соответствующих данных пользователю в UI. Если Ваше приложение не будет работать, то оно будет запущено. Поскольку делегат не будет сразу установлен на запуске приложения, объект NSUserNotification, представление активированного уведомления будет поставлено как объект в пользовательском информационном словаре applicationDidFinishLaunching метода на Вашем делегате приложения, с помощью ключа NSApplicationLaunchUserNotificationKey.

У делегата также есть метод, названный userNotificationCenter:shouldPresentNotification:. Как отмечено выше, если Ваше приложение является frontmost тогда, уведомления будут подавлены. Если Вы хотите, чтобы уведомление было представлено так или иначе, реализуйте этот метод и возвратите YES. Эта функция должна быть использована рассудительно для предотвращения раздражающий пользователи.

Объект NSUserNotification имеет несколько свойств, которые можно сконфигурировать прежде, чем запланировать уведомление. Наиболее распространенные свойства, которые установит Ваше приложение, являются строковыми значениями (заголовок, подзаголовок, и т.д.). Не забудьте локализовать эти строки как надлежащие. Другие важные свойства включают deliveryDate и deliveryRepeatInterval. Повторный интервал указан с помощью NSDateComponents. Если Вы хотите, чтобы уведомление повторялось каждый час, например, то установите свойство 'часа' объекта NSDateComponents к 1. Это гарантирует корректное поведение через границы летнего времени и другие переходы.

Если Ваше уведомление имеет абсолютное время (например, таймер для варки яиц), можно принять решение установить deliveryTimeZone в зону текущего времени. Если значение по умолчанию ноля будет использоваться, то время доставки будет скорректировано, если пользователь изменит часовые пояса.

Объект NSUserNotification также имеет несколько свойств, установленных центром уведомления после того, как уведомление было поставлено, включая значение BOOL, указывающее, было ли Ваше уведомление фактически представлено и NSDate запись фактической даты доставки (полезный для повторения уведомлений).

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

Новый iCloud APIs

В Mac OS 10.7, единственный способ проверить, регистрируется ли пользователь в iCloud с Данными и Документами, включил, должен вызвать - [NSFileManager URLForUbiquityContainerIdentifier:] и проверка на неноль URL. Однако, этот метод может иногда блокировать для существенного количества времени, делая его неподходящим для вызова от основного потока.

В Mac OS 10.8 существует новый вызванный метод - [NSFileManager ubiquityIdentityToken], который может возвратиться намного более быстро, чем-URLForUbiquityContainerIdentifier: и подходит для вызова на основной поток. Этот метод возвратит ноль, если Данные и Документы будут отключены, или пользователь вышел из iCloud полностью, то иначе это возвратит неноль.

Этот API может также использоваться для обнаружения изменений в текущей учетной записи iCloud, если это важно для приложения. Когда пользователь регистрируется в iCloud с Данными, и Документы включили, этот метод возвращает непрозрачный маркер, который может быть скопирован, по сравнению с-isEqual: и закодированный. Каждая учетная запись iCloud будет иметь различный маркер идентификационных данных связанным с ним. Можно обнаружить изменения в текущей учетной записи iCloud путем регистрации наблюдателя для NSUbiquityIdentityDidChangeNotification — новом уведомлении, отправленном через [NSNotificationCenter defaultCenter] — и после получения того уведомления, сравнивающего старые и новые значения-ubiquityIdentityToken. Если маркеры равны, то учетная запись определенно не изменялась. Если маркеры не равны, то текущий счет может быть, и обычно, отличающийся.

Координация файла для-setUbiquitous:itemAtURL:destinationURL:error:

В Mac OS 10.7, - [NSFileManager setUbiquitous:itemAtURL:destinationURL:error:] создал бы его собственный экземпляр NSFileCoordinator и выполнил бы его собственную координацию файла так, чтобы вызывающие стороны не требовались, чтобы. К сожалению, это создало проблемы, когда используется в контексте NSDocument и других NSFilePresenters, не хотящих получать-relinquishPresentedItemToWriter: для той записи. Так как NSFileManager создал сам NSFileCoordinator, не было никакого пути, отфильтровывают-relinquishPresentedItemToWriter: метод путем инициализации NSFileCoordinator с правильным NSFilePresenter.

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

NSFileCoordinator *fc = [[NSFileCoordinator alloc] initWithFilePresenter:myFilePresenter];

[fc coordinateWritingItemAtURL:sourceURL options:NSFileCoordinatorWritingForMoving

              writingItemAtURL:destinationURL options:NSFileCoordinatorWritingForReplacing

                         error:errorPtr byAccessor:^(NSURL *newSourceURL, NSURL *newDestinationURL) {

    success = [fileManager setUbiquitous:YES itemAtURL:newSourceURL destinationURL:newDestinationURL error:errorPtr];

    if (success) {

        [fc itemAtURL:newSourceURL didMoveToURL:newDestinationURL];

    }

];

[fc release];

Необходимо вызвать-setUbiquitous:itemAtURL:destinationURL:error: на том же потоке, инициировавшем координацию файла.

Обратите внимание это, когда Вы начнете делать свою собственную координацию файла для-setUbiquitous:itemAtURL:destinationURL:error: необходимо вызвать - [NSFileCoordinator itemAtURL:didMoveToURL:], когда работа успешна. Иначе система не будет в состоянии надежно сообщить другому NSFilePresenters нового URL файла.

Мусор NSFileManager APIs

В Mac OS 10.8, NSFileManager имеет новые методы для управления Мусором. - [NSFileManager trashItemAtURL:resultingItemURL:error:] попытается переместить элемент в данный URL к мусору, возвращая получающийся URL ссылкой. Как часть этой работы, система может переименовать файл для предотвращения конфликтов имен; если так, resultingItemURL отразит это новое имя.

Необходимо использовать этот API в Координации Файла как так:

NSFileCoordinator *fc = [[[NSFileCoordinator alloc] init] autorelease];

[fc coordinateWritingItemAtURL:urlToMoveToTrash options:NSFileCoordinatorWritingForMoving error:&error byAccessor:^(NSURL *url) {

    success = [[NSFileManager defaultManager] trashItemAtURL:url resultingItemURL:&resultingURL error:&error];

}];

Если необходимо найти URL Папки «Удаленные», можно использовать NSTrashDirectory, новое перечисление значений NSSearchPathDirectory. Можно объединить это значение с NSUserDomainMask, NSLocalDomainMask или URL при вызове - [NSFileManager URLForDirectory:inDomain:appropriateForURL:create:error:], для получения определенного каталога Trash, подходящего для данного домена или URL.

Некоторые объемы могут не поддерживать Папку «Удаленные», таким образом, эти методы сообщат об отказе путем возврата НЕ или ноле и NSError с NSFeatureUnsupportedError. NSFeatureUnsupportedError является новым кодом ошибки в NSCocoaErrorDomain, указывающем отказ выполнить требуемую работу, потому что функция не поддерживается, или потому что файловая система испытывает недостаток в функции, или требуемые библиотеки отсутствуют, или другие подобные причины.

- [NSObject autoContentAccessingProxy]

До Mac OS 10.8, - [NSObject autoContentAccessingProxy] возвратил объект, должным образом не реализовывавший передачу сообщения. Этот прокси теперь ведет себя правильно на Mac OS 10.8.

NSDataWritingWithoutOverwriting

По умолчанию - [NSData writeToURL:options:error:] попытается перезаписать файл в указанном пути, если это будет существовать. До Mac OS 10.8 не было возможно использовать этот метод для записи в указанный файл, только если это уже не существует атомарным способом. В Mac OS 10.8 перечисление NSDataWriting теперь включает NSDataWritingWithoutOverwriting для предоставления этой возможности.

В настоящее время не возможно сделать атомарную запись, предотвращающую перезапись, таким образом указывание и NSDataWritingAtomic и NSDataWritingWithoutOverwriting заставит NSData выдавать исключение.

Перечисление NSIndexSet

В Mac OS 10.7, - [NSIndexSet enumerateIndexesInRange:options:usingBlock:] выдал бы исключение, когда дали пустой диапазон. Это фиксируется в Mac OS 10.8 так, чтобы метод просто ничего не делал, и данный блок никогда не вызывается.

NSUUID

NSUUID является новым классом в Основе. Это включает поддержку создания версии 4 RFC 4122 UUIDs.

Дополнения NSUUID CFUUID в CoreFoundation. Это не бесплатное соединенный мостом с CFUUID, но можно использовать метод UUIDString для преобразования между двумя. Если необходимо сравнить значение двух NSUUIDs, используйте isEqual: вместо ==.

NSLinguisticTagger

С 10,8, NSLinguisticTagger обеспечивает теги частей речи и леммы для испанского и итальянского языка, в дополнение к английскому, французскому и немецкому языку.

NSError

Когда-userInfo вызывают, NSErrors, создаваемые с нолем userInfo больше, не возвращают ноль; вместо этого пустой словарь возвращается. Это эффективно для приложений, соединенных против 10,8 и позже.

NSUserScriptTask

NSUserScriptTask и его подклассы являются новыми классами, намеревался выполнить предоставленные пользователями сценарии и выполнит их за пределами песочницы приложения, если таковые имеются. Они не предназначаются для выполнения сценариев, встроенных в приложение; для этого используйте NSTask, NSAppleScript или AMWorkflow. Если приложение поигралось в песочнице, то сценарий должен быть в папке «сценариев приложений», которая можно получить использование + [NSFileManager URLForDirectory:NSApplicationScriptsDirectory...]. Поигравшее в песочнице приложение может читать из, но не записать в, эта папка.

Если просто необходимо выполнить сценарии вне зависимости от ввода или вывода, используйте NSUserScriptTask, который может выполнить любой из определенных типов. Если Вы нуждаетесь в определенном управлении вводом к или выводите из сценария, используйте один из подклассов, имеющих более подробный, «выполняют» методы.

NSByteCountFormatter

NSByteCountFormatter является подклассом NSFormatter для использования в отображении локализованных количеств байта, таких как файл, диск и емкости памяти. Это имеет способы поведения по умолчанию, которые соответствуют систему и должны быть достаточно хорошими во многих случаях; однако, способы поведения могут также быть явно установлены в случае необходимости.

Одна важная функция этого класса является своей возможностью указать, составляют ли 1000 или 1 024 байта килобайт в выводе. При помощи настройки по умолчанию NSByteCountFormatterCountStyleFile Вы можете дисплейный файл и размеры диска в Ваших приложениях в пути, который является соответствующим остальной части системы. Для отображения емкостей памяти можно выбрать NSByteCountFormatterCountStyleMemory.

В 10,8, этот класс используется только для форматирования и не парсинга. Парсинг APIs, наследованного от NSFormatter, перестанет работать без возврата, если вызвано.

NSString

NSString и NSMutableString-initWithUTF8String: методы больше не проходят через-initWithBytes:length:encoding:. Идеально это не должно влиять ни на кого; однако, возможно, что некоторые подклассификаторы могут зависеть от этого поведения. По этой причине подклассификаторы в приложениях, соединенных прежде 10.8, будут обработаны совместимо и пройдут через старый путь выполнения кода. Приложение может отказать, когда восстановлено против 10.8 SDKs, и подкласс, возможно, должен быть фиксирован.

NSString локализовал форматирование

В 10,8, в приложениях соединился против 10,8 SDK,-localizedStringWithFormat: и-initWithFormat:locale: (и друзья), когда предоставлено ненулевой локалью, теперь сделает локализованное форматирование чисел. Ранее эти вызовы уже сделали обработку десятичной точки; таким образом в некоторых локалях запятая использовалась бы для разделителя десятичной точки. Это новое поведение полагается на это для использования локализованных цифр, а также тысяч разделителей и надлежащего размещения символа знака.

Локализация применяется в следующих случаях:

- Только e, E, f, F, g, G, d, D, я, u, U локализуюсь; варианты верхнего регистра проигнорированы (и обработаны, как будто они были нижним регистром). a, A, o, O, x, X не локализуются, и ни один не все другие нечисловые символы формата.

- % используемый с NSNumber/CFNumber локализуется.

- Флаги +, - 0, ширина и точность соблюдают, но отмечают, что дополнительные символы (вне указанной ширины) могут быть вставлены для размещения тысяч разделителей.

Потенциальные ловушки включают быть локализованным вывода, где не локализовано был предназначен, и использование непреднамеренных тысяч разделителей (например, если кто-то показывал год с %d, теперь они могут добраться «2,012»).

NSString локализовал методы отображения случая

NSString теперь имеет методы для выполнения локализованного отображения случая:-uppercaseStringWithLocale:-lowercaseStringWithLocale: и-capitalizedStringWithLocale:. Для выполнения локализованного отображения на основе предпочтения пользователя передайте + [NSLocale currentLocale] этим методам. Передающий ноль указывает нелокализованное каноническое поведение.

Словарь совместно использовал набор ключей API

NSDictionary теперь предлагает метод для создания совместно используемого объекта набора ключей, +sharedKeySetForKeys:. Вы даете ему массив ключей, и это создает объект, который представляет те ключи и может быть передан в новый метод создания NSMutableDictionary +dictionaryWithSharedKeySet:. Все NSMutableDictionaries, создаваемые с тем же совместно используемым объектом набора ключей, совместно используют ключевые объекты в нем и не должны хранить их или указатели на них, сохраняя память. Так, это полезно при создании большого количества словарей с более или менее теми же ключами.

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

Не становитесь одержимыми термином «набор» в «совместно используемом наборе ключей», это не NSSet. Слово «набор» здесь используется более абстрактно, в смысле «набора» или «группы».

То, когда у Вас есть ситуация, где Вы знаете, что у Вас будет много словарей с большим количеством тех же ключей, и Вы знаете, каковы те ключи, что Вы обычно делали бы, создают совместно используемый объект набора ключей один раз, с наиболее распространенными ключами, сохраняют его далеко где-нибудь, и затем создают словари с помощью +dictionaryWithSharedKeySet: с тем объектом как параметр. Эти словари ведут себя точно так же, как обычные словари ключи могут быть любым copyable объектом, и можно сохранить пары ключ/значение в них для ключей, которые не находятся в совместно используемом объекте набора ключей. Фактически, не желательно создать совместно используемый объект набора ключей с целой вселенной возможных ключей; это может только закончить тем, что тратило впустую память, которая, возможно, лучше использовалась в другом месте. Расход создания совместно используемого объекта набора ключей также зависит от того, сколько ключей, с которыми Вы создаете его. Вы хотите создать совместно используемый ключевой объект с самыми популярными ключами в этих словарях, Вы собираетесь быть созданием. Ключи, которые не находятся в совместно используемом наборе ключей, должны они быть добавленными к одному из этих специальных непостоянных словарей, быть обработанными подобным способом к обычному Предоставленному основой NSMutableDictionary.

Как с любым объектом, используемым в качестве ключа к словарю, ключевые объекты, данные + [NSDictionary sharedKeySetForKeys:] должен реализовать протокол NSCopying и должен иметь - хеш и-isEqual: методы, которые повинуются инварианту хеша-isEqual и должны иметь значения хэш-функции, не изменяющиеся в течение долгого времени. Совместно используемый объект набора ключей является более эффективным (больше памяти и экономии ЦП), когда ключи (или скорее класс (ы) ключей) имеют хорошие хеш-функции, и - метод хеша для каждого из ключей возвращает различное значение. Однако это не требуется, так же, как с обычными словарями (и было бы проблематично для разработчика для обеспечения так или иначе!).

Распределенные Объекты теперь поддерживают включенную архивацию

При использовании Распределенных Объектов между процессами, работающими на OS X 10.7 или позже, включенная архивация теперь используется NSPortCoder. Сообщения, отправленные между OS X 10.7 и любой более ранней версией OS X, будут использовать невключенную архивацию. Вызовите allowsKeyedCoding на кодере в encodeWithCoder и декодере в initWithCoder, чтобы решить, если включено, что используется архивация.

Утечка объектов передала в структурах по Распределенным фиксированным Объектам

В OS X 10,6 Snow Leopard и ранее, объект в структуре, переданной по Распределенным Объектам, имел дополнительное, сохраняют, и был пропущен. Эта утечка была фиксирована в OS X 10.7 для приложений, соединенных с OS X 10,7 SDK или позже.

Объекты NSValue с общими типами структуры теперь поддерживают включенную архивацию

Объект NSValue с NSPoint, NSRect, NSSize, NSRange, CGAffineTransform, NSEdgeInsets или типом структуры UIEdgeInsets может теперь быть заархивирован и разархивировал использование NSKeyedArchiver. Значение только разархивирует на OS X 10.7 или позже.

Новые Макросы Доступности в заголовках Основы и AppKit

Заголовочные файлы для классов, которые являются новыми в OS X 10.7, используют новый макрос, NS_CLASS_AVAILABLE (_MacOSIntro, _iOSIntro), для указания доступности класса. Классы, украшенные этим способом, могут быть проверены в ноле на существование в будущих версиях OS X или iOS, как это:

if ([NSNewClass class]) { /* ... */ }

Методы, функции и экспортируемые значения также используют новый макрос, NS_AVAILABLE (_MacOSIntro, _iOSIntro).

Макросы доступности для символов, представленных в OS X 10.4 Тайгера или ранее, были удалены.

NSFilePresenter

OS X 10.7 включает новый механизм, позволяющий предъявителям файла, которые являются объектами, представляющими содержание файлов или каталогов пользователю для просмотра или редактирования, для взятия активной роли в операциях, получающих доступ к тем файлам или каталогам, даже операции, выполняемые другими процессами в системе. Это - важная часть реализации OS X 10,7 модернизированных моделей документа, описанных в информации о версии AppKit.

Приложение использует этот механизм путем создания и регистрации предъявителя файла для каждого файла документа или пакета файла, содержание которого представляется пользователю. Когда некоторый другой процесс использует механизм координации файла, описанный в следующем разделе, чтобы читать из или записать в представленный элемент файловой системы, скоординировавший чтение, или запись сделана ожидать, в то время как предъявителю файла дают шанс сделать различные вещи сначала. Набор вещей, которые предъявитель файла может сделать, в то время как скоординировано читая и при записи, сделан ожидать, определяется протоколом NSFilePresenter, объявляющимся в <Foundation/NSFilePresenter.h>. Вы используете этот протокол в своем приложении путем инстанцирования классов, соответствующих ему и регистрирующий те экземпляры в классе NSFileCoordinator, представленном в следующем разделе и объявленном в <Foundation/NSFileCoordinator.h>. См. комментарии в тех файлах для подробных данных.

Например, в типичном приложении «обувной коробки» как iPhoto, с готовностью не представляющий понятие файлов пользователю, но тем не менее хранящий данные пользователя в файлах где-нибудь на компьютере пользователя, Вы могли бы сделать класс делегата приложения, которому объект приспосабливает этому протоколу, если файлы - все в одном дереве каталогов. Делегат приложения зарегистрировал бы себя как NSFilePresenter в его-applicationWillFinishLaunching: метод. Если бы файлы находятся в многократных деревьях каталогов тогда, Вы, вероятно, заставили бы некоторый класс своего собственного проекта соответствовать этому протоколу и инстанцировать его на основе одного на дерево каталогов, и каждый из тех экземпляров был бы зарегистрирован.

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

Каждый NSFilePresenter ответственен за отслеживание, какого элемента файловой системы он представляет и обеспечивает URL для него на команде:

@property (readonly) NSURL *presentedItemURL;

Когда Ваше приложение регистрирует NSFilePresenter, оно утверждает «владение» представленного файла или каталога. Ничто иное в системе, использующей координацию файла соответственно, не будет в состоянии читать из или записать в представленный элемент без Вашего NSFilePresenter, даваемого возможность подготовиться к доступу к файлу заранее и уведомленный относительно его завершения позже. Существует два основных метода, которые Ваш NSFilePresenter может реализовать для получения той возможности:

- (void)relinquishPresentedItemToReader:(void (^)(void (^reacquirer)(void)))reader;

- (void)relinquishPresentedItemToWriter:(void (^)(void (^reacquirer)(void)))writer;

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

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

- (void)savePresentedItemChangesWithCompletionHandler:(void (^)(NSError *errorOrNil))completionHandler;

Реализация NSDOCUMENT этого метода сохраняет документ автоматически, если это было изменено с прошлого раза это было сохранено или сохранено автоматически. Это - реализация части OS X 10,7 модернизированных моделей документа, позволяющих пользователю не должным быть знать и заботиться для сохранения изменений документа прежде, чем заставить файл документа быть считанным другим приложением.

NSFilePresenter имеет другие методы. См. комментарии в <Foundation/NSFilePresenter.h> для подробных данных.

NSFileCoordinator

OS X 10.7 включает вызванную координацию файла нового механизма. В дополнение к инициированию работы предъявителями файла, как описано в предыдущем разделе и комментариях в <Foundation/NSFilePresenter.h>, это позволяет Вашему приложению получать доступ к файлам и каталогам в пути, сериализирующемся с доступом другого процесса тех же файлов и каталогов так, чтобы не происходили несоответствия вследствие наложения чтения и записи.

Координация файла выполняется экземплярами нового класса NSFileCoordinator. Существует два основных метода NSFileCoordinator:

- (void)coordinateReadingItemAtURL:(NSURL *)url

                           options:(NSFileCoordinatorReadingOptions)options

                             error:(NSError **)outError

                        byAccessor:(void (^)(NSURL *newURL))reader;

- (void)coordinateWritingItemAtURL:(NSURL *)url

                           options:(NSFileCoordinatorWritingOptions)options

                             error:(NSError **)outError

                        byAccessor:(void (^)(NSURL *newURL))writer;

Вы используете эти методы путем помещения чтения приложения или записи некоторых файлов и каталогов (определенно не все, больше на этом в ниже) в блоках и передаче блоков к вызовам этих методов. Каждый раз, когда Вы вызываете один из этих методов, он будет синхронно ожидать в подходящих случаях, пока другие процессы, также использующие NSFileCoordinator, не заканчивают получать доступ к тому же элементу файловой системы, и в некоторых случаях другим элементам файловой системы. Ваш блок будет вызван. В то время как Ваш блок вызывается другие процессы, также использующие NSFileCoordinator и получающие доступ к тому же элементу файловой системы, и в некоторых случаях другим элементам файловой системы, будет сделан ожидать. Когда Ваш блок возвратится, один, или больше тех других процессов прекратит ожидать как надлежащее. См. комментарии в <Foundation/NSFileCoordinator.h> для подробных данных.

Ваше приложение должно использовать координацию файла для файлов, что пользователь думает, файлы, и открывается умышленно в приложениях, или управляет со Средством поиска или делает присоединения из, как в Почте. Реализации по умолчанию правильного NSDocument и методов NSDocumentController уже используют координацию файла, таким образом, Вам ничего не, вероятно, придется сделать к Вашему приложению, чтобы заставить его использовать координацию файла, если это является находящимся в NSDocument.

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

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

- (void)itemAtURL:(NSURL *)oldURL didMoveToURL:(NSURL *)newURL;

Потребность использовать этот метод редка, но возникает, например, в TextEdit, когда расширение имени файла должно быть изменено от .rtf до .rtfd, потому что пользователь добавил присоединения к документу обогащенного текста, и различный формат файла должен использоваться для него. Если Ваше приложение является находящимся в NSDocument, у Вас, вероятно, нет беспокойства об этом, потому что реализация по умолчанию правильного метода NSDocument уже вызывает это.

NSFileCoordinator имеет другие методы, и существуют опции, можно принять решение управлять скоординированным чтением и записью. См. комментарии в <Foundation/NSFileCoordinator.h> для подробных данных.

Этот механизм отличается от традиционного консультативного захвата файла BSD в этом:

• Это не требует, чтобы Ваше приложение сделало все, что это должно сделать к файлу для определенной пользовательской работы в одном открытом () / скопление () / чтение или запись/завершение () последовательность для осуществления непротиворечивости. Это важно в контексте приложения Какао, потому что большинство методов Какао торгует NSURLs, не дескрипторами файлов или даже NSFileHandles.

• Это имеет несколько функций, которые консультативный захват файла BSD не имеет (и даже не было бы надлежащим поместить в тот уровень). Один важный пример этого - то, что скоординированное чтение файла может фактически инициировать запись в тот файл другим процессом, в то время как Ваше чтение ожидает, чтобы помочь реализовать OS X 10,7 модернизированных моделей документа, описанных в информации о версии AppKit. В то время как Ваш писатель ожидает, скоординированная запись может также инициировать действия в других процессах. Они описаны в предыдущем разделе.

• Это принимает пакеты файла во внимание автоматически.

• Нет никакого эквивалента скопления () опции LOCK_NB или кода ошибки EWOULDBLOCK. Этот механизм для использования, когда доступом к файлу управляет пользователь, и предоставляющей пользователю ошибку о неспособности взять блокировку был бы неприемлемо плохой UI, потому что это - такое техническое понятие.

• Методы, которые мы опубликовали для представления этого механизма, структурированы, чтобы мешать Вам случайно заставлять другие процессы ожидать для доступа к файлам дольше, чем Вы предназначаете. Вы не блокируете и разблокировали, Вы делаете скоординированное чтение или запись, передачу наших блоков кода методов, делающих чтение или запись. Когда один из тех блоков возвращает или выдает исключение Objective C или Ваши сбои приложения, конечно, Ваше приложение определенно прекращает заставлять другие процессы ожидать.

Несколько компонентов OS X 10,7 координаций файла использования. Например:

• Документ NSDocumentController, открывающий код, делает единственное скоординированное чтение каждого файла документа, это открыто. Другими словами, вся работа, которую это выполняет для фактического чтения файла документа, в блоке, переданном - [NSFileCoordinator coordinateReadingItemAtURL:options:error:byAccessor:], даже если работа находится на фоновом потоке. Существует больше к открытию документа, чем просто чтение файла, но другая работа выполнена, прежде и после того, как чтение сделано на основном потоке.

• Документ NSDOCUMENT, сохраняющий код, делает единственную скоординированную запись каждого файла документа, это сохраняется. Другими словами, вся работа, которую это выполняет для фактической записи файла документа, в блоке, переданном - [NSFileCoordinator coordinateWritingItemAtURL:error:options:byAccessor:], даже если это находится на фоновом потоке. “Вся работа” обычно включает запись новой версии документа файлу во временном каталоге, возможно устанавливая некоторые атрибуты файла на нем, и затем безопасно перемещая его в место для замены старой версии на диске. Существует больше к сохранению документа, чем просто, что, но другая работа выполнена прежде и после того, как записи делаются на основном потоке.

• Почта делает скоординированное чтение файлов, которые это превращает в присоединения сообщения так, если какой-либо из тех файлов является открытыми документами, изменения, уже внесенные пользователем в те документы, надежно записаны в диск как раз к Почте для чтения их. Другими словами, вся работа, которую это выполняет для чтения каждого перемещаемого файла, в блоке, переданном coordinateReadingItemAtURL:options:error:byAccessor:.

• Средство поиска делает скоординированное чтение файлов, которые это копирует, для проверки изменения, которые пользователи внесли в документы, копируются также.

Новая обработка неоднозначных спецификаторов расположения сценариев в NSPositionalSpecifier

Во всех предыдущих версиях сценариев Какао OS X поддержка интерпретировала бы спецификаторы расположения, указывающие замену буквально поэтому, если бы Вы использовались в качестве параметра команде, то команда могла бы заменить указанный объект, даже когда это не было тем, что подавляющее большинство людей, пишущих сценарии, будет ожидать или хотеть. Например, говоря Системным событиям ‘сделать новую папку в папке “A Folder to Add To “диска «Материалом» со свойствами {имя”: о нет!”}’ заменил бы папку, названную “Папка для Добавления К” с пустой папкой, названной “О нет!” вместо того, чтобы создать новую папку, названную “О нет!” в “Папке для Добавления К”. В целом этот вид проблемы применился к тому, чтобы делать, копии и командам перемещения в моделях сценариев наличия приложений, где элементы класса могут быть вложенными объектами того же класса, как папки Системных событий или группы XCode.

В OS X 10.7, NSPositionalSpecifier, был изменен класс, где это поведение реализовано, так, чтобы спецификаторы расположения как тот в вышеупомянутом примере указали вставку в указанный объект вместо замены указанного объекта. Это только делает это когда класс объекта, вставляемого соответствия один из классов элемента класса указанного объекта. Для обратной совместимости на уровне двоичных кодов старое поведение остается в приложениях, соединенных против OS X 10.6 или более старый. Если Вы выбираете Вам, может смягчить риск повреждения существующих сценариев, вынудив NSPositionalSpecifier сохранить старое поведение, независимо от того, какая версия OS X это соединяется против путем установки значения пользовательского значения по умолчанию NSPositionalSpecifierPrefersInsertionOverReplacement ко лжи. (Корректный путь к приложению для установки пользовательского значения по умолчанию, которое не является фактически пользовательской настройкой как этот, состоит в том, чтобы использовать - [NSUserDefaults registerDefaults:] во время запуска приложения.)

Более точное удаление наблюдателей значения ключа

Начиная с введения наблюдения значения ключа (KVO) в OS X 10.3 были методы, чтобы зарегистрировать и вычеркнуть из списка один объект как наблюдателя включенного значения в другом, но NSObject (NSKeyValueObserverRegistration) deregistration метод,-removeObserver:forKeyPath: пострадал от дефекта не разрешения Вам указать тот же указатель контекста, который Вы передали-addObserver:forKeyPath:options:context:. Когда тот же наблюдатель регистрируется для того же ключевого пути многократно, но с различными указателями контекста каждый раз,-removeObserver:forKeyPath: должен предположить указатель контекста при решении, что точно удалить, и он может не угадать. Это особенно раздражающее данный наше уведомление проверить указатель контекста при получении уведомления KVO для различения среди различных целей для наблюдения во-первых. Удивление и трудный отладить пример этого является кодом в подклассе, наблюдая то же включенное значение в том же объекте как код в суперклассе.

Чтобы позволить Вам более точно указать свое намерение при удалении наблюдателя, новый NSObject (NSKeyValueObserverRegistration) метод был добавлен в OS X 10.7:

- (void)removeObserver:(NSObject *)observer forKeyPath:(NSString *)keyPath context:(void *)context;

Та же проблема применяется к пакетному наблюдателю значения ключа deregistration, таким образом, был также добавлен новый NSArray (NSKeyValueObserverRegistration) метод:

- (void)removeObserver:(NSObject *)observer fromObjectsAtIndexes:(NSIndexSet *)indexes

            forKeyPath:(NSString *)keyPath context:(void *)context;

Исправление ошибки в наблюдении значения ключа

В OS X 10.6 была ошибка в наблюдении значения ключа, в котором один наблюдатель, наблюдающий ключевой путь как «commonObject.value» от двух различных объектов, где, значение для «commonObject» двух объектов было тем же объектом, мог вызвать множество катастрофических отказов, исключений и неправильного функционирования. Проявилась ли ошибка фактически, зависел от множества факторов, как порядок наблюдателя, добавляющего и удаляющего и был ли указатель контекста для этих двух наблюдений тем же. Эта ошибка была исправлена в OS X 10.7.

Улучшенная обработка ошибок и сообщающий в NSFileManager

Несколько изменений были внесены в NSFileManager в OS X 10.7 для улучшения обработки ошибок и создания отчетов.

Для приложений, соединенных на или после OS X 10.7, метод делегата-fileManager:shouldProceedAfterError:movingItemAtURL:toURL: когда элемент в целевом URL уже будет существовать, будет теперь вызван. Если делегат возвратится то ДА, работа продолжится, который, вероятно, приведет к перезаписи элемента в месте назначения. Ошибки, о которых сообщает копия NSFileManager, переместите, удалите, и методы ссылки являются теперь более непротиворечивыми о возврате NSErrors в ошибочном домене Какао с ошибками лежания в основе домена POSIX. Копия NSFileManager, переместитесь, и методы ссылки теперь сообщают об ошибках с новым кодом ошибки домена NSFileWriteFileExistsError Cocoa, когда уже существует целевой файл.

Для приложений, соединенных на или после OS X 10.7, метод делегата-fileManager:shouldProceedAfterError:linkingItemAtURL:toURL: когда NSFileManager встретится с ошибкой во время работы ссылки, будет теперь должным образом вызван. Перед OS X 10.7, NSFileManager по ошибке вызвал-fileManager:shouldProceedAfterError:copyingItemAtURL:toURL: вместо этого.

Новый основанный на NSURL NSFileManager API

В OS X 10.6, многие NSFileManager APIs были изменены для взятия NSURLs в качестве параметров вместо путей NSString для продвижения эффективности файловой системы. В OS X 10.7, два дополнительных метода теперь имеют версии NSURL-взятия. Новые методы:

- (BOOL)createDirectoryAtURL:(NSURL *)url

         withIntermediateDirectories:(BOOL)createIntermediates

                          attributes:(NSDictionary *)attributes

                               error:(NSError **)error;

- (BOOL)createSymbolicLinkAtURL:(NSURL *)url

             withDestinationURL:(NSURL *)destURL

                          error:(NSError **)error;

Семантика этих новых методов идентична их дубликатам NSString-взятия.

Для создания относительной символьной ссылки destinationURL должен быть создан с помощью [NSURL URLWithString:relativePath relativeToURL:nil].

Перечисление диапазона NSIndexSet NSIndexSet является абстракцией, как имя указывает, ряд индексов. Это также часто используется в качестве ряда диапазонов состоящих из нескольких несмежных участков. Перед OS X 10.7, не было никакого API для доступа к диапазонам индексов, сохраненных в индексном наборе; к диапазонам можно было только получить доступ при помощи основанных на индексе примитивов. Так как это не тривиально, OS X 10.7 имеет новое удобство API для перечисления диапазонов NSIndexSet состоящих из нескольких несмежных участков.

- (void)enumerateRangesUsingBlock:(void (^)(NSRange range, BOOL *stop))block;

- (void)enumerateRangesWithOptions:(NSEnumerationOptions)opts usingBlock:(void (^)(NSRange range, BOOL *stop))block;

- (void)enumerateRangesInRange:(NSRange)range options:(NSEnumerationOptions)opts usingBlock:(void (^)(NSRange range, BOOL *stop))block;

Если диапазон, переданный в последний метод, пересечет диапазон индексов получателя, то то пересечение будет передано блоку.

Эти методы, как только гарантируют, выполнят, а также если они были реализованы с-enumerateIndexesInRange:options:usingBlock:. Однако, если реализация получателя разрешает, она может выполнить лучше, чем это.

Безопасный Файл, Отображающийся для NSData Перед OS X 10.7, указывая NSDataReadingMapped (или NSMappedRead) для-initWithContentsOfFile:options:error: заставил бы NSData всегда пытаться отобразиться в указанном файле. Однако в некоторых ситуациях, отображая файл может быть опасным. Например, когда NSData отображает файл от USB-устройства, или по сети существование сказанного файла не может быть гарантировано для времени жизни объекта. При доступе к байтам NSDATA после того, как исчезает отображенный файл, вероятно, вызовет непредсказуемые катастрофические отказы в приложении.

Для приложений, соединенных на OS X 10.7 или позже, NSDataReadingMapped теперь только отобразит требуемый файл, если это может решить, что отображение файла будет относительно безопасно. Для отражения этого изменения NSDataReadingMapped был осужден и является теперь псевдонимом для NSDataReadingMappedIfSafe.

Методы-dataWithContentsOfMappedFile: и-initWithContentsOfMappedFile: были осуждены. В очень редком случае, что Ваше приложение должно отобразить файл независимо от безопасности, можно использовать опцию NSDataReadingMappedAlways.

Более гибкая версия NSIntegralRect

Основа уже предоставляет NSIntegralRect, берущему прямоугольник и продвигающему каждый край, исходящий к самому близкому целому числу. Для 10,7 мы добавляем NSIntegralRectWithOptions, версия, дающая Вам некоторый контроль над тем, как rect массажируется в явление неотъемлемой частью.

Каждый край rect или его ширины и высоты может быть продвинут входящий, исходящий, или к самому близкому целому числу.

Основная цель этой функции состоит в том, чтобы предоставить возможности (и реализация) используемый в новом методе AppKit, - [NSView backingAlignedRect:options:].

NSUserDefaults и поточная обработка

В более ранних выпусках OS X NSUserDefaults (и CFPreferences) сериализировал весь доступ; если Вы избегали использования предпочтительной системы в в большой степени потоковых приложениях вследствие конкуренции, это должно быть значительно улучшено.

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

Обработка NSUserDefaults euid/uid

До OS X Lion CFPreferences (и поэтому NSUserDefaults) изменил бы владельца plist файлов, которые это записало в uid/gid приложения, пишущего в предпочтения. У Льва, для приложений, соединенных против Льва или позже, файл будет принадлежать euid/egid вместо этого. Можно временно вернуться к старому поведению для тестирования путем установки __ CFPREFERENCES_USE_OLD_UID_BEHAVIOR в ненулевое значение в среде. Это прежде всего повлияет на приложения с привилегированными инструментами помощника, пишущими в предпочтения непривилегированных приложений, такие как Прикрепление или родительский процесс.

Потокобезопасность NSProcessInfo

NSProcessInfo теперь ориентирован на многопотоковое исполнение. Дополнительно это теперь правильно защищает свою инкапсуляцию; это может привести к различным объектным временам жизни для возвращаемых значений - параметров, - среда, и т.д. …, Если Ваш код соблюдет нормальные правила управления памятью Какао правильно, то это не будет иметь значения для Вас.

Поддержка NSProcessInfo автоматического завершения

Автоматическое Завершение является новым средством, чтобы позволить процессам быть завершенными системой автоматически. Например, если система встречается с давлением памяти, автоматическое завершение может используемый для уничтожения скрытых основанных на документе приложений или приложений без видимых окон. Обратите внимание на то, что автоматическое завершение обычно используется только в случаях, где нет никакого очевидного изменения состояния пользователю, и состояние может быть восстановлено автоматически в случае необходимости. Таким образом, скрытый документ базировал приложение, автоматически завершенное, был бы возвращен с его состоянием, неповрежденным, если бы пользователь заставил приложение быть повторно активированным.

NSProcessInfo имеет два дополнительных метода позволить тонкозернистое управление нового управляемого системой завершения функции приложений.

- (void) disableAutomaticTermination:(NSString *)reason;

- (void) enableAutomaticTermination:(NSString *)reason;

Поток NSXMLParser API

NSXMLParser имеет новый метод,-initWithStream:. Это позволяет создавать NSXMLParser, который проанализирует данные инкрементно, как это появляется, вместо того, чтобы собрать все доступные данные и затем проанализировать все это сразу. Это может очень значительно сократить пиковый объем памяти, используемый синтаксическим анализатором.-initWithContentsOfURL: был изменен для использования потоков внутренне при парсинге file:// URLs.

Потокобезопасность NSXMLParser

NSXMLParser теперь ориентирован на многопотоковое исполнение. Однако это не повторно используемо на данном потоке; не вызывайте - анализируют на NSXMLParser из обратного вызова делегата другого NSXMLParser.

NSXMLDocument внешнее ограничение объекта API

Внешние объекты в XML-файлах могут быть проблемой безопасности (см. http://www .securityfocus.com/archive/1/297714/2002-10-27/2002-11-02/0 для примера). Для смягчения этой проблемы NSXMLDocument имеет новый API для управления, как загружаются внешние объекты.

Следующие взаимоисключающие опции могут быть переданы при создании NSXMLDocument:

NSXMLNodeLoadExternalEntitiesAlways

    Это идентично поведению в OS X 10.6 и ранее

NSXMLNodeLoadExternalEntitiesSameOriginOnly

    Когда URL был предоставлен, это только применяется. Это загружает объекты целевым URLs, соответствующим узел, схему и порт документа URL.

NSXMLNodeLoadExternalEntitiesNever

    Это отключает загружающиеся внешние объекты

Если никакие опции не указаны, поведение системного значения по умолчанию используется. Для приложений, соединенных на OS X 10.6 и ранее, это - NSXMLNodeLoadExternalEntitiesAlways. Для приложений, соединенных на 10,7 или позже, загружаются все объекты, не требующие доступа к сети.

Если внешнему объекту не удается загрузиться, документ недопустим, и синтаксический анализ прерывается с ошибкой. Так как много использования NSXMLDocument ожидают маленький набор известных внешних объектов (DTDs, являющийся наиболее распространенным), новый init метод был добавлен, который принимает NSSet URLs, всегда загружающегося независимо от вышеупомянутых опций:

- (id)initWithData:(NSData *)data options:(NSUInteger)mask validExternalEntityURLs:(NSSet *)validURLs error:(NSError **)error;

NSBundle-bundlePath/-bundleURL фиксирует

Даже если пакет создавался с относительным путем, для приложений, соединенных на Льве или позже, NSBundle теперь возвращает полные пути для-bundlePath/-bundleURL. Кроме того, NSBundle больше непосредственно возвращает внутреннее состояние из-bundlePath, приводящего к различным объектным временам жизни для тех возвращаемых значений. Если Ваш код соблюдет нормальные правила управления памятью Какао правильно, то это не будет иметь значения для Вас.

Поддержка получения App Store NSBundle

NSBundle теперь имеет API для получения URL к расположению для файла получения от App Store:

- (NSURL *)appStoreReceiptURL;

Это позволяет Вам использовать файл получения без относительных путей жесткого кодирования в Вашем пакете. Даже если файл получения не будет присутствовать, Обратите внимание на то, что это будет всегда возвращать URL.

NSFileHandle основанный на блоке readability/writeability API

NSFileHandle теперь имеет следующий новый API:

@property (copy) void (^readabilityHandler)(NSFileHandle *);

@property (copy) void (^writeabilityHandler)(NSFileHandle *);

Когда базовый дескриптор файла для рассматриваемого NSFileHandle станет читаемым или writeable соответственно, блоки обработчика вызовут. Их вызовут на определенной с помощью реализации очереди, поэтому если Вам нужны они для выполнения в определенном контексте, необходимо принять меры, чтобы они сделали это (через dispatch_sync или подобный). Обратите внимание на то, что, как только обработчик возвращается, его вызовут снова, если контролируемый дескриптор файла будет продолжать быть writeable; таким образом, если Вы только хотите записать один раз, необходимо установить writeabilityHandler в ноль прежде, чем возвратиться из блока. Для предотвращения сохраняют циклы, блоки обработчика должны получить доступ к своему связанному NSFileHandle через их параметр, не путем получения его.

NSRegularExpression

NSRegularExpression является новым классом, используемым, чтобы представлять и применить регулярные выражения. Экземпляр этого класса является неизменным представлением скомпилированного образца регулярного выражения и различных флагов опции. Синтаксис образца, в настоящее время поддерживаемый, - то, что указанный ICU (описал в http://userguide .icu-project.org/strings/regexp). Поддерживаемые опции следующие:

enum {

   NSRegularExpressionCaseInsensitive            = 1 << 0, // Match letters in the pattern independent of case.

   NSRegularExpressionAllowCommentsAndWhitespace = 1 << 1, // Ignore whitespace and #-prefixed comments in the pattern.

   NSRegularExpressionIgnoreMetacharacters       = 1 << 2, // Treat the entire pattern as a literal string.

   NSRegularExpressionDotMatchesLineSeparators   = 1 << 3, // Allow . to match any character, including line separators.

   NSRegularExpressionAnchorsMatchLines          = 1 << 4, // Allow ^ and $ to match the start and end of lines.

   NSRegularExpressionUseUnixLineSeparators      = 1 << 5, // Treat only \n as a line separator (otherwise, all standard

                                                           //   line separators are used).

   NSRegularExpressionUseUnicodeWordBoundaries   = 1 << 6  // Use Unicode TR#29 to specify word boundaries (otherwise,

                                                           //   traditional regular expression word boundaries are used).

};

typedef NSUInteger NSRegularExpressionOptions;

Фундаментальный метод сопоставления для NSRegularExpression является блочным итератором. Существует несколько дополнительных удобных методов, для возврата всех соответствий сразу, числа соответствий, первого соответствия или диапазона первого соответствия. Каждое соответствие указано экземпляром NSTextCheckingResult (типа NSTextCheckingTypeRegularExpression), в котором полный диапазон соответствия дан свойством диапазона (эквивалентный rangeAtIndex:0), и любые диапазоны группы получения даны rangeAtIndex: для индексов от 1 до numberOfCaptureGroups. Если определенная группа получения не участвует в соответствии, {NSNotFound, 0} используется. Обратите внимание на то, что некоторые регулярные выражения могут успешно соответствовать диапазоны нулевой длины, когда расположение диапазона было бы значительным; это отличается от случая соответствия литеральных строк, в которых длина 0 подразумевала бы отказ соответствовать. Опции, которые могут быть предоставлены методам сопоставления, следующие:

enum {

   NSMatchingReportProgress           = 1 << 0,  // Call the block periodically during long-running match operations.

   NSMatchingReportCompletion         = 1 << 1,  // Call the block once after the completion of any matching.

   NSMatchingAnchored                 = 1 << 2,  // Limit matches to those at the start of the search range.

   NSMatchingWithTransparentBounds    = 1 << 3,  // Allow matching to look beyond the bounds of the search range.

   NSMatchingWithoutAnchoringBounds   = 1 << 4   // Prevent ^ and $ from automatically matching the beginning and end of the search range.

};

typedef NSUInteger NSMatchingOptions;

По умолчанию, блочные вызовы метода итератора блок точно один раз для каждого соответствия, с ненолем заканчиваются и надлежащие флаги. Клиент может тогда остановить работу путем установки содержания остановки к YES. Если опция NSMatchingReportProgress будет указана, то блок будут также вызывать периодически во время продолжительных операций соответствия с нулевым результатом и набором NSMatchingProgress во флагах, в которой точке клиент может снова остановить работу путем установки содержания остановки к YES. Если опция NSMatchingReportCompletion будет указана, то блок вызовут один раз после того, как соответствие будет завершено, с нулевым результатом и набором NSMatchingCompleted во флагах, плюс любые дополнительные соответствующие флаги из числа NSMatchingHitEnd, NSMatchingRequiredEnd или NSMatchingInternalError. NSMatchingReportProgress и NSMatchingReportCompletion не имеют никакого эффекта для методов кроме блочного итератора. Флаги, которые могут быть переданы блоку, следующие:

enum {

   NSMatchingProgress      = 1 << 0,  // Set when the block is called to report progress during a long-running match operation.

   NSMatchingCompleted     = 1 << 1,  // Set when the block is called after completion of any matching.

   NSMatchingHitEnd        = 1 << 2,  // Set when the current match operation reached the end of the search range.

   NSMatchingRequiredEnd   = 1 << 3,  // Set when the current match depended on the location of the end of the search range.

   NSMatchingInternalError = 1 << 4   // Set when matching failed due to an internal error.

};

typedef NSUInteger NSMatchingFlags;

Если текущая работа соответствия достигла конца поискового диапазона, NSMatchingHitEnd установлен во флагах, переданных блоку. Если текущее соответствие зависело от расположения конца поискового диапазона, NSMatchingRequiredEnd установлен во флагах, переданных блоку. NSMatchingInternalError установлен во флагах, переданных блоку если соответствие, отказавшее вследствие внутренней ошибки (такой как выражение, требующее экспоненциальных выделений памяти), не исследуя весь поисковый диапазон.

NSMatchingAnchored, NSMatchingWithTransparentBounds и NSMatchingWithoutAnchoringBounds могут примениться к любому соответствию или заменить метод. Если NSMatchingAnchored указан, соответствия ограничиваются теми в начале поискового диапазона. Если NSMatchingWithTransparentBounds указан, соответствие может исследовать части строки вне границ поискового диапазона, в целях, таких как граничное обнаружение слова, предвидение, и т.д. Если NSMatchingWithoutAnchoringBounds указан, ^, и $ не будет автоматически соответствовать начало и конец поискового диапазона (но будет все еще соответствовать начало и конец всей строки). Если поисковый диапазон покрывает всю строку, NSMatchingWithTransparentBounds и NSMatchingWithoutAnchoringBounds не имеют никакого эффекта.

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

NSRegularExpression также обеспечивает, находят и заменяют методы и для неизменных и для непостоянных строк. Замена обрабатывается как шаблон, с 0$, будучи замененным содержанием соответствующего диапазона, 1$ содержанием первой группы получения, и т.д. Дополнительные цифры вне максимума, требуемого представлять число групп получения, будут обработаны как обычные символы, как будет $, не сопровождаемый цифрами. Наклонная черта влево выйдет и из $ и из его. Для клиентов, реализующих их собственную функциональность замены, существует также метод для выполнения шаблонной замены на единственный результат учитывая строку, от которой результат был соответствующим, смещение, которое будет добавлено к расположению результата в строке (например, в случае, если модификации к строке переместили результат, так как это было соответствующим), и заменяющий шаблон.

Дополнения регулярного выражения к NSString

В дополнение к классу NSRegularExpression некоторая функциональность удобства была добавлена для использования регулярных выражений с NSString непосредственно. Это принимает форму дополнительной опции в NSStringCompareOptions, NSRegularExpressionSearch. Опция NSRegularExpressionSearch применяется только к методам формы rangeOfString:..., stringByReplacingOccurrencesOfString:..., или replaceOccurrencesOfString:..., и это устраняет все другие опции за исключением NSCaseInsensitiveSearch и NSAnchoredSearch.

Поведение эквивалентно тому из NSRegularExpression без указанных опций, кроме NSRegularExpressionCaseInsensitive (если NSCaseInsensitiveSearch указан), или NSMatchingAnchored (если NSAnchoredSearch указан). Обратите внимание на то, что некоторые регулярные выражения могут успешно соответствовать диапазоны нулевой длины, когда расположение диапазона было бы значительным; это отличается от случая соответствия литеральных строк, в которых длина 0 подразумевала бы отказ соответствовать.

В stringByReplacingOccurrencesOfString:... и replaceOccurrencesOfString:... методы, замещающая строка обрабатывается как шаблон, как в соответствующих методах NSRegularExpression, с 0$, будучи замененным содержанием соответствующего диапазона, 1$ содержанием первой группы получения, и т.д. + [NSRegularExpression escapedTemplateForString:] может использоваться для выхода из строки так, чтобы шаблонные символы были обработаны буквально.

NSDataDetector

NSDataDetector является специализированным подклассом NSRegularExpression. Вместо того, чтобы найти соответствия к образцам регулярного выражения, это соответствует элементы, идентифицированные Детекторами Данных, такими как даты, адреса и URLs. checkingTypes параметр должен содержать один или больше типов NSTextCheckingTypeDate, NSTextCheckingTypeAddress, NSTextCheckingTypeLink, NSTextCheckingTypePhoneNumber и NSTextCheckingTypeTransitInformation. Экземпляры NSTextCheckingResult возвратились, будет иметь надлежащие типы из того списка.

Дополнения к NSTextCheckingResult

Как часть усилия поддерживать NSRegularExpression и NSDataDetector, существуют некоторые дополнения к NSTextCheckingResult. Во-первых, существует новый тип, NSTextCheckingTypeRegularExpression, используемый для результатов регулярного выражения. Во-вторых, результаты могут теперь дополнительно иметь дополнительные диапазоны вне полного диапазона, который они всегда имели. Для этого существует новое свойство и метод:

@property (readonly) NSUInteger numberOfRanges;

- (NSRange)rangeAtIndex:(NSUInteger)idx;

numberOfRanges должен всегда быть по крайней мере 1, и rangeAtIndex:0 должен всегда соответствовать существующее свойство диапазона. NSTextCheckingTypeRegularExpression использует rangeAtIndex:n для представления диапазона, соответствующего энной группе получения.

Существует новый метод

- (NSTextCheckingResult *)resultByAdjustingRangesWithOffset:(NSInteger)offset;

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

NSTextCheckingTypePhoneNumber и NSTextCheckingTypeTransitInformation являются новыми типами для NSTextCheckingResult для использования с NSDataDetector. Они связали с ними новые методы создания

+ (NSTextCheckingResult *)phoneNumberCheckingResultWithRange:(NSRange)range phoneNumber:(NSString *)phoneNumber;

+ (NSTextCheckingResult *)transitInformationCheckingResultWithRange:(NSRange)range components:(NSDictionary *)components;

Результаты телефонного номера имеют свойство

@property (readonly) NSString *phoneNumber;

и транзитные информационные результаты имеют свойство

@property (readonly) NSDictionary *components;

с ключами в настоящее время NSTextCheckingAirlineKey и NSTextCheckingFlightKey для получения информации о полете. Старое addressComponents свойство для результатов адреса также заменяется новым компонентным свойством, несмотря на то, что addressComponents будет продолжать работать на совместимость.

NSLinguisticTagger

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

Много схем тега в настоящее время доступны: NSLinguisticTagSchemeTokenType, который является схемой тега, классифицирующей маркеры согласно их широкому типу: слово, пунктуация, пробел, и т.д.; NSLinguisticTagSchemeLexicalClass, классифицирующий маркеры согласно классу: часть речи для слов, типа пунктуации или пробела, и т.д.; NSLinguisticTagSchemeNameType, классифицирующий маркеры относительно того, являются ли они частью именованных сущностей различных типов или нет; NSLinguisticTagSchemeNameTypeOrLexicalClass, следующий за NSLinguisticTagSchemeNameType для имен, NSLinguisticTagSchemeLexicalClass для всех других маркеров; NSLinguisticTagSchemeLemma, предоставляющий форму основы для каждого словоупотребления (если известный); NSLinguisticTagSchemeLanguage, тегирующий маркеры согласно их наиболее вероятному языку (если известный); и NSLinguisticTagSchemeScript, тегирующий маркеры согласно их сценарию. NSLinguisticTagSchemeTokenType, NSLinguisticTagSchemeLexicalClass, NSLinguisticTagSchemeNameType и теги использования NSLinguisticTagSchemeNameTypeOrLexicalClass из указанного списка строковых констант (клиенты могут использовать == сравнение). Теги для NSLinguisticTagSchemeLemma являются леммами с языка. Теги для NSLinguisticTagSchemeLanguage являются стандартными сокращениями языка. Теги для NSLinguisticTagSchemeScript являются стандартными сокращениями сценария.

Не все языки могут быть обработаны теггером, и не все схемы тега доступны для любого данного языка. availableTagSchemesForLanguage: предоставлен для определения во время выполнения схем, доступных для определенного языка. Текущие языки, для которых тегирование частей речи доступно, являются английскими, французскими, и немецкими.

Экземпляр NSLinguisticTagger создается с помощью initWithTagSchemes:options: с массивом схем тега. Теггер будет в состоянии предоставить теги, соответствующие любой из схем в этом массиве. Как только строка была предоставлена для теггера с помощью setString: теггер сегментирует строку по мере необходимости на предложения и маркеры, и возвратит те диапазоны вместе с тегом для любой схемы в ее массиве схем тега. Фундаментальный метод тегирования на NSLinguisticTagger является блочным итератором, enumerateTagsInRange:scheme:options:usingBlock: это выполняет итерации по всем маркерам, пересекающим данный диапазон, предоставляя теги и диапазоны. Существует несколько дополнительных удобных методов, для получения диапазона предложения, информации о единственном маркере, или для получения информации обо всех маркерах, пересекающих данный диапазон сразу, в массивах.

Флаги опции доступны, которые позволяют клиентам управлять, какие типы маркеров возвращаются в результатах. По умолчанию все маркеры будут возвращены, но если соответствие флага опций исключению данного типа будет указано, то маркеры того общего типа (слово, пунктуация, пробел или другой) будут опущены от маркеров, возвращенных в результатах. Для NSLinguisticTagSchemeNameType и NSLinguisticTagSchemeNameTypeOrLexicalClass, существует управление опции, будет ли имя многословное возвращено как единственный маркер, или как отдельный маркер для каждого слова имени (значение по умолчанию).

Если клиенты знают орфографию для данной части строки, они могут предоставить его к теггеру через setOrthography:range:. Иначе, теггер выведет язык из содержания текста. Если строка, присоединенная к теггеру, является непостоянной, клиент должен сообщить теггеру каждый раз, когда строка изменяется через stringEditedInRange:changeInLength:. Приведенный пример NSLinguisticTagger не должен использоваться больше чем от одного потока одновременно.

Существует также некоторое связанное удобство APIs на NSString. Клиенты, желающие проанализировать данную строку один раз, могут использовать этот APIs NSString, не имея необходимость создавать экземпляр NSLinguisticTagger. Если больше чем одна работа тегирования необходима на данной строке, более эффективно использовать явный экземпляр NSLinguisticTagger.

NSURLConnection

Класс NSURLConnection теперь сделал, чтобы очередь поддерживала, включая обратные вызовы делегата, не требуя выполнения runloop.

Эти поддержки метода, выполняющие асинхронную загрузку URL-запросов, где результаты запроса поставлены к блоку через NSOperationQueue:

- (void)setDelegateQueue:(NSOperationQueue *)queue;

Это - подпрограмма удобства, допускающая асинхронную загрузку ОСНОВАННОГО НА URL ресурса.

+ (void)sendAsynchronousRequest:(NSURLRequest *)request

             queue:(NSOperationQueue *)queue

       completionHandler:(void (^)(NSURLResponse *, NSData *, NSError *))handler;

Существует новый метод делегата для NSURLConnection:

- (void)connection: (NSURLConnection *) connection

        willSendRequestForAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge;

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

Если делегат реализует этот новый обратный вызов, обратные вызовы делегата didReceiveAuthenticationChallenge: canAuthenticateAgainstProtectionSpace: и connectionShouldUseCredentialStorage: не будет вызван.

В ассоциации к новому обратному вызову делегата на NSURLConnection протокол NSURLAuthenticationChallengeSender был расширен для включения двух новых дополнительных методов:

@optional

- (void)performDefaultHandlingForAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge;

- (void)rejectProtectionSpaceAndContinueWithChallenge:(NSURLAuthenticationChallenge *)challenge;

Эти два новых метода протокола NSURLAuthenticationChallengeSender позволяют конструкторам обратного вызова делегата NSURLCONNECTION, willSendRequestForAuthenticationChallenge: для направления NSURLConnection для выполнения обработки по умолчанию данного запроса аутентификации. Это позволяет NSURLConnection обрабатывать новые протоколы аутентификации, и у делегатов NSURLConnection не должно быть специальных знаний новых протоколов аутентификации. Кроме того, вызов rejectProtectionSpaceAndContinueWithChallenge: от willSendRequestForAuthenticationChallenge: пропустит текущий NSURLProtectionSpace, включенный в предлагаемый объект NSURLAuthenticationChallenge. Если другой NSURLProtectionSpace существует для NSURLAuthenticationChallenge, willSendRequestForAuthenticationChallenge: будет вызван снова с новым NSURLProtectionSpace в предлагаемом параметре проблемы. Если больше не будет объектов NSURLProtectionSpace, то NSURLConnection обработает это подобное вызову отмены: на проблеме.

NSURLRequest

NSURLRequest имеет новый метод для типов сетевой службы:

- (NSURLRequestNetworkServiceType)networkServiceType;

- (void)setNetworkServiceType:(NSURLRequestNetworkServiceType)networkServiceType;

Типы Сетевой службы обеспечивают сетевые подсистемы подсказка относительно намеченной цели запроса. Текущий список типов сетевых служб включает речевое управление, речевую информацию, видео и фон.

Поддержка конвейерной обработки HTTP была добавлена:

- (BOOL)HTTPShouldUsePipelining;

- (void)setHTTPShouldUsePipelining:(BOOL)shouldUsePipelining;

Конвейерная обработка HTTP допускает передачу многократных параллельных Запросов HTTP, не ожидая ответа, улучшающего производительность по сетям высокой задержки.

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

NSHTTPCookieStorage

Существует новый метод

- (NSArray *)sortedCookiesUsingDescriptors:(NSArray *)sortOrder;

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

- (NSArray *)cookies;

Устаревший OS X 10,4 синтаксических анализаторов предиката удален

Устаревший синтаксический анализатор предиката, поставленный с OS X 10.4 (Тигр), был удален; это не будет влиять на приложения, соединенные на или после OS X 10.5 (Leopard). В приложениях, соединенных против OS X 10.4, это могло привести к немного отличающемуся поведению для предикатов с помощью BETWEEN и операторов CONTAINS и добавления нескольких зарезервированных слов к грамматике предиката. Зарегистрируйте ошибку, если это негативно влияет на Вас или приложение, Вы используете.

Новый класс набора

Существует новый класс набора в Основе, NSOrderedSet. NSOrderedSet является упорядоченным набором, к которому получает доступ индекс, как NSArray, но также и предлагает подобные NSSet операции.

NSOrderedSet имеет 3 примитива, два из которых совпадают с NSArray:

- (NSUInteger)count;

- (id)objectAtIndex:(NSUInteger)idx;

и добавляет одну треть:

- (NSUInteger)indexOfObject:(id)object;

который является основанием Операций присвоения. Последние возвраты индекс данного объекта, как Вы могли бы предположить. Все они [в подклассе] должны быть быстрым «постоянным временем» операции для NSOrderedSet для выполнения хорошо.

-isEqual: метод является основанием для объектного сравнения (например, объект в упорядоченном наборе или не). - метод хеша должен также быть хорошо реализован на объектах, вставленных в упорядоченный набор и hash/isEqual сохраняемый инвариант, так как некоторые реализации упорядоченного набора могут хотеть использовать методы хеширования для реализации примитивов.

NSMutableOrderedSet имеет 3 дополнительных примитива, главным образом действующие как примитивы NSMutableArray:

- (void)insertObject:(id)object atIndex:(NSUInteger)idx;

- (void)replaceObjectAtIndex:(NSUInteger)idx withObject:(id)object;

- (void)removeObjectAtIndex:(NSUInteger)idx;

Различия то, что insertObject:atIndex: если соответствующий объект уже находится в NSMutableOrderedSet и replaceObjectAtIndex:withObject, ничего не делает: если соответствующий объект уже находится в упорядоченном наборе в различном индексе, ничего не делает.

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

Существует два метода в NSOrderedSet, гарантирующих особое внимание:

- (NSArray *)array;

- (NSSet *)set;

Эти два метода возвращают прокси или объекты фасада для базового упорядоченного набора, действуя как, соответственно, неизменный массив или неизменный набор. Они полезны в ситуациях, где Вы имеете NSOrderedSet, но нуждаетесь в NSArray для передачи в некоторый API. Обратите внимание на то, что эти возвращенные фасады не являются копиями упорядоченного набора, и в то время как Вы не можете изменить упорядоченный набор через них, если исходный упорядоченный набор будет непостоянными, прямыми мутациями к нему, то покажет через объекты фасада, и «неизменный» набор, будет казаться, спонтанно будет изменяться. Эффект очевидных изменений в тех объектах, для кодирования, который получил их, может быть тонким. Простой пример был бы этим:

[aMutableOrderedSet removeObjectsInArray:[aMutableOrderedSet array]]

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

В настоящее время самый простой способ сделать NSArray из NSOrderedSet состоит в том, чтобы скопировать возвращаемое значение - массив:

[[anOrderedSet array] copy];

В настоящее время самый простой способ сделать NSSet из NSOrderedSet состоит в том, чтобы скопировать возвращаемое значение - набор:

[[anOrderedSet set] copy];

Распределенная поставка уведомления

Если Вы хотите, чтобы отправленное распределенное уведомление было сразу получено, уверены, что Вы передаете флаг поведения приостановки NSNotificationSuspensionBehaviorDeliverImmediately при регистрации для уведомления или использовании флага NSNotificationDeliverImmediately при регистрации. Ошибки в выпусках OS X до 10,7 означали, что иногда распределенное уведомление поставить через временно отстраненным наблюдателям и не должным образом поставить в очередь, даже когда не использовались те флаги.

NSCalendar

Алгоритмы NSCalendar имеют несколько различий, в зависимости от которых OS версия SDK Вы создаете свое приложение против.-rangeOfUnit:inUnit:forDate: может привести к существенно различным результатам для OS X 10.4, OS X 10.5 и OS X 10.6/10.7.-ordinalityOfUnit:inUnit:forDate: может привести к существенно различным результатам для прееOS X 10.6 и OS X 10.6/10.7.-dateFromComponents: может привести к различным результатам на OS X 10.7, чем ранее при работе с Недельными модулями.

Но конечно, большинство алгоритмов может привести к различным результатам между версиями ОС, поскольку ошибки исправлены, или изменения внесены, или в Основе или в CoreFoundation или в библиотеках ниже их. Различиями, отмеченными в предыдущем абзаце, являются значительные.

В NSCalendar существует 3 новых Связанных с неделей константы модуля/компонента:

NSWeekOfMonthCalendarUnit, NSWeekOfYearCalendarUnit, NSYearForWeekOfYearCalendarUnit

и значения этих количеств являются недельными числами или суммами, касающимися месяца или года, что неделя находится в, и число года для основанных на неделе интерпретаций календаря, таких как календарь ISO 8601.

Для многих операций нет никакого различия в значении между NSWeekOfMonthCalendarUnit и NSWeekOfYearCalendarUnit, но для некоторых, которые существует различие. Очевидно, получение ordinality недели с месяцем будет обычно давать различный ответ, чем ordinality недели в течение года. Постоянный NSWeekCalendarUnit официально еще не осуждается, но его использованию в новом коде обескураживают. Это имеет поведение или как NSWeekOfMonthCalendarUnit или как NSWeekOfYearCalendarUnit, в зависимости от обстоятельств, для предоставления его, поведение как он имело до OS X 10.7.

iCloud

Основа в 10,7 включает APIs, чтобы позволить приложениям сохранить конфигурационную информацию и документы в iCloud:

NSFileManager имеет APIs, чтобы поместить документ в облако или вынуть его и явно инициировать загрузку.

NSMetadataQuery обеспечивает APIs для перечисления документов в облаке.

Даже если документы еще не были загружены, NSURL имеет дополнительные ключи для запросов атрибутов документов в облаке.

NSFileVersion позволяет запросить информацию о различных версиях документа, включая тех, которые имели конфликты в результате синхронизации изменений от облака. Приложения могут использовать, принимают решение сделать более сложное разрешение конфликтов. Также обратите внимание на то, что браузер версий NSDocument показывает эти версии, включая версии, которые имели конфликты, но были полны решимости быть более старыми и таким образом отложить. В приложениях, поддерживающих Автоматическое Сохранение, пользователи могут использовать браузер версий и восстановить этих «проигравших конфликта» частично или оптовую торговлю.

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

Строковая обработка файла

В OS X Lion строковые файлы в системе были преобразованы в двоичный формат списка свойств по причинам производительности. Редко для строковых файлов быть полученным доступ непосредственно (не проходя через CF/NSBundle), и системным строковым файлам еще менее свойственно быть полученным доступ непосредственно приложениями сторонних производителей; однако, если они будут, то тогда они больше не будут открываться должным образом, если получено доступ - [NSString propertyListFromStringsFileFormat] или - [NSString propertyList], которые сначала требуют загрузки файла в как NSString, преобразование в список свойств. Вместо этого APIs в NSPropertyListSerialization должен использоваться для открытия строковых файлов непосредственно.

Методы NSString-propertyList и-propertyListFromStringsFileFormat будут осуждаться в будущем выпуске.

NSPropertyList

Следующие методы на NSPropertyListSerialization являются теперь устаревшими и будут осуждаться в будущем выпуске:

+ (NSData *)dataFromPropertyList:(id)plist format:(NSPropertyListFormat)format errorDescription:(NSString **)errorString;

+ (id)propertyListFromData:(NSData *)data mutabilityOption:(NSPropertyListMutabilityOptions)opt

                    format:(NSPropertyListFormat *)format errorDescription:(NSString **)errorString;

Методы замены:

+ (NSData *)dataWithPropertyList:(id)plist format:(NSPropertyListFormat)format options:(NSPropertyListWriteOptions)opt error:(NSError **)error;

+ (id)propertyListWithData:(NSData *)data options:(NSPropertyListReadOptions)opt format:(NSPropertyListFormat *)format error:(NSError **)error;

+ (NSInteger)writePropertyList:(id)plist toStream:(NSOutputStream *)stream format:(NSPropertyListFormat)format

                       options:(NSPropertyListWriteOptions)opt error:(NSError **)error;

+ (id)propertyListWithStream:(NSInputStream *)stream options:(NSPropertyListReadOptions)opt

                        format:(NSPropertyListFormat *)format error:(NSError **)error;

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

На новых методах, если параметром ошибок является не-NULL и ошибка, происходит тогда, он будет установлен в автовыпущенный NSError описание проблемы.

На dataWithPropertyList:format:options:error: и writePropertyList:toStream:format:options:error: методы, параметр NSPropertyListWriteOptions в настоящее время не использован и должен быть установлен на 0. Параметр формата должен быть установлен в NSPropertyListFormat.

На propertyListWithData:options:format:error: и propertyListWithStream:options:format:error: методы, параметр NSPropertyListReadOptions должен быть установлен на один из NSPropertyListMutabilityOptions. Если параметром формата будет не-NULL, то это будет заполнено форматом списка свойств чтения.

Исправление ошибки в выполнении NSAppleScript собрало «мусор»

В OS X 10.5 была плохая ошибка в NSAppleScript, представившем его эффективно несовместимый со сборкой «мусора». Признаки были частыми катастрофическими отказами и побочным возвратом ошибок. Эта ошибка была исправлена начиная с OS X 10.5.3.

Исправление ошибки в - [NSUndoManager prepareWithInvocationTarget:] (Новый начиная с семени в ноябре)

В более ранних версиях OS X - [NSUndoManager prepareWithInvocationTarget:] всегда возвращал получение NSUndoManager. Из-за пути работает сообщение Objective C, передавая, это означало, что действия отмены не будут зарегистрированы для сообщений, которые сам NSUndoManager может обработать включая, значительно, все сообщения, реализованные NSObject или любой категорией NSObject. Вместо этого сообщения были бы просто обработаны NSUndoManager. Эта ошибка была исправлена в OS X 10.6.

Исправление ошибки в .sdef-заявленном Scriptability

В OS X 10.4 и OS X 10.5 поддержки Сценариев Какао типа «числа» была неполной даже при том, что этот тип является одними из .sdef типов примитивов. Признак этого был исключениями с описаниями, в которых было сказано, что вещи как «Этот экземпляр класса 'NSCFNumber' не отвечают на сообщения-scriptingNumberDescriptor» и «+ [NSNumber scriptingNumberWithDescriptor:]: нераспознанный селектор отправил к классу 0x26a7560». Эта ошибка была исправлена.

Исправление ошибки в генерале Скриптэбилити

Во всех предыдущих версиях OS X - [NSTextStorage (NSScripting) слова] был легко перепутан числами, сопровождаемыми сразу пунктуацией. Результат состоял в том, что вызов метода не возвратит все слова, что это должно, который, конечно, влиял на результаты сообщения приложений как TextEdit возвратить вещи как «слова переднего документа». Эта ошибка была исправлена.

Внезапное Завершение - Быстро Уничтожение Приложений (Обновленный начиная с семени в ноябре)

OS X 10.6 включает новый механизм, позволяющий операционной системе выходить из системы или закрываться более быстро, когда это возможно, уничтожая приложения вместо того, чтобы запросить, чтобы они вышли из себя. Два новых метода были добавлены к NSProcessInfo:

- (void)disableSuddenTermination;

- (void)enableSuddenTermination;

Эти методы отключают или повторно позволяют возможности быть быстро уничтоженной. Реализации по умолчанию этих методов постепенно увеличиваются или декремент, соответственно, счетчик, значение которого равняется 1, когда сначала создается процесс. Когда значение счетчика 0, приложение считается безопасно killable и может быть уничтожено операционной системой без любого уведомления или события, отправляемого в процесс сначала. Если Info.plist приложения имеет запись NSSupportsSuddenTermination, значение которой является истиной тогда, NSApplication вызывает-enableSuddenTermination автоматически во время запуска приложения, обычно представляющего процесс, killable сразу же. Можно также вручную вызвать-enableSuddenTermination сразу же в, например, агенты или демоны, не зависящие от AppKit. После этого можно вызвать эти методы каждый раз, когда процесс имеет работу, это должно сделать, прежде чем это завершится.

Например:

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

 - NSDocument использует их для предотвращения уничтожения процесса между временем, в которое пользователь внес изменение в документ и время, в которое изменение пользователя было записано в диск.

 - Можно использовать их каждый раз, когда приложение задерживает работу, которая должна быть выполнена, прежде чем приложение завершается. Если, например, Ваше приложение когда-нибудь задерживает запись чего-то к диску, и это имеет запись NSSupportsSuddenTermination в своем Info.plist, чтобы не способствовать видимым пользователем задержкам при выходе из системы или время завершения работы, это должно вызвать-disableSuddenTermination, когда запись сначала задерживается и-enableSuddenTermination после того, как фактически делаются записи.

Заметьте, что-enableSuddenTermination используется, чтобы сообщить операционной системе, что процесс может участвовать в быстром механизме уничтожения во-первых, и что это будет автоматически вызвано один раз с этой целью при помещении записи NSSupportsSuddenTermination, значение которой является истиной в Info.plist приложения. Заметьте, что это также используется для балансирования предыдущих вызовов-disableSuddenTermination.

Отладка подсказки: можно узнать значение счетчика, упомянутого в вышеупомянутом комментарии путем выполнения 'печати (долго) [[NSClassFromString («NSProcessInfo») processInfo] _suddenTerminationDisablingCount]' в gdb (использующий Консоль отладки XCode, например). Не пытайтесь вызвать или переопределить - _suddenTerminationDisablingCount в Вашем приложении. Это там только в этой цели отладки и может исчезнуть в любое время.

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

Автоматическое Удаление Завершенных Наблюдателей Значения ключа При Выполнении Собрало «мусор» (Новый начиная с семени в ноябре)

С добавлением поддержки сборки «мусора» Objective C к Основе в OS X 10,5 одно из основных правил наблюдения значения ключа (KVO) осталось, и все еще применилось к, собрал «мусор» приложения: все вызовы-addObserver:forKeyPath:options:context KVO: метод должен быть сбалансирован вызовами-removeObserver:forKeyPath: или KVO пропустит память. (KVO регистрирует, когда он обнаруживает отказ соблюсти это правило, но только когда выполнение несобрало «мусор».) То же правило, примененное к использованию NSArray KVO, обработало регистрационные методы наблюдателя в пакетном режиме. Это привело к ситуациям, в которых классы наблюдателей должны были иметь - завершают методы только, чтобы сделать наблюдателя deregistration, когда они иначе не имели бы к. - завершают методы, как, предполагается, более редки, чем это. В OS X 10.6, явное удаление наблюдателей, когда они завершены, никогда не теперь необходимо. KVO автоматически удаляет наблюдателей, поскольку они собраны. Фактически, в OS X 10,6 всех вызовов - [NSObject (NSKeyValueObserverRegistration) removeObserver:forKeyPath:] и - [NSArray (NSKeyValueObserverRegistration) removeObserver:fromObjectsAtIndexes:forKeyPath:] фактически ничего не делают, когда или получатель или наблюдатель завершаются (таким образом, это не очень плохо для производительности для отъезда их там в приложениях, которые все еще должны работать на OS X 10.5).

Одна вещь не изменилась в OS X 10.6: поскольку производительность обосновывает, что Вы не должны оставлять наблюдателя зарегистрированным в объектах, больше не имеющих значения вообще для наблюдателя. Когда наблюдение свойств объектов в наборе, членство которого изменяется как выполнение приложения, лучше следовать за образцом создания того набора значение для к - многие отношение некоторого родительского объекта и добавления и удаления Вашего наблюдателя отдельных объектов, поскольку они становятся связанными и не связанными. Посмотрите, например, класс SKTGraphicView Эскиза, в частности когда он вызовет свой собственный-startObservingGraphics: и-stopObservingGraphics: методы. Если Вы вместо этого предполагаете, что наблюдаемые объекты просто уйдут, когда не будет никаких ссылок на них кроме наблюдения тогда, Ваше приложение могло бы использовать больше памяти, чем Вы ожидаете, потому что наблюдаемые объекты не будут собраны, как только Вы ожидаете. Можно зависеть от KVO для чистой обработки наблюдателей и наблюдаемых объектов, собираемых, и можно зависеть от KVO, чтобы не заставить наблюдателей идти неинкассированные, но Вы не можете зависеть от наблюдаемого объекта, собираемого перед его наблюдателями, даже если никакие другие объекты не ссылаются на наблюдаемый объект.

Исправления ошибок в Отладке Объектов, Освобождаемых С Наблюдателями, Все еще Зарегистрированными Если не Выполнение, Собрали «мусор» (Обновленный начиная с Семени марта 2009)

В OS X 10.3 до 10,5 была ошибка, в которой не была инициирована ценная функция отладки KVO, когда объект, наблюдая себя не удалял себя как наблюдатель себя во время освобождения. Эта ошибка была исправлена в OS X 10.6. Когда это происходит, Основа теперь регистрирует что-то как «Экземпляр 0x100771010 класса, MySelfObservingClass был освобожден, в то время как наблюдатели значения ключа были все еще зарегистрированы в нем. Информация наблюдения была пропущена и может даже стать по ошибке присоединенной к некоторому другому объекту. Установите точку останова на NSKVODeallocateBreak для остановки здесь в отладчике. Вот текущая информация наблюдения: …»

Была другая ошибка, в которой это журналирование было сделано побочно, когда объект, наблюдаемый вторым объектом, был освобожден, его освобождение вызвало выпуск второго объекта и второго объекта, правильно незарегистрированного самого как наблюдатель первого объекта в то время вследствие его собственного освобождения. Эта ошибка имеет, также был фиксирован в OS X 10.6.

Для суммирования тест KVO для объектов, освобождаемых с наблюдателями все еще, зарегистрировал показанные и ложные отрицания и ложные положительные стороны, и были фиксированы оба вида ошибки.

Новый класс NSPurgeableData

OS X 10.6 включает подкласс NSMutableData, названный NSPurgeableData, использующим в своих интересах новую purgeable функцию памяти. Объекты NSPurgeableData соответствуют протоколу NSDiscardableContents, описание которого является предстоящим.

Для NSPurgeableData, если-beginContentAccess возвращается нет, то байты NSPurgeableData были очищены и байты эффективно недоступны. Обратите внимание на то, что к объектам NSPurgeableData «получают доступ» после создания, таким образом-endContentAccess нужно вызвать после создания для создания данных purgeable.

NSData copyWithZone: измененный (Новый начиная с WWDC 2008)

До OS X 10.6, когда-copyWithZone: был вызван на любой экземпляр CFData посредством бесплатного образования моста, метод будет всегда возвращать новый экземпляр NSData, содержащий копию исходных байтов. Для приложений, соединенных на или после 10.6, этот метод сохранит и возвратит исходный экземпляр, вместо копирования, когда вызвано на неизменный CFData. Если необходимо создать фактическую копию экземпляра CFData, используйте CFDataCopy () или-dataWithData:.

- [NSData getBytes:range:] и NSRangeException (Новый начиная с WWDC 2008)

До OS X 10.6, - [NSData getBytes:range:] должным образом не повышал NSRangeException для диапазонов, запускающихся в байтах NSDATA, но конце вне их. Вместо этого это заполнило предоставленный буфер до конца NSData. Для приложений, соединенных на или после OS X 10.6, этот метод теперь должным образом повысит NSRangeException.

NSNumberFormatter, NSDateFormatter и-getObjectValue:forString:errorDescription: (Новый начиная с WWDC 2008)

До OS X 10.6, и реализация NSNumberFormatter и NSDateFormatter-getObjectValue:forString:errorDescription: если только часть строки могла бы быть проанализирована, возвратил бы YES и проанализированное объектное значение. Это проблематично, потому что с этим API Вы не можете быть уверены, какая часть строки была проанализирована. Если часть строки не может быть проанализирована, для приложений, соединенных на или после OS X 10.6, этот метод вместо этого возвращает ошибку. Можно использовать-getObjectValue:forString:range:error: получить старое поведение; этот метод возвращает диапазон успешно проанализированной подстроки.

Формальное Принятие Протокола (Новый начиная с WWDC 2008)

В OS X 10.6, Основа переключилась на использование формальных протоколов для всех делегатов для обеспечения лучшей проверки типа времени компиляции. Методы требуемого протокола отмечены с @required, если это возможно. Остальные отмечены с @optional.

Затронутые классы

• NSConnection

• NSKeyedArchiver

• NSMetadataQuery

• NSNetService

• NSNetServiceBrowser

• NSPort

• NSMachPort

• NSSpellServer

• NSStream

• NSXMLParser

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

• Ваши классы делегата должны объявить соответствие к новым протоколам. Например:

@interface MyDelegate : NSObject <NSMetadataQueryDelegate> ... @end

• Отправка сообщений к [foo делегат], которые не находятся в протоколе делегата, генерирует предупреждение. Это обычно не рекомендуется, так как нет никаких гарантий о классе делегата. Однако можно работать вокруг этого путем кастинга результата [foo делегат] к ID. Кроме того, необходимо всегда выполнять respondsToSelector: проверьте прежде, чем вызвать метод на [foo делегат], который не является @required методом в протоколе.

• Если у Вас есть подкласс одного из этих классов, добавляющего дополнительные методы делегата, необходимо также создать подпротокол и переопределение - делегат и-setDelegate:. Например:

@protocol MyStreamDelegate;

@interface MyStream : NSStream

- (id <MyStreamDelegate)delegate;

- (void)setDelegate:(id <MyStreamDelegate>)delegate;

@end

@protocol MyStreamDelegate <NSStreamDelegate>

- (void)additionalDelegateMethod;

@end

@implementation MyStream

- (id <MyStreamDelegate)delegate {

    return (id <MyStreamDelegate>)[super delegate];

}

- (void)setDelegate:(id <MyStreamDelegate>)delegate {

    [super setDelegate:delegate];

}

@end

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

#if MAC_OS_X_VERSION_10_6 > MAC_OS_X_VERSION_MAX_ALLOWED

@protocol NSConnectionDelegate <NSObject> @end

#endif

`

Осуждение небезопасных берущих буфер методов (Новый начиная с семени в ноябре)

Следующие методы будут осуждаемый в следующем выпуске OS X.

-[NSString getCharacters:]

-[NSData getBytes:]

-[NSArray getObjects:]

Они были идентифицированы как небезопасные. Как правило, буферы, переданные в к этим методам, измерены относительно результата - количества или - длина. Однако для получателя возможно быть видоизмененным от другого потока между этими вызовами метода. Это может потенциально вызвать переполнение буфера. Для предотвращения этого необходимо использовать следующие методы вместо этого:

-[NSString getCharacters:range:]

-[NSData getBytes:length:] or -[NSData getBytes:range:]

-[NSArray getObjects:range:]

Фатальные ошибки NSXMLParser (Новый начиная с семени в ноябре)

Перед OS X 10.6, NSXMLParser иногда пытался бы продолжать анализировать после фатальной ошибки. Для приложений, соединенных на SnowLeopard или позже, NSXMLParser теперь прервет парсинг после создания отчетов о фатальной ошибке.

Для пользы совместимости можно восстановить поведение pre-SnowLeopard путем установки переменной окружения NSXMLParserContinueParsingAfterFatalError в YES. Однако необходимо устранить любую зависимость от этого поведения как можно скорее.

NSData rangeOfData:withOptions:range: (Новый начиная с семени в ноябре)

NSData теперь имеет метод, который будет эффективно искать его содержание:

    - (NSRange)rangeOfData:(NSData *)dataToFind

                   options:(NSDataSearchOptions)mask

                     range:(NSRange)searchRange;

Семантика почти идентична rangeOfString:withOptions:range: NSSTRING. Единственной значительной разницей является отсутствие 'нечувствительных к регистру' и 'литеральных' параметров поиска, которые только применимы к строкам.

NSFileManager (Новый начиная с семени в ноябре)

Следующие методы на NSFileManager теперь выдают исключения в OS X 10.6:

    - (BOOL)copyItemAtPath:(NSString *)srcPath toPath:(NSString *)dstPath error:(NSError **)error;

    - (BOOL)moveItemAtPath:(NSString *)srcPath toPath:(NSString *)dstPath error:(NSError **)error;

    - (BOOL)linkItemAtPath:(NSString *)srcPath toPath:(NSString *)dstPath error:(NSError **)error;

    - (BOOL)copyItemAtURL:(NSURL *)srcURL toURL:(NSURL *)dstURL error:(NSError **)error;

    - (BOOL)moveItemAtURL:(NSURL *)srcURL toURL:(NSURL *)dstURL error:(NSError **)error;

    - (BOOL)linkItemAtURL:(NSURL *)srcURL toURL:(NSURL *)dstURL error:(NSError **)error;

Если dstPath или dstURL будут нолем, для всех приложений эти методы бросят NSInvalidArgumentException. Для приложений, соединенных на OS X 10.6 или позже, эти методы бросят NSInvalidArgumentException если srcPath или srcURL ноль.

NSString соединяют завершение каналом (Новый начиная с WWDC 2008)

completePathIntoString:caseSensitive:matchesIntoArray:filterTypes NSSTRING: метод ранее правильно не принимал чувствительный к регистру флаг во внимание (в частности, большая часть поведения приняла значение по умолчанию к чувствительному к регистру, даже если флаг был установлен в НЕ). Это теперь фиксируется; весь путь является соответствующим нечувствительно к регистру, если указано. (Обратите внимание на то, что в нечувствительной к регистру файловой системе как большая часть HFS + диски, чувствительное к регистру завершение будет все еще соответствовать путь нечувствительно к регистру; только последний компонент будет соответствующим чувствительно к регистру. Это - ограничение файловой системы.)

NSDecimal (Новый начиная с WWDC 2008)

NSDecimal и NSDecimalNumber теперь правильно сообщают, что нулевое питание отрицательного числа (например, [someNegative decimalNumberByRaisingToPower:0]) 1, вместо-1.

NSIndexSet (Новый начиная с WWDC 2008)

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

Текстовая Проверка (Обновленный начиная с WWDC 2008)

Snow Leopard включает новое средство, известное как текстовая проверка, обеспечивающая объединенный интерфейс для множества типов проверки, включая проверку правописания, проверку правописания, обнаружение URL, умные кавычки, дату и обнаружение адреса через Детекторы Данных и других. Среди прочего это средство допускает автоматическую идентификацию языков, используемых в части текста, так, чтобы проверка правописания могла продолжиться без пользователя, имеющего необходимость к тексту метки относительно языка.

Основной интерфейс для этого средства теперь доступен в AppKit через NSSpellChecker (см. информацию о версии AppKit для подробных данных). Основа содержит два новых класса, предназначенные, чтобы использоваться в качестве части этой функции: NSTextCheckingResult и NSOrthography.

Экземпляр NSTextCheckingResult представляет что-то, что было найдено во время проверки - слово с ошибками, предложение с грамматическими проблемами, обнаруженным URL, прямая кавычка, которая будет заменена изогнутыми кавычками и т.д. Это - неизменный класс значения, предназначенный, чтобы пасоваться назад, когда элементы массива возвратились к клиентам текста, проверяющего APIs. Каждый экземпляр имеет как минимум тип проверки, показывающий вид элемента, отмеченного, и диапазон в строке, проверяемой, к которому применяется результат. В настоящее время существует 10 определенных с помощью системы типов проверки с пространством, зарезервированным для еще 22, и для 32 дополнительных пользовательских текстов, проверяющих типы, которые будут определены клиентами. Сам NSTextCheckingResult является полуабстрактным суперклассом; любые пользовательские типы результата обычно определяли бы подходящий подкласс для содержания надлежащей информации.

NSOrthography является классом, используемым для описания лингвистического содержания части текста, специально для целей проверки правописания и проверки правописания. Это описывает (a), пишущий сценарий текста, содержит, (b) доминантный язык и возможно другие языки для каждого из этих сценариев и (c) доминирующий сценарий и язык для текста в целом. Это - неизменный класс значения, предназначенный, чтобы пасоваться назад как часть результатов автоматического определения языка или передаваться в как начальная точка для той идентификации.

В целях NSOrthography сценарии унифицированно описаны стандартными тегами с четырьмя буквами (Latn, Grek, Cyrl, и т.д.) с супертегами Jpan и Kore, обычно используемый для японского и корейского текста, Ханса и Хэнта для упрощенного и традиционного китайского текста; если определенный сценарий не может быть идентифицирован, Zyyy тега используется. Языки унифицированно описаны тегами BCP 47, предпочтительно в канонической форме; если определенный язык не может быть определен, тег und используется.

Кроме того, существует новый метод делегата для NSSpellServer, который делегат NSSpellServer в программе проверки правописания может использовать для выполнения проверки правописания и проверки правописания одновременно, когда так требуемый новыми текстовыми методами проверки на NSSpellChecker, а также заканчивается указание автоисправления.

- (NSArray *)spellServer:(NSSpellServer *)sender

             checkString:(NSString *)stringToCheck

                  offset:(NSUInteger)offset

                   types:(NSTextCheckingTypes)checkingTypes

                 options:(NSDictionary *)options

             orthography:(NSOrthography *)orthography

               wordCount:(NSInteger *)wordCount;

Возвращаемое значение должно быть массивом объектов NSTextCheckingResult, и другие параметры обычно соответствуют тем для новых методов NSSpellChecker. Результаты должны иметь орфографию, написание, грамматику или типы исправления, как указано checkingTypes. Строка, переданная в к этому методу, может быть подстрокой строки, переданной в к NSSpellChecker, и параметр смещения представляет смещение той подстроки во всей строке; это должно быть добавлено к источнику диапазона для любого возвращенного NSTextCheckingResult. Параметр орфографии представляет идентифицированную орфографию строки, передаваемой в к этому методу.

Изученные Слова (Новый начиная с WWDC 2008)

Формат для изученных списков слов, используемых программой проверки правописания, не был ранее задокументирован. Существует два типа изученных списков слов, оба из которых сохранены как документы простого текста UTF-8 в ~/Library/Spelling. Первый тип состоит из тех слов, изученных в частности в контексте определенного языка; они сохранены в файлах, названных сокращением для того языка, как указано в массиве NSLanguages в Info.plist программы проверки правописания. Второй тип состоит из тех слов, изученных за пределами контекста определенного языка; они сохранены в единственном файле под названием LocalDictionary. В любом случае файлы состоят из списков изученных (нечувствительных к регистру) слов, один на строку, разделенную новыми строками (\n, U+000A). (Встроенный обнуляет, может также использоваться вместо новых строк и так использовались до Snow Leopard, но теперь предпочтены новые строки.) Если определенное слово появляется несколько раз в данном файле, оно обрабатывается, как изучено, если и только если это появляется нечетное число времен. Машинное оборудование проверки правописания будет иногда обновлять эти файлы, которые будут автоматически нормализованы в стандартную форму с каждой строкой, появляющейся самое большее один раз.

ОСНОВАННЫЕ НА URL методы для NSBundle

Для сокращения несоответствия импеданса с другими методами берущий или возвращающийся URLs NSBundle теперь имеет ОСНОВАННЫЕ НА URL эквиваленты своих основанных на первоначальном тракте методов. Параметры обычно параллельны тем из существующих находящихся на пути методов, но имена в некоторых случаях были изменены, чтобы отразить текущие стандарты или избежать терминологии, которая, как находили, сбивала с толку. Новые методы:

+ (NSBundle *)bundleWithURL:(NSURL *)url;

- (id)initWithURL:(NSURL *)url;

- (NSURL *)bundleURL;

- (NSURL *)resourceURL;

- (NSURL *)executableURL;

- (NSURL *)URLForAuxiliaryExecutable:(NSString *)executableName;

- (NSURL *)privateFrameworksURL;

- (NSURL *)sharedFrameworksURL;

- (NSURL *)sharedSupportURL;

- (NSURL *)builtInPlugInsURL;

+ (NSURL *)URLForResource:(NSString *)name withExtension:(NSString *)ext subdirectory:(NSString *)subpath inBundleWithURL:(NSURL *)bundleURL;

+ (NSArray *)URLsForResourcesWithExtension:(NSString *)ext subdirectory:(NSString *)subpath inBundleWithURL:(NSURL *)bundleURL;

- (NSURL *)URLForResource:(NSString *)name withExtension:(NSString *)ext;

- (NSURL *)URLForResource:(NSString *)name withExtension:(NSString *)ext subdirectory:(NSString *)subpath;

- (NSURL *)URLForResource:(NSString *)name withExtension:(NSString *)ext subdirectory:(NSString *)subpath localization:(NSString *)localizationName;

- (NSArray *)URLsForResourcesWithExtension:(NSString *)ext subdirectory:(NSString *)subpath;

- (NSArray *)URLsForResourcesWithExtension:(NSString *)ext subdirectory:(NSString *)subpath localization:(NSString *)localizationName;

NSXMLNode и-setObjectValue:

NSXMLNode определяет-setObjectValue: метод, который автоматически преобразовал бы non-NSString параметры в Нсстрингса для использования в качестве значения объекта NSXMLNode.

Долгосрочная ошибка в коде трансформации числа была исправлена в OS X 10.6, который будет влиять на вывод XML-файлов. До SnowLeopard NSXMLNode неправильно и противоречиво отформатировал бы NSNumbers, переданный в к-setObjectValue:. Для приложений, соединенных на или после OS X 10.6, NSXMLNode будет использовать корректное экспоненциальное представление для всего NSNumbers, переданного в к-setObjectValue:. Приложения, соединенные против SDKs до OS X 10.6, получат оригинал (возможно неправильный) поведение.

Как правило при требовании определенного формата для какого-либо значения в XML-документе необходимо отформатировать данные сами как строку и затем использовать - [NSXMLNode setStringValue:]. Это гарантирует, что сгенерированный текст находится в формате, которым Вы управляете непосредственно.

+ [NSXMLNode namespaceWithName:stringValue:] (Новый начиная с семени в ноябре)

Для приложений, соединенных на SnowLeopard или позже, + [NSXMLNode namespaceWithName:stringValue: если параметр 'имени' будет нолем,] теперь бросит.

NSURL

Существуют значительные дополнения API к NSURL для включения более эффективного манипулирования свойством файла, а также дополнительных способов поведения. Больше описания для этого является предстоящим.

Мы добавили некоторый основанный на NSURL параллельный APIs к местам, где у нас был только находящийся в NSString APIs для ссылки на файлы. Мы намереваемся продолжить это, чтобы удостовериться, что вся ссылка файла может иметь место через NSURLs без потребности преобразовать в другие типы, такие как строки или FSRefs.

NSFileManager ОСНОВАННЫЕ НА URL операции файла

В OS X 10.6 «SnowLeopard» NSFileManager предлагает реализации операций общего файла, основывающихся на NSURLs, а не путях, представленных Нсстрингсом. Это устраняет некоторое несоответствие API при работе прежде всего с AppKit APIs, которые прежде всего используют NSURLs.

Эти методы теперь доступны:

- (BOOL)copyItemAtURL:(NSURL *)srcURL toURL:(NSURL *)dstURL error:(NSError **)error;

- (BOOL)moveItemAtURL:(NSURL *)srcURL toURL:(NSURL *)dstURL error:(NSError **)error;

- (BOOL)linkItemAtURL:(NSURL *)srcURL toURL:(NSURL *)dstURL error:(NSError **)error;

- (BOOL)removeItemAtURL:(NSURL *)URL error:(NSError **)error;

Соответствующие методы делегата также доступны - дополнительную информацию см. в заголовке NSFileManager.h.

NSFileManager смонтировал открытие объема (Новый начиная с семени в ноябре)

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

- (NSArray *)mountedVolumeURLsIncludingResourceValuesForKeys:(NSArray *)propertyKeys

                                                     options:(NSVolumeEnumerationOptions)options;

Ключи свойства - перечисленные в заголовке NSURL.h, как являющемся ключами свойства объема.

Возвращаемое значение является NSArray экземпляров NSURL, кэши ресурса которых были предварительно заполнены с требуемыми значениями ресурса.

Опции:

enum {

    NSVolumeEnumerationSkipHiddenVolumes = 1L << 1,

    NSVolumeEnumerationProduceFileReferenceURLs = 1L << 2

}

typedef NSUInteger NSVolumeEnumerationOptions;

Если I/O требуется, чтобы определять значения для требуемых ключей, этот вызов может блокировать.

Изменения перечисления каталога NSFileManager (Новый начиная с семени в ноябре)

NSFileManager теперь предлагает ОСНОВАННОЕ НА URL перечисление каталога, подобное смонтированному открытию объема выше.

Определение типа NSDirectoryEnumerationOptions описывает опции:

enum {

    NSDirectoryEnumerationSkipsSubdirectoryDescendants = 1L << 0,

    NSDirectoryEnumerationSkipsPackageDescendants      = 1L << 1,

    NSDirectoryEnumerationSkipsHiddenFiles             = 1L << 2

};

typedef NSUInteger NSDirectoryEnumerationOptions;

Для мелких перечислений каталога следующий метод теперь доступен:

- (NSArray *)contentsOfDirectoryAtURL:(NSURL *)url

               includingPropertiesForKeys:(NSArray *)keys

                                  options:(NSDirectoryEnumerationOptions)mask

                                    error:(NSError **)error;

который возвращается, NSArray экземпляров NSURL, представляющих содержание каталога, базировался в URL. Можно также обеспечить NSArray ключей атрибутов для получения во время перечисления (это ключи, указанные в <Foundation/NSURL.h>). Поскольку этот метод обеспечивает мелкое перечисление, единственный флаг, который целесообразен передавать, поскольку опцией является NSDirectoryEnumerationSkipsHiddenFiles. Если ошибка произойдет, то возвращаемое значение будет нулевым массивом, и параметр ошибок будет установлен в надлежащий NSError в ошибочном домене Какао.

Для глубоких перечислений каталога существует новый метод на NSFileManager для возврата NSDirectoryEnumerator, продающего NSURLs:

- (NSDirectoryEnumerator *)enumeratorAtURL:(NSURL *)url

            includingPropertiesForKeys:(NSArray *)keys

                               options:(NSDirectoryEnumerationOptions)mask

                          errorHandler:(BOOL (^)(NSURL *url, NSError *error))handler;

URL и ключевые параметры как выше. Параметр маски может взять любой из флагов, определенных в определении типа NSDirectoryEnumerationOptions. Если ошибка происходит во время перечисления, блок обработчика вызывается, который будет передан URL, на котором ошибка произошла и ошибка. Если никакой обработчик не будет предоставлен, то ошибка будет пропущена, и перечисление будет продолжаться.

Для обоих из этих методов, если Вы хотите только получить URLs и никакие другие атрибуты, затем передают '0' для 'опций' и пустого NSArray (' [массив NSArray]') для 'ключей'. Если Вы хотите иметь кэши свойства продаваемого URLs, предварительно заполненного с набором по умолчанию атрибутов, то передайте '0' для 'опций' и 'ноля' для 'ключей'.

Замена элемента файловой системы NSFileManager (Новый начиная с семени в ноябре)

В OS X 10.6 «SnowLeopard» NSFileManager обеспечивает основанный на NSURL механизм для замены одного объекта файловой системы с другим:

- (BOOL)replaceItemAtURL:(NSURL *)originalItemURL

           withItemAtURL:(NSURL *)newItemURL

          backupItemName:(NSString *)backupItemName

                 options:(NSFileManagerItemReplacementOptions)options

        resultingItemURL:(NSURL **)resultingURL error:(NSError **)error;

Если заменяющая работа была успешна, этот метод возвращает YES. resultingURL будет заполнен с URL, указывающим на новый элемент. если замена могла бы быть сделана, не имея необходимость создавать новый объект файловой системы, resultingURL может совпасть с originalItemURL. resultingURL может отличаться, чем originalItemURL, если замена не могла бы быть сделана, не имея необходимость создавать новый объект (например, хождение от rtf документа до rtfd требует, чтобы создание нового элемента - в этом случае, resultingURL определил бы местоположение недавно создаваемого rtfd).

По умолчанию дата создания, полномочия, метка Средства поиска и цвет и комментарии Центра внимания исходного элемента будут сохранены на получающемся элементе.

Если backupItemName - то, при условии, что имя будет использоваться для создания резервного копирования исходного элемента. Резервное копирование будет помещено в тот же каталог как исходный элемент. Если ошибка происходит во время создания резервного элемента, работа перестанет работать. Если уже будет элемент с тем именем, то элемент будет удален.

NSFileManagerItemReplacementOptions определяется следующим образом:

enum {

    NSFileManagerItemReplacementUsingNewMetadataOnly = 1L << 0,

    NSFileManagerItemReplacementWithoutDeletingBackupItem = 1L << 1

}

typedef NSUInteger NSFileManagerItemReplacementOptions;

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

NSFileManagerItemReplacementUsingNewMetadataOnly подразумевает, что метаданные по получающемуся элементу будут взяты полностью от нового элемента.

Флаг NSFileManagerItemReplacementWithoutDeletingBackupItem вызывает-replaceItemAtURL:withItemAtURL:backupItemName:options:resultingItemURL:error: оставить резервный элемент на месте, если работа успешна.

Новый доменный селектор, NSItemReplacementDirectory, был добавлен для использования с - [NSFileManager URLForDirectory:inDomain:appropriateForURL:create:error:]. Это возвращает NSURL определение местоположения самого надлежащего каталога для использования с этим методом. Необходимо записать новый элемент в этот каталог.

Если ошибка происходит в замене элемента файловой системы, и исходный элемент не оставили ни в исходном расположении, ни во временном расположении, NSError возвратился, будет содержать пользовательский информационный словарь с ключом NSFileOriginalItemLocationKey, и его значение будет экземпляром NSURL, определяющим местоположение элемента. Код ошибки является одним из различных NSFile* ошибки, уже существующие в <Foundation/FoundationErrors.h>.

NSTask (Новый начиная с WWDC 2008)

В SnowLeopard следующий метод был добавлен к NSTask:

- (NSTaskTerminationReason)terminationReason;

который возвращает одно из следующего:

enum {

    NSTaskTerminationReasonExit = 1,

    NSTaskTerminationReasonUncaughtSignal = 2

};

typedef NSInteger NSTaskTerminationReason;

Это позволяет клиенту различать дочерний процесс, выходящий чисто и окончание дочернего процесса, потому что это получило сигнал, который это не сделало или не могло обработать.

Если - [NSTask terminationReason] вызывается до завершения задачи, исключение выдается.

NSURL включил архивацию (Новый начиная с семени февраля 2009)

OS X 10.6 «SnowLeopard» представляет ссылку на файл URLs; URLs, отслеживающий идентификационными данными элемента файловой системы, а не его путем. Поскольку ссылка на файл URLs не функционирует после определенной файловой системы или других событий (например, входит в систему/выходит из системы или повторно монтируется файловой системы), ссылка на файл, URLs должен использоваться экономно и кодироваться тщательно.

Когда спросили выполнить включенную архивацию, ссылка на файл URLs закодирует их минимальные данные закладки и, когда декодируется разрешит к пути к файлу URL (если Вы хотите получить ссылку на файл URL от этого, вызовите - [NSURL fileReferenceURL] на получающемся элементе).

Утилиты Пути NSURL (Новый начиная с семени в ноябре)

NSURL имеет новые методы для общих манипуляций путем, определенных в категории NSURLPathUtilities на NSURL:

+ (NSURL *)fileURLWithPathComponents:(NSArray *)components;

- (NSArray *)pathComponents;

- (NSString *)lastPathComponent;

- (NSString *)pathExtension;

- (NSURL *)URLByAppendingPathComponent:(NSString *)pathComponent isDirectory:(BOOL)isDirectory;

- (NSURL *)URLByAppendingPathComponent:(NSString *)pathComponent;

- (NSURL *)URLByDeletingLastPathComponent;

- (NSURL *)URLByAppendingPathExtension:(NSString *)pathExtension;

- (NSURL *)URLByDeletingPathExtension;

С находящимся на пути файлом: схема URLs, вышеупомянутые методы работают так же к методам категории NSPathUtilities на NSString. Когда ссылка на файл, URLs (например, file:/// .file/id=103.3747951) отправляется эти сообщения, ссылка на файл URL, будет возвращена, который был соответственно изменен. fileURLWithPathComponents: будет всегда возвращать находящийся на пути файл: схема URL.

Например, при отправке URLByAppendingPathComponent:isDirectory: передайте к ссылке на файл URL, Вы получили бы ссылку на файл URL, поскольку основа с относительной частью, являющейся строкой, передала как pathComponent параметр. Это создает ссылку на файл URL, отслеживающий родительский каталог идентификационными данными файловой системы, но определяющий местоположение файла собственного имени в том каталоге.

Эти преобразования происходят только при необходимости. Если работа может быть безопасно выполнена путем управления строкой относительной части экземпляра NSURL, то эти методы сделают так. Эти преобразования гарантируют, что возвращающийся экземпляр NSURL имеет тот же базовый тип как исходный NSURL. Если основа исходного экземпляра NSURL была ссылкой на файл URL, то основа нового экземпляра NSURL будет ссылкой на файл URL.

Если существует никакое последнее расширение компонента контура или пути, первые два метода возвращают пустую строку («»).

Следующие методы работают только над файлом: схема находящийся на пути URLs; для ссылки на файл URLs или для нефайла: схема URLs, эти методы возвращают неизменный URL:

- (NSURL *)URLByStandardizingPath;

- (NSURL *)URLByResolvingSymlinksInPath;

lastPathComponent не подходит для дисплея для пользователя. Необходимо использовать getResourceValue:forKey:error NSURL: и передайте NSURLLocalizedNameKey для ключа.

pathExtension не должен использоваться для определения типа файла. Необходимо вместо этого использовать getResourceValue:forKey:error NSURL: и передайте NSURLTypeIdentifierKey как ключ.

NSHost (Новый начиная с семени в ноябре)

NSHost теперь обеспечивает метод для получения имени компьютера, как указано в «Совместном использовании» предпочтительной области.

- (NSString *)localizedName;

Это - имя, использующееся на боковой панели Средства поиска и как имя по умолчанию при публикации NSNetServices. Этот метод только возвращает NSString, когда отправлено в + [NSHost currentHost] экземпляр; все другие экземпляры в настоящее время возвращают ноль.

NSUserDefaults (новый начиная с семени в феврале)

NSUserDefaults теперь имеет методы для установки и чтения NSURLs как значения.

- (void)setURL:(NSURL *)url forKey:(NSString *)key;

- (NSURL *)URLforKey:(NSString *)key;

Когда NSURL сохранен с помощью - [NSUserDefaults setURL:forKey:], некоторые корректировки внесены:

1. Любой нефайл URL записан путем вызова + [NSKeyedArchiver archivedDataWithRootObject:] использование экземпляра NSURL как корневой объект.

2. Любой файл ссылки на файл: схема URL будет обработана как нефайл URL, и информация, делающая этот URL совместимым с 10,5 системами, будет также записана как часть архива, а также его минимальных данных закладки.

3. Любой находящийся на пути файл: если путь может быть сделан относительно корневого каталога пользователя, схема URL записана первым взятием абсолютного URL, получением пути от этого и затем определения. Если это может, строка, которая будет сокращаться при помощи stringByAbbreviatingWithTildeInPath и выписываться. Это позволяет пред10.6 клиентам читать значение по умолчанию и использование - [NSString stringByExpandingTildeInPath] для использования этой информации.

Когда NSURL читается с помощью - [NSUserDefaults URLForKey:], следующая логика используется:

1. Если значение для ключа является NSData, NSData используется в качестве параметра + [NSKeyedUnarchiver unarchiveObjectWithData:]. Если NSData может быть разархивирован как NSURL, NSURL возвращается иначе, ноль возвращается.

2, Если значение для этого ключа было ссылкой на файл URL, ссылка на файл, URL будет создаваться, но его данные закладки не будут разрешены, пока экземпляр NSURL позже не используется (например, в - [NSData initWithContentsOfURL:]).

3. Если значение для ключа будет NSString, начинающимся с ~, то NSString будет расширен с помощью - [NSString stringByExpandingTildeInPath] и файл: схема NSURL будет создаваться из этого.

Примечания о персистентности NSURL и ссылки на файл URLs

При использовании экземпляров NSURL для обращения к файлам в процессе важно сделать различие между основанным на местоположении отслеживанием (файл: схема URLs, которые являются в основном путями) по сравнению с отслеживанием идентификационных данных файловой системы (файл: схема URLs, которые являются ссылкой на файл URLs). При сохранении NSURL необходимо принять то поведение во внимание. Если Ваше приложение отслеживает ресурс, располагаемый его идентификационными данными так, чтобы можно было найти, перемещает ли пользователь файл, то необходимо явно записать данные закладки NSURL или закодировать ссылку на файл URL.

Если Вы хотите отследить файл ссылкой, но Вы требуете явного управления, когда разрешение происходит, необходимо заботиться, чтобы выписать данные закладки к NSUserDefaults, а не полагаться - [NSUserDefaults setURL:forKey:]. Это позволяет Вам вызывать + [NSURL URLByResolvingBookmarkData:options:relativeToURL:bookmarkDataIsStale:error:] в то время, когда Вы будете знать, Ваше приложение будет в состоянии обработать потенциальный I/O или требуемые взаимодействия пользовательского интерфейса.

команда значений по умолчанию

Инструмент командной строки значений по умолчанию теперь в состоянии распечатать идентификатором хоста, используемый для определенного компьютера. Этот идентификатор является строкой, использующейся для предпочтительных имен файлов в каталоге Library/Preferences/ByHost пользователя. Можно распечатать этот идентификатор при помощи следующего вызова командной строки:

    defaults printHostIdentifier

NSXMLParser (новый начиная с семени февраля 2009)

Для приложений, соединенных на или после SnowLeopard, NSXMLParser прекратит анализировать, когда это встретится с фатальной ошибкой; не останавливая приложения иногда отказывал бы вследствие противоречивого состояния синтаксического анализатора.

Приложения, соединенные на SDKs до 10,6, будут продолжать получать старое поведение. Новые приложения должны ожидать, что парсинг закончится, когда произойдет ошибка.

Новый NSCalendarUnit

Новая единица времени по календарю «четверти» (NSQuarterCalendarUnit) была добавлена к набору NSCalendarUnits (NSCalendar.h). Новая пара методов доступа (-quarter/-setQuarter:) были также добавлены к NSDateComponents.

Новые календари (Обновленный начиная с семени в ноябре)

Четыре новых календарных константы (NSRepublicOfChinaCalendar, NSPersianCalendar, NSIndianCalendar, NSISO8601Calendar) были добавлены (NSLocale.h). Календарь ISO8601 еще не реализован. Может быть создан китайский календарь, и можно сделать calendrical вычисления с ним, но он не должен использоваться для форматирования, поскольку необходимая базовая функциональность правильно еще не функционирует.

Новый метод класса NSTimeZone

Новый метод, +setAbbreviationDictionary: был добавлен (NSTimeZone.h). Это соответствует CFTimeZoneSetAbbreviationDictionary () функция в CFTimeZone API.

Осуждение метода NSConnection

+defaultConnection метод в NSConnection был осужден. Это обеспечило одноэлементный объект соединения на поток. Поскольку, что должно быть очевидными причинами, это никогда не была особенно хорошая идея использовать этот метод/соединение, если у Вас не было абсолютной уверенности, что никто больше не использовал его (или собирался использовать его), который был проблематичен. Просто используйте [[NSConnection, новый] автовыпуск] вместо этого (в сочетании со словарем потока NSTHREAD, если у Вас должен быть тот, сохраненный на поток, хотя как точка проекта, которая может вызвать Вас проблемы в будущем, таким образом, было бы лучше избежать соединения на поток).

Осуждение метода NSMutableArray

-removeObjectsFromIndices:numIndices: метод был осужден. Используйте-removeObjectsAtIndexes: вместо этого.

Осуждения метода NSDate и дополнения

-addTimeInterval: метод NSDate был осужден и заменен-dateByAddingTimeInterval: (NSDate.h). Новый метод доступен от 10,5 вперед.

Методы +dateWithTimeInterval:sinceDate: и-initWithTimeIntervalSince1970: были добавлены к NSDate (NSDate.h). Эти новые методы доступны от 10,4 вперед.

Объявления метода переместились

Объявления для включенных методов категории структуры геометрии архивации на NSCoder –encodePoint:forKey:-encodeSize:forKey:-encodeRect:forKey:-decodePointForKey:-decodeSizeForKey:-decodeRectForKey: – перемещенный от NSKeyedArchiver.h до NSGeometry.h.

Объявление для метода NSDate-descriptionWithLocale: перемещенный от категории в NSCalendarDate.h к NSDate.h.

Новые удобные методы для NSDateFormatter, NSNumberFormatter

Новый метод класса, +localizedStringFromDate:dateStyle:timeStyle: был добавлен к NSDateFormatter для создания локализованного строкового представления отформатированной даты в меньшем количестве строк кода, чем предыдущая последовательность, включающая создание NSDateFormatter.

Новый метод класса, +localizedStringFromNumber:numberStyle: был добавлен к NSNumberFormatter для создания локализованного отформатированного представления числовой строки в меньшем количестве строк кода, чем предыдущая последовательность, включающая создание NSNumberFormatter.

Приватизированные переменные экземпляра

В нескольких классах объявления переменных экземпляра были фиксированы для маркировки их частный, защищенный или пакет, где ранее полномочия были более разрешающими. Это включает классы NSIndexPath, NSMutableIndexSet, NSNotificationCenter и NSSimpleCString.

Отладка/производительность пула автовыпуска зонды DTrace добавила

Несколько точек зонда DTrace были добавлены для анализа эффективности пула автовыпуска и отлаживающий использующий сценарии DTrace:

provider Cocoa_Autorelease {

   probe pool_push(unsigned long value);    // arg is a token representing pool

   probe pool_pop_start(unsigned long value);    // arg is a token representing pool

   probe pool_pop_end(unsigned long value);    // arg is a token representing pool

   probe autorelease(unsigned long value);    // arg is object pointer

   probe error_no_pool(unsigned long value);    // arg is object pointer

   probe error_freed_object(unsigned long value);    // arg is object pointer

};

Они инициированы в том, что должно быть очевидными фактами.

NSAutoreleasePool отлаживая вспомогательные методы осужден

Эти методы в NSDebug.h в категории на NSAutoreleasePool были осуждены:

+enableFreedObjectCheck:

+enableRelease:

+resetTotalAutoreleasedObjects

+totalAutoreleasedObjects

+autoreleasedObjectCount

+topAutoreleasePoolCount

+poolCountHighWaterMark

+setPoolCountHighWaterMark:

+poolCountHighWaterResolution

+setPoolCountHighWaterResolution:

Эта функция больше не существует для установки точки останова на:

_NSAutoreleaseHighWaterLog

Больше нет никакого прямого способа сделать то, что они раньше делали.

Эти две функции точки останова были переименованы:

_NSAutoreleaseNoPool к __ NSAutoreleaseNoPool

_NSAutoreleaseFreedObject к __ NSAutoreleaseFreedObject

Системное время работы

Новый метод, +systemUptime, был добавлен к NSProcessInfo (NSProcessInfo.h). Это возвращает количество времени, система бодрствовала начиная с последнего перезапуска.

Новые системные часы изменяют уведомление (Обновленный начиная с семени в ноябре)

Новое уведомление NSSystemClockDidChangeNotification теперь доступно (NSDate.h), отправляющийся после часов с календарем изменений машины (часы, используемые NSDate, gettimeofday (), и т.д.).

NSJavaSetup.h удален

Заголовок NSJavaSetup.h был удален.

Доступность NSCondition

NSCondition в настоящее время отмечается как доступный в OS X 10.0 и позже. Однако существует ошибка в реализациях на OS X 10.0 - 10.4, который может заставить его не работать должным образом в некоторых образцах использования. Таким образом, мы будем, вероятно, отмечать его «доступный в 10,5 и позже» в некоторый момент для следующего выпуска.

Изменения NSAssertionHandler

При компиляции с C99-совместимым компилятором макрос NSAssert теперь принимает переменное число параметров (включая нуль как прежде) для описания и может использоваться вместо «числа параметра определенный» NSAssert1, NSAssert2, и т.д.

Новая константа – NSAssertionHandlerKey – был добавлен, который является ключом в словаре потока объекта-обработчика утверждения на поток.

Изменения NSObject

-forwardingTargetForSelector: метод теперь должным образом объявляется на NSObject в NSObject.h.

Новые Основанные на блоке методы перечисления набора

Были добавлены новые методы для перечисления наборов. Эти методы берут Блоки, вызывающиеся с каждым элементом в наборе (или подмножество этого). Эти методы в настоящее время не доступны ObjC ++, так как Блоки еще не доступны C++.

NSArray:      -enumerateObjectsUsingBlock:, -enumerateObjectsWithOptions:usingBlock:, -enumerateObjectsAtIndexes:options:usingBlock:

NSDictionary: -enumerateKeysAndObjectsUsingBlock:, -enumerateKeysAndObjectsWithOptions:usingBlock:

NSSet:        -enumerateObjectsUsingBlock:, -enumerateObjectsWithOptions:usingBlock:

NSIndexSet:   -enumerateIndexesUsingBlock:, -enumerateIndexesWithOptions:usingBlock:, -enumerateIndexesInRange:options:usingBlock:

Подписи типа для параметров Block:

NSArray:      void (^)(id obj, NSUInteger idx, BOOL *stop)

NSDictionary: void (^)(id key, id obj, BOOL *stop)

NSSet:        void (^)(id obj, BOOL *stop)

NSIndexSet:   void (^)(NSUInteger idx, BOOL *stop)

Параметром 'остановки' является единственный параметр, хотя не в настоящее время отмечаемый как таковой, и также, действительно, это - указатель на «энергозависимый» BOOL. Если Вы собираетесь использовать его вообще, необходимо только когда-либо устанавливать эту булевскую переменную в ДА, и в никогда нет, из Блока.

Посмотрите ниже для объяснения флагов опций.

Новые Основанные на блоке методы поиска набора

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

Эти методы возвращают индекс первого найденного соответствующего объекта:

NSArray:     -indexOfObjectPassingTest:, -indexOfObjectWithOptions:passingTest:, -indexOfObjectAtIndexes:options:passingTest:

Эти методы возвращают первое найденное соответствие индекса:

NSIndexSet:  -indexPassingTest:, -indexWithOptions:passingTest:, -indexInRange:options:passingTest:

Эти методы возвращают индексный набор всех индексов соответствующих объектов:

NSArray:     -indexesOfObjectsPassingTest:, -indexesOfObjectsWithOptions:passingTest:, -indexesOfObjectsAtIndexes:options:passingTest:

Подписи типа для параметров Block совпадают с для методов перечисления для каждого класса:

NSArray:     void (^)(id obj, NSUInteger idx, BOOL *stop)

NSIndexSet:  void (^)(NSUInteger idx, BOOL *stop)

Параметром 'остановки' является единственный параметр, хотя не в настоящее время отмечаемый как таковой, и также, действительно, это - указатель на «энергозависимый» BOOL. Если Вы собираетесь использовать его вообще, необходимо только когда-либо устанавливать эту булевскую переменную в ДА, и в никогда нет, из Блока.

Посмотрите ниже для объяснения флагов опций.

Новые Основанные на блоке методы сортировки

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

NSArray:        -sortedArrayUsingComparator:, -sortedArrayWithOptions:usingComparator:

NSMutableArray: -sortUsingComparator:, -sortWithOptions:usingComparator:

NSDictionary:   -keysSortedByValueUsingComparator:, -keysSortedByValueWithOptions:usingComparator:

Подписи типа для параметров Block являются NSComparator:

NSComparisonResult (^)(id obj1, id obj2)

Посмотрите ниже для объяснения флагов опций.

Опции на новом Основанном на блоке перечислении набора, поиске и методах сортировки

Эти опции доступны на новом Основанном на блоке перечислении набора и ищущих методах:

NSEnumerationConcurrent: вызовите Block на выбранные элементы одновременно; порядок вызова недетерминирован и не определен; этот флаг является подсказкой и может быть проигнорирован реализацией при некоторых обстоятельствах; код Блока должен быть безопасным против параллельного вызова

NSEnumerationReverse: вызовите Block на выбранные элементы в реверсе естественного порядка; доступный для NSArrays и NSIndexSets; неопределенный для NSDictionarys и NSSets, или, когда объединено с флагом NSEnumerationConcurrent

Эти опции доступны на новых Основанных на блоке методах сортировки набора:

NSSortConcurrent: вызовите Block одновременно на пар элементов, которые будут сравнены; этот флаг является подсказкой и может быть проигнорирован реализацией при некоторых обстоятельствах; код Блока должен быть безопасным против параллельного вызова

NSSortStable: используйте стабильный алгоритм сортировки, так, чтобы равные элементы остались в их исходном относительном порядке; без этого флага это не определено, будет ли алгоритм сортировки стабилен или нет

Протокол NSDiscardableContent добавил

Протокол NSDiscardableContent был добавлен к NSObject.h. Этот протокол включает Вашим объектам объявить, что их содержание может уйти в любой точке и позволяет пользователям Вашего содержания явно получать доступ к содержанию для имения в наличии его.

NSDiscardableContent-связанный метод NSObject добавил

-autoContentAccessingProxy метод был добавлен в категории на NSObject. Если получатель принимает протокол NSDiscardableContent и все еще не отбросил содержание, этот метод создает и возвращает автовыпущенный прокси для принимающего объекта. Прокси вызывает-beginContentAccess на получателе для хранения содержания доступным пока жизни прокси и вызывает-endContentAccess, когда прокси освобожден (или завершен). Интерфейсный объект является иначе подклассом NSProxy и передает сообщения к исходному объекту получателя, как NSProxy делает. Этот метод может использоваться для сокрытия энергозависимости содержания объекта NSDiscardableContent путем создания объекта, реагирующего на те же сообщения, но содержащего содержание исходного получателя, доступного пока создаваемые жизни прокси. Таким образом скрытый, объект NSDiscardableContent (посредством прокси) может быть выделен не подозревающим получателям объекта, которые иначе не знали бы, что им, возможно, придется вызвать-beginContentAccess и-endContentAccess вокруг определенных использований (определенный для каждого объекта NSDiscardableContent) объекта NSDiscardableContent.

Класс NSCache добавил

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

Не используйте NSCopyObject () (Новый начиная с WWDC 2008)

Эта функция является опасной и очень трудной использовать правильно. Это - использование в качестве части-copyWithZone: любым классом, который может быть разделен на подклассы, очень подвержено ошибкам. Эта функция, как известно, перестала работать для объектов со встроенным, сохраняют количество ivars, одиночные элементы, и C++ ivars и другие обстоятельства. Кроме того, под GC или под ObjC 2.0, зона полностью проигнорирована.

Вот реализация близко к тому, что присутствует в OS X для иллюстрирования:

id NSCopyObject(id object, NSUInteger extraBytes, NSZone *zone) {

    if (object == nil) return nil;

    id result = nil;

#if !__OBJC2__

    if (!(objc_collecting_enabled() && auto_zone_size((malloc_zone_t *)NSDefaultMallocZone(), object))) {

        if (!zone) zone = NSDefaultMallocZone();

        result = object_copyFromZone(object, extraBytes, (void *)zone);

    } else

#endif

    {   // ignore zone completely

        result = class_createInstance([object class], extraBytes);

        NSUInteger size = class_getInstanceSize([object class]) + extraBytes;

        objc_memmove_collectable(result, object, size);

    }

    return result;

}

Очевидно, objc_memmove_collectable () (по существу, memmove ()) не является правильной вещью для C++ ivars, и object_copyFromZone (), как известно, не работает на C++ ivars также. Больше предостережений при использовании NSCopyObject () может быть найдено здесь:

http://developer .apple.com/documentation/LegacyTechnologies/WebObjects/WebObjects_3.5/Reference/Frameworks/ObjC/Foundation/Protocols/NSCopying/Description.html

NSCopyObject (), вероятно, будет осужден после OS X 10.6.

NSOperation, изменения NSOperationQueue (Новый начиная с WWDC 2008)

На NSOperation существует несколько новых методов:

- (void (^)(void))completionBlock;

- (void)setCompletionBlock:(void (^)(void))block;

Можно установить Блок, который будет вызван, когда закончен NSOperation. Контекст выполнения этого Блока не определен, и Блок должен шунтировать вещи соответственно, если это или та вещь это делает потребности, которые будут сделаны в определенном контексте.

- (void)waitUntilFinished;

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

- (double)threadPriority;

- (void)setThreadPriority:(double)p;

Указывает то, чем приоритет потока должен быть при выполнении - основной. Только применяется к непараллельный (isConcurrent, возвращается НЕ), операции. Приоритет изменяется на основе максимальных усилий и не может быть гарантирован.

На NSOperationQueue существует несколько новых методов:

- (void)addOperations:(NSArray *)ops waitUntilFinished:(BOOL)wait;

Объемный сумматор, с опцией ожидания каждого все те операции закончились. Поток блокируется во время ожидания. Добавление операций с-addOperation: также намного быстрее, чем в 10,5.

- (NSUInteger)operationCount;

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

- (void)setName:(NSString *)n;

- (NSString *)name;

NSOperationQueues можно теперь назвать, и некоторые инструменты могут быть в состоянии видеть это имя.

+ (id)currentQueue;

Если выполняемый код делается так в контексте NSOperation, конечно, currentQueue является тем, выполняющим код текущей работы-. Возвращаемое значение часто является нолем.

+ (id)mainQueue;

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

Новый класс NSBlockOperation (Новый начиная с WWDC 2008)

Это - подкласс NSOperation, к которому могут быть добавлены Блоки, и объект выполнит Блоки как свою работу. Если многократные Блоки добавляются (-addExecutionBlock:), они выполняются одновременно. Когда все Блоки будут сделаны, выполняясь, работа станет Законченной. Это может быть удобным способом получить параллельное разветвление на выходе в некоторых случаях, не имея необходимость создавать многократный NSOperations.

NSOperationQueue и Параллельные Операции и «Текущий поток» в 10,5 (Новый начиная с WWDC 2009)

В попытке объяснить параллельный NSOperations в 10,5 документации, документация содержала этот комментарий: «Для параллельной работы очередь просто вызывает метод запуска объекта на текущем потоке». Некоторые люди взяли это, чтобы быть определенным поведением NSOperationQueue API, но поскольку документация не говорила или делала любую поддержку о том, каков «текущий поток» был, это не было информацией, которая можно было полезно действовать или положиться.

То, что описывала документация, было последовательностью с 4 строками как это в 10.5.x реализация NSOperationQueue:

   if ([op isConcurrent]) {

      [op start];

   } else {

      [NSThread detachNewThreadSelector:@selector(start) toTarget:op withObject:nil];

   }

и с той точки зрения документация была буквально корректна. Однако один шаг дальше вопрос становится: «на какой, поток что вызывается код?» Или точно так же, «когда вызывается тот код?» Без той информации на факт, что - к запуску «обратились текущий поток», нельзя, очевидно, и серьезно положиться для достижения любого определенного эффекта.

В 10,5 то, что фактически произошло, было то, что тот блок кода был выполнен каждый раз, когда законченный NSOperation, на любом потоке отправил уведомление isFinished KVO для той работы, к которой очередь работы будет прислушиваться и реагировать на путем запуска следующей работы. Код был также вызван в других случаях, когда было определено, что «способность существует» и «существует некоторая работа, чтобы сделать» (такой как после addOperation:) и работа для выполнения была выбрана из очереди. [Обратите внимание на то, что несмотря на то, что addOperation: на некотором потоке мог бы заставить другую работу быть выполненной, так как NSOperationQueues не являются очередями FIFO, которыми не обязательно случилось бы так, что определенная новая работа, которая будет выбрана.] Так, «текущий поток» мог быть потенциально любым потоком, включая, которые вскоре после того завершатся.

Эти комментарии и некоторый пример кода были удалены из 10,6 документации.

Основанные на хешировании изменения наборов (Новый начиная с WWDC 2008)

CoreFoundation и Основа, предоставленная платформой реализации основанных на хешировании наборов, такие как словари, изменились, как они хранят элементы, таким образом, элементы могут быть получены в различном порядке, чем в предыдущих выпусках. Порядок элементов в основанных на хешировании наборах не определен и может измениться в любое время, таким образом, разработчики никогда не должны полагаться на порядок, что элементы перечисляются или возвращаются из функции как CFDictionaryGetKeysAndValues (). Это - истина даже для случаев, где разработчик может пытаться управлять хэш-кодами объектов для достижения некоторого определенного упорядочивания.

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

Фактор максимальной нагрузки хеширования наборов теперь меняется в зависимости от размера набора, но для среднего и большого количества (скажите, более чем 100 элементов, хотя не обязательно, что определенное число), приблизительно 62% по сравнению с 75% Leopard. Другие изменения заставили наборы хеширования расти более медленно, чем ранее как сохраняющая память мера, которая может произвести более вызванные ростом перефразировки, чем в Leopard (в основном влияет на процессорное время).

NSNotificationCenter новый API (Новый начиная с семени в ноябре)

Этот метод был добавлен к NSNotificationCenter:

- (id)addObserverForName:(NSString *)name object:(id)obj queue:(NSOperationQueue *)queue usingBlock:(void (^)(NSNotification *))block;

Можно использовать его для указания блока для обработки уведомлений вместо традиционного целевого объекта и селектора. Объект действовать как наблюдатель – неуказанного типа, хотя это будет реагировать на методы в протоколе NSObject – создается для Вас и возвращается. Вы используете-removeObserver: с этим возвращенным объектом как параметр, для отмены регистрации. Система поддерживает сохранение на этом объекте (пока это не удалено). Под GC, как с наблюдателями зарегистрировал в старом addObserver:... метод, система не сохраняет ссылку на тех наблюдателей, и регистрация автоматически очищена, когда забран наблюдатель. Таким образом под GC, необходимо зависнуть - на возвращенном объекте наблюдателя где-нибудь (который, вероятно, имеет место, если Вы намереваетесь явно вызвать removeObserver: на нем), пока Вы хотите, чтобы осталась регистрация уведомления.

Этот новый API также выполняет 3 других вещи:

- нерегистрация точна; эта регистрация не страдает от неоднозначности-removeObserver:name:object: относительно которого будет удалена регистрация

- контекст выполнения обработчика уведомления может быть указан, по крайней мере до степени NSOperationQueue; если параметр очереди является ненолем, уведомление обрабатывается в контексте той очереди работы. Если параметр очереди является нолем, блок вызывается как традиционно в контексте потока регистрации.

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

Используя NSNotificationQueue, Предупреждающий (Новый начиная с WWDC 2009)

NSNotificationQueue является API и механизм, связанный с выполненными циклами (NSRunLoop) и выполнением выполненных циклов. В частности регистрация уведомлений через очередь уведомления управляется выполнением ее связанного цикла выполнения. Однако нет никакого определения для того, что выполненный циклично выполняют очередь уведомления использование, и нет никакого способа для клиента сконфигурировать это. Фактически, любую данную очередь уведомления могли бы «щекотать» в регистрацию почти любой цикл выполнения и различные в разное время (и, учитывая, что ставившие в очередь уведомления также специфичны для режима, какой режим (ы) цикл (ы) выполнения выполняет в любое любое данное время, также играют роль). Далее, несмотря на то, что каждая очередь уведомления «специфична для потока» (см. +defaultQueue документацию), никогда не было никакого отношения между тем потоком и циклом выполнения, используемым очередью уведомления. Это все более проблематично, когда все больше вещей перемещается в случай на различных и новых потоках.

Практический результат:

- Уведомления, отправленные через очередь, не могли бы быть отправлены никаким определенным «своевременным» способом;

- Уведомления, отправленные через очередь, никогда не могли бы отправляться (цикл выполнения потока, что очередь приняла решение попросить вводить его по абсолютному адресу, не мог бы быть выполнен снова; например, поток того цикла выполнения мог бы выйти и отброшенная очередь уведомления);

- Уведомления могут быть отправлены любой данной очередью на различном потоке, чем поток, очередь является очередью по умолчанию для (когда очередь является очередью по умолчанию для некоторого потока);

- Уведомления могут отправляться любой данной очередью на различных потоках в течение долгого времени;

- Нет никакого необходимого/гарантированного отношения между потоком (ами), на котором уведомления ставятся в очередь и те, на которых уведомления в конечном счете отправляются (поставленные) для любой очереди уведомления

Это - истина для всех выпусков OS X. Основа и AppKit не используют NSNotificationQueue самостоятельно, частично по этим причинам.

Параллелизм, GCD и Предостережения Цикла Выполнения (Новый начиная с семени в ноябре)

Многие Основа и AppKit APIs все еще выполняются основанные на цикле. Двумя примерами является NSTask и NSFileHandle. Этот APIs еще не имеет никакого предназначения очереди или блочного взятия завершения APIs. Для получения уведомлений завершения (например, о завершении задачи или чтении в фоновом окончании), цикл выполнения потока, запустившего асинхронную работу (например, запустил задачу или запустился, фоновое чтение) должен все еще быть выполнен, как исторически, по крайней мере пока не поставлено то уведомление.

При переключении кода на NSOperation или GCD, или в целом когда код перемещен от одного контекста выполнения, где это хорошо и удобно для другого контекста выполнения, могут быть косвенные воздействия. Конечно, при представлении параллелизма или потоков код, возможно, должен контролироваться для безопасности параллелизма и скорректирован. Если код был в зависимости от существующих данных на поток (возможно, что-то еще создало его), те данные на поток могут не существовать. Или, код, возможно, помещал источники или таймеры в цикле выполнения текущего потока, и полагался на что-то еще для выполнения цикла выполнения, который может не произойти в новой среде выполнения. Связано, но с другой стороны, если некоторый код помещал источники в текущий цикл выполнения и тот код перемещения в другом месте, текущий цикл выполнения исходного потока ничего больше может не иметь в нем, и таким образом, другой код, пытающийся выполнить тот цикл выполнения, может только закончить тем, что вращал или ничего не сделал. И конечно если бы выполнение того цикла выполнения, как предполагалось, обслуживало что-то, что заставило бы выполнение того цикла выполнения останавливаться, те условия могут больше изменяться, который может означать цикл выполнения, который рабочий цикл может не завершить и вращать навсегда.

Изменения NSIndexPath (Новый начиная с WWDC 2008)

Если бы получатель имел длину 1, в системах Предлеопарда-indexPathByRemovingLastIndex NSIndexPath возвратил бы ноль. На Leopard и более новых системах, этот метод возвратит пустой indexPath вместо этого и никогда не будет возвращать ноль.

NSAttributedString

NSAttributedString теперь имеет два метода для разрешения блоков использования перечислений.

- (void)enumerateAttributesInRange:(NSRange)enumerationRange

             options:(NSAttributedStringEnumerationOptions)opts

             usingBlock:(void (^)(NSDictionary *attrs, NSRange range, inout BOOL *stop))block;

Этот метод выполнит предоставленный блок с каждым атрибутом, выполненным в enumerationRange, передавая его словарь атрибутов и диапазон, по которому, применяются.

Диапазоны являются по умолчанию самым длинным диапазоном измерений, отсеченным к enumerationRange. Если опция NSAttributedStringEnumerationLongestEffectiveRangeNotRequired предоставляется, то самое долгое вычисление диапазона измерений не выполняется; блоки могут быть вызваны с последовательными выполнениями атрибута, имеющими то же значение.

Блок может остановить перечисление путем установки *остановка = YES; это не должно затрагивать *остановка иначе.

Если этот метод отправляется в экземпляр NSMutableAttributedString, мутация (удаление, дополнение или изменение) позволяется, пока это в диапазоне, предоставленном для блока; после мутации перечисление сразу продолжает диапазон после обработанного диапазона, после того, как длина обработанного диапазона будет приведена в соответствие с мутацией. (Перечислитель в основном предполагает, что любое изменение в длине происходит в указанном диапазоне.), Например, если блок вызывают с диапазоном, запускающимся в расположении N, и блок удаляет все символы в предоставленном диапазоне, следующий вызов также передаст N как индекс диапазона.

- (void)enumerateAttribute:(NSString *)attrName

             inRange:(NSRange)enumerationRange

             options:(NSAttributedStringEnumerationOptions)opts

             usingBlock:(void (^)(id value, NSRange range, inout BOOL *stop))block;

Этот метод подобен вышеупомянутому, но перечисление имеет место на единственном атрибуте.

NSString (Обновленный начиная с семени в ноябре)

NSString теперь имеет API для перечисления множества блоков использования типов подстроки:

- (void)enumerateSubstringsInRange:(NSRange)range

        options:(NSStringEnumerationOptions)options

        usingBlock:(void (^)(NSString *substring, NSRange substringRange, NSRange enclosingRange, BOOL *stop))block;

Этот метод перечисляет подстроки указанного типа (строки, слова, предложения, и т.д.) в указанном диапазоне получателя.

Параметр опций указывает тип подстроки для перечисления, а также следующее:

NSStringEnumerationSubstringNotRequired может использоваться в качестве способа указать, что блоку не нужна подстрока, когда будет передан ноль. Это - просто ярлык производительности.

NSStringEnumerationReverse заставляет перечисление происходить от конца указанного диапазона к запуску.

NSStringEnumerationLocalized заставляет перечисление происходить с помощью локали пользователя по умолчанию. Это никогда не будет иметь значения в строке, абзаце, или составленном перечислении последовательности символов, но этом май для слов или предложений.

В блоке, выполняющемся, подстрока является перечислимой строкой, substringRange является диапазоном перечислимой строки в получателе, и enclosingRange является диапазоном, включающим следующие подстроку, а также любые символы разделителя/заполнителя.

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

Блок может остановить перечисление путем установки *остановка = YES; это не должно затрагивать *остановка иначе.

Если этот метод отправляется в экземпляр NSMutableString, мутация (удаление, дополнение или изменение) позволяется, пока это в enclosingRange. После мутации перечисление сразу продолжает диапазон после обработанного диапазона, после того, как длина обработанного диапазона будет приведена в соответствие с мутацией. (Перечислитель в основном предполагает, что любое изменение в длине происходит в указанном диапазоне.) Например, если блок вызовут с диапазоном, запускающимся в расположении N, и блок удаляет все символы в предоставленном диапазоне, то следующий вызов также передаст N как индекс диапазона. Обратите внимание на то, что дело обстоит так, даже если бы мутация предыдущего диапазона изменяет строку таким способом, которым следующая подстрока расширилась бы для включения уже перечислимого диапазона. (Например, если строка «Привет Мир» будет перечислен через слова и блочные изменения «Привет» в «Привет», таким образом формируя «HelloWorld», то следующее перечисление возвратит «Мир», а не «HelloWorld».

Этот следующий метод является удобным методом перечислить все строки в строке. Переданный в строке содержит просто содержание строки без разделителей строки:

- (void)enumerateLinesUsingBlock:(void (^)(NSString *line, BOOL *stop))block;

С 2009 WWDC реализованы слово и перечисление предложения, но перечисление слова еще не корректно на японском, китайском языке и тайском языке.

NSString (новый начиная с WWDC2008)

NSString имеет набор удобных методов для сравнения, но ни один не соответствует непосредственно способу, которым имена файлов сортируются в системе Средством поиска или открытой панелью. Это сравнение возможно в Leopard с:

return [str compare:otherStr

       options:NSCaseInsensitiveSearch|NSNumericSearch|NSWidthInsensitiveSearch|NSForcedOrderingSearch

      range:NSMakeRange(0, [str length])

      locale:[NSLocale currentLocale]];

но SnowLeopard добавляет новый API для этого:

- (NSComparisonResult)localizedStandardCompare:(NSString *)string;

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

Методы lengthOfBytesUsingEncoding: и maximumLengthOfBytesUsingEncoding: теперь возвратитесь 0, если бы объем памяти, требуемый для хранения результатов преобразования кодирования, превысил бы NSIntegerMax. Обратите внимание на то, что прежний уже возвратился бы 0 для любых ошибок преобразования.

Методы substringWithRange: getLineStart:end:contentsEnd:forRange: rangeOfString: rangeOfCharacterFromSet: и варианты (более специализированные формы) теперь обнаружат все недопустимые диапазоны (включая тех с отрицательными длинами). Для приложений, соединенных против SnowLeopard, эта ошибка вызовет исключение; для приложений, соединенных против более ранних выпусков, эта ошибка вызывает предупреждение, выведенное на экран только один раз на выполнение приложений.

Методы-UTF8String и cStringUsingEncoding: теперь объявляются как __ сильным, что означает, что они возвращают указатели, которые безопасно иметь в наличии при выполнении со сборкой «мусора».

APIs основы, берущий параметры формата строки (APIs, такие как initWithFormat: NSLog (), и т.д.), теперь украшены атрибутами, позволяющими компилятору генерировать предупреждения на потенциально небезопасных использованиях. Это в настоящее время включает использование, такое как:

NSString *str = ...;

NSString *formattedStr = [[NSString alloc] initWithFormat:str];

где формат не является константой и нет никаких параметров. В случае как вышеупомянутый, вызов к initWithFormat: является ненужным, так чтобы избежать предупреждений, просто отбросить вызов. В случае как NSLog (str), можно вместо этого использовать NSLog («%», str).

NSData (новый начиная с WWDC2008)

Следующие перечислимые значения были переименованы как показано:

    NSMappedRead   -> NSDataReadingMapped

    NSUncachedRead -> NSDataReadingUncached

    NSAtomicWrite  -> NSDataWritingAtomic

Старые названия все еще доступны, но осуждены и будут удалены в будущем выпуске.

NSError

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

NSString *const NSHelpAnchorErrorKey;

- (NSString *)helpAnchor;

Если - [NSError helpAnchor] возвращает ненулевое значение для ошибки, будучи используемым с + [NSAlert alertWithError:], предупредительная панель будет включать кнопку привязки справки с тем значением. Различный presentError: варианты в наборе проходят через метод NSAlert и таким образом автоматически генерируют кнопку справки.

Простой способ получить набор значений для-helpAnchor состоит в том, чтобы указать его как значение NSHelpAnchorErrorKey в userInfo словаре NSERROR; или метод может быть переопределен.

Несмотря на то, что эта функциональность разглашена в 10,6, это - доступная спина к 10,4.

Мы также добавили новый код ошибки, NSFileWriteVolumeReadOnlyError, для представления ошибки при попытке записать в объем только для чтения.

Сообщения об ошибках для ошибок проверки в NSNumberFormatter были улучшены; вместо того, чтобы «Форматировать ошибку» сообщения теперь попытаются указать недопустимое значение и причину отказа проверки. Обратите внимание на то, что NSNumberFormatter использует NSFormattingError для указания ошибок проверки; на данный момент это значение немного, к сожалению, называют, и это могло адресоваться в будущем.

Примечание предупреждений NSComparator (Новый начиная с семени в ноябре)

В попытке использовать блоки NSComparator как так:

  [myArray sortUsingComparator:^(id obj1, id obj2) {

      return ([obj1 doubleValue] < [obj2 doubleValue]) ? NSOrderedAscending : NSOrderedDescending;

   }];

Можно получить ошибку от компилятора:

  error: incompatible block pointer types initializing ‘int (^)(struct objc_object *, struct objc_object *)’, expected ‘NSComparator’

Это вызвано тем, что блок думает, что его возвращаемое значение является интервалом. Одно решение состоит в том, чтобы бросить возвращаемые значения:

  [myArray sortUsingComparator:^(id obj1, id obj2) {

      return ([obj1 doubleValue] < [obj2 doubleValue]) ? (NSComparisonResult)NSOrderedAscending : (NSComparisonResult)NSOrderedDescending;

   }];

Лучшее решение состоит в том, чтобы объявить блок как возврат NSComparisonResult:

  [myArray sortUsingComparator:^NSComparisonResult(id obj1, id obj2) {

      return ([obj1 doubleValue] < [obj2 doubleValue]) ? NSOrderedAscending : NSOrderedDescending;

   }];

Сравнения набора с isEqual: по сравнению с isEqualTo <набор>:

В Leopard и более ранних выпусках, isEqual: и isEqualToArray: (или Словарь/Набор), прошел через различные пути выполнения кода, которые могли иногда давать различные результаты. В SnowLeopard, в приложениях соединился против SnowLeopard, isEqual: теперь проходит через соответствующий isEqualTo... методы для трех типов набора. Это должно заставить эти методы давать непротиворечивые результаты. Одно примечательное изменение здесь - то, что эти два числа [NSNumber numberWithInteger:1] и [NSNumber numberWithBool:YES] (или числа, создаваемые с 0 и НЕ), теперь выдержат сравнение равный, когда в наборах (точно так же, как они делают при сравнении с - [NSNumber isEqual:]).

Основа API, не доступный в iPhone OS 2.0

OS X APIs в этих заголовках не доступен в iPhone OS 2.0:

NSAffineTransform.h, NSAppleEventDescriptor.h, NSAppleEventManager.h, NSAppleScript.h, NSArchiver.h, NSAttributedString.h, NSCache.h, NSCalendarDate.h, NSClassDescription.h, NSComparisonPredicate.h, NSCompoundPredicate.h, NSConnection.h, NSDistantObject.h, NSDistributedLock.h, NSDistributedNotificationCenter.h, NSExpression.h, NSGarbageCollector.h, NSGeometry.h, NSHFSFileTypes.h, NSHashTable.h, NSHost.h, NSMapTable.h, NSMetadata.h, NSObjectScripting.h, NSPointerArray.h, NSPointerFunctions.h, NSPortCoder.h, NSPortMessage.h, NSPortNameServer.h, NSPredicate.h, NSProtocolChecker.h, NSScriptClassDescription.h, NSScriptCoercionHandler.h, NSScriptCommand.h, NSScriptCommandDescription.h, NSScriptExecutionContext.h, NSScriptKeyValueCoding.h, NSScriptObjectSpecifiers.h, NSScriptStandardSuiteCommands.h, NSScriptSuiteRegistry.h, NSScriptWhoseTests.h, NSSpellServer.h, NSTask.h, NSURLDownload.h, NSURLHandle.h, NSUndoManager.h, NSValueTransformer.h, NSXMLDTD.h, NSXMLDTDNode.h, NSXMLDocument.h, NSXMLElement.h, NSXMLNode.h, NSXMLNodeOptions.h

Различный другой APIs, или связанный с (или используют типы, определенные) вышеупомянутое, или которые осуждаются с 10,5, также недоступен.

Кроме того, этот APIs в доступных заголовках не доступен:

- Связанное со сборщиком «мусора» выделение APIs (NSAllocateCollectable (), NSReallocateCollectable (), и их флаги опции) в NSZone.h

- NSCoder-encodePropertyList: и методы-decodePropertyList (просто используют-encodeObject: и-decodeObject)

- 10,0 поведений специфичные методы на NSDateFormatter и NSNumberFormatter

Иначе, iPhone OS 2.0 содержит Основу API, соответствующий это в OS X 10.5.

Основа API, не доступный в iPhone OS 3.0

OS X APIs в этих заголовках не доступен в iPhone OS 3.0:

NSAffineTransform.h, NSAppleEventDescriptor.h, NSAppleEventManager.h, NSAppleScript.h, NSArchiver.h, NSAttributedString.h, NSCache.h, NSCalendarDate.h, NSClassDescription.h, NSConnection.h, NSDistantObject.h, NSDistributedLock.h, NSDistributedNotificationCenter.h, NSGarbageCollector.h, NSGeometry.h, NSHFSFileTypes.h, NSHashTable.h, NSHost.h, NSMapTable.h, NSMetadata.h, NSObjectScripting.h, NSPointerArray.h, NSPointerFunctions.h, NSPortCoder.h, NSPortMessage.h, NSPortNameServer.h, NSProtocolChecker.h, NSScriptClassDescription.h, NSScriptCoercionHandler.h, NSScriptCommand.h, NSScriptCommandDescription.h, NSScriptExecutionContext.h, NSScriptKeyValueCoding.h, NSScriptObjectSpecifiers.h, NSScriptStandardSuiteCommands.h, NSScriptSuiteRegistry.h, NSScriptWhoseTests.h, NSSpellServer.h, NSTask.h, NSURLDownload.h, NSURLHandle.h, NSXMLDTD.h, NSXMLDTDNode.h, NSXMLDocument.h, NSXMLElement.h, NSXMLNode.h, NSXMLNodeOptions.h

Различный другой APIs, или связанный с (или используют типы, определенные) вышеупомянутое, или которые осуждаются с 10,5, также недоступен.

Кроме того, этот APIs в доступных заголовках не доступен:

- Связанное со сборщиком «мусора» выделение APIs (NSAllocateCollectable (), NSReallocateCollectable (), и их флаги опции) в NSZone.h

- NSCoder-encodePropertyList: и методы-decodePropertyList (просто используют-encodeObject: и-decodeObject)

- 10,0 поведений специфичные методы на NSDateFormatter и NSNumberFormatter

Иначе, iPhone OS 3.0 содержит Основу API, соответствующий это в OS X 10.5.

64 бита

Leopard содержит 64-разрядные версии системных платформ, включая создание и выполнение многих приложений Какао как 64-разрядные.

Существует значительное количество изменений API в Какао, чтобы разместить и включить 64-разрядный. Большинство вследствие введения двух новых типов, NSInteger и NSUInteger, как способ представлять целые числа «размера адреса» и на 32 и на 64-разрядный. NSInteger определяется как «интервал» на 32-разрядном и «длинное» на 64-разрядном, и NSUInteger является своим дубликатом без знака. Почти весь Основанный на какао APIs был обновлен для использования NSInteger или NSUInteger вместо международного или интервала без знака. NSInteger походит на тип CFIndex CoreFoundation.

(Обратите внимание на то, что рано в Leopard, NSInteger и NSUInteger назвали NSInt и NSUInt, соответственно. Эти старые названия были удалены перед заключительным выпуском Leopard.)

Продвижение, приложения должны использовать эти новые типы (и CGFloat - видят ниже) вместо интервала, интервала без знака и плавания, так как это сделает возможное перемещение к 64-разрядному намного проще. Мы рекомендуем это даже для приложений, которые должны работать на Тайгере; они могут выполнить это со своими собственными, определениями Только для тигра этих типов.

У нас есть «вершины» - базируемый сценарий преобразования в/Developer/Extras/64BitConversion, чтобы помочь преобразовать приложения Какао в 64-разрядный. Информация об этом сценарии и Какао 64-разрядное усилие в целом может быть найдена в 64-разрядном Руководстве по Переходу для Какао.

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

#if __LP64__

...

#endif

как способ сделать 64-разрядный определенный код.

В APIs, где термин «интервал» появился как часть имени метода (например, «intValue»), термин «целое число» используется для представления этого нового типа NSInteger, в то время как «интервал» продолжает относиться к собственному международному типу (который является 32-разрядным и под 32 и под 64). Таким образом методы как intValue, numberWithInt: scanInt: и т.д. продолжайте брать или возвращать ints, в то время как методы, такие как integerForKey: в NSUserDefaults были изменены для взятия NSInteger. Мы добавляем много методов дубликата в Основе и AppKit, берущих или возвращающих параметры NSInteger или NSUInteger.

Новые методы в Основе:

NSCoder:

 - (void)encodeInteger:(NSInteger)intv forKey:(NSString *)key;

 - (NSInteger)decodeIntegerForKey:(NSString *)key;

NSString:

 - (NSInteger)integerValue;

NSScanner:

 - (BOOL)scanInteger:(NSInteger *)ptr;

NSNumber:

 - (NSInteger)integerValue;

 - (NSUInteger)unsignedIntegerValue;

 - (id)initWithInteger:(NSInteger)value;

 - (id)initWithUnsignedInteger:(NSUInteger)value;

 + (NSNumber *)numberWithInteger:(NSInteger)value;

 + (NSNumber *)numberWithUnsignedInteger:(NSUInteger)value;

У нас также есть следующие новые константы в NSObjCRuntime.h:

 #define NSIntegerMax   LONG_MAX

 #define NSIntegerMin   LONG_MIN

 #define NSUIntegerMax  ULONG_MAX

Обратите внимание на то, что проектом, обработка включенной архивации целочисленных типов не строга. Целочисленное количество, записанное с любым из encodeInteger:forKey: encodeInt32:forKey: или encodeInt64:forKey: может быть считан назад с помощью любого из целочисленных методов декодирования. Если значение является слишком большим для чтения использования указанного метода декодирования, исключение повышено.

Для большинства интегральных значений мы рекомендуем использование encodeInteger:forKey: и decodeIntegerForKey:. Для значений, диапазоны которых больше, чем, что 32-разрядные целые числа со знаком могут содержать, Int64: варианты продолжают быть более надлежащим выбором, даже на 32-разрядном.

Существует дополнительная архивация и другие соображения в присутствии 64-разрядных изменений в нашем APIs. 64-разрядное вышеуказанное Руководство по Переходу имеет больше информации об этой теме и больше.

CGFloat

Другое существенное изменение в Какао APIs является введением типа CGFloat в Кварце. Это заменяет использование плавания и определяется как дважды для 64-разрядного. Обратите внимание на то, что это не изменение, продиктованное 64-разрядным перемещением; однако, мы используем в своих интересах перемещение для представления этого нового типа. Цель CGFloat состоит в том, чтобы обеспечить более высокую точность и диапазон в графических значениях для 64-разрядных приложений. Этот тип заменяет использование всех графических типов плавающих в Какао APIs, включая тех в NSGeometry.h Основы.

Другое изменение в NSGeometry.h является redeclaration NSRect, NSPoint и NSSize использование Кварцевых дубликатов, CGRect, CGPoint и CGSize. К сожалению, вследствие соображений совместимости на уровне двоичных кодов, это изменение сделано для 64-разрядного только. Обратите внимание на то, что подписи типа Objective C этих типов таким образом расходятся в 64-разрядном от этого на 32 битах.

Перечислимое удаление имени

Как часть 64-разрядной очистки, мы добавили явно измеренные типы, где мы ранее использовали перечисления. Например, мы пошли от:

typedef enum NSAlertStyle {

    NSWarningAlertStyle = 0,

    NSInformationalAlertStyle = 1,

    NSCriticalAlertStyle = 2

} NSAlertStyle;

к

enum {

    NSWarningAlertStyle = 0,

    NSInformationalAlertStyle = 1,

    NSCriticalAlertStyle = 2

};

typedef NSUInteger NSAlertStyle;

Последний удостоверяется, что NSAlertStyle остается фиксированным размером и со знаком независимо от того, как изменяется перечислимое содержание.

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

Быстрое перечисление

Leopard представляет протокол NSFastEnumeration, позволяющий быстрый, надежный метод для объектов обеспечить объектные перечисления:

@protocol NSFastEnumeration

- (NSUInteger)countByEnumeratingWithState:(NSFastEnumerationState *)state

                                  objects:(id *)stackbuf

                                    count:(NSUInteger)len;

@end

typedef struct {

    unsigned long state;

    id *itemsPtr;

    unsigned long *mutationsPtr;

    unsigned long extra[5];

} NSFastEnumerationState;

Этот протокол реализован наборами Основы, а также NSEnumerator, и используется новым языком «для... в» функции перечисления:

for (id myObj in myArray) { ... do something with myObj ... }

Мутация объекта запрещается во время итерации, и может быть несколько итераций, выполняющихся одновременно.

Соблюдающим правилам должна повиноваться любая реализация:

1. На первой записи поле «состояния» будет 0, иначе клиенту ни не разрешают или требуют изменить состояние. Состояние должно быть установлено в ненулевое прежде, чем возвратить ненулевое количество (иначе, клиент войдет в бесконечный цикл, ожидая нулевой возврат, и объект будет всегда запускать новое перечисление). Для сложных «дополнительных» перечислений предоставляется для содержания дополнительного состояния.

2. На выходе, количестве 0 средних значений, что нет никаких объектов, доступных для перечисления. Это может отразить плохое или противоречивое внутреннее состояние, или более обычно оно может просто отразить, что больше объектов не доступно. Но если значение является нулем, клиент не может сделать предположения о содержании состояния.

3. Ненулевой возврат количества подразумевает, что itemsPtr был установлен указать на первый из ненулевых объектов количества. Это призвано быть указателем на внутреннее объектное состояние, где выполнимо. Если не выполнимый, клиент предоставил буфер штабеля в «объектах» и длине в параметре «количества», и объектные указатели, которые будут выполнены с помощью итераций, должны быть скопированы там (никакие требуемые примитивы GC). Кроме того, mutationsPtr установлен в допустимый адрес, который должен отследить некоторую форму счетчика изменения для этого объекта. Если объект является неизменным, этот указатель мог бы указать на сам объект.

Этот протокол разработан для работы, когда отправлено в нулевые объекты.

Предупреждение о мутациях во время перечислений

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

Для приложений, соединенных на Leopard, когда мутация будет обнаружена во время перечисления, будет брошен NSInvalidArgumentException:

2006-05-23 13:46:08.945 MyTestApp[756] *** Uncaught exception: <NSInvalidArgumentException>

                                       Collection <NSCFArray: 0x303d70> was mutated while being enumerated.

Сборка «мусора»

В Leopard теперь возможно записать собранные «мусор» приложения Какао. Разработчики приложений выбирают (в XCode, или через флаги компилятора), хотят ли они, чтобы их приложения работали, собрал «мусор» или нет. Системные платформы разработаны для работы и с собрали «мусор» и несобрали «мусор» приложения. Обратите внимание на то, что все двоичные файлы (пакеты, платформы, плагины) загруженный собравшим «мусор» приложением также должны быть собраны «мусор», иначе они не загружаются.

См. документация разработчика для большего количества подробных данных о сборке «мусора».

Основа включает новый класс, NSGarbageCollector, обеспечивающий значение по умолчанию, совместно использовал экземпляр, который может быть передан для управления поведением сборки «мусора».

NSMapTable, NSHashTable

NSMapTable и NSHashTable теперь доступны как объекты. Они обычно применимы, но особенно полезны в собравших «мусор» приложениях. Существующий функциональный API продолжает работать также.

Как объекты, эти классы обеспечивают новый APIs для доступа к ним, как будто они всегда и только содержат объекты. Мы также предоставляем общие и интересные возможности для конструкции - создаваться с опцией скопировать в ее параметрах, обработать объекты как указатели относительно хеширования и равенства и опции содержать их несохраненным обнуляющим слабым способом. Они, и особенно последний, являются преобладающим использованием, поднявшимся, поскольку код был преобразован, чтобы быть совместимым с GC.

Обратите внимание на то, что, как раз когда объекты, NSMapTable и NSHashTable отличны от NSDictionary и NSSet, имеющих строгие семантические определения, на которые полагается много кода. NSMapTable и NSHashTable не являются типами plist.

NSMapTable и NSHashTable соответствуют NSFastEnumeration, как другие наборы.

Исключения

Служебные нулем исключения в 64-разрядном

В 64-разрядном Objective C использует ту же технологию в качестве C++ для реализации броска исключения, делающего стоимость из ввода блочного падения @try к нулю, и стоимость повышения исключения намного выше.

Новый API NSException

Класс NSException теперь предлагает этот новый API:

- (NSArray *)callStackReturnAddresses;

Этот метод возвращает массив NSNumbers с обратными адресами от штабеля потока, с первыми значениями в массиве, являющемся от самых низких кадров на штабеле, в это время и на потоке, на котором было сначала повышено исключение. Переповышение исключения не сбрасывает это значение. Нет никакого способа установить это значение.

Изменения макроса NSException

_NSSETJMP макрос больше не определяется. Это не было для Вашего использования.

NSHandler и NSHandler2 и структура _NSHandler2 типы больше не определяются. Они не были для Вашего использования.

_NSAddHandler2, _NSRemoveHandler2, и функции _NSExceptionObjectFromHandler2 больше не объявляются. Они не были для Вашего использования.

NS_DURING, NS_HANDLER и макросы NS_ENDHANDLER были переопределены с точки зрения @try / синтаксис Objective C выгоды. NS_VALUERETURN и макросы NS_VOIDRETURN были обновлены для соответствия.

Бросок объектов кроме NSExceptions в приложениях Какао

Не бросайте объекты кроме NSExceptions (или, возможно, подкласс этого) в приложениях Какао. Если исключение замечено кодом Какао, выполнение так является рецептом для потенциального бедствия. Просто не делайте этого. Код какао может также полностью и тихо раздавить любой нетип объекта, и возможно любой non-NSException * тип, исключения, добирающиеся до кода Какао.

Установка точки останова для ловли повышений исключения

Для захвата исключений, бросаемых в отладчик, повредитесь на objc_exception_throw. Это поймает весь бросок исключения в 32-разрядном и 64-разрядном, и было ли исключение выдано с @throw или брошено с - [Повышение NSException]. Установка точки останова на последнем никогда не имеет броска перехваченной исключительной ситуации вследствие @throw.

Исключения, пойманные от внешних обратных вызовов больше, не отбрасываются

В то время как...» или «Исключение повысило во время, основа раньше ловила исключения в определенных местах и не повторно повышала их, просто регистрировала сообщение как «Исключение, проигнорированное... Проигнорированный....». Для приложений, соединенных на 10,5 и позже, Основа больше не делает это, она просто позволяет исключению пройти через те точки.

Обратите внимание на то, что разрешение исключению сбежать из кода приложения копирует в системный код платформы/библиотеки (Какао или код некакао) в непредсказуемом inheritently. C код, например, не может реагировать на исключения, повышаемые через кадр активации языка C на штабеле, частично потому что синтаксис не доступен и частично потому что исключения не являются частью языка, таким образом, не должно быть никакой потребности в коде C для знания об исключениях. Так, структуры данных, блокировки и другие вещи можно оставить в непредсказуемом/противоречивом состоянии, и память или другие ресурсы протекли. Даже существующий код Objective C не обязательно устойчив в этих отношениях. Это совершенно возможно - так же, как один пример, который не является катастрофическим отказом - что повышенное исключение заставит приложение UI замерзнуть и быть абсолютно безразличным после исключения, что означает, что пользователь не будет в состоянии сохранить любые документы или другие несохраненные изменения.

NSOperation, NSOperationQueue

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

NSOperations не должен быть помещен в NSOperationQueues, который будет выполняться - они могут быть выполнены в любое время, и NSOperations, разработанные, поскольку «активные» объекты могут фактически запустить себя, когда существуют надлежащие условия.

NSOperation имеет управление зависимостью; работа не готова быть выполненной, пока все другие операции в его списке зависимости не закончены.

NSOperation обеспечивает методы, чтобы позволить объявить, может ли он быть выполнен асинхронно; NSOperationQueue поочередно обеспечивает методы для указания сколько параллельных операций для разрешения. Эти функции делают NSOperation/NSOperationQueue подходящим вариантом для указания инкапсулированных задач в пути, который использует в своих интересах многопроцессорные машины.

См. документация для получения дополнительной информации о NSOperation и NSOperationQueue.

NSThread

NSThread теперь позволяет определить имя. Основная цель этого метода отлаживает:

- (void)setName:(NSString *)n;

- (NSString *)name;

Теперь можно указать размер штабеля для потока. Этому повинуются, если это установило только, прежде чем поток был запущен. Базовая операционная система может наложить ограничения на значение:

- (void)setStackSize:(NSUInteger)s;

- (NSUInteger)stackSize;

Следующие методы позволяют узнать об основном потоке:

- (BOOL)isMainThread;

+ (BOOL)isMainThread; // reports whether current thread is main

+ (NSThread *)mainThread;

NSThread теперь имеет init методы для включения создания без запуска:

- (id)init;    // designated initializer

- (id)initWithTarget:(id)target selector:(SEL)selector object:(id)argument;

Если целевой объект не реализует селектор,-initWithTarget:selector:object: метод возвращает ноль. Целевой объект и параметр сохраняются для жизни NSThread.

Следующие методы включают больше управления выполнением NSThread:

- (BOOL)isExecuting;

- (BOOL)isFinished;

- (BOOL)isCancelled;

- (void)cancel;

- (void)start;

- (void)main;    // thread body method

- запускаются, метод создает базовый объект потока и запускает его выполнение; это может перестать работать вследствие достигаемых пределов ресурса OS или ранее отменяемый поток. - запускают причины - основной, чтобы быть вызванным в контексте нового потока. Поведение по умолчанию - основной ничего не состоит в том, чтобы сделать, если бы поток не был инициализирован с целью/селектором/параметром, иначе это вызывает метод на цель. Подкласс NSThread может переопределить - основной для выполнения безотносительно работы, которую поток, как предполагается, выполняет (аналогичный функции потока, данной pthread_create ()).

- запускаются, метод является тем, который должны вызвать клиенты NSThread для запуска выполнения потока; - основной не должен быть вызван извне объекта потока.

Выполнение pthread имеет логическое, сохраняют на объекте потока, как только - запускаются, был вызван. То, когда поток управления потока завершается, поддержка pthread уничтожается, но объект NSThread может продолжать существовать, если там дополнительны, сохраняет.

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

Состояние «отмены» является консультацией: это состояние может быть опрошено кодом, чтобы узнать, должно ли это остановить то, что это делает, но это не вызывает остановку всегда. Это не то же как pthread отмена. 'Отмененный' одностороннее изменение состояния, Вы не можете задержать объект операции к «неотмененному». Код, выполняемый работой, может завершить выполнение, заставив поток управления выйти - основной метод (путем возврата из того метода или повышения исключения из того метода). Поскольку отмененное состояние является консультацией, это ортогонально к «выполнению» и «законченным» состояниям.

Следующее является немного менее дорогой версией +sleepUntilDate: метод, так как объект NSDate не должен быть создан. Несмотря на то, что это было просто разглашено, это было в Основе с тех пор 10.0 и может использоваться в более старых системах:

+ (void)sleepForTimeInterval:(NSTimeInterval)ti;

Следующий новый метод на NSObject позволяет выполниться в контексте определенного NSThread:

- (void)performSelector:(SEL)aSelector

               onThread:(NSThread *)thr

             withObject:(id)arg

          waitUntilDone:(BOOL)wait

                  modes:(NSArray *)array;

Существует также версия без режимов: параметр, который эквивалентен вышеупомянутому методу, вызванному с kCFRunLoopCommonModes.

Именование соответствует существующему performSelectorOnMainThread:... методы, становящиеся особым случаем этих методов. Эти новые методы имеют ту же семантику как существующий performSelectorOnMainThread:... методы, за исключением того, что может быть указан определенный объект NSThread.

Наконец следующий метод является удобством к encapulate процесс создания нового потока для выполнения данного метода. Никакой параметр 'режимов' не необходим, поскольку цикл выполнения не включается здесь. Семантически подобный другим существующим методам performSelector-стиля.

- (void)performSelectorInBackground:(SEL)aSelector withObject:(id)arg;

Другой новый метод в NSThread:

+ (NSArray *)callStackReturnAddresses;

Этот метод возвращает массив NSNumbers с обратными адресами от штабеля текущего потока, с первыми значениями в массиве, являющемся от самых низких кадров на штабеле, во время вызова к этому методу.

NSProcessInfo

NSProcessInfo теперь представляет новый метод для возврата суммы физической памяти, установленной в компьютере.

- (unsigned long long)physicalMemory;

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

Следующие новые методы возвращают число процессоров, а также число активных процессоров в машине:

- (NSUInteger)processorCount;

- (NSUInteger)activeProcessorCount;

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

NSCondition

NSCondition является новым классом в Основе. NSCondition является условной переменной pthread-стиля, объединенной со связанной взаимоисключающей блокировкой. NSCondition работает точно так же, как pthread_conds с теми же образцами использования и потенциальными ловушками.

Существующий класс NSConditionLock является более ограниченной версией этого. NSConditionLock определяет только целочисленное состояние, против которого тестирует тест условия. Так, NSCondition, позволяя, в то время как тест предиката, который будет перемещен вне объекта, допускает большую гибкость вне простого целочисленного равенства.

Образец использования - почти всегда это:

[cond lock];

while (TEST) {

    [cond wait];

}

...

[cond signal]; // or broadcast

[cond unlock];

NSCondition уже существовал в Основе и имеет прежде 10.0. Таким образом, это может использоваться в более старых операционных системах.

Журналирование NSLock

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

2006-07-14 09:17:00.729 MyTestApp *** -[NSConditionLock unlockWithCondition:]: lock (<NSConditionLock: 0x183b3800>)

                        unlocked when not locked

2006-07-14 09:17:00.729 MyTestApp *** Break on _NSLockError() to debug.

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

Именование NSLock

NSLock, NSRecursiveLock, NSConditionLock и объекты NSCondition можно теперь назвать с двумя новыми методами в каждом классе:

- (void)setName:(NSString *)n;

- (NSString *)name;

Имя испускается в NSLogs об объектах и в их описаниях.

Распределенные объекты

Распределенные Объекты и 64 бита

В среде распределенных объектов до Leopard сигнатуры методов локальных и удаленных объектов, как предполагалось, были тем же; если бы они отличались, то исключение было бы выдано. С введением Основы на 64 бита могут отличаться подписи. Например, сервер написания на 32 бита, связывающийся с текстовым редактором на 64 бита, приведет к различным типам NSRange - сервер будет полагать, что он структура двух 32 битов ints, и клиент будет полагать, что он структура двух 64 битов longs.

Для обеспечения коммуникации DO между этими процессами требование равенства подписи DO было ослаблено к сигнатуре метода «совместимость». Если тип каждого параметра (и возвращаемое значение) в подписи может быть преобразован в соответствующий тип в другой подписи, два сигнатур методов совместимы. Преобразования в (но не между) следующие группы позволяются:

• int, long, long long

• unsigned int, unsigned long, unsigned long long

• float, double

Если их элементы совместимы, рекурсивно, составные типы, такие как структуры совместимы. Например, плавание может быть преобразовано в или от двойного, и поэтому NSPoints и NSSizes могут быть переданы между процессами на 64 бита и на 32 бита, потому что они составлены из плаваний, и удваивается, и поэтому NSRects может быть передан также, потому что они составлены из NSPoints и NSSizes.

Распределенное переполнение Объектов и поведение потери значимости

Если преобразование привело бы к из значения диапазона, результат установлен в самое близкое значение, поддерживаемое тем типом. Например, если значение целого числа со знаком на 64 бита 5000000000 (пять миллиардов) будет передано через DO объекту, ожидая значение целого числа со знаком на 32 бита, то оно получит значение INT_MAX. Возможные результаты целочисленного переполнения или потери значимости поэтому:

INT_MAX

INT_MIN

UINT_MAX

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

FLT_MAX

-FLT_MAX

0.f

-0.f

Знайте, что это поведение может не сохранить семантику определенных специальных значений. Например, - [NSArray indexOfObject:] обратился к процессу на 64 бита, возвратит UINT_MAX процессу на 32 бита вместо 32 битовых значений NSNotFound.

Если переполнение или потеря значимости происходят для какого-либо типа, сообщение регистрируется сервером к консоли.

Распределенные Объекты локальная подпись ищут последовательность

Когда метод, который будет передан, вызывают на NSDistantObject, объектной информации о потребностях о том, как метод вызвали для надлежащего построения NSInvocation - в частности, этому нужен NSMethodSignature, соответствующий сигнатуре метода, которую использовал компилятор. NSDistantObject ищет сигнатуру метода в следующих местах в порядке:

• В наборе Протокола на NSDistantObject через setProtocolForProxy:

• В локальном классе того же имени как класс удаленного объекта

• В удаленном объекте

Поэтому, если вызов, возможно, был скомпилирован против различной сигнатуры метода, чем тот из удаленного объекта, необходимо гарантировать, что класс доступен локально, или еще лучше, что методы, которые Вы вызываете, присутствуют в Протоколе NSDistantObject. Если сигнатура метода будет только доступна удаленно, и она отличается от того, что видел компилятор, то параметры и возвращаемые значения не будут переданы правильно. Например, если Вы скомпилируете клиент на 32 бита против сигнатуры методов, который использует NSInteger, но фактический сервер составляет 64 бита, и никакой протокол не установлен на объекте, и класс не присутствует в клиенте, то параметры не будут переданы правильно.

Распределенная совместимость Объектов Тигра

Если или клиент или сервер выполняют Тайгера или ранее, эти преобразования не поддерживаются. Для использования распределенных объектов на версии перед Leopard OS необходимо гарантировать, чтобы сигнатуры методов клиента и сервера соответствовали точно и в размере и в типе.

NSNotFound

Как часть 64-разрядного портирования, NSNotFound теперь определяется как NSIntegerMax. Раньше это был 0x7fffffff, эффективно та же вещь на 32-разрядном. Обратите внимание на то, что, так как значение отличается в 32-разрядном и 64-разрядном, это - плохая идея [продолжаются к], сохраняют его в файлах или архивах, если Вы сегодня, и отправка его между 32-разрядными и 64-разрядными процессами через Распределенные Объекты не получит Вас NSNotFound с другой стороны. Это применяется к любым методам Какао, вызванным по D.O. также, который мог бы возвратить NSNotFound, такой как-indexOfObject: в NSArray (в частности, когда отправлено в прокси к массиву, конечно).

Утечки в Распределенных Объектах включились

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

Кодирование значения ключа и наблюдение (KVC, KVO)

Новые опции KVO

Две новых опции наблюдения значения ключа, которые могут использоваться при вызове - [NSObject (NSKeyValueObserverRegistration) addObserver:forKeyPath:options:context:] были добавлены в OS X 10.5. Первое просто позволяет Вам, указывают, что наблюдатель должен получить уведомление о значении наблюдаемого свойства сразу же:

NSKeyValueObservingOptionInitial = 0x04,

Указывает, должно ли уведомление быть сразу отправлено наблюдателю, прежде чем даже возвратится регистрационный метод наблюдателя. Если NSKeyValueObservingOptionNew будет также указан, но никогда не будет содержать запись NSKeyValueChangeOldKey, словарь изменения в уведомлении будет всегда содержать запись NSKeyValueChangeNewKey. (В первоначальном уведомлении текущая стоимость наблюдаемого свойства может быть старой, но это в новинку для наблюдателя.) Можно использовать эту опцию вместо явного вызова, одновременно, код, также вызывающийся-observeValueForKeyPath:ofObject:change:context наблюдателя: метод. Когда эта опция используется с-addObserver:toObjectsAtIndexes:forKeyPath:options:context: уведомление будет отправлено за каждым индексируемым объектом, к которому добавляется наблюдатель.

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

NSKeyValueObservingOptionPrior = 0x08

Указывает, должны ли отдельные уведомления быть отправлены наблюдателю прежде и после каждого изменения вместо единственного уведомления после изменения. Словарь изменения в уведомлении, отправленном перед изменением всегда, содержит запись NSKeyValueChangeNotificationIsPriorKey (также объявленный в <Foundation/NSKeyValueObserving.h>), чье значение [NSNumber numberWithBool:YES], но никогда не содержит запись NSKeyValueChangeNewKey. Когда эта опция указана словарь изменения в уведомлении, отправленном после того, как изменение содержит те же записи, которые это содержало бы, если бы не была указана эта опция. Можно использовать эту опцию, когда собственное KVO-соответствие наблюдателя требует, чтобы он вызвал один из-willChange... методы для одного из его собственных свойств, и значение того свойства зависит от значения свойства наблюдаемого объекта. (В той ситуации слишком поздно для простого вызова-willChange. .. должным образом в ответ на получение-observeValueForKeyPath:ofObject:change:context: сообщение после изменения.)

Поддержка Ключевых Путей в Механизме Зависимости KVO (Обновленный начиная с WWDC 2007)

Простой механизм зависимости от свойства был включен в KVO, когда это было сначала опубликовано в OS X 10.3 в форме + [NSObject (NSKeyValueObservingCustomization) setKeys:triggerChangeNotificationsForDependentKey:] метод и использование KVO информации зарегистрированы вызовом Вашего приложения его. Этот механизм, однако:

• Не поддерживал ключевые пути.

• Не было очень просто к программе с, потому что было трудно определить, когда точно вызвать +setKeys:triggerChangeNotificationsForDependentKey:.

В OS X 10.5, +setKeys:triggerChangeNotificationsForDependentKey: был осужден и новый метод, +keyPathsForValuesAffectingValueForKey: был опубликован. Это не страдает ни от одной из просто описанных проблем. См. комментарии для него в <Foundation/NSKeyValueObserving.h> для получения дополнительной информации.

Примечание: Это еще не было истиной в семени 2007 года WWDC, даже при том, что это улучшение было упомянуто в версии семени этой информации о версии.

Лучшая Поддержка в KVO для Свойств, Добавленных Категориями (Обновленный начиная с WWDC 2007)

+automaticallyNotifiesObserversForKey: не предоставлял себя хорошо ситуациям, где метод get для включенного свойства был добавлен категорией класса. Решить эту проблему, реализацию по умолчанию +automaticallyNotifiesObserversForKey: был обновлен для нахождения методов, имена которых следуют за образцом +automaticallyNotifiesObserversOf <Ключ>. (Это является соответствующим пути новый +keyPathsForValuesAffectingValueForKey: работы метода.) Такие методы могут быть легко реализованы в категориях прямо рядом с соответствующими методами получателя. См. комментарии для него в <Foundation/NSKeyValueObserving.h> для получения дополнительной информации.

Примечание: Это еще не было истиной в семени 2007 года WWDC, даже при том, что это улучшение было упомянуто в версии семени этой информации о версии.

Поддержка в KVO для Расположения каскадом Зависимостей от Свойства (Новый начиная с WWDC 2007)

В OS X 10.3 и OS X 10.4 Вы могли использовать теперь осуждаемый +setKeys:triggerChangeNotificationsForDependentKey: метод, чтобы объявить, что свойство X класса зависит от свойства Y, и что свойство Y зависит от свойства Z, но изменяется на значение Z, не привел бы к уведомлениям, отправленным наблюдателям X. В OS X 10,5 изменений в значении Z теперь приводят к уведомлениям, отправленным наблюдателям обоих X и y, независимо от того, были ли зависимости зарегистрированы с помощью +setKeys:triggerChangeNotificationsForDependentKey: или более новый +keyPathsForValuesAffectingValueForKey: механизм, описанный выше.

Исправление ошибки в механизме зависимости KVO

В OS X 10.3 и OS X 10.4 была ошибка, в которой механизм зависимости KVO не взаимодействовал хорошо с наблюдением ключевым путем. Например, учитывая класс Фу с «видимыми» свойствами и «visibleThing «, куда-visibleThing всегда возвращал бы ноль, если видимый, был установлен в нет, или всегда возвращайте объект, сам имевший атрибут «имени», если видимый был установлен ДА, и, учитывая, что зависимость «visibleThing» на «видимом» была объявлена путем вызова [Фу setKeys: [NSArray, arrayWithObject:@» видимый»] triggerChangeNotificationsForDependentKey:@ «visibleThing»], наблюдатели «visibleThing.name» Фу не были бы уведомлены когда значение «видимого» измененного свойства Фу. Эта ошибка была исправлена в OS X 10.5.

Лучшая функциональная совместимость между KVO и категориями класса, загруженными от пакетов

В OS X 10.3 и 10.4 была ошибка, в которой методы, добавленные к классам категориями, загруженными из пакетов, не будут работать в варианте класса, это создается автоуведомлением KVO isa-swizzling машинное оборудование. Так, было возможно добавить наблюдателя KVO к объекту, загрузить пакет, который, как предполагалось, добавил методы к классу наблюдаемого объекта, и затем имел те методы не быть отвеченным на. Эта ошибка была исправлена в OS X 10.5.

Поддержка типа класса в KVC и KVO

В OS X 10.5, KVC теперь работает с Типом класса. Например,-valueForKey: вызовет методы как - ключ (Class) и-setValue:forKey: вызовет методы как - (недействительный) setKey: (Класс) класс А. Оба метода работают с соответственно переменными именованного экземпляра, типом которых является Класс. Автоматическое машинное оборудование уведомления наблюдателя KVO также обрабатывает свойства Class должным образом.

Поддержка произвольных типов в KVC и KVO

В OS X 10.5, KVC теперь работают с произвольными типами. Например, если у Вас есть класс как это:

typedef struct {

    float x, y, z;

} ThreeFloats;

@interface MyClass

- (void)setThreeFloats:(ThreeFloats)threeFloats;

- (ThreeFloats)threeFloats;

@end

[anInstanceOfMyClass valueForKey:@ «threeFloats»] вызовет - [MyClass threeFloats] и возвратит результат, обернутый в NSValue. Аналогично [anInstanceOfMyClass setValue:anNSValueWrappingThreeFloats forKey:@ «threeFloats»] вызовет - [MyClass setThreeFloats:] с результатом отправки-getValue: к anNSValueWrappingThreeFloats. Оба метода работают с соответственно переменными именованного экземпляра произвольного типа. Автоматическое машинное оборудование уведомления наблюдателя KVO также обрабатывает произвольно введенные свойства должным образом. Этот механизм не принимает во внимание подсчет ссылок или сборку «мусора», поэтому заботится при использовании с указателем объекта «типов структуры, содержащим».

Меньше броска исключения для ключей Нулевой Длины и путей в KVC

В OS X 10.5, переопределения-valueForKey: и-valueForKeyPath: в NSDictionary NSArray, NSSet и классы NSUserDefaults больше не бросают побочный «Диапазон или индексируют за пределы» исключения для ключей нулевой длины и ключевых путей.

Поддержка отладки плохого удаления KVO

В OS X 10.3 и 10.4, - [NSObject (NSKeyValueObserverRegistration removeObserver:forKeyPath:] сделал бы одну из двух вещей, когда передано объект, не зарегистрированный как наблюдатель получателя в тот момент:

1) Катастрофический отказ

2) Ничто

В OS X 10.5 KVO было обновление, чтобы всегда выдать исключение для плохого удаления наблюдателя значения ключа. Для обратной совместимости на уровне двоичных кодов не выдается никакое исключение в случае, если № 2, в приложениях соединился против OS X 10.4 или ранее.

Поддержка отладки плохого соответствия KVO

Наиболее распространенная ошибка, которую люди делают при попытке сделать наблюдение значения ключа (KVO) класса совместимым для определенного ключа, забыла устраивать отправку надлежащих уведомлений наблюдателя, когда изменяется значение для того ключа. Это особенно просто сделать при воздержании от автоматического наблюдения значения ключа в классе. Наиболее с готовностью видимый признак этой ошибки - то, который просматривает, которые связываются в некотором роде с включенным свойством, не обновляют для отражения измененных значений, как Вы ожидали бы. Когда Вы видите проблемы как этот анализ страница «Ensuring KVO Compliance» и связанные страницы Значения ключа, Наблюдая Руководство по программированию.

Когда ключ используется по ключевому пути, появляется более серьезный признак плохого соответствия KVO. В OS X 10.3 и 10.4 плохих KVO-соответствий могут вызвать катастрофические отказы в собственном наблюдающем путь машинном оборудовании KVO. Такой катастрофический отказ обычно выглядит примерно так:

Program received signal EXC_BAD_ACCESS, Could not access memory.

Reason: KERN_PROTECTION_FAILURE at address: 0x00000006

0x90285e24 in CFRetain ()

(gdb) bt 4

#0  0x90285e24 in CFRetain ()

#1  0x90b8165c in _NSKeyValueObservationInfoCreateByRemoving ()

#2  0x90b81434 in -[NSObject(NSKeyValueObserverRegistration) _removeObserver:forProperty:] ()

#3  0x90b81324 in -[NSObject(NSKeyValueObserverRegistration) removeObserver:forKeyPath:] ()

#4  0x90b81274 in -[NSObject(NSKeyValueObserverRegistration) removeObserver:forKeyPath:] ()

(More stack frames follow...)

(gdb)

Когда этот катастрофический отказ произойдет, в OS X 10.5 KVO были обновлены для выдачи исключения. Теперь, например, выполнение этого кода:

- (void)demonstrateExceptionsForBadKVOCompliance {

    /* Allocate an object that can be used as a key-value observer.

       In a typical Cocoa application using Bindings the observers are usually private

       objects created by the key-value bindings machinery, but any class can be used as a

       key-value observer as long as it implements the -observeValueForKeyPath:ofObject:change:context:

       method properly.

    */

    KeyValueObserver *observer = [[KeyValueObserver alloc] init];

    /* Allocate an instance of a class that has a to-one relationship to a mutable dictionary, keyed

       by "toOneRelationshipWithBadKVOCompliance," but doesn't properly notify key-value observers when

       the dictionary itself is replaced by another dictionary. The use of a mutable dictionary as the

       related object in this example is arbitrary; key-value coding (KVC) and key-value observing work

       with all sorts of objects as long as they are KVC and KVO compliant for the keys in use.

       (Dictionaries are automatically KVC and KVO compliant for all keys.)

    */

    PlentyOProperties *plentyOProperties = [[PlentyOProperties alloc] init];

    /* Start observing an entry in that mutable dictionary. This causes KVO to not only start

       observing the dictionary, but also to register itself as an observer of the plentyOProperties

       object, so it knows when the dictionary has changed and it therefore needs to stop observing

       the old dictionary and start observing the new dictionary.

    */

    [plentyOProperties addObserver:observer forKeyPath:@"toOneRelationshipWithBadKVOCompliance.anyOldKey"

                           options:0 context:NULL];

    /* Change the pointed-to dictionary. For this demonstration we made the PlentyOProperties

       class KVO noncompliant by overriding +automaticallyNotifiesObserversForKey: to turn off

       automatic observer notification and by neglecting to implement a -setToOneRelationshipWithBadKVOCompliance:

       method that does manual observer notification using -willChangeValueForKey: and -didChangeValueForKey:.

       Because PlentyOProperties is not KVO compliant, the KVO mechanism that's used when observing

       key paths doesn't get notified that it should stop observing the old dictionary and start observing

       the new one here.

    */

    [plentyOProperties setValue:[NSMutableDictionary dictionaryWithObject:@"anyOldValue" forKey:@"anyOldKey"]

                         forKey:@"toOneRelationshipWithBadKVOCompliance"];

    /* Stop observing what we started observing up above. In Panther and Tiger: Crash! Because KVO itself tries

       to stop observing the newly-related dictionary, but it never started observing it in the first place.

       In OS X 10.5: A helpful exception is thrown.

    */

    [plentyOProperties removeObserver: observer forKeyPath:@"toOneRelationshipWithBadKVOCompliance.anyOldKey"];

    /* Etc, etc. */

}

заставит что-то вроде этого появляться в консоли:

Cannot remove an observer <KeyValueObserver 0x40fdb0> for the key path

"toOneRelationshipWithBadKVOCompliance.anyOldKey" from <PlentyOProperties 0x410a30>,

most likely because the value for the key "toOneRelationshipWithBadKVOCompliance" has

changed without an appropriate KVO notification being sent. Check the KVO-compliance

of the PlentyOProperties class.

Если Вы повредитесь на objc_exception_throw в отладчике, то Вы будете, вероятно, видеть, что проходят два исключения. В дополнение только к описанному исключению Вы будете видеть что-то вроде этого, во-первых:

Cannot remove an observer <NSKeyValueObservationForwarder 0x3125c0> for the key path "anyOldKey"

from <NSCFDictionary 0x312250> because it is not registered as an observer.

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

Для любопытного: Что такое NSKeyValueObservationForwarder? Это - частный класс объектов что использование KVO для реализации наблюдения ключевых путей. Ваше приложение не должно зависеть от него. Это может уйти в будущих выпусках OS X.

Уведомление для фиксации одного отчасти плохого соответствия KVO

Одно внутреннее приложение Apple бросало вид исключения, описанного выше. Это было похоже на это:

2005-09-04 17:42:16.146 MyTestApp[936] *** -[NSAutoreleasePool dealloc]: Exception ignored while

releasing an object in an autorelease pool: Cannot remove an observer <NSArrayDetailBinder 0x3e48890>

for the key path "myBook.indexMarkersInBook" from <MyDocument 0x439930>, most likely because

the value for the key "myBook" has changed without an appropriate KVO notification being sent.

Check the KVO-compliance of the MyDocument class.

Вот то, на что было похоже средство доступа для myBook свойства в классе MyDocument:

- (Book *) myBook {

    return [[self myChapter] myBook];

}

Это выглядит довольно простым, и класс MyDocument был KVO-совместим для myChapter свойства. Таким образом, какова была проблема? Проблема состояла в том, что KVO не может вывести, что значение myBook изменяется, когда изменяется значение myChapter. Проблемы как это могут быть решены по крайней мере двумя способами:

• Используйте различный ключевой путь в привязке. В этом примере, связывающем NSArrayController с «myChapter.myBook.indexMarkersInBook» документа вместо, он - myBook.indexMarkersInBook», решил проблему. Поскольку MyDocument KVO-совместим для myChapter в этом примере, и класс Главы KVO-совместим для myBook, все работает. Этот вид решения не всегда желателен хотя; возможно, автор класса MyDocument не хочет публиковать факт, что экземпляры его даже имеют «главы» к другим частям программы по причинам проекта.

• Используйте + [NSObject (NSKeyValueObservingCustomization) setKeys:triggerChangeNotificationsForDependentKey:], чтобы сказать KVO, что значение myBook MyDocument зависит от значения его myChapter. Тот путь, с реализацией-myBook выше, MyDocument KVO-совместим для myBook.

Исправление ошибки в наблюдении ключевого пути сам

В OS X 10.3 и 10.4 была ошибка, в которой функция отладки KVO мешала объекту наблюдать одно из его собственных значений с помощью многокомпонентного ключевого пути: прямо, прежде чем-dealloc метод класса был бы вызван с объектом все еще как наблюдатель себя, Основа зарегистрирует что-то как «Экземпляр 0x123456 класса, MySelfObservingClass освобождается, в то время как наблюдатели значения ключа все еще регистрируются в нем. Повреждение на _NSKVODeallocateLog, чтобы начать отлаживать». Тогда, если бы объект правильно удалил себя как наблюдатель себя, то исключение было бы выдано, или катастрофический отказ произошел бы. Эта ошибка была исправлена в OS X 10.5. KVO все еще имеет функцию, в которой он регистрирует предупреждение, если объект освобождается с наблюдателями, зарегистрированными в нем, но он теперь надежно игнорирует сам объект как наблюдателя.

NSBundle

Ошибки загрузки NSBundle, Preflighting и обнаружение архитектуры

NSBundle теперь содержит методы, чтобы позволить ему возвращать NSError, если загрузка пакета перестала работать, для разрешения тестирования перед рейсом пакета, загружающегося, фактически не заставляя пакет быть загруженной и определить архитектуры процессора, которые содержит Мужественная исполнимая программа. Метод-loadAndReturnError: ведет себя как существующее - метод загрузки, за исключением того, что, если дополнительным параметром ошибок ссылкой будет не-NULL и сбои загрузки, то это будет заполнено в подходящим NSError предоставляющий описания проблемы, подходящей для представления пользователю. Если метод возвратит YES - т.е. если пакет был уже загружен или был теперь успешно загружен - тогда, то содержание параметра ошибок не будет затронуто. Все ошибки возвратились, находятся в ошибочном домене Какао, и их коды описаны в FoundationErrors.h. Вызывающая сторона не получает ссылку на возвращенный NSError и должна сохранить его, если это хочет держаться за него вне времени жизни текущего пула автовыпуска. Обратите внимание на то, что, если параметром ошибок является не-NULL и сбои загрузки, то этот метод может выполнить дополнительную работу и вне того, что - загрузка сделала бы для определения точного ошибочного типа.

Текущие возможные коды ошибки: NSFileNoSuchFileError, если не может быть расположена исполнимая программа пакета; NSExecutableNotLoadableError, если исполнимая программа пакета существует, но не является загружаемой исполнимой программой; NSExecutableArchitectureMismatchError, если исполнимая программа пакета существует, но не обеспечивает версию для архитектуры процессора текущего процесса; NSExecutableRuntimeMismatchError, если исполнимая программа пакета существует, но содержит информацию о выполнении Objective C, которая не совместима с текущим процессом; NSExecutableLoadError, если исполнимой программе пакета не удается быть загружаемой по некоторой другой причине, обнаруживаемой до соединения, особенно отсутствие требуемой библиотеки или отсутствие архитектуры - и совместимая версия во время выполнения требуемой библиотеки; и NSExecutableLinkError, если исполнимая программа пакета передает все другие проверки, но не удается загрузиться вследствие ошибок ссылки. Обратите внимание на то, что NSExecutableNotLoadableError будет возвращен, если исполнимая программа пакета будет PEF/CFM, но текущий процесс не поддерживает CFM. Другие коды ошибки могут быть добавлены в будущих выпусках. Более определенная информация может быть показана в описании отладки ошибки, доступном через - описание или gdb объектная команда печати.

Подобная информация об ошибках загрузки может также быть получена, фактически не загружая пакет, с помощью метода-preflightAndReturnError:. Этот метод возвращает YES, если пакет уже загружается, или если это, кажется, загружаемо всеми тестами за исключением фактического соединения. Дополнительный параметр ошибок ссылкой ведет себя как параметр ошибок к-loadAndReturnError: за исключением того, что это не может возвратить NSExecutableLinkError.

-executableArchitectures метод может использоваться для определения списка архитектур процессора, которые поддерживает исполнимая программа пакета. Если исполнимая программа является Мужественной, то эта функция возвращает массив NSNumbers целого типа, каждый из которых представляет тип ЦП, для которого исполнимая программа имеет версию. NSBundle объявляет константы для определенных известных типов (NSBundleExecutableArchitecturePPC, NSBundleExecutableArchitecturePPC64, NSBundleExecutableArchitectureI386 и NSBundleExecutableArchitectureX86_64), но значения приняты непосредственно от исполнимой программы, таким образом, другие значения могут произойти, и другие значения могут быть добавлены в будущем. Если исполнимая программа не является Мужественной, то этот ноль возвратов метода.

NSBundle, загружающийся по сравнению с загрузкой CFBundle

Ранее было рекомендовано, чтобы связался содержащий код Objective C, или код Java Какао должен быть загружен с помощью NSBundle, а не CFBundle. В Leopard существует меньше различий между CFBundle и загрузкой NSBundle, и пакеты, содержащие код Objective C, могут быть загружены также. Однако существует все еще несколько остающихся различий. Во-первых, пакеты с исполнимым типом MH_BUNDLE (т.е. загружаемые пакеты, а не платформы) загруженный использующий CFBundle загружаются конфиденциально и с непосредственной привязкой, в то время как те же пакеты загрузили использование, NSBundle загружаются глобально и с ленивой привязкой. Пакеты с исполнимым типом MH_DYLIB (т.е. платформы) загружаются глобально и с ленивой привязкой в любом случае. Во-вторых, в то время как загрузка того же пакета с помощью CFBundle не произведет эти уведомления, загрузка пакетов с помощью NSBundle заставит уведомления NSBundleDidLoadNotification быть отправленными. В-третьих, пакеты, содержащие код Java Какао, должны все еще быть загружены с помощью NSBundle.

NSBundle разгрузка

В Leopard NSBundle представляет - (BOOL), разгружают метод. Этот метод пытается разгрузить пакет, если это загружается и возвращает YES, если пакет не загружается в конце вызова, т.е. если это было успешно разгружено или если это не было загружено во-первых. Успешность или неуспешность в разгрузке зависит от базового динамического загрузчика, обычно dyld. (Обратите внимание на то, что в Leopard, dyld теперь поддерживает разгрузку MH_DYLIB, а также исполнимых программ MH_BUNDLE.) Пакеты могут также быть разгружены с помощью CFBundle, но рекомендуется, чтобы пакеты, загруженные NSBundle, были разгружены с NSBundle и загруженными CFBundle быть разгруженными с CFBundle. Как обычно, это - ответственность клиента удостовериться, что нет никаких висячих указателей к коду, разгружающемуся, и в частности что нет никаких существующих экземпляров классов, определенных в пакете. Этот метод существует в предыдущих версиях OS X, но всегда возвращается НЕ в системах перед Leopard, потому что разгрузка NSBundles не поддерживается в тех системах.

NSFileManager

Делегаты NSFileManager и экземпляры (Обновленный начиная с WWDC 2007)

В версиях OS X до Leopard единственный поддерживаемый экземпляр NSFileManager был экземпляром, возвращенным из + [NSFileManager defaultManager] (одноэлементный экземпляр). При вызове [[выделение NSFileManager] init] возвратило бы новый экземпляр объекта NSFileManager, но этот экземпляр мог бы вести себя странно перед лицом многократных потоков.

В Leopard, вызывая + [NSFileManager defaultManager] все еще получает Вас тот же одноэлементный экземпляр независимо от того, когда или в том, какой поток Вы вызываете его, но вызывающий [[выделение NSFileManager] init] теперь явно поддерживается и возвращает новый экземпляр. Кроме того, экземпляры NSFileManager могут теперь иметь объекты делегата. Делегат установлен обычным способом:

- (void)setDelegate:(id)delegate;

- (id)delegate;

Делегат не сохраняется в обычной работе. В GC сильная ссылка сведена к делегату.

NSFileManager копируют/перемещают/соединяют/удаляют API (Обновленный начиная с WWDC 2007)

Leopard представляет новый API для копирования, перемещения, соединения и удаления элементов файловой системы.

- (BOOL)copyItemAtPath:(NSString *)srcPath toPath:(NSString *)dstPath error:(NSError **)error;

- (BOOL)moveItemAtPath:(NSString *)srcPath toPath:(NSString *)dstPath error:(NSError **)error;

- (BOOL)linkItemAtPath:(NSString *)srcPath toPath:(NSString *)dstPath error:(NSError **)error;

- (BOOL)removeItemAtPath:(NSString *)path error:(NSError **)error;

которые заменяют так же названные методы, в настоящее время существующие в NSFileManager.

События передаются делегату, использующему следующие методы, определенные в категории на NSObject:

- (BOOL)fileManager:(NSFileManager *)fileManager shouldCopyItemAtPath:(NSString *)srcPath toPath:(NSString *)dstPath;

- (BOOL)fileManager:(NSFileManager *)fileManager shouldProceedAfterError:(NSError *)error

                                                    copyingItemAtPath:(NSString *)srcPath toPath:(NSString *)dstPath;

- (BOOL)fileManager:(NSFileManager *)fileManager shouldMoveItemAtPath:(NSString *)srcPath toPath:(NSString *)dstPath;

- (BOOL)fileManager:(NSFileManager *)fileManager shouldProceedAfterError:(NSError *)error

                                                     movingItemAtPath:(NSString *)srcPath toPath:(NSString *)dstPath;

- (BOOL)fileManager:(NSFileManager *)fileManager shouldLinkItemAtPath:(NSString *)srcPath toPath:(NSString *)dstPath;

- (BOOL)fileManager:(NSFileManager *)fileManager shouldProceedAfterError:(NSError *)error

                                                    linkingItemAtPath:(NSString *)srcPath toPath:(NSString *)dstPath;

- (BOOL)fileManager:(NSFileManager *)fileManager shouldRemoveItemAtPath:(NSString *)path;

- (BOOL)fileManager:(NSFileManager *)fileManager shouldProceedAfterError:(NSError *)error removingItemAtPath:(NSString *)path;

У делегатов в «shouldXXXItemAtPath» методах есть возможность возвратить «НЕТ» для пропуска определенного элемента. Выполнение так не инициировало ошибочный возврат в XXXItemAtPath:toPath:error верхнего уровня: метод. Поведение по умолчанию состоит в том, чтобы действовать, как будто эти методы возвращают YES.

Делегаты в shouldProceedAfterError:XXXingItemAtPath:toPath: методы имеют возможность возвратить YES. Это подавит ошибочный возврат из XXXItemAtPath:toPath:error: верхнего уровня. Делегаты в shouldProceedAfterError: метод может воспользоваться возможностью, чтобы попытаться решить проблему, чтобы позволить работе продолжаться. Поведение по умолчанию состоит в том, чтобы действовать, как будто эти методы возвращаются НЕТ.

- [NSFileManager copyPath:toPath:handler:] и ACLs

OS X v10.4 представил Списки управления доступом (ACLs), сложный механизм для управления доступом в файловой системе. copyPath:toPath:handler NSFileManager: метод не копирует ACLs при копировании объекта файловой системы. Но новый Leopard API, copyItemAtPath:toPath:error: действительно копирует ACLs.

NSFileManager APIs, которые возвращают ошибки (Обновленный начиная с WWDC 2007)

Сообщение об ошибке NSFileManager было улучшено в Leopard с добавлением многих новых методов, берущих параметр NSError ссылкой.

Следующие методы являются новыми в Leopard и предназначаются как замены для их дубликатов «не ошибочное взятие»:

- (BOOL)setAttributes:(NSDictionary *)attributes ofItemAtPath:(NSString *)path error:(NSError **)error;

- (BOOL)createSymbolicLinkAtPath:(NSString *)path withDestinationPath:(NSString *)destPath error:(NSError **)error;

- (NSArray *)contentsOfDirectoryAtPath:(NSString *)path error:(NSError **)error;

- (NSArray *)subpathsOfDirectoryAtPath:(NSString *)path error:(NSError **)error;

- (NSDictionary *)attributesOfItemAtPath:(NSString *)path error:(NSError **)error;

- (NSDictionary *)attributesOfFileSystemForPath:(NSString *)path error:(NSError **)error;

- (NSString *)destinationOfSymbolicLinkAtPath:(NSString *)path error:(NSError **)error;

- (BOOL)createDirectoryAtPath:(NSDictionary *)path

              withIntermediateDirectories:(BOOL)createIntermediates

              attributes:(NSDictionary *)attributes

              error:(NSError **)error;

Некоторые методы не были улучшены; для тех методов нет никакой полезной презентабельной пользователем ошибки, которая будет сгенерирована, или общая утилита была сомнительна. Одним примером метода этого типа является-isWritableFileAtPath:. Окна гонки существуют между тестированием на writability и фактически записью; намного лучший подход должен делать попытку записи в файл и обработки ошибок, которые могут произойти корректно.

Проверка правописания

Проверка правописания является новой функцией, связанной с существующей функциональностью проверки правописания. Любой сервер проверки правописания имеет опцию также обеспечения проверки правописания путем реализации метода делегата NSSpellServer

- (NSRange)spellServer:(NSSpellServer *)sender checkGrammarInString:(NSString *)stringToCheck

              language:(NSString *)language details:(NSArray **)details;

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

NSString *NSGrammarRange;

NSString *NSGrammarUserDescription;

NSString *NSGrammarCorrections;

Значение для ключа NSGrammarRange должно быть NSValue, содержащим NSRange, поддиапазон диапазона предложения, используемого в качестве возвращаемого значения, расположение которого должно быть смещением с начала предложения - так, например, NSGrammarRange для первых четырех символов полного диапазона предложения должен быть {0, 4}. Значение для ключа NSGrammarUserDescription должно быть NSString, содержащим описательный текст о том диапазоне, чтобы быть представленным непосредственно пользователю; это предназначается, что пользовательское описание должно предоставить достаточно информации, чтобы позволить пользователю исправлять проблему. Значение может также быть предоставлено для ключа NSGrammarCorrections, состоя из NSArray Нсстрингса, представляющего потенциальные замены для исправления проблемы, но ожидается, что это может не быть доступно во всех случаях. Рекомендуется, чтобы NSGrammarUserDescription были предоставлены во всех случаях; при любых обстоятельствах или NSGrammarUserDescription или NSGrammarCorrections должны быть предоставлены для чего-то, чтобы быть представленными пользователю. Если NSGrammarRange не будет присутствовать, то он, как будет предполагаться, будет равен полному диапазону предложения. Дополнительные ключи могут быть добавлены в будущих выпусках.

Неизменные наборы и поведение копии

В OS X v10.4 и ранее, поведение копии по умолчанию пользовательских подклассов NSArray, NSSet и NSDictionary (неизменные варианты) состояло в том, чтобы глубоко скопировать содержание набора. Это означало что, отправляя копию или copyWithZone: к любому из этих наборов скопировал каждый элемент в наборе. Это потребовало что содержание набора, которому приспосабливают протоколу NSCopying.

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

Если на Тигре Вы использовали код как это:

NSArray *deepCopyOfArray = [someArray copyWithZone:nil];     // deep copy on Tiger

и полагаясь на глубокое поведение копии получить глубокую копию, Вы использовали бы следующий код и Тайгера и Leopard:

NSArray *deepCopyOfArray = [[NSArray alloc] initWithArray:someArray copyItems:YES];   // explicitly deep copy

как понижение замены (поскольку правила владения являются тем же).

Способы строительства набора и NS_REQUIRES_NIL_TERMINATION

Существует шесть методов создания набора в Основе, требующих, чтобы нулевое завершение функционировало должным образом. Они:

+[NSArray arrayWithObjects:]

-[NSArray initWithObject:]

+[NSDictionary dictionaryWithObjectsAndKeys:]

-[NSDictionary initWithObjectsAndKeys:]

+[NSSet setWithObjects:]

-[NSSet initWithObjects:]

Эти методы были украшены макросом NS_REQUIRES_NIL_TERMINATION, добавляющим дополнительную проверку к вызовам тех методов, чтобы удостовериться, что ноль был включен в конце списка аргументов. Это предупреждение только доступно при компиляции с-Wformat.

Порядок значений в основанных на хешировании наборах

CoreFoundation и Основа, предоставленная платформой реализации основанных на хешировании наборов, такие как словари, изменились, как они хранят элементы, таким образом, элементы могут быть получены в различном порядке, чем в предыдущих выпусках. Порядок элементов в основанных на хешировании наборах не определен и может измениться в любое время, таким образом, разработчики никогда не должны полагаться на порядок, что элементы перечисляются или возвращаются из функции как CFDictionaryGetKeysAndValues (). Это - истина даже для случаев, где разработчик может пытаться управлять хэш-кодами объектов для достижения некоторого определенного упорядочивания.

NSSet

NSSet и NSMutableSet теперь имеют основанные на предикате методы для фильтрации. Они подобны существующим методам фильтрации на NSArray/NSMutableArray.

NSSet имеет следующие новые методы, которые должны быть очевидными с имени:

- (NSSet *)setByAddingObject:(id)anObject;

- (NSSet *)setByAddingObjectsFromSet:(NSSet *)other;

- (NSSet *)setByAddingObjectsFromArray:(NSArray *)other;

NSIndexSet

Имеет следующий новый метод для возврата числа индексов в указанном диапазоне:

- (NSUInteger)countOfIndexesInRange:(NSRange)range;

Уведомление для Invokers - [NSUndoManager removeAllActions]

- [NSUndoManager removeAllActions] сбрасывает «isUndoing» и «isRedoing» состояние менеджера по отмене. Если Ваше приложение вызовет его во время отмены или работы восстановления, менеджер по отмене, то объект оставят в противоречивом состоянии, вызывая трудные к отладке ошибки или катастрофические отказы. Разработайте свое приложение так, чтобы это не происходило. Нет никакой бывшей известной серьезной причины, чтобы отправить менеджеру по отмене сообщение-removeAllActions, когда это посреди работы отмены. Если необходимо, можно использовать-isUndoing и-isRedoing для защиты от выполнения такой вещи.

NSGeometry.h и преобразовывающий между CGRect и NSRect

В 32-разрядном коде CGRects и NSRects являются отличными типами. Для помощи в преобразовании между CGRects и NSRects, NSGeometry.h определяет 6 новых функций:

NSRectFromCGRect

NSRectToCGRect

NSPointFromCGPoint

NSPointToCGPoint

NSSizeFromCGSize

NSSizeToCGSize

которые делают преобразование указателя между NSRects и CGRects.

- [NSData getBytes:range:] и NSRangeExceptions

- [NSData getBytes:range:] должным образом не повышает NSRangeException для диапазонов, запускающихся в NSData, но конце вне NSData. Вместо этого это заполняет предоставленный буфер до конца NSData. Это будет продолжать иметь место для OS X v10.5 Leopard, но будущий выпуск операционной системы начнет выдавать исключения диапазона для приложений, соединенных позже, чем OS X v10.5.

Каталоги NSSearchPathForDirectoriesInDomains и Developer

В OS X v10.5 «Leopard» возможно иметь многократные версии программного обеспечения Developer Tools (XCode, Интерфейсный Разработчик, и т.д.) установленный в Вашей системе когда-то. Также возможно установить их в расположении, не базированном в «/Разработчик» путь в файловой системе. В результате каталоги, возвращенные из NSSearchPathForDirectoriesInDomains путем передачи констант NSDeveloperApplicationDirectory или NSDeveloperDirectory, могут не возвратить что-то, что соответствует фактическому расположению установленных Инструментов Разработчика.

+ [NSInputStream inputStreamWithData:] (Новый начиная с WWDC 2007)

В OS X v10.4 «Тигр», NSData передал + [NSInputStream inputStreamWithData:] не был бы сохранен создаваемым потоком. В OS X v10.5 «Leopard» NSData теперь сохраняется потоком.

NSNetServices

Это - ошибка вызвать - [NSNetService публикуют] на NSNetService, инициализированном с - [NSNetService initWithDomain:type:name:]. Для приложений, соединенных на OS X v10.5 «Leopard» или позже, делая так, заставит исключение быть брошенным.

Приложения, которые были соединены на OS X v10.5 Leopard или позже повысят исключение когда передающий ноль к + [NSNetService dictionaryFromTXTRecordData:] или + [NSNetService dataFromTXTRecordDictionary:].

NSNetServices (Новый начиная с WWDC 2007)

Поведение NSNetServices в обработке тайм-аутов немного отличается, чем, что предоставлено CFNetServices. В Leopard CFNetServices безусловно сообщит об ошибке из-за тайм-аута, когда тайм-аут, выбранный в CFNetServiceResolveWithTimeout (), будет поражен, независимо от того, были ли фактически разрешены какие-либо адреса.

NSNetServices только сообщит о NSNetServicesTimeoutError netService:didNotResolve делегата: обратный вызов, если никакие адреса не были разрешены вызовом к - [Решение NSNetService] или - [NSNetService resolveWithTimeout:]. Если адреса были разрешены, когда тайм-аут будет достигнут, делегат будет уведомлен относительно его-netServiceDidStop: метод делегата.

NSDateFormatter

NSDateFormatter имеет новые методы:

- (NSArray *)longEraSymbols;

- (void)setLongEraSymbols:(NSArray *)array;

- (NSArray *)veryShortMonthSymbols;

- (void)setVeryShortMonthSymbols:(NSArray *)array;

- (NSArray *)standaloneMonthSymbols;

- (void)setStandaloneMonthSymbols:(NSArray *)array;

- (NSArray *)shortStandaloneMonthSymbols;

- (void)setShortStandaloneMonthSymbols:(NSArray *)array;

- (NSArray *)veryShortStandaloneMonthSymbols;

- (void)setVeryShortStandaloneMonthSymbols:(NSArray *)array;

- (NSArray *)veryShortWeekdaySymbols;

- (void)setVeryShortWeekdaySymbols:(NSArray *)array;

- (NSArray *)standaloneWeekdaySymbols;

- (void)setStandaloneWeekdaySymbols:(NSArray *)array;

- (NSArray *)shortStandaloneWeekdaySymbols;

- (void)setShortStandaloneWeekdaySymbols:(NSArray *)array;

- (NSArray *)veryShortStandaloneWeekdaySymbols;

- (void)setVeryShortStandaloneWeekdaySymbols:(NSArray *)array;

- (NSArray *)quarterSymbols;

- (void)setQuarterSymbols:(NSArray *)array;

- (NSArray *)shortQuarterSymbols;

- (void)setShortQuarterSymbols:(NSArray *)array;

- (NSArray *)standaloneQuarterSymbols;

- (void)setStandaloneQuarterSymbols:(NSArray *)array;

- (NSArray *)shortStandaloneQuarterSymbols;

- (void)setShortStandaloneQuarterSymbols:(NSArray *)array;

Они устанавливают и возвращаются:

- «длинные» имена эры, например «нашей эры» вместо «AD»

- «очень короткие» имена в течение многих месяцев и рабочих дней; например, «F» вместо «пятницы»

- «автономные» имена в течение многих месяцев и рабочих дней; для некоторых локалей/языков имя месяца, выведенное на экран в изоляции, должно быть написано по-другому, чем имя месяца в выведенной на экран дате

- имена четвертей; например, «Q2» для короткого имени четверти

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

- (NSDate *)gregorianStartDate;

- (void)setGregorianStartDate:(NSDate *)date;

Это используется для указания даты начала переключателя Григорианского календаря от юлианского календаря. В разное время различные локали переключились. Обычно необходимо просто принять дату локали по умолчанию переключателя.

Новый NSNumberFormatter API

Существует некоторый новый API в NSNumberFormatter в 10,5:

- (NSString *)currencyGroupingSeparator;

- (void)setCurrencyGroupingSeparator:(NSString *)string;

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

- (BOOL)isLenient;

- (void)setLenient:(BOOL)b;

Может включить большую мягкость в парсинге строк в числа в некоторых выпусках операционной системы когда истина.

- (BOOL)usesSignificantDigits;        // whether to use the next two or not

- (void)setUsesSignificantDigits:(BOOL)b;

- (NSUInteger)minimumSignificantDigits;

- (void)setMinimumSignificantDigits:(NSUInteger)number;

- (NSUInteger)maximumSignificantDigits;

- (void)setMaximumSignificantDigits:(NSUInteger)number;

Они полезны для форматирования экспоненциального представления.

- (BOOL)isPartialStringValidationEnabled;

- (void)setPartialStringValidationEnabled:(BOOL)b;

Эти методы используются для включения частичной строковой проверки, которую по умолчанию NSNumberFormatters не делают (и никогда не делали). Однако реализация в 10,5 ничего не делает с этим свойством.

Поведение Средства форматирования по умолчанию

Когда новый NSNumberFormatter или NSDateFormatter создаются в приложениях, соединенных на 10,5 и позже, установка поведения по умолчанию для того средства форматирования «10_4» поведение. Это - все еще хорошая идея установить желаемое поведение средства форматирования явно сразу после создания его (при выполнении так в коде), чтобы ясно дать понять намерение.

Новый NSMachPort API

Когда Вы создаете один с портом Маха, можно теперь указать некоторые опции освобождения к NSMachPort:

enum {

    NSMachPortDeallocateNone = 0,

    NSMachPortDeallocateSendRight = (1 << 0),

    NSMachPortDeallocateReceiveRight = (1 << 1)

};

+ (NSPort *)portWithMachPort:(uint32_t)machPort options:(NSUInteger)f;

- (id)initWithMachPort:(uint32_t)machPort options:(NSUInteger)f;

Эти опции позволяют Вам указать, должен ли NSMachPort эффективно взять владение отправить правильной ссылки и/или получить правильные ссылки для порта при создании объекта порта. Когда объект порта будет освобожден, он освободит указанные права. Необходимо, конечно, понять то, что все это означает для порта Маха, и поймите, какие ссылки Вы можете иметь, перед использованием этих новых опций. Плюс, они идут с главным протестом: Ваш вызов должен быть первым создавание объекта порта с тем, что порт Маха или Ваши опции будет проигнорирован, и нет никакого хорошего способа сказать, были ли проигнорированы Ваши опции.

Новый APIs NSCalendar

NSCalendar имеет следующий новый API для вычислений диапазона времени для данного модуля, окружающего данный момент:

- (BOOL)rangeOfUnit:(NSCalendarUnit)unit startDate:(NSDate **)datep

           interval:(NSTimeInterval *)tip forDate:(NSDate *)date;

Вторые и третьи параметры отсутствуют параметры.

Например, для нахождения стартового момента и продолжительности недели около текущего момента, для данного календаря, Вы могли бы сделать:

NSDate *start;

NSTimeInterval length;

Boolean ret = [calendar rangeOfUnit:NSCalendarUnitWeek startDate:&start interval:&length forDate:[NSDate date]];

if (ret) { ...

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

+ (id)autoupdatingCurrentCalendar;

Возвращает специальный экземпляр NSCalendar, всегда отражающий текущее состояние календарных настроек текущего пользователя. Существующий currentCalendar метод будет продолжать возвращать снимок, который был текущим в то время, когда это вызывают.

Китайский календарь, все еще доступный

Несмотря на то, что существует константа для него, китайский календарь не доступен от NSCalendar или связал APIs все же. В 10,5, пытаясь создать NSCalendar, с которым постоянный возвратит ноль (сбой).

Вычисления Calendrical

Некоторые calendrical вычисления были исправлены в 10,5. В частности - [NSCalendar rangeOfUnit:inUnit:forDate:] изменился на больше интерпретации сторонника буквального толкования «диапазона» для приложений, соединенных на или после 10.5.

Использованию NSCalendarDate обескураживают

Использованию класса NSCalendarDate снова обескураживают в 10,5, но это еще не осуждается. Это может быть в следующей главной версии ОС после 10.5. NSDateFormatter должен использоваться для форматирования даты, и NSCalendar должен использоваться для calendrical вычислений. Где форматирование отличается между NSCalendarDate, и NSDateFormatter (с 10.4 стилями), отличаются, результат NSDateFormatter будет считаться корректным результатом (отсутствующий осуществляемая ошибка). Где NSCalendar и вычисления NSCalendarDate calendrical отличаются, и результат NSCalendar разумен, мы определяем его значение, чтобы быть правильным значением. Разработчики должны отказаться от надежды на исправления ошибок NSCalendarDate.

Новый NSTimeZone API

- (NSTimeInterval)daylightSavingTimeOffsetForDate:(NSDate *)aDate;

- (NSDate *)nextDaylightSavingTimeTransitionAfterDate:(NSDate *)aDate;

Если нет никаких данных в течение того времени, первый метод возвращает смещение летнего времени из GMT в данный момент, или 0.0. Второй метод возвращается в следующий момент после данного времени, в которое летнее время происходит, или ноль, при отсутствии данных после того времени.

- (NSTimeInterval)daylightSavingTimeOffset;

- (NSDate *)nextDaylightSavingTimeTransition;

Эти два являются удобными методами для двух выше с датой, взятой, чтобы быть текущим временем.

enum {

    NSTimeZoneNameStyleStandard,

    NSTimeZoneNameStyleShortStandard,

    NSTimeZoneNameStyleDaylightSaving,

    NSTimeZoneNameStyleShortDaylightSaving

};

typedef NSInteger NSTimeZoneNameStyle;

- (NSString *)localizedName:(NSTimeZoneNameStyle)style locale:(NSLocale *)locale;

Этот API возвращает локализованную строку дисплея для данного часового пояса и локали в данном стиле. Если данные не существуют для той комбинации параметров, ноля возвратов.

NSTimeZone имеет следующее новое имя уведомления API:

NSString * const NSSystemTimeZoneDidChangeNotification;

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

Новый NSPortNameServer API

- (NSPort *)servicePortWithName:(NSString *)name;

Этот метод может использоваться для поиска автозапущенного порта услуг. Этот метод используется самой службой (если кто-либо) во время запуска для регистрации с launchd.

Новый API NSConnection

+ (id)serviceConnectionWithName:(NSString *)name rootObject:(id)root usingNameServer:(NSPortNameServer *)server;

+ (id)serviceConnectionWithName:(NSString *)name rootObject:(id)root;

Эти новые методы используются для создания нового NSConnection автозапущенным процессом службы для услуги, которую они предоставляют. Соединение сконфигурировано с данным корневым объектом.-registerName: не должен использоваться с таким NSConnection и-setRootObject: является ненужным. Это также регистрирует службу с launchd.

Новый NSRunLoop APIs

+ (NSRunLoop *)mainRunLoop;

Возвращает объект цикла выполнения основного потока. В настоящее время этот метод имеет сомнительное значение, так как некоторая функциональность NSRunLoop не ориентирована на многопотоковое исполнение (все «выполняют» функциональность в NSRunLoop.h, например).

NSString * const NSRunLoopCommonModes;

Это - новая константа для NSRunLoop, соответствующего kCFRunLoopCommonModes константе CFRunLoop. Обратитесь к документации CFRunLoop для получения дополнительной информации.

NSURLConnection (Обновленный начиная с WWDC 2007)

NSURLConnection теперь поддерживает планирование на отдельные выполненные циклы. Если делегат хочет получить сообщения делегации на потоке кроме текущего потока, они могут создать соединение с помощью-initWithRequest:delegate:startImmediately: указание НЕ для последнего параметра (startImmediately). Они могут тогда выбрать, где запланировать методы делегации с помощью-scheduleInRunLoop:forMode: и-unscheduleFromRunLoop:forMode:. Как только соединение было запланировано, оно может быть запущено с помощью - запускаются. Как только соединение было запущено, его планирование не может быть изменено.

Новые константы NSURLRequestReloadIgnoringLocalAndRemoteCacheData и NSURLRequestReloadRevalidatingCacheData были добавлены к списку кэширующихся политик по NSURLRequest. Однако они не реализованы; они - просто заполнители в это время.

Метод делегата connection:willSendRequest:redirectResponse: изменил поведение в 10,5. Во-первых, если ноль был возвращен, до 10,5, его поведение было противоречиво; иногда нулевой возврат отменял бы соединение, но иногда, нулевой возврат заставит соединение использовать данный неизмененный запрос. В 10,5., нулевой возврат будет всегда отменять соединение; это соответствует задокументированное поведение. Во-вторых, до 10,5, NSURLConnection часто изменял бы поступление NSURLRequest до передачи, не уведомляя делегата. В 10,5, делегат всегда уведомляется через метод делегации connection:willSendRequest:redirectResponse:. Это означает, что делегат будет часто получать connection:willSendRequest:redirectResponse: сообщение перед соединением даже должным образом началось до передачи запроса к удаленному серверу. Это может быть удивительно к более старому коду, записанное принятие connection:willSendRequest:redirectResponse: если перенаправление произошло, будет только вызван. Для фиксации такого кода просто проверьте, является ли redirectResponse нолем. Если это, никакое перенаправление не произошло, и NSURLConnection просто сообщает делегату, что это изменило запрос до передачи. Если делегат не хочет вмешиваться, это должно возвратить неизмененный запрос. Вот пример:

- (NSURLRequest *)connection:(NSURLConnection *)connection

             willSendRequest:(NSURLRequest *)request

            redirectResponse:(NSURLResponse *)redirectResponse {

  if (redirectResponse) {

    // Handle the redirection; older code goes here

    ...

  } else {

    // Just being shown the final request prior to transmission

    return request;

  }

}

Новый APIs NSLocale

+ (NSArray *)commonISOCurrencyCodes;

Возвращает массив Кфстрингса, представляющего коды валют ISO для широко использующихся валют, который является более широко полезным набором, чем возвращенный +ISOCurrencyCodes.

+ (NSArray *)preferredLanguages;

Возвращает массив Нсстрингса, дающего предпочтительные идентификаторы языка пользователя, канонические, в порядке.

NSTimeZone имеет следующее новое имя уведомления API:

NSString * const NSCurrentLocaleDidChangeNotification;

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

+ (id)autoupdatingCurrentLocale;

Возвращает специальный экземпляр NSLocale, всегда отражающий текущее состояние настроек локали текущего пользователя. Это полезно в присвоении NSDateFormatter, например. Этот экземпляр автообновления, будет казаться, изменился к тому времени, когда NSCurrentLocaleDidChangeNotification отослан.

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

Методы, берущие параметры локали

Некоторые методы в Основе раньше брали NSDictionary * в качестве локали: (или Локаль:) параметр. Типы этих параметров на тех методах были изменены на ID. Например:

- (NSString *)descriptionWithLocale:(NSDictionary *)locale;        // previously

- (NSString *)descriptionWithLocale:(id)locale;                // now

Такие методы, реализованные в Основе теперь, принимают или словарь локали NSDictionary старого стиля или NSLocale * локаль. Использование NSLocales в новом коде мотивировано.

Обратите внимание на то, что некоторые существующие методы в Какао вводятся для взятия NSLocale * параметр локали, и они все еще только принимают объект NSLocale.

Методы, берущие словари локали, которые не находятся в Основе, CoreData или AppKit (Само какао) были не обязательно улучшены с этой возможностью. Это включает переопределения этих методов в подклассах, которые не находятся в Какао.

-descriptionWithLocale NSDATE: принимает также, но игнорирует параметры словаря локали в 10,5 и позже, давая результаты на основе локали текущего пользователя для ненулевых словарей локали. Объекты NSLocale как параметр соблюдают.

Наконец обратите внимание на то, что класс NSCalendarDate все еще только берет параметры локали стиля словаря локали старого стиля для своих методов, берущих локали.

Избегите NSMessagePort

Существует мало причины использовать NSMessagePort, а не NSMachPort или NSSocketPort. Нет никакого определенного преимущества производительности или функциональности. Мы рекомендуем избежать его. Это может быть осуждено в следующей главной версии ОС после 10.5.

Избегите 'долго дважды' и типы '_Complex'

Мы строго рекомендуем избежать всего использования «длинного двойного» типа и различных типов C99 «_Complex» кроме - самое большее - чисто локальное вычислительное использование. В частности мы рекомендуем не использовать его для типов параметра; не используя его для возвращаемых значений; не используя или передающие указатели для длинного удвоения или типы _Complex; использование массивов длинных удваивается, или типы _Complex или массивы указателей на длинный удваивается или типы _Complex как параметры; не встраивание долго удваивается, или типы _Complex или указатели на длинный удваивается или типы _Complex в структурах, передающихся как параметры или возвращающихся как возвращаемые значения, ни указатели использования на такие структуры; не использование долго удваивается или типы _Complex как типы переменных экземпляра объекта; и т.д. Не смешивайте вызовы метода Objective C или переменные с немного долго дважды или использование типа _Complex; другими словами, и не пытайтесь использовать, долго удваивается или типы _Complex с любым Какао API. Можно заметить, что Какао не предлагает, любой «долго удваивается», или «_Complex» вводят APIs (такой как в NSNumber) - мы избегаем их также.

Часть проблемы - то, что компилятор испускает «d» (дважды) как строку кодирования типа для @encode (долго дважды), таким образом, нет никакого способа различить эти два, и это влияет на все, что использует строки кодирования типа Objective C, включая кодирование значения ключа, передачу и архивацию. Если компилятор должен был когда-либо фиксировать это теперь, приложение, использующее долго дважды, будет иметь проблемы совместимости на уровне двоичных кодов.

Так же для типов _Complex, компилятор испускает «» (пустая строка) для @encode (_Complex {плавание, дважды, долго удваивается}). Таким образом эти типы абсолютно невидимы в параметрах метода и кодировках структуры и т.д. Это не вызывает конца опустошения.

NSMethodSignature, NSInvocation

NSMethodSignature и NSInvocation были переписаны в 10,5. Это, вероятно, означает, что существуют некоторые вещи, ведут себя по-другому на 10,5, чем они сделали на 10,4. В частности были некоторые исправленные ошибки, но могут быть другие тонкие изменения, недокументированные способы поведения, на которые Вы, возможно, полагались. Если Вы хотите, чтобы Ваше приложение работало хорошо на 10,4 и 10.5, несомненно, протестируют на обоих.

NSInvocation отмечает на установке и отставании параметров и возвращаемых значений (Новый начиная с WWDC 2007)

В 10,5, NSInvocation не сохраняет параметры или возвращаемые значения, если-retainArguments не вызывают на нем. Основная цель-retainArguments состоит в том, чтобы заставить вызов получения копировать или содержать на определенные типы параметров, пока вызов остается в силе. Вы сделали бы это при сохранении вызовов для более позднего использования или какого-либо использования на другом потоке. Например, Вы обычно хотели бы использовать это, даже если, синхронно ожидая на одном потоке вызова, чтобы закончить вызываться на другого, так как пулы автовыпуска и сборщик «мусора» на другом потоке очищают объекты асинхронно с потоком ожидания.

К сожалению, существует слишком много неоднозначности и исторической совместимости на языке Objective C и библиотеках для NSInvocation для «разбираний в этом» все время для всех. Например, для некоторых методов, можно хотеть возвращаемое значение указателя, сохраненное и возвращенное неизменный, и для других, Вы могли бы хотеть, чтобы указанный элементы был скопирован мелко, или в других случаях глубоко, для сохранения указываемых данных. В различных контекстах можно даже хотеть различные способы поведения от NSInvocation для того же вызываемого метода. Таким образом, NSInvocation реализует некоторые универсальные обычно полезные способы поведения. Некоторые из этих способов поведения могут варьироваться от тех на 10,4 и ранее, которые были немного больше оперативно.

В 10,5, типы кандидата для отставания являются объектом Objective C [указатель] типы, массивы фиксированной длины и струны до. Обратите внимание на то, что существует свойственная неоднозначность в типе «символ *», который может по-разному означать, в Objective C, «указатель на единственный символ», «указатель на массив символа некоторой известной длины», и «указатель на завершенный нулем массив символа». Компилятор Objective C и время выполнения исторически принял решение интерпретировать «символ *» (и изменения) как струна до (завершенный нулем массив) указатель, и эта традиция продолжается. Вы не можете использовать другие две интерпретации ни с чем, что использует метаданные типа выполнения, такие как передача кодирование значения ключа или (NSInvocations).

Для объекта Objective C [указатель] вводят, как «NSArray *», объекты параметра и эхо-сигналы сохраняются, когда был вызван-retainArguments. Для массивов фиксированной длины, не встроенных в структуру, копируется массив, и указатель на копию становится новым параметром или возвращаемым значением. Для струн до копируется струна до, и указатель на копию становится новым параметром или возвращаемым значением. NSInvocation также, рекурсивно, сохраняет (или копии) объект Objective C и типы струны до в структуре C и аргументах Array C и возвращаемых значениях (массивы фиксированной длины, встроенные в структуре, являются частью структуры).

Другое использование указателя не является кандидатами на отставание. Например, если метод берет «интервал *» параметр, NSInvocation не принимает мер (даже когда-retainArguments вызвали) копировать/сохранять интервал, на который указывает тот указатель. Если Вы вручную устанавливаете тот параметр (-setArgument:atIndex:), Вы устанавливаете указатель только, не [также] указываемое значение (и конечно, начиная с первого параметра-setArgument:atIndex: указатель на значение, которое будет установлено, это должен быть указатель на указатель на интервал, который будет установлен, не сам указатель на интервал). Это поведение некопирования обычно desireable, так как Вы обычно не хотите, чтобы NSInvocation попытался скопировать FILE * или объект C++ (который, насколько затронуто время выполнения Objective C, просто указатель на структуру, и никакой конструктор копии не был бы вызван), значение параметра или возвращаемое значение.

Арифметические типы естественно сохраняются/копируются вследствие их простого характера, когда установлено или получено как часть передачи или вызова NSInvocation. Когда-retainArguments был вызван, структуры, переданные значением, также сохраняются/копируются.

Обратите внимание на то, что для объекта вызова, сказанного-retainArguments, которому установили параметры на нем многократно, или вызывается многократно, накапливает те retainable параметры и возвращаемые значения, и содержит их для времени жизни вызова.

Для несколько более высокой степени безопасности/совместимости, для приложений, соединенных на или прежде 10.4, NSInvocations автоматически сохраняют возвращаемые значения после того, как - вызовут.

Новый NSMethodSignature API

+ (NSMethodSignature *)signatureWithObjCTypes:(const char *)types;

Этот метод, доступный начиная с OS X v10.0, был представлен. Метод создает NSMethodSignature для данной строки типа метода Objective C. Это - полностью ответственность вызывающей стороны передать в строках типа, которые являются или от текущих данных во время выполнения или соответствуют стиль строки типа в использовании ко времени выполнения, на котором работает приложение. Только введите строки кодирования стиля времени выполнения, против которого работает приложение, поддерживаются. Если Вы Вы можете быть неприятно удивлены какими-либо изменениями в строках кодирования типа, которых тип метода твердого кода представляет в виде строки в Вашу платформу или приложение и попытку использовать этот метод. В представлении этого метода нет никакой приверженности двоичному файлу compatibily поддерживающий строки кодирования типа «старого стиля» после того, как произойдут такие изменения.

Новые методы класса NSObject для разрешения методов во время выполнения

Objective C теперь дает классу возможность динамично разрешить реализации метода во время выполнения. Класс может переопределить +resolveInstanceMethod: и используйте class_addMethod () для добавления реализации метода к классу. +resolveClassMethod: также предоставлен для того, чтобы динамично разрешить методы класса. Эти методы вызываются, прежде чем передающее машинное оборудование вызывается, когда объект не реализует метод.

Оба метода возвращаются, BOOL раньше указывал, был ли разрешен рассматриваемый селектор. Если метод возвратится то нет, время выполнения Objective C передаст управление к передающему механизму метода. Если это будет разрешено, то метод будет вызван. После того, как разрешенный, все будущие вызовы непосредственно выполнят методы тем же способом, что выполняется любой другой метод. Обычно необходимо вызвать реализацию super этого метода сначала, чтобы дать суперклассу шанс разрешить сам метод. Если это возвращается ДА, Вы не должны должны быть делать что-либо сами, просто возвращать YES назад Вашей вызывающей стороне. Класс NSObject реализует эти методы с реализацией по умолчанию, возвращающейся НЕ сегодня, хотя необходимо все еще вызвать его даже при просто прямом разделении на подклассы NSObject.

Новый передающий быстрый путь

Когда передающий механизм вызывается (т.е. когда объект не реагирует на сообщение, отправленное в него), передающий механизм в 10,5 первых попытках отправить это сообщение в исходный объект получателя сообщения:

- (id)forwardingTargetForSelector:(SEL)sel;

Если объект реализует (или наследовался), этот метод, и возвращает неноль и несам результат, тот возвращенный объект используется в качестве нового объекта получателя и резюме отгрузки сообщения тому новому объекту. (Очевидно, если бы 'сам' были позволены быть возвращенным из метода, то код просто попал бы в бесконечный цикл.) Таким образом этот метод дает объекту шанс перенаправить неизвестное сообщение, отправленное в него перед намного более дорогим forwardInvocation: машинное оборудование вступает во владение. Это полезно в основных ситуациях с проксированием и может быть порядком величины быстрее, чем регулярная передача. Не полезно, где цель передачи состоит в том, чтобы получить NSInvocation или управлять параметрами или возвращаемым значением во время передачи.

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

Старый форвард:: метод Objective C

Время выполнения Objective C больше не пытается вызвать - вперед:: метод на объекте, когда объект не реагирует на сообщение, отправляющееся в него. Какао заменяет передающий механизм времени выполнения полностью его собственной версией в 10,5, который распространяет известный methodSignatureForSelector: и forwardInvocation: методы к объектам, таким образом, они могут передать методы.

Изменения в NSZombie отлаживают механизм

NSZombieEnabled теперь работает на объекты генерала Кфтайпа, включая бесплатные соединенные мостом. Если NSZombieEnabled установлен в «YES», то переменная окружения CFZombieLevel проигнорирована.

В 10,5, когда зомби включают, сообщение, что-то вроде этого регистрируется, и прерывание отладчика вызывается:

2006-09-09 19:24:31.122 MyTestApp[402] *** -[NSURLConnection release]: message sent to deallocated instance 0x2141e30

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

NSPropertyListSerialization (Обновленный начиная с WWDC 2007)

В предыдущей информации о версии в информации о версии Основы Leopard было сказано, что утечка была фиксирована в двух методах NSPropertyListSerialization, возвращающих NSString * описание ошибки ссылкой. Эта фиксация вернулась и никогда не будет делаться. Как утверждено в документации для тех методов, и как была истина в 10,4 и ранее, это - ответственность клиента выпустить ту строку (если любой метод возвращает ноль) в 10,5 и вне также.

Имена NSTimeZone не могут быть нолем

Методы NSTimeZone:

- (id)initWithName:(NSString *)tzName;

- (id)initWithName:(NSString *)tzName data:(NSData *)aData;

и косвенно, любые методы класса, вызывающие их, теперь настаивают на tzName и aData параметрах, не являющихся нолем. В предшествующих версиях ОС это вызвало бы катастрофический отказ. В 10,5 и позже, это - теперь более явно исключение недействительного аргумента.

Изменения поведения метода NSDate (Обновленный начиная с WWDC 2007)

Методы NSDate, берущие NSDate * параметр, исторически имели неопределенный / произвол когда переданный ноль. В частности они имели бы тенденцию использовать непредсказуемое значение с плавающей точкой для timeIntervalSinceReferenceDate ноля. Теперь они ведут себя, как будто временным интервалом ноля является NaN.

При сравнении с нолем или NSDate с NaN как его временной интервал, последовательно возвращается NSOrderedSame. Ранее возвращаемое значение было немного произвольно. Однако ноль не равен никакому объекту даты, и только дата NaN-содержания может быть равна дате NaN-содержания.

-earlierDate: и-laterDate: методы имели тенденцию возвращать свои параметры, когда переданный ноль, NaN-содержание NSDate или дата, которая была равна получателю, но не во всех случаях. В 10,5 и позже, эти методы возвращают объект получателя для этих неоднозначных случаев.

NSString

Существует несколько новых значений NSStringEncoding:

NSUTF16StringEncoding

NSUTF16BigEndianStringEncoding

NSUTF16LittleEndianStringEncoding

NSUTF32StringEncoding

NSUTF32BigEndianStringEncoding

NSUTF32LittleEndianStringEncoding

NSUTF16StringEncoding является просто псевдонимом для существующего NSUnicodeStringEncoding.

При создании NSString из байтов NSUTF16BigEndianStringEncoding и NSUTF16LittleEndianStringEncoding позволяют Вам указать порядок байтов потока UTF-16 байтов явно, не консультируясь с символом BOM. Обратите внимание на то, что как следствие, если будет символ BOM в потоке, то он будет интерпретирован как фактический символ и включен в создаваемый NSString.

NSUTF32StringEncoding, NSUTF32BigEndianStringEncoding и значения NSUTF32LittleEndianStringEncoding подобны их дубликатам UTF16, кроме они работают с 4-байтовыми символами Unicode.

Несмотря на то, что эти имена кодирования представляются в заголовках Leopard, фактические значения действительно работают назад Тайгеру.

NSProprietaryStringEncoding был осужден, так как он фактически не использовался вообще с тех пор 10.0.

Разъяснение: maxLength параметр getCString:maxLength:encoding: потребности разместить и возвращенные байты и дополнительный байт NULL. В этом отношении этот метод ведет себя по-другому, чем осуждаемый getCString:maxLength: метод.

Предыдущая документация и комментарий в NSString.h были оба неправильными в этом отношении. Вместо того, чтобы изменять реализацию и представлять проблемы совместимости, мы обновляем документацию.

NS и CFString теперь проверяют большинство неизменных запросов создания по ряду «популярных» строк, и в некоторых случаях возвратят предварительно создаваемую строку. То, что это означает, - то, что теперь более вероятно, что два отличных запроса создания на NS или CFString с тем же содержанием могли бы возвратить ту же точную строку; не рассчитывайте на неравенство указателя в тех случаях. Также возможно, что в тех случаях любой разбалансировался, сохраняют/выпускают запросы, останется незамеченным.

Обратите внимание на то, что набор «популярных» строк изменится между выпусками, не делайте предположения о том, какие строки совместно используются на основе наблюдений относительно Leopard. Фактически, набор был обновлен значительно между семенем 2007 года WWDC и заключительным выпуском Leopard.

Следующий новый метод включает удобный способ, увеличивают диапазон для включения всех составленных последовательностей символов, которые это перекрывает. Это может использоваться с substringWithRange: и т.д., для возвращения «надлежащих» подстрок, не повреждающих составленные последовательности символов:

- (NSRange)rangeOfComposedCharacterSequencesForRange:(NSRange)range;

Для удобства диапазон нулевой длины обрабатывается как диапазон с 1 длиной, кроме тех случаев, когда диапазон в конце строки (так, {длина, 0}), когда это возвратит {длину, 0}. Таким образом для строки «abc», {0,0} возвратится {0,1}, и {3,0} возвратится {3,0}.

Следующий метод включает инкрементному преобразованию кодирования Нсстрингса. Передайте желаемый диапазон, который будет преобразован и возвратите остающийся диапазон. Этот метод возвращает YES, если он смог преобразовать какие-либо символы, даже если он должен был остановиться в неконвертируемом символе. (Это означало бы, что следующее преобразование возвратится НЕТ.)

enum {

  NSStringEncodingConversionAllowLossy = 1,

  NSStringEncodingConversionExternalRepresentation = 2

};

typedef NSUInteger NSStringEncodingConversionOptions;

- (BOOL)getBytes:(void *)buffer

       maxLength:(NSUInteger)maxBufferCount

      usedLength:(NSUInteger *)usedBufferCount

        encoding:(NSStringEncoding)encoding

         options:(NSStringEncodingConversionOptions)options

           range:(NSRange)range

  remainingRange:(NSRangePointer)leftover;

Несмотря на то, что этот метод был разглашен в 10,5, он действительно существует назад к 10,4.

Следующий метод возвращает массив строк, следующих из деления получателя как componentsSeparatedByString: делает, но на границах, идентифицированных любым из символов в параметре.

- (NSString *)componentsSeparatedByCharactersInSet:(NSCharacterSet *)set;

Следующие методы для различных удобных замен в NSString. Они уже существуют в NSMutableString.

- (NSString *)stringByReplacingOccurrencesOfString:(NSString *)target

                    withString:(NSString *)replacement

                      options:(NSUInteger)optionMask

                       range:(NSRange)searchRange;

- (NSString *)stringByReplacingOccurrencesOfString:(NSString *)target

                    withString:(NSString *)replacement;

- (NSString *)stringByReplacingCharactersInRange:(NSRange)range withString:(NSString *)replacement;

longLongValue анализирует длинное долго из строки, с помощью «свободных» правил во многом как существующий intValue и floatValue методы. Пропустит начальные белые символы (whitespaceSet) и проигнорирует символы после числа. Используйте NSScanner для более формализованного парсинга:

- (long long)longLongValue;

boolValue проанализирует булевскую переменную. Пробелы начальной буквы пропусков (whitespaceSet), или дополнительный - / + знак, сопровождаемый, обнуляют. Возвраты YES при обнаружении с одним из «Y», «y», «T», «t», или цифра 1-9. Это игнорирует любые конечные символы.

- (BOOL)boolValue;

Следующее новое определение типа используется в APIs NSString для указания параметров, берущих комбинацию, сравнивают опции (такие как NSCaseInsensitiveSearch, NSBackwardsSearch, и т.д.):

typedef NSUInteger NSStringCompareOptions;

NSString теперь поддерживает символы форматирования %L, %a, %A, %F, %z, %t, и %j при форматировании строк. %n, никогда не работавший должным образом (он всегда возвращал значение нуля), теперь отключен для приложений, соединенных на Leopard. %n в строке формата все еще обрабатывается как прежде, но соответствующий параметр больше не пишется в.

Параметр локали за-compare:options:range:locale: теперь принимает NSLocale. Когда ноль, это выполняет нелокализованное сравнение. Для обратной совместимости это обрабатывает объекты non-NSLocale, как будто это + [NSLocale currentLocale].

Существует новый метод поиска, берущий параметр локали. Когда ноль, это выполняет нелокализованный поиск.

- (NSRange)rangeOfString:(NSString *)aString options:(NSUInteger)mask range:(NSRange)searchRange locale:(NSLocale *)locale;

Следующие новые константы представлены для искать/сравнивать флага опции.

Проигнорируйте диакритические знаки (o-умляут == o):

NSDiacriticInsensitiveSearch = 128

Проигнорируйте различия в ширине (== UFF41):

NSWidthInsensitiveSearch = 256

Сравнения силы для возврата или kCFCompareLessThan или kCFCompareGreaterThan, если строки эквивалентны, но не строго равны для устойчивости при сортировке (например, «aaa»> «AAA» с указанным kCFCompareCaseInsensitive):

NSForcedOrderingSearch = 512

Существует теперь метод символы «сворачивания»:

- (NSString *)stringByFoldingWithOptions:(NSUInteger)options locale:(NSLocale *)theLocale;

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

Поддержка кодирования файла простого текста NSString

Методы writeToFile:atomically:encoding:error: writeToURL:atomically:encoding:error: осуждаемый writeToFile:atomically: и writeToURL:atomically: теперь сохраните указанное кодирование файлом в расширенном атрибуте. Методы initWithContentsOfFile:usedEncoding:error: initWithContentsOfURL:usedEncoding:error: и их stringWith... дубликаты используют эту информацию для открытия файла с помощью правильного кодирования.

Расширенный атрибут сохранен под именем «com.apple. TextEncoding». Значение содержит имя IANA для кодирования и значение CFStringEncoding для кодирования, разделенного точкой с запятой. Значение CFStringEncoding записано как строка ASCII, содержащая 32-разрядное десятичное целое число без знака. Строка не завершается символом NUL.

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

Примеры значения, записанного в расширенные атрибуты, включают:

MACINTOSH;0

UTF-8;134217984

UTF-8;

;3071

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

initWithContentsOfURL:encoding:error: initWithContentsOfURL:usedEncoding:error: и их stringWith... дубликаты теперь работают с данными, которые являются сжатым http, распаковывая его сначала в случае необходимости. initWithContentsOfURL:usedEncoding:error: и его stringWith... дубликат теперь пытаются поднять текстовое кодирование с http заголовков.

В отсутствие всей другой информации о кодировании, куда они возвратили бы ноль в Тайгере, initWithContentsOfFile:usedEncoding:error: initWithContentsOfURL:usedEncoding:error: и их stringWith... дубликаты теперь пробуют UTF-8 как нейтрализацию. Так любой файл ASCII или файл, который похож, допустимый поток UTF-8 загрузят и сообщат как UTF-8.

Осуждения NSString

NSString cString и связанные методы, осужденные с тех пор 10.4, теперь формально отмечены, как осуждается. Все устаревшие методы имеют более новые дубликаты (добавил 10.4 или ранее), которые берут явные параметры кодирования.

NSMaximumStringLength теперь осуждается. Это не работает в приложениях на 64 бита. Используйте NSUIntegerMax вместо этого.

NSAttributedString

Методы создания initWithString:attributes: и initWithString: теперь проверьте на нулевой аргумент строки и журнал (только один раз на сеанс). Намерение состоит в том, чтобы иметь это повышение, исключение для приложений соединило пост-Leopard.

NSCharacterSet

NSCharacterSet теперь имеет новый метод фабрики, +newlineCharacterSet.

Тип возврата для всех методов фабрики является теперь (ID) вместо этого (NSCharacterSet *) избавлением от необходимости кастинг при создании непостоянных экземпляров.

NSScanner

Следующий метод походит на scanHexInt::

- (BOOL)scanHexLongLong:(unsigned long long *)result;

Следующие значения с плавающей точкой шестнадцатеричного формата сканирования, выписанные с %a или %A, форматируют символы в NSString или printf (). Они требуют префикс 0X или 0x:

- (BOOL)scanHexFloat:(float *)result;

- (BOOL)scanHexDouble:(double *)result;

CFError

Новый тип CoreFoundation, CFError, был добавлен для управления обработкой ошибок. Это бесплатное соединенный мостом с NSError и обеспечивает тот же уровень функциональности.

Мы не ожидаем, что приложения Какао сделают прямое использование CFError, но мы упоминаем его здесь, так как это действительно позволяет неоснове низшего уровня, базируемой APIs обеспечить ошибки, которые могут быть автоматически представлены ошибочным представлением и погрузочно-разгрузочным оборудованием Какао.

Как с NSError, провайдеры CFErrors призваны удостовериться, что ошибки имеют презентабельные пользователем сообщения об ошибках, позволяющие им быть подаренными минимальную дополнительную работу.

NSError

NSError теперь имеет два дополнительных кода к для дополнительных состояний ошибки на чтении файла: NSFileReadTooLargeError, NSFileReadUnknownStringEncodingError.

NSValue

NSValue теперь предоставит лучшие описания для часто используемых структур, таких как NSRect, NSSize, NSPoint и NSRange.

NSPredicate

Были добавлены два новых оператора: NSContainsPredicateOperatorType предназначается для дополнения NSInPredicateOperatorType, так как IN и CONTAINS не являются непосредственно обратимыми, когда модификаторы предиката рассматривают (т.е. 'ANY X в Y' не достигает того же эффекта, как 'ANY Y содержит X'). NSBetweenPredicateOperatorType допускает более упрощенную конструкцию и оценку общего типа составного предиката, имеющего прямое отображение в некоторых внешних технологиях, к которым предикаты являются отображаемыми (т.е. X BETWEEN {LOWERBOUND, UPPERBOUND}). Между также допускает более эффективные операции базы данных, чем (x> =, понижают && x <= верхний) вследствие обработки индексов.

Следующий новый метод оптимизирован для ситуаций, требующих неоднократно оценки предиката с переменными замены с различными подстановками переменных:

- (BOOL)evaluateWithObject:(id)object substitutionVariables:(NSDictionary *)variables;

Оценивает указанный объект, занимающий место в значениях в словаре переменных для любых заменяющих маркеров. Этот метод возвращает тот же результат как два процесса шага первого вызова predicateWithSubstitutionVariables: и затем вызов evaluateWithObject:.

NSCompoundPredicate

Для приложений, соединенных на OS X v10.5 «Leopard» или позже, инициализируя NSCompoundPredicate теперь, копирует массив подпредикатов вместо того, чтобы сохранить его. Приложения, соединенные на OS X v10.4 «Тигр», продолжают только сохранять массив подпредикатов для совместимости на уровне двоичных кодов.

NSExpression

Новые типы выражения NSSubqueryExpressionType, NSAggregateExpressionType, NSUnionExpressionType, NSIntersectExpressionType и NSMinusExpressionType разрешают CoreData генерировать намного более эффективный SQL. На 10,4, работающий вокруг отсутствия этих операций требует, чтобы разработчики выбрали промежуточные результаты (обернутый как объекты) и выполнили некоторые операции в памяти, повлиявшей на масштабируемость. С этими выражениями CoreData может разгрузить существенно больше работы над базовой базой данных и избежать приносить иначе ненужные строки в память.

NSExpression теперь также имеет конструктора для NSFunctionExpressionType, позволяющего создать Ваши собственные функции для использования в оценке предиката.

Сценарии

Улучшенная ошибка при обнаружении и создании отчетов в Scriptability

В OS X 10.5 много улучшений были сделаны к обнаружению Сценариев Какао и созданию отчетов ошибок. Среди них:

• Механизм какао для преобразования спецификаторов объекта-события Apple к NSScriptObjectSpecifiers и оценке их теперь ограничивает себя использованием кодов стандартной погрешности, перечисленных в документации AppleScript при создании отчетов об ошибках, и всегда пытается выбрать самую дескриптивную. Ваши сценаристы не должны будут выяснять что «NSReceiverEvaluationScriptError: 4 дюйма означают больше. Можно сделать то же в коде приложения; это абсолютно допустимо для передачи кодов ошибки, объявленных в <CarbonCore/MacErrors.h> к - [NSScriptCommand setScriptErrorNumber:] или - [NSScriptObjectSpecifier setEvaluationErrorNumber:].

• Оценка NSIndexSpecifier теперь делает намного лучшую проверку диапазона и будет всегда возвращать ошибку для недопустимого индекса вместо того, чтобы ничего иногда не возвратить.

• Конструкция NSPositionalSpecifier и оценка теперь проверяют на ерунду и возвращают ошибки вместо того, чтобы позволить реализациям команды, зависящим от него сбой или неправильное функционирование необъяснимыми способами. Например, сообщение TextEdit 'сделать новое окно в перед словами переднего документа' больше не создает новое окно и пытается вставить его в слова переднего документа (!). Теперь это приводит к «TextEdit, получил ошибку: не Может сделать или переместить тот элемент в тот контейнер».

• NSSpecifierTest улучшил проверку типа. Например, сообщение TextEdit 'получить каждое слово переднего документа, где это - окно переднего документа', раньше ничего не возвращало. Теперь это приводит к «TextEdit, получил ошибку: не Может превратить окно документа 1 в слово типа».

• Оценка NSWhoseSpecifier теперь возвращает ошибки для многих конструкций, которые недопустимы, вместо того, чтобы возвратить мусор. Например, когда передний документ TextEdit содержит текст «Быстрая коричневая лиса, перепрыгнул через ленивую собаку», говоря TextEdit 'получить четвертое слово переднего документа, третий символ которого является «e»', раньше возвращался, даже при том, что не было фактически никакого четвертого слова, третий символ которого является «e» вообще. Теперь это приводит к «TextEdit, получил ошибку: не Может получить Word 4 документа 1 чей символ 3 = «e». Недопустимый индекс».

• Поскольку объектное машинное оборудование спецификатора теперь намного лучше в записи, когда ошибки произошли, машинное оборудование выполнения команды теперь ведет себя более очевидно. Например, сообщение TextEdit 'переместить окно «There is no window with this name!» в начало каждого окна' раньше ничего не делало. Теперь это приводит к «TextEdit, получил ошибку: не Может получить окно «There is no window with this name!»».

Исправления ошибок в .sdef-заявленном Scriptability

Поддержка парсинга .sdef файлов была добавлена к поддержке Сценариев Какао в OS X 10.4. Некоторые существенные ошибки были исправлены в OS X 10.4.3:

• Обработка, пунктов которой, имеющих несопоставленные но совместимые объектные спецификаторы теперь, работает. Например, отправка «первого абзаца theDocument, последнее слово которого равно абзацу 3 theDocument» к версии TextEdit, scriptability которого не объявляется с .sdef файлом больше, приводит к «TextEdit, получил ошибку: не Может превратить абзац 3 документа 1 в слово типа».

• Сделайте команды с «с данными» параметр, значение которого является объектным спецификатором, теперь работают. Например, отправка «делает новое слово в конце документа 2 с данными первым словом документа 1» версии TextEdit, scriptability которого объявляется с .sdef файлом, больше не приводит к «TextEdit, получил ошибку: не Может превратить Word 1 документа 1 в слово типа».

• Команды количества теперь возвращают корректные результаты вместо списков, содержащих корректные результаты.

В OS X 10.4 машинное оборудование, преобразовывающее объекты Objective C в дескрипторы события Apple, не принимало во внимание вложение объектов в массивах должным образом в приложении, scriptability которого объявляется в .sdef файле, таким образом говоря, что Эскиз 2 для получения «каждой диаграммы каждого документа» возвратил ошибку. Эта ошибка была исправлена в OS X 10.5.

В OS X 10.4 машинное оборудование, преобразовывающее дескрипторы события Apple в объекты Objective C, не всегда принимало во внимание возможность оценки объектного спецификатора сразу для получения значения. Например, сообщение документа Эскиза 'установить цвет заливки графического 1 к цвету заливки графических 2' всегда перестало работать, независимо от сколько графики, там были в документе. Для другого примера, этого простого сценария:

tell application "Sketch"

    set theDocument to make new document

    set theWindow to the first window whose name is the name of theDocument

end tell

Возвращенный «Эскиз получил ошибку: не Может сделать имени документа, «Неназванного» в строку типа, даже при том, что тип имени документа является, конечно, строкой. Эта ошибка была исправлена в OS X 10.5.

Исправление ошибки в - .scriptSuite/.scriptTerminology-заявленный Scriptability

Во всех предыдущих версиях OS X была ошибка, в которой определение действительно ли команда имела результат, который должен быть вставлен, событие Apple ответа было сделано с помощью типа возврата метода обработки команды сценария первого получателя вместо .scriptSuite-заявленного типа результата команды. Это вызвало бы, например, результат сообщения TextEdit «закрыть каждое окно», чтобы быть списком отсутствующих значений, один на окно. Эта ошибка была исправлена в OS X 10.5. Сообщение TextEdit закрыть каждое окно теперь не помещает результата в событие Apple ответа. Для обратной совместимости на уровне двоичных кодов старое поведение остается в приложениях, соединенных против OS X 10.4 или ранее (потому что ошибка могла замаскировать недостающие описания типа результата в .scriptSuite файлах).

Исправления ошибок в генерале Скриптэбилити (Обновленный начиная с WWDC 2007)

Когда получатели были глубоко вложены в других объектах, во всех предыдущих версиях OS X команда количества не работала должным образом. Например, в то время как Эскиз всегда возвращал корректное число, когда спросили возвратить «количество каждой текстовой области каждого документа», это всегда возвращало то же самое число, когда спросили возвратить «количество слов каждой текстовой области каждого документа», который был неправильным. Эта ошибка была исправлена в OS X 10.5.

Индексные спецификаторы, следующие из использования повторения AppleScript с … в конструкции …, не обрабатывали глубокое вложение также. Например, говоря Эскизу сделать что-то с theGraphic в «повторении с theGraphic в каждой диаграмме каждого документа» пункт выдало бы исключение и возвратило бы очень недружелюбную ошибку сценаристу. Эта ошибка была исправлена в OS X 10.5.

Во всех предыдущих версиях OS X, оценка спецификатора которого не принимала во внимание факт, что нет ничего действительно неправильно с тестом, использующим свойство, не присутствующее на каждом протестированном объекте. Например, говоря документу Эскиза получить 'каждую диаграмму, текстовое содержание которой является «Некоторым текстом»'. возвращенный ошибка, если какая-либо графика не имела текстового содержания, как круги. В OS X 10,5 этих видов, того, спецификатор которых теперь возвращает соответствующие объекты вместо ошибки.

Аналогично, чья оценка спецификатора не принимала во внимание факт, что нет ничего действительно неправильно с тестом, использующим индексный спецификатор из диапазона. Например, сообщение документа TextEdit получить 'каждый абзац, где десятое слово его является «foo»', возвратило ошибку, если какой-либо из абзацев не имел десяти слов. В OS X 10,5 этих видов, того, спецификатор которых теперь возвращает соответствующие объекты вместо ошибки.

С тех пор - [NSObject (NSScripting) scriptingProperties] введение в OS X 10.2 это безвозмездно поймало и тихо глотало исключения, выданные его вызовами - [NSObject (NSKeyValueCoding) valueForKey:]. Это упростило пропускать недостающее KVC-соответствие в scriptable классах; получение «свойств» scriptable объекта без ошибки и никаких неправильных записей в возвращенной записи не означало, что все действительно работало должным образом (и абсолютно недостающие записи просто пропустить!). - [NSObject (NSScripting) setScriptingProperties:] пострадал от подобной проблемы. В OS X исправлены 10,5 этих ошибок. Для обратной совместимости на уровне двоичных кодов старое поведение остается в приложениях, соединенных против OS X 10.4 или ранее.

В последних версиях OS X была ошибка, предотвратившая NSPropertySpecifiers, указывающие все объекты в к - многие отношение, NSMiddleSpecifiers и NSRandomSpecifiers от того, чтобы быть должным образом преобразованным в дескрипторы события Apple. В результате AppleScript не мог обработать результат возврата одного из этих видов объектных спецификаторов от реализаций-objectSpecifier метода. Эта ошибка была исправлена в OS X 10.5.

Измененное Поведение - [NSSObject (NSScripting) setScriptingProperties:] (Новый начиная с WWDC 2007)

С тех пор - [NSSObject (NSScripting) setScriptingProperties:] был представлен в OS X 10.2, его реализация по умолчанию вызвала [сам coerceValue:theValue forKey:theKey] для каждой записи в переданном - в словаре свойств прежде, чем установить значение отдельного свойства в получателе. Реализации Сценариев какао стандартных команд (Копия, Сделайте, и Набор, в частности) не принуждал отдельные значения свойств прежде, чем вызвать его. Рассмотрение, что-setScriptingProperties: просто метод set «scriptingProperties» свойства, это поведение было противоречиво с тем, как установка значения свойств обычно делается Какао; в любом случае метод set передается результат применения приведения. Запускаясь в OS X 10.5, это несоответствие было фиксировано.-setScriptingProperties: теперь передается словарь, содержащий значения, уже принужденные, и реализация по умолчанию-setScriptingProperties: не делает никакого дальнейшего приведения. Для обратной совместимости на уровне двоичных кодов старое поведение остается в приложениях, соединенных против OS X 10.4 или ранее.

Поддержка скрытого атрибута в .sdef-заявленном Scriptability

Поддержка парсинга .sdef файлов была добавлена к Сценариям Какао в OS X 10.4, но .sdef синтаксический анализатор Какао проигнорировал все использование скрытого атрибута ('человек 5 sdef' для наблюдения, какие элементы могли быть скрыты). Это не влияло на появление scriptability приложения в 10.4's Редактор сценариев, потому что средство просмотра словаря Редактора сценариев делает свой собственный парсинг .sdef. Это действительно, однако, влияло на приложения сценариев, проанализировавшие ответ приложения Какао на событие Get Apple Event Terminology (kASAppleScriptSuite/kGetAETE). В OS X 10.5, Какао, Пишущее сценарий теперь, генерирует 'aete' данные, принимающие сокрытие во внимание путем помещения объявлений скрытых элементов терминологии сценариев в неявно скрытый комплект «Имен типов», где они могут быть найдены интерпретатором AppleScript, но не должны быть представлены пользователям путем сценариев средств просмотра словаря.

Сделайте Команды без «В» Параметре и Поддержке Атрибута Вставки вначале в .sdef-заявленном Scriptability (Новыми начиная с WWDC 2007)

.sdef формат файла не имеет никакого эквивалента записи LocationRequiredToCreate старого .scriptSuite формата, что означает, что команда Make «в» параметре является всегда дополнительной в приложениях с .sdef-заявленным scriptability. Когда сценарий отправляет команду Make без «в» параметре к приложению, реализация по умолчанию NSCreateCommand отправляет контейнер недавно-созданного-объекта - [NSObject (NSScriptKeyValueCoding) insertValue:inPropertyWithKey:] сообщение. Если бы класс контейнера не реализовывал-insertIn <Ключ>, в OS X 10.4 это привело бы к исключению: метод. В результате каждый класс scriptable контейнера должен был реализовать-insertIn <Ключ>: метод в течение каждого к - многие отношение (или, реже, переопределение insertValue:inPropertyWithKey:) быть корректным. Это было очень просто пропустить. В OS X 10.5, в приложениях с .sdef-заявленным scriptability, реализацией по умолчанию - [NSObject (NSScriptKeyValueCoding) insertValue:inPropertyWithKey:] теперь вызывает [сам insertValue:theNewObject atIndex:anIndex inPropertyWithKey:theKey] когда никакой-insertIn <Ключ>: метод реализован. Значением индекса управляет новый атрибут «вставки вначале» в <какао> подэлемент объявления <элемент> .sdef элемент. Значение по умолчанию атрибута является «нет», указывая, что индекс вставки для использования совпадает с текущим количеством связанных объектов. Если значение будет «да», то индекс вставки будет 0. Так, новыми объектами по умолчанию добавляются к концам списков элементов. В случаях, где это не является надлежащим, можно использовать «вставку вначале», чтобы объявить, что новыми объектами по умолчанию должен быть вставлен в начале списков элементов. Посмотрите, например, объявление «графического» элемента класса «документа» Эскиза в/Developer/Examples/AppKit/Sketch/Sketch.sdef.

Обновленная поддержка отвечания - к элементу в .sdef-заявленном Scriptability

.sdef формат файла был изменен в OS X 10.5. «отвечает - на» элементы, теперь имеют атрибут «команды» вместо атрибута «имени». Поскольку .sdef синтаксический анализатор Какао обратной совместимости на уровне двоичных кодов распознает любое имя для атрибута.

Поддержка динамического .sdef-заявленного Scriptability

Какао не обрабатывало записи Info.plist OSAScriptingDefinition, значения которых были «динамичными» в OS X 10.4. В OS X 10.5, Какао теперь использует OSACopyScriptingDefinition () функция для получения собственных .sdef данных приложения. Для «динамических» записей OSAScriptingDefinition Info.plist эта функция отправляет 'ascr'/'gsdf' событие Apple, таким образом, можно возвратить .sdef сценарии объявлений, вычисленных во время выполнения, для взятия плагина scriptability во внимание, например. Необходимо зарегистрировать обработчик для события Apple. Например, можно сделать это в-applicationWillFinishLaunching делегата приложения: метод:

// Register to provide .sdef data when asked by apps like Script Editor, or this app's own scripting machinery.

[[NSAppleEventManager sharedAppleEventManager] setEventHandler:self

                                                   andSelector:@selector(handleGetSDEFEvent:withReplyEvent:)

                                                 forEventClass:'ascr'

                                                    andEventID:'gsdf'];

И затем реализуйте соответствующий метод обработчиков:

- (void)handleGetSDEFEvent:(NSAppleEventDescriptor *)event withReplyEvent:(NSAppleEventDescriptor *)replyEvent {

    // Our dynamic sdef isn't really that dynamic, but you can see that you have a great deal of flexibility here.

    NSData *sdefData = [NSData dataWithContentsOfFile:[[NSBundle mainBundle] pathForResource:@"Sketch" ofType:@"sdef"]];

    [replyEvent setDescriptor:[NSAppleEventDescriptor descriptorWithDescriptorType:typeUTF8Text data:sdefData]

                   forKeyword:keyDirectObject];

}

Поддержка Включенного .sdef-заявленного Scriptability (Новый начиная с WWDC 2007)

В OS X 10.5 существует новый файл в/System/Library/ScriptingDefinitions/CocoaStandard.sdef, который можно импортировать из .sdef файла приложения, таким образом, это не должно повторно объявлять стандартные классы и команды. Вы импортируете его использование Xinclude, как это:

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE dictionary SYSTEM "file://localhost/System/Library/DTDs/sdef.dtd">

<dictionary title="Sketch Terminology" xmlns:xi="http://www.w3.org/2001/XInclude">

    <xi:include href="file:///System/Library/ScriptingDefinitions/CocoaStandard.sdef"

                 xpointer="xpointer(/dictionary/suite)"/>

    […Stuff that's not in the Standard Suite, including stuff in the Text Suite, if that's applicable…]

<dictionary>

XPointer обеспечивает большую гибкость в выборе который элементы от CocoaStandard.sdef фактически включать в объявление сценариев Вашего приложения. См. документацию для того стандарта.

Объявление команды Save в CocoaStandard.sdef требует, чтобы «saveable формат файла» тип был объявлен где-нибудь в Вашем .sdef. Посмотрите 'Поддержку «раздела As " Parameter of the Save Command ' ниже. См. также следующий раздел для получения информации о многократном использовании объявления CocoaStandard.sdef класса документа, все еще указывая определенный подкласс NSDocument, который необходим.

Поддержка Элементов Расширения Класса в .sdef-заявленном Scriptability (Обновленный начиная с WWDC 2007)

В OS X 10.5, .sdef синтаксический анализатор Какао понимает новый <дополнительный классом> элемент, позволяющий объявление дополнительных функций существующего класса. Его содержание и размещение идентичны тем из элемента «класса», но единственный допустимый атрибут, «расширяется», который является именем расширяемого класса. <Дополнительный классом> элемент может и обычно происходить в различном комплекте, чем исходный класс.

<Дополнительный классом> элемент может иметь <какао> подэлемент, имеющий атрибут «класса». Например:

<class-extension extends="document">

    <cocoa class="SKTDrawDocument"/>

    …

    </class-extension>

Значение атрибута «класса» должно быть именем класса Objective C, который является подклассом того, объявленного для расширяемого класса сценариев. Можно использовать это в приложениях, .sdef которых импортирует CocoaStandard.sdef, чтобы объявить, что подкласс NSDocument быть инстанцированным, когда сценарий говорит, что приложение «делает новый документ». (Объявление CocoaStandard.sdef класса документа не может возможно назвать класс Objective C более определенным, чем NSDocument.) Результат многократных <дополнительных классом> элементов, изменяющих класс Objective C того же класса сценариев, не определен.

Поддержка Элементов Синонима в .sdef-заявленном Scriptability (Новый начиная с WWDC 2007)

Поддержка парсинга .sdef файлов была добавлена к Сценариям Какао в OS X 10.4, но .sdef синтаксический анализатор Какао проигнорировал все использование <синоним> элемент. В OS X 10.5 синтаксических анализов Какао <синоним> элементы и использование коды события Apple, объявленные в них при преобразовании входящих событий Apple в NSScriptCommands.

Поддержка пользовательских типов значения в .sdef-заявленном Scriptability

В OS X 10.4, Вы могли поместить <тип значения>, элементы в .sdef и Какао Вашего приложения будут использовать их, но этой поддержке пользовательских типов значения недоставало двумя способами:

• Соответствующие скрытые классы не были помещены в 'aete', сгенерированный Сценариями Какао. Это означало, что AppleScript не распознает имя типа, если это не было то, объявленное самим AppleScript. В OS X 10.5 Какао теперь генерируют право 'aete' данные для <типа значения> объявления. (В OS X 10.5, AppleScript спрашивает приложения с .sdef-заявленным scriptability для их sdef данных вместо их 'aete' данных, таким образом, эта фиксация менее важна, чем это было, но это все еще могло бы влиять на некоторые инструменты сценариев.)

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

При помещении <тип значения> элемента в .sdef приложения также необходимо обеспечить методы, которые Какао может использовать для преобразования дескрипторов события Apple того типа к объектам Objective C и наоборот. Должен быть метод класса, имя которого соответствует образец +scripting <CondensedTypeName> WithDescriptor: где CondensedTypeName является именем типа с первой буквой каждого капитализируемого слова и удаленные пробелы. Какао отправляет +scripting <CondensedTypeName> WithDescriptor: сообщения к классу назвали в <какао> подэлемент <тип значения> рассматриваемый элемент, когда это должно преобразовать дескриптор события Apple в объект Objective C. Метод должен возвратить ноль для отказа и использовать в своих интересах регулярное приведение события Apple где применимо. Должен также быть метод экземпляра, имя которого соответствует образец - пишущий сценарий <CondensedTypeName> Дескриптор. Какао отправляет - пишущий сценарий <CondensedTypeName> сообщения Дескриптора к объектам, что это должно преобразовать в дескрипторы события Apple. Этот метод должен также возвратить ноль для отказа. Никакой вид метода не должен записывать информацию об ошибке в текущей команде сценария, когда это возвращает ноль.

См. NSColor_SKTScripting.m в/Developer/Examples/AppKit/Sketch для примера. Это - реализация Эскиза «типа значения» цвета RGB.

Поддержка типа отсутствующего значения в .sdef-заявленном Scriptability

В OS X 10.5 можно теперь использовать «отсутствующее значение» в качестве имени типа. Это соответствует Objective C класс NSNull. Вы будете обычно использовать его в качестве альтернативы в составном типе. Например, объявление свойства цвета заливки графического класса в Sketch.sdef теперь похоже на это:

<property name="stroke thickness" code="slwd">

    <type type="real"/>

    <type type="missing value"/>

    <cocoa key="scriptingStrokeWidth"/>

</property>

Это означает по крайней мере четыре вещи:

• AppleScript может установить штриховую толщину диаграммы или к числу или к отсутствующему значению.

• Метод, обеспечивающий соответствие KVC для установки значения для «scriptingStrokeWidth» ключа, должен быть подготовлен обработать или число с плавающей точкой или ноль. См. Эскиз - [SKTGraphic setScriptingStrokeWidth:], чтобы видеть, как это делает это.

• Методу получателя для «scriptingStrokeWidth» ключа позволяют возвратить или число с плавающей точкой или ноль. См. Эскиз - [SKTGraphic scriptingStrokeWidth].

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

Большая часть кода приложения, как предполагается, не должна иметь дело с NSNull, поэтому каждый раз, когда Сценарии Какао вызывают один из методов установщика Вашего приложения KVC, это всегда преобразовывает NSNull в ноль сначала. Для обратной совместимости на уровне двоичных кодов, однако, это не делает этого в приложениях, соединенных против OS X 10.4 или ранее (потому что там был ограничен, неопубликованная поддержка значений NSNull даже перед OS X 10.5, и там, вероятно, будут поставлять приложения с методами set, которые ожидают быть переданными NSNull и неправильно функционировали бы когда переданный ноль). Аналогично, методы получателя Вашего приложения KVC могут возвратить ноль вместо NSNull.

Кроме того, Какао, Пишущее сценарий теперь, выполняет хорошую работу возврата отсутствующих значений в списках результата. Например, сообщение Эскиза получить «текстовое содержание каждой диаграммы переднего документа», когда передний документ содержит текстовую область и круг (круги не имеют текстового содержания), теперь возвращает что-то как {«содержание текстовой области», отсутствующее значение} вместо ошибки.

Как Поддержка Составных типов в .sdef-заявленных Работах Scriptability и Исправление ошибки (Новый начиная с WWDC 2007)

Когда Вы объявляете, что свойство класса или параметр команды имеют составной тип, как этот пример от .sdef файла iChat:

        <enumeration name="InviteType" code="invt">

            <enumerator name="audio invitation" code="acon">

                <cocoa name="AudioInvitation"/>

            </enumerator>

            <enumerator name="text chat invitation" code="tcon">

                <cocoa name="TextInvitation"/>

            </enumerator>

            <enumerator name="video invitation" code="vcon">

                <cocoa name="VideoInvitation"/>

            </enumerator>

        </enumeration>

        <command name="send" code="ichtsend" description="Sends a message or file to a buddy or to a chat.">

            <cocoa class="SendCommand"/>

            <direct-parameter>

                <type type="text"/>

                <type type="file"/>

                <type type="InviteType" hidden="yes"/>

            </direct-parameter>

            […]

        </command>

Машинное оборудование в Какао, Пишущем сценарий, который преобразовывает входящие дескрипторы события Apple в объекты Objective C, пытается сделать настолько использующую информацию о каждом типе, в свою очередь, пока успешное преобразование не было сделано, когда это прекращает пробовать и игнорирует остальную часть типов. В этом примере Какао сначала попытается преобразовать дескриптор события Apple в NSString (класс Objective C, соответствующий «текстовому» типу), затем NSURL (соответствующий «файлу»), и затем NSNumber (класс по умолчанию, соответствующий перечислителям).

Это было истиной в OS X 10.4 и является все еще обычно истиной в OS X 10.5 с одним новым улучшением: для размещения факта, что приведения события Apple, встроенные в платформы OS X иногда, позволяют преобразовать в тип, который является не обязательно лучшим из альтернатив Какао может теперь попытаться все еще преобразовать в другие типы в списке и выбрать получающееся значение одного из тех других типов. В OS X 10.5 это делает это путем одобрения любого другого класса значения по NSString или NSURL, потому что те - эти два класса, к которым преобразование часто успешно только из-за непреднамеренного приведения. Когда дескриптор события Apple может быть преобразован или в NSString или в NSURL согласно заявленному составному типу, он одобряет NSURL, если исходный тип дескриптора события Apple является тем, явно указывающим файлы (typeFileURL, typeAlias, и т.д.) NSString иначе. Учитывая эти правила, в нашем выразительном iChat в качестве примера для 'отправки видео приглашения на aBuddy' теперь приводит к отправить команде, прямой параметр которой является NSNumber обертывание четырех кодов символа 'vcon', который корректен. На OS X 10.4 это привело бы к отправить команде, прямой параметр которой является NSString, содержащим «vcon «, который является неправильным. Точно так же говорящий iChat для 'отправки файла POSIX»/Applications/Chess.app»' теперь приводит к отправить команде, прямой параметр которой является NSURL, содержащим «file://localhost/Applications/Chess .app», который корректен. На Mac 10.4 это привело бы к отправить команде, прямой параметр которой является NSString, содержащим «YourRootVolumeName:Applications:Chess.app:», который является неправильным.

Поддержка значений перечислителя не по умолчанию в .sdef-заявленном Scriptability

В OS X 10.5 можно теперь добавить атрибут к подэлементу «какао» .sdef-заявленных объявлений перечислителя для указания то, что оценивает код, передается, когда сценарий использует тот перечислитель. Например:

        <enumeration name="printing error handling" code="enum">

            <enumerator name="standard" code="lwst" description="Standard PostScript error handling">

                <cocoa boolean-value="NO"/>

            </enumerator>

            <enumerator name="detailed" code="lwdt" description="print a detailed report of PostScript errors">

                <cocoa boolean-value="YES"/>

            </enumerator>

        </enumeration>

Атрибуты «булева значения», в сочетании с этим свойством в стандартных настройках печати записывают объявление:

        <property name="error handling" code="lweh" type="printing error handling" description="how errors are handled">

            <cocoa key="NSDetailedErrorReporting"/>

        </property>

Преобразовываются результаты в записи, ключ которой является «NSDetailedErrorReporting» и чьим значением является булев NSNumber со значением НЕ или YES, помещаемый в NSDictionary, к которому печать настройки записывают дескриптор события Apple. (И это удобно, потому что такой словарь может использоваться в качестве словаря атрибутов NSPrintInfo без последующей обработки, в то время как сценарист просто работает с видом записи настроек печати, описанной в Техническом примечании 2082, «Улучшенная Печать Событие Apple».)

В дополнение к «булеву значению» поддерживаются «строковое значение» и атрибуты «целочисленного значения». «строковое значение» не удивительно соответствует NSString, и другие два соответствуют NSNumber. Можно только использовать один на подэлемент «какао». Если Вы не используете никого, поведение по умолчанию совпадает с OS X 10.4's, который должен сделать программируемое значение связанным с перечислителем NSNumber, содержащий четыре кода символа перечислителя.

Это работает с любым видом перечислителя. Например, можно использовать атрибуты «целочисленного значения» в типе перечисления, это используется в качестве типа параметра команды и соглашения с простыми маленькими целыми числами в коде вместо четырех кодов символов. (Просто удостоверьтесь, что сохранили .sdef и код непротиворечивыми!)

Поддержка «как» параметр команды сохранения

Во всех предыдущих версиях OS X - [NSDocument handleSaveScriptCommand:] проигнорировал «как» параметр, даже при том, что собственное объявление Основы команды сохранения включает такой параметр. В OS X 10.5 - [NSDocument handleSaveScriptCommand:] теперь использует «в качестве» параметра, если его значение является NSString, интерпретируя его как имя типа вида, используемого NSDocument. В .sdef-заявленном scriptability можно использовать в своих интересах механизм значения перечислителя, описанный в предыдущем разделе для обеспечения записи сценариев, которые не должны упоминать имена типов NSDocument, которые могут быть слишком техническими для заключения пользовательской сделки с. Например, Эскиз 2 (который использует UTIs в качестве его имен типа документа; посмотрите информация о версии AppKit для получения информации о выполнении этого) объявляет «saveable формат файла» перечисление и использует его в качестве типа «как» параметр:

    <enumeration name="saveable file format" code="savf">

        <enumerator name="Sketch" code="sktc" description="The native Sketch 2 file format">

            <cocoa string-value="com.apple.sketch2"/>

        </enumerator>

        <enumerator name="PDF" code="PDF " description="Portable Document Format">

            <cocoa string-value="com.adobe.pdf"/>

        </enumerator>

        <enumerator name="TIFF" code="TIFF" description="Tagged Image File Format">

            <cocoa string-value="public.tiff"/>

        </enumerator>

    </enumeration>

    <command name="save" code="coresave" description="Save a document.">

        <direct-parameter type="specifier" description="The document(s) or window(s) to save."/>

        <parameter name="in" code="kfil" type="file" optional="yes" description="The file in which to save the document.">

            <cocoa key="File"/>

        </parameter>

        <parameter name="as" code="fltp" type="saveable file format" optional="yes" description="The file format to use.">

            <cocoa key="FileType"/>

        </parameter>

    </command>

Это позволяет людям писать этот вид вещи в их сценариях:

    save theDocument in theFile as TIFF

Лучшее поведение команды сохранения в несохраненных документах

Если документ никогда не сохранялся, в OS X 10.4 не было возможно экспортировать документ несобственному формату файла. (Приложение также литерального чтения Инструкций по Интерфейсу Сценариев «сохраняет в с несохраненными действиями файла как Сохранение Как».) В OS X 10.5, если формат файла, указанный командой сохранения, или неявно с «как» параметр или неявно с расширением файла, не является собственным форматом файла для документа, но это - то, в которое документ может быть экспортирован, действия команды сохранения как Сохранение Копия (также известный как NSSaveToOperation, также известный как Экспорт Как, в Инструкциях по Интерфейсу пользователя в наше время).

Поддержка в NSCloneCommand для того, чтобы сделать «к» параметру двойной команды дополнительный

Когда сценарий не указывает «к» параметру, вставляя каждую копию после оригинала в последовательности элемента, реализация по умолчанию NSCloneCommand теперь копирует получатели команды на месте. Например, можно теперь сказать документу Эскиза 'копировать каждую диаграмму'. Для приложений с .scriptSuite/.scriptTerminology-declared scriptability, собственное объявление Какао двойной команды было обновлено для пользования преимуществом. Для приложений с .sdef-заявленным scriptability будет отключена эта опция, пока Вы не обновили .sdef приложения для объявления «к» дополнительному параметру.

Окончание Undo Manager Groups во время обработки сценариев команд

В предыдущих версиях OS X механизм, автоматически заканчивающий менеджера по отмене группы во время обработки событий, не был инициирован во время обработки событий Apple, включая тех, которые содержат сценарии команд. Это означало, что заданные сценарием изменения иногда помещались в того же менеджера по отмене группа как безотносительно изменения, которое пользователь, оказалось, вносил после переключения назад на приложение. Это также означало, что вещи как состояние модификации документов не всегда обновлялись своевременно. Запускаясь в OS X 10.5, любой открытый менеджер по отмене группы заканчиваются после отгрузки каждого события Apple.

Новые Методы Можно Переопределить для Настройки Создания и Копирования Сценариев Объектов (Новый начиная с WWDC 2007)

Исторически Сценарии Какао создали новые объекты сценариев путем отправки +alloc к классу и-init к полученному объекту. Это скопировало объекты сценариев путем отправки-copyWithZone:. Люди обнаружили много ситуаций, где это не достаточно. Так, чтобы можно было взять на себя больше управления над тем, что происходит, когда заявление послано команда Make или Duplicate, новые методы были добавлены к NSObject (NSScripting) для Вас для переопределения. Эти методы вызываются на предполагаемый контейнер нового или скопированного объекта. Возвращенные объекты или объекты тогда вставляются в контейнер с помощью кодирования значения ключа:

- (id)newScriptingObjectOfClass:(Class)class

                 forValueForKey:(NSString *)key

              withContentsValue:(id)contentsValue

                     properties:(NSDictionary *)properties;

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

- (id)copyScriptingValue:(id)value forKey:(NSString *)key withProperties:(NSDictionary *)properties;

Создайте один или несколько объектов сценариев, которые будут вставлены в отношение, идентифицированное ключом путем копирования переданного - в значении, установят свойства в скопированном объекте или объектах, и возвратят его или их. Значение, например, получено на получатели команды Duplicate. Его тип должен соответствовать тип свойства, идентифицированного ключом. Например, если свойство будет к - многие отношение, то значение всегда будет массивом объектов, которые будут скопированы, и массив объектов должен поэтому быть возвращен. Свойства получены из «со свойствами» параметр команды Duplicate.

Новый Метод Можно Переопределить для Настройки Объектной Оценки Спецификатора, Не Составляя Объектные Индексы (Новый начиная с WWDC 2007)

Было несколько запросов на альтернативу реализации - [NSObject (NSScriptObjectSpecifiers) indicesOfObjectsByEvaluatingObjectSpecifier:] для настройки оценки объектных спецификаторов, тот, не требующий, чтобы контейнер сценариев составил индексы для содержащих в нем объектов, естественно не имеющих индексов. Новый метод был добавлен к NSObject (NSScripting) для Вас для переопределения:

- (id)scriptingValueForSpecifier:(NSScriptObjectSpecifier *)objectSpecifier;

Учитывая объектный спецификатор возвращают указанный объект или объекты в контейнере получения. Это могло бы успешно возвратить объект, массив объектов или ноль, в зависимости от вида объектного спецификатора. Поскольку ноль является допустимым значением, отказ сообщен путем отправки объектному спецификатору-setEvaluationError: перед возвратом. Ваше переопределение не должно также вызывать ни одну ошибку NSScriptCommand сигнальные методы, хотя это может, для записи очень определенной информации об ошибке. Номера NSUnknownKeySpecifierError и NSInvalidIndexSpecifierError являются особенными, в котором Какао может продолжать оценивать внешний спецификатор, если с ними встречаются для удобства сценаристов.

Новые Методы NSScriptObjectSpecifier для Доступа к Базовому Дескриптору События Apple (Новый начиная с WWDC 2007)

Несколько человек запросили способ создать спецификатор NSScriptObject из дескриптора события Apple и способа вытащить дескриптор события Apple из NSScriptObjectSpecifier. Новые методы были добавлены к NSScriptObjectSpecifier:

+ (NSScriptObjectSpecifier *)objectSpecifierWithDescriptor:(NSAppleEventDescriptor *)descriptor;

Учитывая дескриптор typeObjectSpecifier Apple события, создайте и возвратите объектный спецификатор или ноль для отказа. Если это вызывается и перестало работать во время выполнения команды сценария, информация об ошибке, вызвавшей отказ, зарегистрирована в [NSScriptCommand currentCommand].

- (NSAppleEventDescriptor *)descriptor;

Возвратите дескриптор события Apple, представляющий получатель. Если получатель создавался с +objectSpecifierWithDescriptor: переданный - в дескрипторе возвращается. Иначе новый создается и возвращается (автовыпущенный, конечно).

Новые Методы NSScriptClassDescription для Доступа к информации из Объявления класса (Новый начиная с WWDC 2007)

Поскольку «имя» NSScriptClassDescription, следующего из .sdef объявления класса, является своим человекочитаемым именем, - метод имени не может использоваться для обнаружения класса Objective C, который нужно инстанцировать для создания объектов того scriptable класса. Чтобы позволить Вам достигнуть ту информацию, существующий метод в NSScriptClassDescription был опубликован:

- (NSString *)implementationClassName;

Возвратите имя Objective C, реализующего описанный scriptable класс. Этот метод также работает над OS X 10.4.

NSScriptClassDescription не имел достаточных методов доступа допускать некоторые настройки, которые люди хотят сделать. Кроме того, сверхнаездники - [NSObject (NSScripting) scriptingValueForSpecifier:], вероятно, придется сделать часть той же проверки ошибок, которую делает реализация по умолчанию того метода. Новые методы были добавлены к NSScriptClassDescription:

- (BOOL)hasPropertyForKey:(NSString *)key;

- (BOOL)hasOrderedToManyRelationshipForKey:(NSString *)key;

- (BOOL)hasReadablePropertyForKey:(NSString *)key;

- (BOOL)hasWritablePropertyForKey:(NSString *)key;

Возвратитесь, идентифицировал ли описанному классу свойство ключ, является ли это к - многие отношение, читаемо ли это, или перезаписываемо ли это, соответственно. Например, - [NSObject (NSScripting) scriptingValueForSpecifier:] использует-hasPropertyForKey: удостоверяться, что объект в виде сценария фактически имеет указанное свойство. (Поскольку Сценарии Какао позволяют Вам сделать вещи как сообщение Эскиза получить «текстовое содержание графического 1 из документа 1», и что-то должно удостовериться, что графический 1 не является фактически кругом, не имеющим текстового содержания.) Это тогда использует-isPropertyReadableForKey: удостоверяться, что свойство, как объявляли, не было только для записи.

Поскольку существующее - [NSScriptClassDescription isReadOnlyKey:] не соответствует образцу, установленному этими новыми методами, и потому что это немного опасно (результат НЕ мог означать писать в то свойство, разрешен, или это могло просто означать, что ключ является просто нераспознанным), это осуждается в OS X 10.5.

Новые Методы NSScriptCommand для Сообщения об ошибке (Новый начиная с WWDC 2007)

Сообщение об ошибке Сценариев какао очень улучшено в OS X 10.5. Одно из больших улучшений - то, что это теперь заполняет событие Apple ответа со стандартом kOSAErrorOffendingObject и kOSAErrorExpectedType параметрами, когда те применимы. Так, чтобы Ваш код мог сделать то же, новые методы были добавлены к NSScriptCommand:

- (void)setScriptErrorOffendingObjectDescriptor:(NSAppleEventDescriptor *)errorOffendingObjectDescriptor;

- (void)setScriptErrorExpectedTypeDescriptor:(NSAppleEventDescriptor *)errorExpectedTypeDescriptor;

- (NSAppleEventDescriptor *)scriptErrorOffendingObjectDescriptor;

- (NSAppleEventDescriptor *)scriptErrorExpectedTypeDescriptor;

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

Новые Методы доступа NSPositionalSpecifier (Новый начиная с WWDC 2007)

Так, чтобы можно было получить значения, с которыми NSPositionalSpecifier («спецификатор расположения», в AppleScript-говорят, как «в» параметре команды Make) был инициализирован, новые методы доступа были добавлены:

- (NSInsertionPosition)position;

- (NSScriptObjectSpecifier *)objectSpecifier;

Возвратите позицию или объектный спецификатор, указанный во время инициализации.

Результаты, Теперь Возвращенные Открыть Command (New начиная с WWDC 2007)

В предыдущих версиях обработки значения по умолчанию AppKit OS X команды Open никогда не возвращал результат. Запускаясь в OS X 10.5, это возвращает NSDocument или NSArray NSDocuments, в зависимости от того, является ли прямой параметр команды файлом или списком файлов. Для приложений с .scriptSuite/.scriptTerminology-declared scriptability, объявление Основы стандартного комплекта (в его файле ресурсов NSCoreSuite.scriptSuite) было обновлено для соответствия. Для приложений с .sdef-заявленным scriptability файл CocoaStandard.sdef, упомянутый в другом месте в этих примечаниях также, включает объявление команды Open с надлежащими типами результата.

Методы NSURL

NSURL имеет новые методы создания:

- initFileURLWithPath:(NSString *)path isDirectory:(BOOL)isDir;

+ (id)fileURLWithPath:(NSString *)path isDirectory:(BOOL)isDir;

Эти методы позволяют NSURL избежать дополнительного I/O, чтобы проверить, является ли путь каталогом или нет.

Обратите внимание на то, что NSURL.h перечисляет эти два метода, как являющиеся доступной спиной к 10,4. Это неправильно; эти методы были добавлены в 10,5 и не существуют назад на 10,4.

Осуждаемый NSURLHandle

NSURLHandle был осужден, как имеют весь APIs, ссылающийся на них. NSURLConnection (представленный в 10,3) должен использоваться в его месте.

NSJavaSetup.h осужден

Весь API в NSJavaSetup.h был осужден в 10,5. Заголовок, вероятно, не будет доступен в следующей главной версии ОС после 10.5.

NSInvocation.h осуждения API

Перечисление _NSObjCValueType тип и тип NSObjCValue было осуждено. Эти вещи, вероятно, не будут доступны в этом заголовке в следующей главной версии ОС после 10.5.

+poseAsClass: осуждаемый

+poseAsClass: метод в NSObject был осужден. Во время выполнения Objective C было осуждено изложение, и это изменение является отражением этого.

NSCoder.h API осужден

Функциональный NXReadNSObjectFromCoder () и методы encodeNXObject: и decodeNXObject, появляющиеся в NSCoder.h, были осуждены в 10,5. При выносе зарегистрированных сообщений с тех пор 10.0 это - время для Вас для хождения дальше.

Осуждаемый NSRunLoop API

Метод-configureAsServer осуждается в 10,5. Это никогда ничего не делало, таким образом, никогда не было точки в вызове его в OS X.

устаревшие (deprecated) константы значений по умолчанию в NSUserDefaults.h

Как упомянуто в этих 10,4 информации о версии для Основы, следующие пользовательские значения по умолчанию осуждаются в 10,5:

NSString * const NSWeekDayNameArray;

NSString * const NSShortWeekDayNameArray;

NSString * const NSMonthNameArray;

NSString * const NSShortMonthNameArray;

NSString * const NSTimeFormatString;

NSString * const NSDateFormatString;

NSString * const NSTimeDateFormatString;

NSString * const NSShortTimeDateFormatString;

NSString * const NSCurrencySymbol;

NSString * const NSDecimalSeparator;

NSString * const NSThousandsSeparator;

NSString * const NSDecimalDigits;

NSString * const NSAMPMDesignation;

NSString * const NSHourNameDesignations;

NSString * const NSYearMonthWeekDesignations;

NSString * const NSEarlierTimeDesignations;

NSString * const NSLaterTimeDesignations;

NSString * const NSThisDayDesignations;

NSString * const NSNextDayDesignations;

NSString * const NSNextNextDayDesignations;

NSString * const NSPriorDayDesignations;

NSString * const NSDateTimeOrdering;

NSString * const NSInternationalCurrencyString;

NSString * const NSShortDateFormatString;

NSString * const NSPositiveCurrencyFormatString;

NSString * const NSNegativeCurrencyFormatString;

Разработчики должны использовать NSLocale, NSDateFormatter и NSNumberFormatter APIs вместо этого.

Где возможно, NSUserDefaults предоставит совместимые значения для этих ключей, полученных из вышеупомянутых источников. Для следующих ключей локализованные значения не доступны из вышеупомянутых источников, и значения будут предоставлены на английском языке для всех локализаций:

NSDecimalDigits, NSHourNameDesignations, NSYearMonthWeekDesignations, NSEarlierTimeDesignations, NSLaterTimeDesignations,

NSThisDayDesignations, NSNextDayDesignations, NSNextNextDayDesignations, NSPriorDayDesignations

Удаленные заголовки

Следующие ранее устаревшие (deprecated) заголовки были удалены из Основы в 10,5:

NSCompatibility.h

NSUtilities.h

NSSerialization.h

Двоичный файл профиля основы

Основа больше не обеспечивает версию двоичного файла, созданного для профилирования. Конечно, Основа раньше была одной из нескольких библиотек, фактически обеспечивавших тот. Используйте dtrace вместо этого.

NSXMLNode, NSXMLDocument, NSXMLElement, NSXMLDTD, NSXMLDTDNode (Раздел, обновленный начиная с WWDC)

Это новые классы для представления объектов XML. Существует справочная документация в Какао-> Интернет и сеть-> Основанная на дереве обработка XML.

Для обеспечения внедрения FAST, NSXML не проверяет законность данных при использовании setStringValue или setObjectValue. Это означает, что, например, содержание комментария могло быть установлено в «foo - панель» и NSXML выведут недопустимый комментарий: <! - foo - панель->. Для обеспечения устойчивой реализации при обработке неизвестного ввода клиенты должны проверить на «-» где угодно и «-» в конце строки; обработка инструкций должна быть проверена на»?>». NSXML разбивает разделы CDATA на вывод, если они содержат»]]>». Например, если содержание cdata узла будет установлено в «foo]]> панель», то NSXML выведет» <! CDATA [foo]]]]> <! CDATA [> панель]]>». NSXML не нормализует данные (измените разрывы строки, текстовые узлы слияния) при установке значения узла. Недопустимые символы XML, такие как управляющие символы будут выведены, если значение узла будет включать их.

Реализация XQuery/XPath соответствует черновой спецификации в октябре 2004. Это поддерживает дополнительные функции «Полная Ось» и «Функция Модуля». Регулярные выражения используют pcre и не поддерживают классы символов Unicode, такие как \p {Лютеций} или блокируют Escape.

NSLocale (Раздел, обновленный начиная с WWDC)

Новый класс NSLocale является покрытием по API CFLocale в CoreFoundation. NSLocales и CFLocales бесплатные соединенный мостом.

NSLocales не может быть передан в Какао APIs, берущий локаль: параметр - они ожидают словарь для того параметра. Неясно, будет ли такой APIs улучшен для взятия или NSDictionary * или NSLocale * в будущем, поскольку существуют проблемы совместимости, такие как возможное существование подклассов, которые переопределили те методы и приведут к сбою, если дали NSLocale *. Нет никакого API для преобразования NSLocale * к NSDictionary *, и несмотря на то, что обе реализации-objectForKey: два использования различные наборы ключей.

Существуют некоторые дополнительные примечания по CFLocale в Информации о версии CoreFoundation, которая может быть полезна для пользователей API NSLocale.

NSCalendar (Раздел добавил начиная с WWDC),

Новый класс NSCalendar является покрытием по новому API CFCalendar в CoreFoundation. NSCalendar позволяет Вам просить числовые свойства календаря, преобразовывать между NSDates и анализируемыми представлениями модуля, и выполнять некоторые типы calendrical арифметики. NSCalendars и CFCalendars бесплатные соединенный мостом.

NSCalendars создаются с помощью идентификаторов календарей в NSLocale.h, и только те идентификаторы поддерживаются. Вы не можете определить свои собственные календари с помощью NSCalendar, хотя можно разделить на подклассы и переопределить каждый метод экземпляра, и необходимо было бы также создать пользовательский NSDateFormatter для получения форматирования даты с помощью календаря, поскольку NSDateFormatter только понимает четко определенные встроенные календари в OS X v10.4 и не обязательно вызывает методы на его атрибут NSCalendar для вычислений ответов. «Текущий календарь», возвращенный +currentCalendar, является предпочтительным календарем пользователя, сконфигурированным с локалью пользователя и часовым поясом по умолчанию. Локаль по умолчанию для NSCalendar является Системной Локалью (+ [NSLocale systemLocale]).

Примечание: китайский календарь в настоящее время не реализуется в NSCalendar и связывается, APIs. (Результаты не определены.)

Можно изменить некоторые свойства NSCalendar (локаль, часовой пояс, первый день недели и минимальное число дней в течение недели, чтобы быть первой неделей года). Однако они - просто удобство для установки параметров на calendrical вычисления, и не изменяют NSCalendar, скажем, в целях тестирования равенства и не архивируются.

Значения/вычисления/результаты API NSCalendar не обязательно согласовывают со значениями/вычислениями/результатами NSCalendarDate API в NSCalendarDate.h. NSCalendarDate API занимает вторичное место к NSCalendar и NSDateFormatter APIs с OS X v10.4, и может быть осужден в следующем выпуске.

Существует много дополнительных примечаний по CFCalendar в Информации о версии CoreFoundation, которая будет полезна для пользователей API NSCalendar. Следующие примечания описывают основное различие между CFCalendar и APIs NSCalendar.

Вместо методов аргумента переменной и строк описания компонента как в API CFCalendar, NSCalendar использует простой объект NSDateComponents содержать произвольные наборы компонентов для calendrical методов расчета. NSDateComponents является в основном просто объектом с полями, которые могут быть, получают и устанавливают, но может также быть расширен позже, и результаты в API, который более подобен Какао, чем API CFCalendar. Поля компонента, не инициализирующиеся или которые должны быть проигнорированы, имеют значение NSUndefinedDateComponent. NSDateComponents может использоваться для представления дат/времен, как, 26 марта до переменных степеней специфики (например, пример не указывает, какой год, который мог представлять любого), или количества компонентов, как «5 месяцев и 1 час». Важно отметить, что NSDateComponents (1) не делает никаких calendrical вычислений (это не дает «корректные» ответы для полей, не установленных), и (2) это не проверяет поля, устанавливаемые на (a) непротиворечивость среди полей или (b) законность диапазона. NSDateComponents также не связывается ни к какому определенному календарю, таким образом, в некоторых ситуациях, и NSCalendar и NSDateComponents, возможно, должны держаться вместе для понимания даты позже.

Когда NSDateComponents является возвращаемым значением, unitFlags параметр указывает, какие поля NSDateComponents должны инициализироваться/использоваться. Константы модуля являются поразрядным OR'd вместе для приведения unitFlags аргумента.

Подход NSDateComponents не допускает компоненты, которые будут указаны в определенном порядке к-dateByAddingComponents:toDate:options: и-components:fromDate:toDate:options: операции calendrical. NSCalendar всегда использует компоненты в порядке, что константы модуля перечислены в NSCalendar.h, таким образом, для осуществления определенного порядка вычисления к компонентам множественным вызовам методов вычисления, вероятно, придется выполнить, и вычисление промежуточных значений. Вычисления различия с Недельным модулем будут особенно неприятны в этом отношении.

Обратите внимание на то, что класс NSDateComponents не реализует NSCopying или протоколы NSCoding, который является контролем в OS X v10.4.

NSDateFormatter (Раздел, обновленный начиная с WWDC)

Для OS X v10.4, класс NSDateFormatter получает главную перестройку функциональности. Новая реализация основывается на CFDateFormatter, который основывается на ICU с открытым исходным кодом (Международные Компоненты для Unicode) библиотека и должен произвести намного лучше локализованные отформатированные даты. NSDateFormatter и CFDateFormatter, однако, не бесплатные соединенный мостом.

Существует в основном два режима, в которых NSDateFormatter может работать, названный «поведением средства форматирования». 10.0 (к 10,3) режим эмуляции работает как NSDateFormatter, имеет в предыдущих выпусках OS X, включая ограничения и ошибки. Новые 10,4 режимов поведения позволяют больше конфигурируемости и лучшей локализации.

Разработчики призваны использовать константы NSDateFormatterStyle для указания, сколько информации выведено на экран для частей даты и времени отформатированного NSDate. Стилями является NoStyle (опустите эту часть, или дата или время или оба), ShortStyle, MediumStyle, LongStyle и FullStyle (выводящий на экран большую часть информации). Это стили, которые пользователь может сконфигурировать в Международной предпочтительной панели в Установках системы. Если Вы как разработчик решаете, что просто не любите ни одного из стилей и устанавливаете Вашу собственную строку формата, то Вы можете просто просто компоненты, Вы хотите быть выведенными на экран, но Вы теряете пользовательскую конфигурируемость.

В дополнение к методам, наследованным от NSFormatter, NSDateFormatter добавляет getObjectValue:forString:range:error: метод. Этот метод позволяет Вам указывать поддиапазон строки, которая будет проанализирована и возвращает диапазон строки, фактически проанализированной (который, при отказе, указывает, где отказ произошел). Метод также возвращает объект NSError, который может содержать более богатую информацию, чем строка отказа, возвращенная наследованным getObjectValue:... метод. NSDateFormatter также добавляет два удобных метода,-stringFromDate: и-dateFromString:.

Обратите внимание на то, что NSCell, так как это работает с генералом Нсформэттерсом, только вызывает NSFormatter getObjectValue:... метод в OS X v10.4. Для средства форматирования даты с 10.4 стилями, что вызовы метода новый getObjectValue:... метод.

Но, NSDateFormatters не должны быть просто присоединены к ячейкам. Новые методы предоставлены для создания более хорошим использовать NSDateFormatter непосредственно в коде, и это - направление, в которое перемещается платформа Основы. Разработчики, желающие отформатировать даты в строки, будут использовать средства форматирования даты.

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

Новые методы в 10,4 ничего не делают, когда вызвано на средство форматирования с 10.0 стилями и возвращают универсальное возвращаемое значение при необходимости для возврата чего-то. Новые методы не должны быть вызваны на средство форматирования с 10.0 стилями.

Самое большое изменение в средстве форматирования с 10.4 стилями является форматом строки формата. «%A %B %y» стиль форматов NSDateFormatter в 10,3 и ранее и форматов NSCalendarDate был заменен структурой строки формата CFDateFormatter (и ICU). Эти строки формата подобны найденным в C#/.Net и Java APIs. См. документацию для CFDateFormatter или NSDateFormatter для получения дополнительной информации. Когда средство форматирования находится в «10,0» режим, строки формата старого стиля требуются. Одна вещь отметить с форматом строки формата CFDateFormatter состоит в том, что буквенный текст должен быть включен в одинарных кавычках (') в строке формата - это просто забыть.

Тип объекта для «10,0» средствами форматирования даты является все еще NSCalendarDates, но для модернизированных средств форматирования, это - NSDates. Можно сконфигурировать модернизированное средство форматирования для генерации NSCalendarDates с setGeneratesCalendarDates: если Вы хотите их. Вы призваны переключиться на NSDates теперь, если это возможно, для модернизированных средств форматирования.

Поведение по умолчанию для NSDateFormatters в OS X v10.4 является 10,0 поведениями для назад совместимости на уровне двоичных кодов. Разработчики призваны испытать средства форматирования с 10.4 стилями, и переключиться на них, если это возможно, получить лучшую поддержку локализации. Если приложение поставляет на выпусках до 10,4 также, очевидно, это должно быть условно сделано.

Можно вызвать [средство форматирования setFormatterBehavior:NSDateFormatterBehavior10_4] на каждом отдельном экземпляре средства форматирования, который Вы хотите изменить. Обратите внимание на то, что старый-initWithDateFormat:allowNaturalLanguage: метод всегда инициализирует тот к 10,0 поведениям. Но Вам, вероятно, придется обновить поведение Вашего приложения также, когда Вы делаете это; например, модернизированное средство форматирования начнет возвращать NSDates вместо NSCalendarDates по умолчанию, и если Ваше приложение будет ожидать NSCalendarDates позже, то будет проблема.

Существует новое значение по умолчанию, которое можно также установить для преобразовывания средств форматирования даты в новый стиль автоматически (который мог доставить другие неприятности в приложении, быть предупрежден). Установите значение по умолчанию «NSMakeDateFormatters10_4» в булево YES/ИСТИННОЕ ЗНАЧЕНИЕ в предпочтениях приложения с помощью команды 'значений по умолчанию'. Предпочтение должно быть установлено, прежде чем любое использование класса NSDateFormatter сделано. Значение по умолчанию имеет два эффекта: (1) средства форматирования даты, создающиеся с +alloc/-init, будут с 10.4 стилями; (2) средства форматирования даты, разархивированные или от невключенных или от включенных архивов, будут преобразованы в с 10.4 стилями, если заархивированное средство форматирования будет иметь неспециализированную строку формата - большинство из найденных в инспекторе NSDateFormatter IB - в разархивировало время.

Основной недостаток, который может быть замечен с новым средством форматирования даты с 10.4 стилями, - то, что снисходительный режим парсинга не является столь же прощающим как парсинг «естественного языка» NSDateFormatter, когда «allowsNaturalLanguage» был включен в средстве форматирования. Это имеет плохое и хорошую сторону. Пользователи должны будут быть немного более осторожными и возможно полными при вводе в датах, но они, более вероятно, найдут, что значение, которое они пытались ввести, было правильно установлено в значение, которое они хотели, а не что парсинг «естественного языка» предположил, что они имели в виду.

NSNumberFormatter (Раздел, обновленный начиная с WWDC)

Для OS X v10.4, класс NSNumberFormatter получает главную перестройку функциональности. Новая реализация основывается на CFNumberFormatter, который основывается на ICU с открытым исходным кодом (Международные Компоненты для Unicode) библиотека и должен произвести намного лучше локализованные отформатированные числа. NSNumberFormatter и CFNumberFormatter, однако, не бесплатные соединенный мостом.

Существует в основном два режима, в которых NSNumberFormatter может работать, названный «поведением средства форматирования». 10.0 (к 10,3) режим эмуляции работает как NSNumberFormatter, имеет в предыдущих выпусках OS X, включая ограничения и ошибки. Новые 10,4 режимов поведения позволяют больше конфигурируемости и лучшей локализации.

Разработчики призваны использовать константы NSNumberFormatterStyle для указания предконсервированных наборов атрибутов, определяющих, как отформатированное число выведено на экран. Стилями является NoStyle (использование, когда Вы собираетесь установить строку формата сами), DecimalStyle, CurrencyStyle, PercentStyle, ScientificStyle и SpellOutStyle (текстовое представление числа). Это стили, которые пользователь может сконфигурировать в Международной предпочтительной панели в Установках системы. Если Вы как разработчик решаете, что просто не любите ни одного из стилей и устанавливаете Вашу собственную строку формата, то Вы можете просто просто компоненты, Вы хотите быть выведенными на экран, но Вы теряете пользовательскую конфигурируемость.

В дополнение к методам, наследованным от NSFormatter, NSNumberFormatter добавляет getObjectValue:forString:range:error: метод. Этот метод позволяет Вам указывать поддиапазон строки, которая будет проанализирована и возвращает диапазон строки, фактически проанализированной (который, при отказе, указывает, где отказ произошел). Метод также возвращает объект NSError, который может содержать более богатую информацию, чем строка отказа, возвращенная наследованным getObjectValue:... метод. NSNumberFormatter также добавляет два удобных метода,-stringFromNumber: и-numberFromString:.

Обратите внимание на то, что NSCell, так как это работает с генералом Нсформэттерсом, только вызывает NSFormatter getObjectValue:... метод в OS X v10.4. Для средства форматирования числа с 10.4 стилями, что вызовы метода новый getObjectValue:... метод.

Но, NSNumberFormatters не должны быть просто присоединены к ячейкам. Новые методы предоставлены для создания более хорошим использовать NSNumberFormatter непосредственно в коде, и это - направление, в которое перемещается платформа Основы. Разработчики, желающие отформатировать числа в строки более сложными способами или возможно более удобными, чем форматирование NSString, позволяют, будет использовать средства форматирования числа.

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

Новые методы в 10,4 ничего не делают, когда вызвано на средство форматирования с 10.0 стилями и возвращают универсальное возвращаемое значение при необходимости для возврата чего-то. Новые методы не должны быть вызваны на средство форматирования с 10.0 стилями. На средстве форматирования с 10.4 стилями старые методы отображаются приблизительно на один или несколько новые методы/атрибуты, но новые методы должны использоваться непосредственно, если это возможно.

Существуют небольшие изменения в средстве форматирования с 10.4 стилями к формату строки формата. С 10.0 стилями из форматов NSNumberFormatter в 10,3 и ранее был заменен структурой строки формата CFNumberFormatter (и ICU). Эти строки формата подобны найденным в C#/.Net и Java APIs. См. документацию для CFNumberFormatter или NSNumberFormatter для получения дополнительной информации. Одна вещь отметить с форматом строки формата CFNumberFormatter состоит в том, что буквенный текст должен быть включен в одинарных кавычках (') в строке формата - это просто забыть. Основное различие - то, что '_' (underbar) символ формата средства форматирования с 10.0 стилями не принят средством форматирования с 10.4 стилями, и что позиция запятой (ых), если они происходят в 10,4 строках формата (и им нужно не) является значительной и определяет, куда группирующиеся разделители будут помещены (где это не значительно в формате с 10.0 стилями).

Тип объекта для «10,0» средствами форматирования числа является все еще NSDecimalNumbers, но для модернизированных средств форматирования, это - NSNumbers. Можно сконфигурировать модернизированное средство форматирования для генерации NSDecimalNumbers с setGeneratesDecimalNumbers: если Вы хотите их. Вы призваны переключиться на NSNumbers теперь, если это возможно, для модернизированных средств форматирования.

Поведение по умолчанию для NSNumberFormatters в OS X v10.4 является 10,0 поведениями для назад совместимости на уровне двоичных кодов. Разработчики призваны испытать средства форматирования с 10.4 стилями, и переключиться на них, если это возможно, получить лучшую поддержку локализации. Если приложение поставляет на выпусках до 10,4 также, очевидно, это должно быть условно сделано.

Можно вызвать [средство форматирования setFormatterBehavior:NSNumberFormatterBehavior10_4] на каждом отдельном экземпляре средства форматирования, который Вы хотите изменить. Но Вам, вероятно, придется обновить поведение Вашего приложения также, когда Вы делаете это; например, модернизированное средство форматирования начнет возвращать NSNumbers вместо NSDecimalNumbers по умолчанию, и если Ваше приложение будет ожидать NSDecimalNumbers позже, то будет проблема.

Существует новое значение по умолчанию, которое можно также установить для преобразовывания средств форматирования даты в новый стиль автоматически (который мог доставить другие неприятности в приложении, быть предупрежден). Установите значение по умолчанию «NSMakeNumberFormatters10_4» в булево YES/ИСТИННОЕ ЗНАЧЕНИЕ в предпочтениях приложения с помощью команды 'значений по умолчанию'. Предпочтение должно быть установлено, прежде чем любое использование класса NSNumberFormatter сделано. Значение по умолчанию имеет два эффекта: (1) средства форматирования даты, создающиеся с +alloc/-init, будут с 10.4 стилями; (2) средства форматирования даты, разархивированные или от невключенных или от включенных архивов, будут преобразованы в с 10.4 стилями, если заархивированное средство форматирования будет иметь неспециализированную строку формата - большинство из найденных в инспекторе NSNumberFormatter IB - в разархивировало время.

NSIndexPath

NSIndexPath является новым классом для представления последовательности индексов; его основная цель состоит в том, чтобы инкапсулировать информацию, должен был переместиться вниз по дереву объектов. NSTreeController, новый класс в AppKit, использует NSIndexPath.

Определяемый инициализатор для NSIndexPath:

- (id)initWithIndexes:(unsigned int *)indexes length:(unsigned int)length;

и примитивные средства доступа:

- (unsigned int)indexAtPosition:(unsigned int)position;

- (unsigned int)length;

См. NSIndexPath.h для остальной части API.

Кодирование значения ключа и Наблюдение для Наборов (Раздел добавил начиная с WWDC),

OS X 10.3 представил наблюдение значения ключа (KVO), механизм, которым объект может наблюдать свойства, включая упорядоченный - много отношений, другого. Это также представило явную поддержку упорядоченного - много отношений к существующему механизму кодирования значения ключа (KVC). Поскольку некоторые приложения, особенно те, которые используют CoreData, должны представлять неупорядоченный - много отношений, поддержки неупорядоченного к - много отношений были добавлены к KVC/KVO. Эта поддержка принимает форму дополнений к-valueForKey KVC: метод, новые методы KVC и новые методы KVO.

Явно поддерживать невидоизменяющийся доступ неупорядоченных к - многих отношений, - [NSObject (NSKeyValueCoding) valueForKey:], существующий метод, теперь находит методы KVC-соответствия, соответствующие примитивам NSSet. После поиска методов доступа массива (как в OS X 10.3), но перед поиском переменных экземпляра (как в OS X 10.3), это теперь ищет методы доступа набора. Из комментариев NSKEYVALUECODING.H для-valueForKey:

«3 (представленный в OS X 10.4). Иначе (никакой простой метод доступа или набор методов доступа к массиву не найдены), ищет класс получателя для тройки методов, имена которых соответствуют образцы-countOf <Ключ>,-enumeratorOf <Ключ> и-memberOf <Ключ>: (соответствие примитивным методам, определенным классом NSSet). Если все три таких метода сочтены объектом прокси набора, реагирующим на все методы NSSet, возвращается. Каждое сообщение NSSet, отправленное в объект прокси набора, приведет к некоторой комбинации-countOf <Ключ>,-enumeratorOf <Ключ> и-memberOf <Ключ>: сообщения, отправляемые в исходный получатель-valueForKey:».

Реализации Вашего класса таких методов KVC-соответствия должны иметь те же подписи как:

- (unsigned int)countOf<Key>;

- (NSEnumerator *)enumeratorOf<Key>;

- (id)memberOf<Key>;

Как имел место для упорядоченных отношений, это разумно и обычно более удобно просто реализовать метод доступа KVC-соответствия для всего набора. Для неупорядоченного отношения метод доступа должен иметь ту же подпись как:

- (NSSet *)<key>;

Для поддержки мутации неупорядоченных к - много отношений два новых метода были добавлены к NSObject (NSKeyValueCoding):

- (NSMutableSet *)mutableSetValueForKey:(NSString *)key;

- (NSMutableSet *)mutableSetValueForKeyPath:(NSString *)keyPath;

Учитывая ключевой или ключевой путь, идентифицирующий отношение, возвратите объект, который может использоваться для видоизменения отношения. Распознаны несколько образцов имени метода KVC-соответствия:

- (void)add<Key>Object:(id)objectToAdd;

- (void)remove<Key>Object:(id)objectToRemove;

- (void)add<Key>:(NSSet *)objectsToAdd;

- (void)remove<Key>:(NSSet *)objectsToRemove;

- (void)intersect<Key>:(NSSet *)intersectionObjects;

- (void)set<Key>:(NSSet *)replacementObjects;

Обычно Ваш класс реализует, каждый добавляет, и каждый удаляет метод для определенного ключа. Могут быть преимущества исполнения всех условий к реализации NSSet-взятия. См. комментарии NSKEYVALUECODING.H для подробных данных.

- mutableSetValueForKeyPath: следует за образцом, установленным существующими методами взятия пути ключа KVC; в основном это просто вызывает [[сам valueForKey:firstKeyPathComponent] mutableSetValueForKeyPath:theRestOfTheKeyPath].

Для поддержки наблюдения за неупорядоченными к - много мутаций отношения новое перечисление было добавлено, и пара методов была добавлена к NSObject (NSKeyValueObserverNotification):

typedef enum {

    // The set representing an unordered to-many relationship is being changed using NSMutableSet's

       -unionSet:, -minusSet:, -intersectSet:, or -setSet: method, or something that has the same

       semantics.

    NSKeyValueUnionSetMutation = 1,

    NSKeyValueMinusSetMutation = 2,

    NSKeyValueIntersectSetMutation = 3,

    NSKeyValueSetSetMutation = 4

} NSKeyValueSetMutationKind;

- (void)willChangeValueForKey:(NSString *)key withSetMutation:(NSKeyValueSetMutationKind)mutationKind

    usingObjects:(NSSet *)objects;

- (void)didChangeValueForKey:(NSString *)key withSetMutation:(NSKeyValueSetMutationKind)mutationKind

    usingObjects:(NSSet *)objects;

Учитывая ключ, идентифицирующий неупорядоченный для - многие отношение, подготовьте отправлять, и отправлять, соответственно,-observeValueForKeyPath:ofObject:change:context: сообщение. Переданный - в виде мутации соответствует методу NSMutableSet. Переданный - в наборе должен содержать набор, который был бы передан соответствующему методу NSMutableSet. Вызовы этих методов должны всегда соединяться с идентичными параметрами. Словари изменения в уведомлениях, следующих из использования этих методов всегда, содержат запись NSKeyValueChangeKindKey. Его значение будет зависеть от переданного - в значении mutationKind:

- NSKeyValueUnionSetMutation-> NSKeyValueChangeInsertion

- NSKeyValueMinusSetMutation-> NSKeyValueChangeRemoval

- NSKeyValueIntersectSetMutation-> NSKeyValueChangeRemoval

- NSKeyValueSetSetMutation-> NSKeyValueChangeReplacement

Словарь изменения может также содержать дополнительные записи:

- Запись NSKeyValueChangeOldKey, если настоящее (только для для NSKeyValueChangeRemoval и NSKeyValueChangeReplacement), содержит набор удаленных объектов.

- Запись NSKeyValueChangeNewKey, если настоящее (только для NSKeyValueChangeInsertion и NSKeyValueChangeReplacement), содержит набор добавленных объектов.

Новые Переопределения Общедоступных Методов Кодирования Значения ключа NSSet (Раздел добавил начиная с WWDC),

Для непротиворечивости с существующим поведением NSARRAY KVC NSSet теперь переопределяет два общедоступных метода KVC:

- (id)valueForKey:(NSString *)key;

Возвратите набор, содержащий результаты вызова-valueForKey: на каждом из элементов получателя. Возвращенный набор не мог бы иметь того же числа членов как получатель. Возвращенный набор не будет содержать элементов, соответствующих экземплярам-valueForKey: возврат ноля (в отличие от - [NSArray (NSKeyValueCoding) valueForKey:], который может поместить NSNulls в массивы, которые он возвращает).

Для обратной совместимости на уровне двоичных кодов этот метод просто вызовет реализацию по умолчанию NSObject's-valueForKey: в приложениях, соединенных против OS X 10.3 или ранее.

- (void)setValue:(id)value forKey:(NSString *)key;

Вызовите-setValue:forKey: на каждом из элементов получателя.

Для обратной совместимости на уровне двоичных кодов этот метод просто вызовет реализацию по умолчанию NSObject's-setValue:forKey: в приложениях, соединенных против OS X 10.3 или ранее.

Поддержка Новых Образцов Имени метода в Кодировании Значения ключа для Массивов (Раздел добавил начиная с WWDC),

- [NSObject (NSKeyValueCoding) valueForKey:], существующий метод, теперь найдет методы, имена которых соответствуют образцу:

- (NSArray *)<key>AtIndexes:(NSIndexSet *)indexes;

в дополнение к-objectIn <Ключ> AtIndex: образец, поддерживаемый в OS X 10.3. Если тот же класс имеет обоих - <ключевой> AtIndexes: и-objectIn <Ключ> AtIndex: метод, автоматические прокси набора, возвращенные-valueForKey: вызовет, какой бы ни является лучшим для производительности, в зависимости от сообщения, отправленного в прокси набора.

- [NSObject (NSKeyValueCoding) mutableArrayValueForKey:], существующий метод, теперь найдет методы, имена которых соответствуют образцам:

- (void)insert<Key>:(NSArray *)objectsToAdd atIndexes:(NSIndexSet *)indexes;

- (void)remove<Key>AtIndexes:(NSIndexSet *)indexes;

- (void)replace<Key>AtIndexes:(NSIndexSet *)indexes with<Key>:(NSArray *)replacementObjects;

в дополнение к-insertObject:in <Ключ> AtIndex:-removeObjectFrom <Ключ> AtIndex: и-replaceObjectIn <Ключевой> AtIndex:withObject: образцы, поддерживаемые в OS X 10.3. Если тот же класс имеет и индексное взятие набора и берущую индекс вставку, удаление или метод замены, автоматические непостоянные прокси набора, возвращенные-valueForKey: вызовет, какой бы ни является лучшим для производительности, в зависимости от сообщения, отправленного в непостоянный прокси набора.

Новый метод NSIndexSet-взятия в NSArray

Новый метод был добавлен к NSArray:

- (NSArray *)objectsAtIndexes:(NSIndexSet *)indexes;

Возвратите массив объектов в индексах или бросьте NSRangeException, если самый большой индекс в наборе больше, чем количество приемной антенной решетки.

Новые методы NSIndexSet-взятия в NSMutableArray

Новые методы были добавлены к NSMutableArray:

- (void)insertObjects:(NSArray *)objects atIndexes:(NSIndexSet *)indexes;

Вставьте объекты в индексах или бросьте NSRangeException, если самый большой индекс в наборе не является меньше, чем сумма количеств приемной антенной решетки и переданного - в массиве, или бросьте NSInvalidArgumentException, если переданные - в NSIndexSet и NSArray не имеют того же количества. Переданными - в индексах являются индексы, в которых должны быть расположены вставленные объекты после того, как вся работа завершена.

- (void)removeObjectsAtIndexes:(NSIndexSet *)indexes;

Удалите индексируемые объекты или бросьте NSRangeException, если самый большой индекс в наборе больше, чем количество приемной антенной решетки. Переданными - в индексах являются индексы, в которых удаленные объекты были перед работой.

- (void)replaceObjectsAtIndexes:(NSIndexSet *)indexes withObjects:(NSArray *)objects;

Замените индексируемые объекты другими объектами или бросьте NSRangeException, если самый большой индекс в наборе больше, чем количество приемной антенной решетки. если переданные - в NSIndexSet и NSArray не имеют того же количества, или бросают NSInvalidArgumentException.

Явное переопределение регистрационных методов наблюдателя значения ключа NSArray и NSSet

NSArrays и NSSets не заметны, таким образом, эти методы:

- (void)addObserver:(NSObject *)observer forKeyPath:(NSString *)keyPath

    options:(NSKeyValueObservingOptions)options context:(void *)context;

- (void)removeObserver:(NSObject *)observer forKeyPath:(NSString *)keyPath;

исключения повышения, когда вызвал на NSArrays и NSSets. Вместо того, чтобы наблюдать массив или набор, наблюдайте упорядоченный или неупорядоченный к - многие отношение, для которого массив или устанавливают, набор связанных объектов. Для NSArrays это поведение неизменно начиная с OS X 10.3; единственное изменение является явным объявлением бросающих исключение переопределений метода в NSKeyValueObserving.h. Для NSSets это поведение является новым начиная с OS X 10.3; для обратной совместимости на уровне двоичных кодов бросающие исключение переопределения метода просто вызывают реализации по умолчанию NSObject's в приложениях, соединенных против OS X 10.3 или ранее.

Осуждение сохраненных методов кодирования значения ключа

В OS X 10.3, документация для каждого из этих методов:

+ (BOOL)useStoredAccessor;

- (id)storedValueForKey:(NSString *)key;

- (void)takeStoredValue:(id)value forKey:(NSString *)key;

требуемый:

Примечание: Этот метод не осуждается с OS X v10.3, но может быть осужден в пользу нового метода в будущем выпуске OS X.

Эти методы теперь осуждаются. Их реализации фактически неизменны начиная с OS X 10.3, и можно продолжать использовать их, но их реализации не будут улучшены для хождения в ногу с улучшениями кодирования значения ключа и наблюдения.-storeValueForKey: и-takeStoredValue:forKey: не вызываются ниоткуда в Какао, как в OS X 10.3 и ранее. +useStoredAccessor только вызывается из-storeValueForKey: и-takeStoredValue:forKey: как в OS X 10.3 и ранее.

При использовании нового класса NSManagedObject используйте его-primitiveValueForKey: и-setPrimitiveValue:forKey: методы вместо этого.

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

Были опубликованы строки для имен операторов массива, поддерживавшихся значением ключа, кодирующим начиная с OS X 10.3:

NSString *NSAverageKeyValueOperator;

NSString *NSCountKeyValueOperator;

NSString *NSDistinctUnionOfArraysKeyValueOperator;

NSString *NSDistinctUnionOfObjectsKeyValueOperator;

NSString *NSMaximumKeyValueOperator;

NSString *NSMinimumKeyValueOperator;

NSString *NSSumKeyValueOperator;

NSString *NSUnionOfArraysKeyValueOperator;

NSString *NSUnionOfObjectsKeyValueOperator;

Значения их не включают, выстраивают префиксы оператора.

Исправление ошибки в кодировании значения ключа

В OS X 10.3, - [NSArray valueForKeyPath: поддержка] операторов имела ошибки, вызвавшие катастрофический отказ, зависание и бросок исключения, когда @sum, @max, или @min оператор был применен к массиву, содержащему элемент, возвративший ноль для включенного значения. Например:

[[NSArray arrayWithObject:[NSDictionary dictionary]] valueForKeyPath:@"@sum.anyOldKey"]

отказал бы или завис бы (потому что с нолем, который словарь возвратил из -valueForKey:@ «anyOldKey», не справились). Эта проблема была решена.

И в OS X 10.3 и в OS X 10.4 поддержка @count и @avg операторов не принимает во внимание возвращенные ноли. Это - истина независимо от обоих - [NSArray valueForKeyPath:] и - [NSSet valueForKeyPath:].

Исправление ошибки в Наблюдении Значения ключа для - Методы описания (Раздел добавил начиная с WWDC),

В OS X 10.3, - сообщения описания, отправленные в любой наблюдаемый объект, всегда приводили бы к вызову закрытого метода, ведшего себя более или менее как - [Описание NSObject], даже если - описание было переопределено классом получателя, если автоуведомление наблюдения значения ключа не было отключено для всех наблюдаемых свойств путем переопределения +automaticallyNotifiesObserversForKey:. Это было ошибкой и было фиксировано. Переопределение Вашего класса - описание будет теперь вызвано, даже если получатель будет наблюдаться, и его «isa swizzled» машинным оборудованием автоуведомления KVO.

- [Описание NSObject] само, который является прежде всего для использования в отладке, не пытается скрыть isa-swizzling от Вас. Например, когда - [Описание NSObject] иначе возвратило бы что-то как» <Фу: 0x301780>» это теперь возвратит что-то как» <NSKVONotifying_Foo: 0x301780>», если isa объекта был swizzled. Если Вы видите это при отладке и удивлены видеть, что объект наблюдается, можно отправить объект,-observationInfo передает и просматривает описание результатов. Например, команда GDB как 'почтовый [mySurprisinglyObservedObject observationInfo]' выведет список соблюдения на том объекте.

Исправление ошибки в Наблюдении Значения ключа для Вложенных Последовательностей WillChange/DidChange (Раздел добавил начиная с WWDC),

В OS X 10.3 была ошибка, в которой вложил последовательности willChange/didChange, приведет к уведомлениям наблюдателя, отправляемым слишком рано. Например:

    [observedObject addObserver:observer forKeyPath:@"someProperty" options:0 context:NULL];

    [observedObject willChangeValueForKey:@"someProperty"];

    [observedObject willChangeValueForKey:@"someProperty"];

    [observedObject didChangeValueForKey:@"someProperty"];

            // Observer is sent two -observeValueForKeyPath:... messages. It should be sent one.

    [observedObject didChangeValueForKey:@"someProperty"];

            // Observer is sent zero -observeValueForKeyPath:... messages.

            // It should be sent one (unless the first -observeValueForKeyPath:... invoked

            // [observedObject removeObserver:observer forKeyPath:@"someProperty"]).

Эта ошибка была исправлена. Было самым примечательным, когда наблюдатель сделал что-то как удаление себя как наблюдатель в ответ на первое уведомление наблюдателя с ожиданием, что это не получит секунду.

Изменения NSAppleEventDescriptor

+appleEventWithEventClass:eventID:targetDescriptor:returnID:transactionID: и-initWithEventClass:eventID:targetDescriptor:returnID:transactionID:] были каждый обновлены для принятия нулевого целевого параметра дескриптора. Получающийся дескриптор события Apple не имеет никакого атрибута keyAddressAttr.

Наблюдение значения ключа и сценарии какао

В OS X 10.3, поддержка сценариев Какао не использовала методы Кодирования Значения ключа, внедренные у Пантеры как-setValue:forKey: и-mutableArrayValueForKey: таким образом, изменения в объектах модели, сделанных AppleScripts, не были заметным использующим автоматическим Наблюдением Значения ключа. Это было фиксировано. Поддержка сценариев какао теперь вызывает-setValue:forKey: вместо-takeValue:forKey: если рассматриваемый контейнер не переопределяет-takeValue:forKey: когда-takeValue:forKey: будет вызван для обратной совместимости на уровне двоичных кодов. Реализации-insertValue:atIndex:inPropertyWithKey:-removeValueAtIndex:fromPropertyWithKey: и-replaceValueAtIndex:inPropertyWithKey:withValue: были обновлены для вызова-mutableArrayValueForKey: и видоизмените результат если никакой соответствующий scripting-KVC-compliant метод (вставка <Ключа>: atIndex:-removeFrom <Ключ> AtIndex: или replaceIn <Ключ>: atIndex: соответственно), найден.

Исправления ошибок в приостановке NSScriptCommand и возобновлении

В OS X 10.3, - [NSScriptCommand suspendExecution] мог неправильно функционировать если соответствующий вызов resumeExecutionWithResult:] был сделан очень быстро в различном потоке, приведя к катастрофическим отказам. Эта ошибка была исправлена.

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

Поддержка сценариев какао .sdef файлов

Какао теперь поддерживает объявление scriptability в .sdef файлах вместо .scriptSuite/.scriptTerminology файлов. Эта поддержка является неполной несколькими способами в семени 2004 года WWDC Тайгера, но здесь является некоторыми интересными фактами:

- 'человек sdef' для обнаружения то, о чем формат файла - все. Посмотрите .sdef файлы в Основе и каталогах Resources AppKit для примеров. Кроме того, проверьте сайт Соединения Разработчика Apple в <connect.apple.com> для получения информации о Сеансе 2004 года WWDC 430, «Усовершенствования в Сценариях Какао», для получения дополнительной информации.

-. sdefs загружаются вместо .scriptSuite/.scriptTerminology файлов, только если приложение соединяется против Тайгера или лучше и основной пакет приложения включает по крайней мере один .sdef файл. Это, вероятно, изменится так, чтобы решение Какао загрузить .sdef вместо .scriptSuite/.scriptTerminology файлов зависело от новой записи «OSAScriptingDefinition» Info.plist.

- Большая разница между парсингом .sdef Какао и версией sdp, шедшего с Пантерой, - то, что имя атрибута Какао, идентифицирующего ключ KVC свойства, является «ключевым», не «метод».

- Другие большие различия: используйте «спецификатор» теперь, не «объект», и «спецификатор расположения» вместо «расположения».

- Цветной класс в NSCoreSuite. [scriptSuite|scriptTerminology] не будет объявлен как класс в собственных .sdef файлах Какао. Один из .sdef файлов Какао просто объявляет простой тип значения, «цвет». Дескрипторы события Apple нескольких типов convertable к NSColors.

- Тип «файла», который всегда имел .sdef, соответствует классу NSURL.

- «Любой» тип, который всегда имел .sdef, соответствует классу NSAppleEventDescriptor, не NSObject.

- Класс реализации Objective C «элемента», scriptable класс является NSObject, не искусственным типом AbstractObject, использовавшимся в .scriptSuite файлах.

- Стандарт для классов документа изменился, чтобы быть соответствующим Инструкциям по Интерфейсу Сценариев. Каждый класс документа должен теперь иметь свойство «файла» только для чтения типа «файл» вместо свойства «пути» чтения-записи строкового типа. Свойство «имени» класса документа должно теперь быть только для чтения вместо чтения-записи.

- Ключ Cocoa для свойства «имени» должен быть «displayName», не «lastComponentOfFileName». - [NSDocument (Пишущий сценарий) lastComponentOfFileName], вероятно, будет осуждаемым.

- Различные свойства класса окна были удалены для обеспечения Какао в соответствии с новыми Инструкциями по Интерфейсу Сценариев. Имена окна теперь только для чтения. «Miniaturizable» и «миниатюризированный» были переименованы к «minimizable» и «минимизируемому».

- Текстовый тип свойства «размера» класса теперь реален вместо целого числа.

- Текстовый присоединяемый класс теперь имеет свойство «файла» только для чтения типа «файл» вместо свойства строки «имени файла» чтения-записи.

- Прямой параметр открытой команды имеет тип «список файла».

- Прямой параметр команды печати имеет тип «список файла | спецификатор», таким образом, можно или распечатать файлы или документы (это может не работать очень хорошо в семени 2004 года WWDC Тайгера).

- Близкая команда, «сохраняющая в» параметре и команда сохранения «в» параметре, имеет теперь тип «файл».

- Различные методы обработчиков команды сценария в AppKit были обновлены для контакта с параметрами NSURL, потому что это - то, во что преобразовываются дескрипторы события Apple «файла».

- «С данными» параметр сделать команды был переименован к «с содержанием».

-suiteName NSScriptClassDescription и - возврат имени класса человекочитаемые строки, которыми включаются .sdefs, когда класс объявляется в .sdef.

- Так же для-suiteName и-commandName NSScriptCommand.

-suiteNames NSScriptSuiteRegistry возвращает тот же вид человекочитаемых строк для .sdef-заявленного материала и-appleEventCodeForSuite:-bundleForSuite:-classDescriptionsInSuite: и-commandDescriptionsInSuite: возьмите тот же вид строк.

NSNetServices конечные решения

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

/* Starts a resolve for the NSNetService of a finite duration. If your delegate is called before the

timeout expires, the resolve can be considered successful. If the resolve times out, your

netService:didNotResolve:  callback will be called with the appropriate error dictionary.

*/

- (void)resolveWithTimeout:(NSTimeInterval)timeout;

Это позволит решение конечной продолжительности, ограничивая сетевой трафик. Для приложений, соединенных на Тайгере, теперь осуждаемом - решение вызовет-resolveWithTimeout с тайм-аутом 5 секунд (обычно, если что-то соберется произойти, то это произойдет в течение первой приблизительно полусекунды). Для приложений, соединенных на Пантере, работающей на Тайгере, - решение вызовет-resolveWithTimeout: с тайм-аутом в далеком будущем.

Поддержка записи NSNetServices TXT

У Тигра мы осудили вызовы protocolSpecificInformation, работающие с Нсстрингсом в пользу:

/* Allows the developer to use an NSData containing arbitrary bytes as the TXT record.

Returns YES if the data is successfully set as the TXT record. Returns NO if it cannot be set.

*/

- (BOOL)setTXTRecordData:(NSData *)recordData;

- (NSData *)TXTRecordData;

Разработчики, проверяющие, чтобы видеть, является ли это текстовой записью стиля значения ключа, могут использовать следующий API для попыток преобразования:

/* TXT record data can be presented either as an NSData or an NSDictionary of key-value pairs.

It's very useful to be able to convert between the two. NSNetService provides a pair of class methods

to do this conversion. Each returns nil in the event that the conversion cannot take place.

*/

+ (NSDictionary *)dictionaryFromTXTRecordData:(NSData *)txtData;

+ (NSData *)dataFromTXTRecordDictionary:(NSDictionary *)txtDictionary;

Основная утилита этого для использования в netService:didUpdateTXTRecordData:.

Приложения, соединенные на Пантере или Ягуаре и работающий на Тайгере, будут продолжать быть в состоянии взаимодействовать с тем же приложением, работающим на другой Пантере или машинах Ягуара в сети.

Запись NSNetServices TXT обновляет наблюдение

В старом поведении, дополнительном netService:didResolve: когда protocolSpecificInformation обновил, метод делегата вызвали бы. Это требует отъезда открытого решения, который генерирует ненужный сетевой трафик.

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

Во-первых, на самом NSNetService, двух новых методах:

/* These calls control whether an NSNetService will watch for TXT record updates, notification

of which would be delivered to the delegate on the netServiceDidUpdateTXTRecord: method in the

NSNetServiceDelegateMethods category.

*/

- (void)startMonitoring;

- (void)stopMonitoring;

И на категории NSNetServiceDelegateMethods:

/* Called to inform the delegate that the TXT record associated with the sending NSNetService

object has updated. txtData contains the new TXT record as an NSData.

*/

- (void)netService:(NSNetService *)sender didUpdateTXTRecordData:(NSData *)txtData;

Этот метод поставляет обновленную запись TXT как NSData делегату.

Публикация NSNetServices

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

- (void)netServiceDidPublish:(NSNetService *)sender;

Ошибка (поставленный на текущем ошибочном методе делегата) инициирована в одном из двух случаев: (1) Тайм-аут был достигнут, или (2), коллизия Имени произошла.

Существует новый код ошибки для случая тайм-аута:

NSNetServicesTimeoutError = -72007

NSDirectoryEnumerator (Раздел добавил начиная с WWDC),

Была исправлена долгосрочная ошибка в-directoryAttributes методе NSDirectoryEnumerator. У Тигра это теперь ведет себя, как задокументировано, возвращая атрибуты каталога, в котором началось перечисление.

Для общего падежа перечисления каталога, не прося атрибуты, производительность очень улучшена по предыдущим версиям OS X.

Повышение производительности во включенной архивации

В OS X v10.4, было значительное повышение производительности в создании включенных архивов, имеющих много объектов массива.

Повышение производительности в регистрации уведомления

В OS X v10.4, было значительное повышение производительности в регистрации уведомлений, для которых нет никаких наблюдателей. Производительность всей регистрации также обычно улучшалась.

NSNumber (Раздел добавил начиная с WWDC),

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

У Тигра «популярные» числа включают-1.. 12, несмотря на то, что это могло бы очень хорошо измениться в любой точке, включая в обновлении программного обеспечения.

Сравнения с NAN (не число) теперь работают правильно, в котором никакое число не равно NAN (включая + [NSDecimalNumber notANumber]), кроме самого NAN (который должен быть особым случаем, так как объектное равенство должно содержать). Сравнение с NAN также даст детерминированные результаты; однако, никакие предположения не должны быть сделаны на упорядочивании, и результаты могут варьироваться между системными выпусками.

NSString

getCString:maxLength NSSTRING: и getCString:maxLength:range:remainingRange: если предоставленный размер буфера не будет достаточно большим, методы больше не будут повышать. Обратите внимание на то, что они не повышали во всех случаях.

Больше NSString и методы NSMutableString теперь обнаруживают за пределы индексы и недопустимые диапазоны. Один случай, должным образом не обнаруживавшийся до сих пор, был то, где расположение и/или длина были столь большими, что сумма закончила тем, что была меньше, чем длина строки. Для приложений, соединенных на Тайгере, эта ошибка вызовет исключение после журналирования проблемы в консоли; для более старых приложений, для совместимости, мы просто регистрируем один раз, но не повышаем. Обратите внимание на то, что, даже если старое поведение кажется работой под рядом обстоятельств, это фактически просто становится удачным и во многих случаях могло бы закончить тем, что отказало в некоторый момент. Таким образом, любые экземпляры этих журналов должны быть фиксированы.

Если вызов к componentsSeparatedByString: приведший к массиву с одной строкой, равной получателю, одна строка иногда не копировалась, и ее значение могло измениться, когда была впоследствии отредактирована строка получателя. Это было фиксировано.

Осуждение NSString cString API

В постоянном усилии для осуждения cString методов, не кодируя параметры NSString теперь имеет следующий новый API. Обратите внимание на то, что этот новый API также обеспечивает возвраты NSError как способ обеспечить больше информации об отказах в случаях, где она могла бы иметь значение для пользователя, например, для чтения/записи.

Следующий возврат максимальное и точное число байтов должен был сохранить получатель в указанном кодировании в невнешнем представлении. В то время как второй является O (n), первый является O (1). Они не включают пространство для завершающегося нуля. Если преобразование в указанное кодирование не будет возможно, второй возвратится 0; первый не проверяет.

- (unsigned)maximumLengthOfBytesUsingEncoding:(NSStringEncoding)enc;

- (unsigned)lengthOfBytesUsingEncoding:(NSStringEncoding)enc;

Методы для преобразования NSString в ЗАВЕРШЕННЫЙ NULL cString использование указанного кодирования. Отметьте, они - «новые» cString методы и не осуждаются как более старые cString методы, не берущие параметры кодирования.

- (const char *)cStringUsingEncoding:(NSStringEncoding)encoding;

- (BOOL)getCString:(char *)buffer maxLength:(unsigned)maxBufferCount encoding:(NSStringEncoding)encoding;

Следующее является новыми и улучшенными cString методами, берущими явные параметры кодирования.

- (id)initWithCString:(const char *)nullTerminatedCString encoding:(NSStringEncoding)encoding;

+ (id)stringWithCString:(const char *)cString encoding:(NSStringEncoding)enc;

Это следующее представлено в Тайгере, но фактически было вокруг с тех пор 10.3 и так доступно для использования на 10,3.

- (id)initWithBytesNoCopy:(void *)bytes length:(unsigned)len

      encoding:(NSStringEncoding)encoding freeWhenDone:(BOOL)freeBuffer;

Они используют указанное кодирование. Если ноль возвращается, дополнительный ошибочный возврат указывает проблему, с которой встретились (например, файловая система или ошибки кодирования).

- (id)initWithContentsOfURL:(NSURL *)url encoding:(NSStringEncoding)enc error:(NSError **)error;

- (id)initWithContentsOfFile:(NSString *)path encoding:(NSStringEncoding)enc error:(NSError **)error;

+ (id)stringWithContentsOfURL:(NSURL *)url encoding:(NSStringEncoding)enc error:(NSError **)error;

+ (id)stringWithContentsOfFile:(NSString *)path encoding:(NSStringEncoding)enc error:(NSError **)error;

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

- (id)initWithContentsOfURL:(NSURL *)url usedEncoding:(NSStringEncoding *)enc error:(NSError **)error;

- (id)initWithContentsOfFile:(NSString *)path usedEncoding:(NSStringEncoding *)enc error:(NSError **)error;

+ (id)stringWithContentsOfURL:(NSURL *)url usedEncoding:(NSStringEncoding *)enc error:(NSError **)error;

+ (id)stringWithContentsOfFile:(NSString *)path usedEncoding:(NSStringEncoding *)enc error:(NSError **)error;

Следующая запись к указанному URL с помощью указанного кодирования. Дополнительный ошибочный возврат должен указать ошибки кодирования или файловая система.

- (BOOL)writeToURL:(NSURL *)url atomically:(BOOL)useAuxiliaryFile

        encoding:(NSStringEncoding)enc error:(NSError **)error;

- (BOOL)writeToFile:(NSString *)path atomically:(BOOL)useAuxiliaryFile

        encoding:(NSStringEncoding)enc error:(NSError **)error;

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

- (const char *)cString;

- (const char *)lossyCString;

- (unsigned)cStringLength;

- (void)getCString:(char *)bytes;

- (void)getCString:(char *)bytes maxLength:(unsigned)max;

- (void)getCString:(char *)bytes maxLength:(unsigned)max range:(NSRange)rg remainingRange:(NSRangePointer)rem;

+ (id)stringWithCString:(const char *)bytes length:(unsigned)length;

+ (id)stringWithCString:(const char *)bytes;

+ (id)stringWithContentsOfFile:(NSString *)path;

+ (id)stringWithContentsOfURL:(NSURL *)url;

- (id)initWithContentsOfFile:(NSString *)path;

- (id)initWithContentsOfURL:(NSURL *)url;

- (id)initWithCStringNoCopy:(char *)bytes length:(unsigned)length freeWhenDone:(BOOL)freeBuffer;

- (id)initWithCString:(const char *)bytes length:(unsigned)length;

- (id)initWithCString:(const char *)bytes;

- (BOOL)writeToFile:(NSString *)path atomically:(BOOL)flag;

- (BOOL)writeToURL:(NSURL *)url atomically:(BOOL)flag;

NSAttributedString

Приписанные строковые методы, такие как attribute:atIndex:effectiveRange: используемый для повышения NSInternalInconsistencyException на за пределы доступах; они были теперь переключены на повышение NSRangeException, как задокументировано.

- [NSMutableAttributedString initWithString:attributes:] мог создать приписанную строку повреждения, когда инициализировано со строкой ненулевой длины. Это было фиксировано.

Существует теперь CFAttributedString, который является бесплатный соединенный мостом к NSAttributedString.

Мутация NSAttributedString атрибутов, предупреждающих (Раздел добавил начиная с WWDC),

Как только значение атрибута установлено в приписанной строке, значение атрибута не должно быть изменено позади приписанной строки. Таким образом, любая модификация к значению должна быть выполнена новой операцией присвоения (использующий любой из методов мутации атрибута в NSMutableAttributedString) с новым значением.

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

Другая причина этого ограничения состоит в том, что приписанные строки делают кэширование и uniquing атрибутов (это фактически происходит больше на уровне AppKit, но это - подробность реализации). uniquing предполагает, что значения атрибута не изменяются, т.е. что isEqual: и хеш на значениях атрибута не изменится, пока значение атрибута находится в приписанной строке.

Если необходимо изменить значения атрибута, два возможных предложения:

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

- Используйте косвенность; используйте значение атрибута в качестве ключа поиска в таблицу, где может быть изменено фактическое значение. Например, это могло бы быть надлежащим подходом для того, чтобы иметь «таблицу стилей» как атрибут.

Это предупреждение всегда было применимо, но это - больше истины в Тайгере, так как NSAttributedString теперь хеширует больше значений в словаре атрибута когда uniquing это. Это привело к проблемам в нескольких приложениях, где некоторые значения атрибута видоизменялись, или хуже, повредили или освободили (но ранее остающийся незамеченный). Как временное обходное решение к этой проблеме, значение по умолчанию под названием NSPreTigerAttributedStringHash доступно; установка этого к YES для Вашего приложения заставит NSAttributedString использовать тот же алгоритм хеширования в качестве у Пантеры. Это может помочь диагностировать проблемы, и даже привести приложение в чувство. Это значение по умолчанию не должно использоваться в качестве долгосрочного решения все же.

NSCocoaErrorDomain

Для формализации вида ошибок, возвращенных платформами AppKit и Основы, существует теперь новый ошибочный домен:

NSString *const NSCocoaErrorDomain;

Это представляет домен для ошибок, возвращенных из большинства подсистем Какао. Ошибки в этом домене имеют разумный и локализовали читаемые пользователем сообщения об ошибках, которые достаточно хороши, чтобы быть выведенными на экран на предупреждениях и других пользовательских интерфейсах. За несколькими существующими исключениями AppKit, Основа и CoreData APIs, как ожидают, возвратят NSErrors в этом домене; в некоторых случаях более низкие погрешности нивелировки будут упакованы как базовая ошибка.

NSError (Раздел, обновленный начиная с WWDC)

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

localizedDescription: «Не мог сохранить файл 'Буква' в папке 'Documents', потому что объем 'MyDisk' не имеет достаточного количества пространства».

localizedRecoverySuggestion: «Удалите файлы из диска и попробуйте еще раз».

localizedRecoveryOptions: ноль (так, «OK»)

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

Следующий метод возвращает строку, которая может быть выведена на экран как «информативное» (иначе «вторичный») сообщение на предупредительной панели. Ноль возвратов, если никакая такая строка не доступна. Реализация по умолчанию этого возьмет значение NSLocalizedRecoverySuggestionKey из userInfo словаря.

- (NSString *)localizedRecoverySuggestion;

Следующий метод возвращает заголовки кнопок, которые являются подходящими для отображения на предупреждении. Они должны соответствовать строку, предоставленную как часть localizedRecoverySuggestion. Первая строка была бы заголовком самой правой и кнопки по умолчанию, второй рядом с нею, и т.д. Если используется на предупреждении соответствующими возвращаемыми значениями по умолчанию является NSAlertFirstButtonReturn + n. Реализация по умолчанию этого возьмет значение NSLocalizedRecoveryOptionsKey из userInfo словаря. нулевой возврат обычно не подразумевает специального предложения, которое подразумевало бы единственную кнопку «OK».

- (NSArray *)localizedRecoveryOptions;

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

- (NSArray *)localizedFailureReason;

В дополнение к вышеупомянутому NSError теперь также имеет возможность делать попытку восстановления после ошибки. Следующий метод возвращает объект, приспосабливающий NSErrorRecoveryAttempting неофициальному протоколу:

- (id)recoveryAttempter;

Реализация по умолчанию этого метода просто возвращается [[сам userInfo] objectForKey:NSRecoveryAttempterErrorKey]:

NSString *const NSRecoveryAttempterErrorKey;

Если неноль, восстановление attempter должно быть объектом, который может правильно интерпретировать индекс в массив, возвращенный-localizedRecoveryOptions.

NSErrorRecoveryAttempting неофициальный протокол имеет два метода:

- (void)attemptRecoveryFromError:(NSError *)error optionIndex:(unsigned int)recoveryOptionIndex

          delegate:(id)delegate didRecoverSelector:(SEL)didRecoverSelector contextInfo:(void *)contextInfo;

Учитывая, что ошибочное предупреждение было представленным документом модально пользователю, и пользователь выбрал одну из опций восстановления ошибки, восстановления попытки после ошибки, и отправляет выбранное сообщение указанному делегату. Индекс опции является индексом в массив ошибки локализованных опций восстановления. Метод, выбранный didRecoverSelector, должен иметь ту же подпись как:

- (недействительный) didPresentErrorWithRecovery: (BOOL) didRecover contextInfo: (недействительный *) contextInfo;

Если бы восстановление после ошибки было абсолютно успешно, НЕТ иначе, значением, переданным для didRecover, должен быть YES.

- (BOOL)attemptRecoveryFromError:(NSError *)error optionIndex:(unsigned int)recoveryOptionIndex;

Учитывая, что ошибочное предупреждение было представлено applicaton-модально пользователю, и пользователь выбрал одну из опций восстановления ошибки, восстановления попытки после ошибки и возврата YES, если восстановление после ошибки было абсолютно успешно, НЕТ иначе. Индекс опции восстановления является индексом в массив ошибки локализованных опций восстановления.

Посмотрите раздел «NSResponder-Based Error Presentation» в информации о версии AppKit для получения информации о том, как само Какао использует восстановление после ошибки attempters.

Изменение от Пантеры - то, что NSError теперь передаст копией по распределенным объектам, если параметр не будет указан, чтобы быть «byref». Это раньше всегда шло ссылкой.

Дополнительные примечания NSError (Раздел добавил начиная с WWDC),

Соглашения какао для возвратов NSError включают:

- Возврат NSError должен всегда присутствовать в дополнение к более простому способу указать отказ, например, через возвращаемое значение функции (Нет, ноль, NULL, или независимо от того, что является надлежащим). NSErrors обычно возвращаются через параметр «ссылкой», т.е. указатель на объект NSError.

- Параметр NSError является «дополнительным». Если вызывающая сторона указала NULL для ошибочного параметра указателя, то не возвращайте его.

- Если отказ обозначен в вызове, и вызывающая сторона передала в ошибочном указателе не-NULL, NSError должен быть возвращен для указания то, что пошло не так, как надо. Не приемлемо установить *errorPtr в ноль, сказать, потому что точная причина ошибки не могла быть определена, или не было никакой реальной ошибки.

- Если отказ не обозначен, то не используйте NSError в качестве способа передать другое состояние, такое как предупреждения. По успешному возврату *обычно не изменяется errorPtr; возможно установленный в NULL.

- NSErrors не используются для программных ошибок (таких как индекс массива за пределы, значение недопустимого параметра, попытайтесь видоизменить неизменный объект, и т.д.). Какао использует исключения для тех.

Два «глюка», на которые стоит указать о NSErrors:

Если бы NSError создавался с нолем, userInfo метод мог бы возвратить ноль в некоторых случаях, например. Это означает, что, если Вы копируете NSError и добавляете некоторые новые ключи к userInfo словарю, чему-то как [[ошибка userInfo] mutableCopy] перестанет работать, если словарь будет нолем. Так, проверьте на ноль при выполнении этого.

Другой глюк для указания с автовыпущенным возвратом NSErrors. Если вызовы метода другой метод, возвращающий NSError, и затем возвращающий это NSError его вызывающей стороне, необходимо быть осторожными, если Вы, оказывается, добавляете пул автовыпуска в том методе, так как Вы могли бы закончить тем, что выпустили ошибку, Вы добрались от вложенного вызова.

Это, конечно - тот же вид проблемы, которую необходимо было бы не упустить с нормальными возвращаемыми значениями; однако, когда NSErrors возвращаются, это особенно тонко. Поэтому NSErrors являются вторичными возвращаемыми значениями, так более легко пропущенными. Кроме того, по большинству регулярных путей кода ошибки сценариев тестирования не тестируются, который означал бы, что не встретятся с ошибкой. Фактически, Вы закончили бы с ошибкой, вызывающей катастрофический отказ только при попытке сообщить об ошибке, которая неудачна.

Решение, конечно, состоит в том, чтобы расширить время жизни NSError вокруг уничтожения пула, например:

- (BOOL)aMethod:... error:(NSError **)errorPtr {

    BOOL success;

    NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];

    ...

    success = [someObj anotherMethod:...  error:errorPtr];

    ...

    if (!success && errorPtr) [*errorPtr retain];        // Extend the lifetime of the error

    [pool release];

    if (!success && errorPtr) [*errorPtr autorelease];

    return success;

}

NSData (Раздел добавил начиная с WWDC),

Следующие новые методы возвращают дополнительный NSErrors для чтения файла и записи. Как с другими методами NSError-возврата, NSError возвращается в случае отказа (НЕ или возврат NULL), если errorPtr не является NULL. Во многих случаях возвращенная ошибка достаточно хороша, чтобы быть представленной пользователю:

enum {    // Options for NSData reading methods

    NSMappedRead = 1,    // Hint to map the file in if possible

    NSUncachedRead = 2    // Hint to get the file not to be cached in the kernel

};

enum {    // Options for NSData writing methods

    NSAtomicWrite = 1    // Hint to use auxiliary file when saving; equivalent to atomically:YES

};

+ (id)dataWithContentsOfFile:(NSString *)path options:(unsigned)readOptionsMask error:(NSError **)errorPtr;

+ (id)dataWithContentsOfURL:(NSURL *)url options:(unsigned)readOptionsMask error:(NSError **)errorPtr;

- (id)initWithContentsOfFile:(NSString *)path options:(unsigned)readOptionsMask error:(NSError **)errorPtr;

- (id)initWithContentsOfURL:(NSURL *)url options:(unsigned)readOptionsMask error:(NSError **)errorPtr;

- (BOOL)writeToFile:(NSString *)path options:(unsigned)writeOptionsMask error:(NSError **)errorPtr;

- (BOOL)writeToURL:(NSURL *)url options:(unsigned)writeOptionsMask error:(NSError **)errorPtr;

NSAffineTransform (Раздел добавил начиная с WWDC),

Реализация класса NSAffineTransform переместилась от AppKit до Основы.-transformBezierPath: - набор и-concat методы являются теперь частью категории, реализованной в AppKit.

Используя NSURLRequest для запросов с крупными организациями

Исторически, для использования NSURLRequest и NSURLConnection для выполнения транзакции HTTP с большим Телом HTTP, организация должна была сначала быть загружена полностью в в память, тогда соединение могло быть создано, и транзакция HTTP могла иметь место. Это, к сожалению, помещает нагрузку памяти большой емкости в такие транзакции - при загрузке больших изображений или файлов, например, использование памяти распространилось бы для длины транзакции для содержания всего содержания организации.

Для Тигра мы позволили установить организацию Запроса HTTP как NSInputStream, тогда избегающий проблемы памяти. Когда соединение обрабатывается, указанный поток открыт, и байты читаются некоторые за один раз из потока, который будет записан в сервер HTTP. Новые методы и появляются в NSURLRequest.h и являются-HTTPBodyStream (на категории NSHTTPURLRequest NSURLRequest) и-setHTTPBodyStream: (на категории NSMutableHTTPURLRequest NSMutableURLRequest). Для использования этой функции просто создайте NSInputStream к тому, везде, где данные организации находятся (обратите внимание на то, что, потому что NSInputStream бесплатный соединенный мостом к CFReadStream, можно передать CFReadStreamRef, если Вы предпочитаете), затем вызовите-setHTTPBodyStream: по соответствующему запросу.

Существует несколько протестов при использовании этих методов. Прежде всего, как только поток организации был установлен по запросу, это становится свойством того запроса и любых следующих соединений, сделанных из того запроса. Никто больше не должен управлять им никакой путь. Это включает кого-либо получающего поток от существующего NSURLRequest через-HTTPBodyStream метод. Во-вторых, поток организации и данные организации (как установлено-setHTTPBody:) являются взаимоисключающими; установка той очистит другой.

NSUserDefaults (Раздел добавил начиная с WWDC),

NSUserDefaults теперь сохраняет предпочтения с помощью двоичного файла plist формат, а не XML. Это делает предпочтительные файлы меньшими, и ускоряет времена чтения-записи.

Так как двоичный файл plist формат поддерживается назад к 10,2, это должно работать в домашних папках, совместно использующихся системами, работающими 10.4, 10.3, и 10.2. Для случаев, где 10,1 совместимости необходима, существует булево значение по умолчанию, CFPreferencesWritesXML, который заставит предпочтения быть сохраненными с помощью формата XML. Как с большинством значений по умолчанию, это может быть установлено глобально или на основе на приложение.

Если необходимо переписать plist вручную по некоторым причинам, можно или преобразовать его с помощью plutil инструмента командной строки или просто открыть его и отредактировать его с помощью Редактора Списка свойств приложение.

Поддержка локали в библиотеке C (Раздел добавил начиная с WWDC),

У Пантеры C библиотечные функции обработки строк (форматирование, сканирование, сравнения---функции, такие как atof (), strtod (), scanf (), printf (), и т.д.) запустили уделение внимания текущей локали POSIX, как установлено setlocale (). Например, для европейской локали, strtod () обрабатывает»», как десятичный разделитель при преобразовании его аргумента строки к значению с плавающей точкой. Так как это изменение представляло потенциальную проблему совместимости для приложений, любой CoreFoundation (и выше), приложение имело локаль, соединенную проводами назад к «C» локали для сохранения предыдущего поведения для этих функций.

У Тигра это поведение совместимости сохраняется для находящихся в AppKit приложений, соединяющихся на Пантере или прежде. Другие приложения получают новое поведение для библиотечных функций C. Однако, так как очень немного приложений когда-либо устанавливают значение локали POSIX во что-либо кроме значения по умолчанию, изменение в поведении вряд ли будет проблемой. Изменение языка пользователя в OS X автоматически не заставляет локаль POSIX быть измененной в приложениях.

То, где новое поведение могло бы быть большим количеством проблемы, является платформами и библиотеками, загружающимися в произвольные приложения или исполнимые программы; если исполнимая программа вызвала setlocale () для изменения текущей локали в приложении, любые вызовы обработки строк от не подозревающей библиотеки или платформы могли бы генерировать неожиданные результаты.

Как решение, функции добавляются к библиотеке C в Тайгере, чтобы позволить вызывающей стороне явно указать локаль для обработок строк. Несмотря на то, что точное решение не завершено во время этой записи, функции, вероятно, примут форму strtod_l (), т.е. исходное имя функции с суффиксом «_l». Кроме того, новая функция uselocale () будет, вероятно, добавлена, чтобы позволить изменить локаль для текущего потока только. Это позволит клиентам установить и сбросить локаль вокруг набора вызовов ориентированным на многопотоковое исполнение способом.

64-разрядное Примечание (Раздел добавил начиная с WWDC),

Платформа Основы не доступна для использования в 64-разрядных процессах в OS X v10.4.

Осуждения API (Раздел добавил начиная с WWDC),

NSArchiver и классы NSUnarchiver и другой APIs в NSArchiver.h не осуждаются в этом выпуске, но могут быть в следующем выпуске.

Класс NSCalendarDate, категории NSDate и другой APIs в NSCalendarDate.h не осуждаются в этом выпуске, но могут быть в следующем выпуске.

Классы NSDecimalNumber и NSDecimalNumberHandler, протокол NSDecimalNumberBehaviors и другой APIs в NSDecimalNumber.h не осуждаются в этом выпуске, но могут быть в следующем выпуске. Структура NSDecimal и функции в NSDecimal.h не осуждаются в этом выпуске, но могут быть в следующем выпуске. Собственный компонент долго удваивается, поддержка в NSNumber в следующем выпуске заменит большую часть потребности в NSDecimal и NSDecimalNumber (и будет намного намного быстрее).

Дата/время, форматирующая константы «локали» в NSUserDefaults, не осуждается в этом выпуске, но может быть в следующем выпуске: NSAMPMDesignation, NSDateFormatString, NSDateTimeOrdering, NSEarlierTimeDesignations, NSHourNameDesignations, NSLaterTimeDesignations, NSMonthNameArray, NSNextDayDesignations, NSNextNextDayDesignations, NSPriorDayDesignations, NSShortDateFormatString, NSShortMonthNameArray, NSShortTimeDateFormatString, NSShortWeekDayNameArray, NSThisDayDesignations, NSTimeDateFormatString, NSTimeFormatString, NSWeekDayNameArray, NSYearMonthWeekDesignations.

Константы «локали» форматирования чисел в NSUserDefaults не осуждаются в этом выпуске, но могут быть в следующем выпуске:

NSCurrencySymbol, NSDecimalSeparator, NSThousandsSeparator, NSDecimalDigits, NSInternationalCurrencyString, NSPositiveCurrencyFormatString, NSNegativeCurrencyFormatString.

Если осуждается, API остается (некоторое время, по крайней мере), но не получает исправлений ошибок, улучшений производительности или других улучшений. устаревшие (deprecated) константы API могут не иметь никаких значений или не могут использоваться реализацией платформы в будущих версиях. Кроме того, осудил API, может не быть доступным ни в какой будущей 64-разрядной версии платформы Основы.