Spec-Zone .ru
спецификации, руководства, описания, API
Библиотека Разработчика iOS Разработчик
Поиск
Copyright © 2011 Информации о версии iOS Apple Inc Все права защищены.


iOS 5 Информации о версии
Платформа основы



Платформа Основы является библиотекой классов Objective C, обеспечивающих инфраструктуру для основанных на объектах приложений. Это доступно на Mac OS X и iOS.


Обратная совместимость

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

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

В некоторых случаях мы обеспечиваем значения по умолчанию (предпочтения) настройки, которые могут использоваться для получения старого или нового поведения, независимого от того, против какой системы приложение было создано. Часто эти предпочтения предоставлены для отладки целей только; в некоторых случаях предпочтения могут использоваться для глобального изменения поведения приложения путем регистрации значений (сделайте это где-нибудь очень рано, с - [NSUserDefaults registerDefaults:]).


Поддержка JSON в основе

Новый класс NSJSONSerialization в Основе имеет поддержку сериализации объектов Основы к JSON и десериализации JSON в объекты Основы. Чтение и запись и из объектов данных и из потоков поддерживаются. Посмотрите заголовок NSJSONSerialization.h для получения дополнительной информации о новом классе и методах.


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

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


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

Заголовочные файлы для классов, которые являются новыми в iOS 5, используют новый макрос, NS_CLASS_AVAILABLE (_MacOSIntro, _iOSIntro), для указания доступности класса. Классы, украшенные этим способом, могут быть проверены в ноле на существование в будущих версиях Mac OS X или iOS, как это:
if ([NSNewClass class]) { /* ... */ }
Методы, функции и экспортируемые значения также используют новый макрос, NS_AVAILABLE (_MacOSIntro, _iOSIntro).


NSFilePresenter

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

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

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

Каждый 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;

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


NSFileCoordinator

iOS 5 включает вызванную координацию файла нового механизма. В дополнение к инициированию работы предъявителями файла, как описано в предыдущем разделе и комментариях в <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> для подробных данных.

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

NSFileCoordinator разработан для размещения факта, что файлы и каталоги могут быть перемещены или переименованы, в то время как процесс ожидает для доступа к ним; заметьте NSURL, передающийся блокам средства доступа файла. Если Ваше приложение переименовывает файл при сохранении его тогда тогда приложение должно объявить, что делает так, с помощью этого метода NSFileCoordinator:
- (void)itemAtURL:(NSURL *)oldURL didMoveToURL:(NSURL *)newURL;
Потребность использовать этот метод редка, но возникает, например, в TextEdit, когда расширение имени файла должно быть изменено от .rtf до .rtfd, потому что пользователь добавил присоединения к документу обогащенного текста, и различный формат файла должен использоваться для него.

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

Этот механизм отличается от традиционного консультативного захвата файла BSD в этом:
• Это не требует, чтобы Ваше приложение сделало все, что это должно сделать к файлу для определенной пользовательской работы в одном открытом () / скопление () / чтение или запись/завершение () последовательность для осуществления непротиворечивости. Это важно в контексте Сенсорного приложения Какао, потому что большинство Сенсорных методов Какао торгует NSURLs, не дескрипторами файлов или даже NSFileHandles.
• Это имеет несколько функций, которые консультативный захват файла BSD не имеет (и даже не было бы надлежащим поместить в тот уровень). Один важный пример этого - то, что скоординированное чтение файла может фактически инициировать запись в тот файл другим процессом, в то время как Ваше чтение ожидает, помочь реализовать iOS 5 модернизировало модель документа, описанную в информации о версии AppKit. В то время как Ваш писатель ожидает, скоординированная запись может также инициировать действия в других процессах. Они описаны в предыдущем разделе.
• Это принимает пакеты файла во внимание автоматически.
• Нет никакого эквивалента скопления () опции LOCK_NB или кода ошибки EWOULDBLOCK. Этот механизм для использования, когда доступом к файлу управляет пользователь, и предоставляющей пользователю ошибку о неспособности взять блокировку был бы неприемлемо плохой UI, потому что это - такое техническое понятие.
• Методы, которые мы опубликовали для представления этого механизма, структурированы, чтобы мешать Вам случайно заставлять другие процессы ожидать для доступа к файлам дольше, чем Вы предназначаете. Вы не блокируете и разблокировали, Вы делаете скоординированное чтение или запись, передачу наших блоков кода методов, делающих чтение или запись. Когда один из тех блоков возвращает или выдает исключение Objective C или Ваши сбои приложения, конечно, Ваше приложение определенно прекращает заставлять другие процессы ожидать.


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

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

Чтобы позволить Вам более точно указать свое намерение при удалении наблюдателя, новый NSObject (NSKeyValueObserverRegistration) метод был добавлен в iOS 5:
- (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;


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

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


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

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

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

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


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

В iOS 4, многие NSFileManager APIs были изменены для взятия NSURLs в качестве параметров вместо путей NSString для продвижения эффективности файловой системы. В iOS 5 два дополнительных метода теперь имеют версии 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 является абстракцией, как имя указывает, ряд индексов. Это также часто используется в качестве ряда диапазонов состоящих из нескольких несмежных участков. Перед iOS 5 не было никакого API для доступа к диапазонам индексов, сохраненных в индексном наборе; к диапазонам можно было только получить доступ при помощи основанных на индексе примитивов. Так как это не тривиально, iOS 5 имеет новое удобство 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

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

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

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


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

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

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


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

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

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


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

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


Поток 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
    Это идентично поведению в iOS 4 и ранее
NSXMLNodeLoadExternalEntitiesSameOriginOnly
    Когда URL был предоставлен, это только применяется. Это загружает объекты целевым URLs, соответствующим узел, схему и порт документа URL.
NSXMLNodeLoadExternalEntitiesNever
    Это отключает загружающиеся внешние объекты

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

Если внешнему объекту не удается загрузиться, документ недопустим, и синтаксический анализ прерывается с ошибкой. Так как много использования NSXMLDocument ожидают маленький набор известных внешних объектов (DTDs, являющийся наиболее распространенным), новый init метод был добавлен, который принимает NSSet URLs, всегда загружающегося независимо от вышеупомянутых опций:
- (id)initWithData:(NSData *)data options:(NSUInteger)mask validExternalEntityURLs:(NSSet *)validURLs error:(NSError **)error;


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

Даже если пакет создавался с относительным путем, для приложений, соединенных на iOS 5 или позже, 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;


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

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

NSOrderedSet имеет три примитива, два из которых совпадают с NSArray:
- (NSUInteger)count;
- (id)objectAtIndex:(NSUInteger)idx;
и добавляет одну треть:
- (NSUInteger)indexOfObject:(id)object;
который является основанием Операций присвоения. Последние возвраты индекс данного объекта, как Вы могли бы предположить. Все они [в подклассе] должны быть быстрым «постоянным временем» операции для NSOrderedSet для выполнения хорошо.

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

NSMutableOrderedSet имеет три дополнительных примитива, главным образом действующие как примитивы 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];


NSCalendar

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

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

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

NSWeekOfMonthCalendarUnit, NSWeekOfYearCalendarUnit, NSYearForWeekOfYearCalendarUnit

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

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


iCloud

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

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

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

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

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

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


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

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

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