Spec-Zone .ru
спецификации, руководства, описания, API
Библиотека разработчика Mac Разработчик
Поиск
Сгенерированный документ: 05.06.2014 12:26:27 - 0700
Copyright © 2014 информации о версии OS X Apple Inc Все права защищены.


OS X 10.10 информации о версии
Платформа основы какао



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

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

Эти примечания покрывают многих, но ни в коем случае все изменения в Наборе Основы в OS X 10.10. Эти примечания применяются к выпуску семени 1, выпущенный в 2014 WWDC.

Некоторые главные темы покрыли в этом документе:





Swift

Swift является новым языком программирования для Касания Какао и Какао, обеспечивающего много инновационных функций, также беспрепятственно управляя с Какао APIs и Objective C. Можно найти документацию, информацию о версии и другие ресурсы для разработки Swift на веб-сайте разработчика Apple.

Некоторые элементы примечания относительно взаимодействия Swift с существующим Какао APIs:

• Методы экземпляра в Какао APIs сталкиваются к Swift в значительной степени как есть. Метод, такой как:
- (BOOL)setResourceValue:(id)value forKey:(NSString *)key error:(NSError **)error;
в Swift похож:
func setResourceValue(value:AnyObject?, forKey key:String?, error:NSErrorPointer) -> Bool
Первая часть имени Objective C появляется как первая часть имени Swift вне parens, и метки на вторых и последующих параметрах появляются как метки в Swift также.

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

Важный, чтобы отметить, что имя Swift такого метода включает метки, таким образом, имя такого метода было бы считано как в ObjC, как «ошибка setResourceValue forKey», не «setResourceValue». Удаляя имена параметров, сигнатура метода:
func setResourceValue(AnyObject?, forKey:String?, error:NSErrorPointer) -> Bool
Таким образом, в основном имена метода экземпляра Objective C представлены автоматически и без любых изменений в Swift.

методы init также представлены автоматически, но существует отображение: И методы init и конструкторы удобства представлены в Swift как конструкторы. В таких случаях, если настоящее, «с» отбрасывается, и все параметры, включая первый, имеют явную метку. Так метод, такой как:
- (instancetype)initWithTimeIntervalSinceNow:(NSTimeInterval)secs;
представлен как:
convenience init(timeIntervalSinceNow secs: NSTimeInterval)
и та же вещь происходит с конструктором удобства, таким как:
+ (NSColor *)colorWithPatternImage:(NSImage *)image;
который появляется как:
init(patternImage image: NSImage?)
• Как Вы видите в вышеупомянутых примерах, некоторые типы Какао Objective C отображаются на их дубликатах Swift, таких как NSString/String выше. Также обратите внимание на то, что - касательно параметров возврата NSError (NSError **) появляются как NSErrorPointer в Swift. ID появляется в Swift как AnyObject, и NSArray появляется как AnyObject []. NSInteger отображается на Интервале, и в большинстве случаев так NSUInteger.

• Структуры какао, такие как NSRange и NSSize доступны Swift с пользовательскими конструкторами, таковы как:
let size = NSSize(width: 20, height: 40)
• Для локализации строк в приложениях, можно использовать NSLocalizedString (key:tableName:bundle:value:comment:) функция. Эта функция обеспечивает значения по умолчанию для имени таблицы, пакета и параметров значения, таким образом, можно использовать его во множестве форм, самого короткого существа:
result = NSLocalizedString("Update", comment:"Title of button the user can click to update account info")
• Перечисления в Какао, следующие «общей префиксной» рекомендации по именованию (который применяется к более свежим перечислениям) появляются в Swift с общим удаленным префиксом. Например:
typedef NS_ENUM(NSInteger, NSByteCountFormatterCountStyle) {
    NSByteCountFormatterCountStyleFile,
    NSByteCountFormatterCountStyleMemory,
    NSByteCountFormatterCountStyleDecimal,
    NSByteCountFormatterCountStyleBinary
};
представлен в Swift как:
enum NSByteCountFormatterCountStyle : Int {
    case File
    case Memory
    case Decimal
    case Binary
}
и можно именовать отдельные значения как NSByteCountFormatterCountStyle. Файл или просто.File в надлежащих контекстах.

• Селекторы Objective C кажутся использующими Селекторный тип в Swift. Можно создать селектор со строковым литералом, такой как
let action: Selector = "updateAccountInfo:"


Строковое обнаружение кодирования

NSString добавил API, который может использоваться для обнаружения строкового кодирования массива байтов. API:
+ (NSStringEncoding)stringEncodingForData:(NSData *)data
             encodingOptions:(NSDictionary *)opts
             convertedString:(NSString **)string
           usedLossyConversion:(BOOL *)usedLossyConversion;
Этот API используется для обнаружения строкового кодирования данного необработанные данные. Это может также сделать преобразование строк с потерями. Это преобразовывает данные в строку в обнаруженном строковом кодировании. Объект данных содержит необработанные байты, и словарь опции содержит подсказки и параметры для анализа. Выбирает, словарь может быть нолем. Если строковым параметром не является NULL, строка, создаваемая обнаруженным строковым кодированием, возвращается. Строка замены с потерями испускается в выводимой строке для символов, которые не могли быть преобразованы, когда включено преобразование с потерями. usedLossyConversion указывает, существует ли какое-либо преобразование с потерями в законченной строке. Если никакое кодирование не может быть обнаружено, 0 возвращается.

Возможный ключ для словаря опции и их значений:

• Ключ: NSStringEncodingDetectionSuggestedEncodingsKey; Значение: массив предложенных строковых кодировок (не указывая 3-ю опцию в этом списке, все строковые кодировки рассматривают, но у тех в массиве будет более высокое предпочтение; кроме того, порядок кодировок в массиве важен: первое кодирование имеет более высокое предпочтение, чем второе в массиве),
• Ключ: NSStringEncodingDetectionDisallowedEncodingsKey; Значение: массив строковых кодировок для не использования (строковые кодировки в этом списке не рассмотрят вообще),
• Ключ: NSStringEncodingDetectionUseOnlySuggestedEncodingsKey; Значение: булев параметр, указывающий, являются ли только предложенные строковые кодировки, рассматривает
• Ключ: NSStringEncodingDetectionAllowLossyKey; Значение: булев параметр, указывающий, позволяется ли с потерями
• Ключ: NSStringEncodingDetectionFromWindowsKey; Значение: опция, дающая определенную строку для заменения таинственные байты
• Ключ: NSStringEncodingDetectionLossySubstitutionKey; Значение: язык текущего пользователя
• Ключ: NSStringEncodingDetectionLikelyLanguageKey; Значение: булев параметр, указывающий, сгенерированы ли данные Windows

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

Если строковое кодирование известно, + [NSString initWithData:encoding:] должен использоваться для создания строки. Используйте этот новый API для создания строки, только если строковое кодирование неизвестно, или преобразование с потерями необходимо.


Средство форматирования интервала даты

NSDateIntervalFormatter был добавлен в 10,10. Это используется для форматирования интервала даты чувствительным к локали способом. Интервал даты определяется двумя датами, например, 1-го сентября 2013 - 1-го октября 2013. В разных странах и различных областях, люди используют различные языки и различные форматы для выражения интервала даты. NSDateIntervalFormatter разработан для удовлетворения потребности, что мы можем легко отформатировать интервал даты в локализованную строку.

NSDateIntervalFormatter является подклассом NSFormatter. Однако это не поддерживает парсинг. Кроме того, NSDateIntervalFormatter требует двух объектов продолжить работать, таким образом, базовые методы в NSFormatter, такие как stringForObjectValue: не применяться.

В NSDateIntervalFormatter существует отдельный метод:-stringFromData:toDate:. Тем, как даты отформатированы, управляют или dateTemplate свойством или dateStyle и timeStyle свойствами (точно так же, как NSDateFormatter). dateTemplate свойство отличается от dateFormat свойства в NSDateFormatter. Информация о положении каждого модуля в dateTemplate проигнорирована, и значение dateTemplate может быть изменено и нормализовано.

Компонентное средство форматирования даты

Основа теперь обеспечивает локализованное форматирование продолжительностей и количества времени через новый класс NSDateComponentsFormatter. Заголовочный файл NSDateComponentsFormatter.h экстенсивно прокомментирован с примерами, информацией и инструкциями по использованию. ‘formattingContext’ свойство, упомянутое ниже, еще не реализовано в семени WWDC.

Средства форматирования модуля

Три новых средства форматирования модуля были добавлены в 10,10. Они - NSMassFormatter, NSLengthFormatter и NSEnergyFormatter. Эти средства форматирования не поддерживают или парсинг или преобразование модуля. Эти средства форматирования могут отформатировать комбинацию значения и модуля в локализованную строку. Они могут также использоваться для получения локализованной строки модуля, и если модуль исключителен, или множественный основывается на данном значении.

NSMassFormatter имеет специальное свойство, названное isForPersonMassUse. Если средство форматирования используется для форматирования массы лица, это свойство должно быть установлено в YES.
NSEnergyFormatter имеет специальное свойство, названное isForFoodEnergyUse. Если средство форматирования используется для форматирования значений для продовольственной энергии, это свойство должно быть установлено в YES.

Форматирование контекста

Новое свойство, названное formattingContext, было добавлено к NSDateFormatter, NSNumberFormatter, NSDateComponentsFormatter и NSByteCountFormatter для выражения контекстной информации для форматирования данных. Контекстная информация - то, где данные будут выведены на экран так, чтобы это могло капитализироваться соответственно. Например, дата или элемент даты могли быть в течение начала предложения, середина предложения, для дисплея в списке UI, или для автономного дисплея. Дата или элемент даты могут иметь различную капитализацию для различного контекста. API контекста форматирования дает лучший контроль того, как капитализируются данные.

Существует 6 различных значений для formattingContext, и они определяются в NSFormatter.h.

В большую часть времени должен использоваться NSFormattingContextDynamic. Когда NSFormattingContextDynamic используется, контекст капитализации определяется динамично от набора {NSFormattingContextStandalone, NSFormattingContextBeginningOfSentence, NSFormattingContextMiddleOfSentence}. Например, если дата помещается в начале предложения, NSFormattingContextBeginningOfSentence используется для форматирования строки автоматически. Когда этот контекст будет использоваться, средство форматирования возвратит строковый прокси, работающий как нормальная строка в большинстве случаев. После возврата из средства форматирования строка в строковом прокси отформатирована при помощи NSFormattingContextUnknown. Когда строковый прокси используется в - [NSString stringWithFormat:], мы можем определить, где % является и затем установил контекст соответственно. С новым контекстом строка в строковом прокси будет отформатирована снова и помещена в заключительную строку, возвращенную из - [NSString stringWithFormat:].

Исправление ошибки NSDateFormatter

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

NSCalendar

Два исламских календарных варианта были добавлены в 10,10:
// A simple tabular Islamic calendar using the astronomical/Thursday epoch of CE 622 July 15
NSString * const NSCalendarIdentifierIslamicTabular;
// The Islamic Umm al-Qura calendar used in Saudi Arabia. This is based on astronomical calculation, instead of tabular behaviour.
NSString * const NSCalendarIdentifierIslamicUmmAlQura;
Они могут использоваться для создания объектов NSCalendar с initWithCalendarIdentifier:.

Исправление ошибки:
Когда параметр NSDateComponents имеет набор isLeapMonth для китайского календаря, следующие методы теперь работают правильно в 10,10:

- enumerateDatesStartingAfterDate:matchingComponents:options:usingBlock:
- nextDateAfterDate:matchingComponents:options:

Изменение поведения:
Поведение следующих методов было изменено в 10,10 с опцией NSCalendarMatchPreviousTimePreservingSmallerUnits или опцией NSCalendarMatchNextTimePreservingSmallerUnits:

- enumerateDatesStartingAfterDate:matchingComponents:options:usingBlock:
- nextDateAfterDate:matchingComponents:options:

В 10,9, если дата, соответствующая компоненты предоставления, отсутствует, методы возвратят предыдущее (или следующее, в зависимости от которого опция указана), существующее значение самого высокого модуля с существует и сохраняет значения более низких модулей. Например, давая 01.01.2014 11:11:11, если компоненты 29 февраля, методы возвратят 29 января 0:00:00 в 2014, давая опцию NSCalendarMatchPreviousTimePreservingSmallerUnits.

В 10,10, было изменено поведение: если дата, соответствующая компоненты предоставления, будет отсутствовать, то методы возвратят предыдущее (или следующее, в зависимости от которого опция указана), существующее значение недостающего модуля, и сохраняет значения более низких модулей даты предоставления. Например, давая 01.01.2014 11:11:11, если компоненты 29 февраля, методы возвратят 28-го февраля 11:11:11 в 2014, давая опцию NSCalendarMatchPreviousTimePreservingSmallerUnits.



NSXPCConnection и NSProgress

В OS X 10.10 и iOS 8.0, NSXPCConnection и NSProgress были интегрированы для сотрудничества беспрепятственно.

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

Например, следующий код является частью приложения, просящего, чтобы служба помощника XPC загрузила файл.
- (IBAction)fetch:(id)sender
{
NSURL *urlToFetch = ...;
    NSProgress *progress = [NSProgress progressWithTotalUnitCount:1];
[progress becomeCurrentWithPendingUnitCount:1];
    // Create a connection to our fetch-service and ask it to download for us. The fetch-service will implement the 'Fetch' protocol.
NSXPCConnection *fetchServiceConnection = [[NSXPCConnection alloc] initWithServiceName:@"com.apple.SandboxedFetch.fetch-service"];
fetchServiceConnection.remoteObjectInterface = [NSXPCInterface interfaceWithProtocol:@protocol(Fetch)];
[fetchServiceConnection resume];
    // Send a message to the fetch service. Because there is a current progress object (‘progress’), it will be updated if the remote side reports progress.
[[fetchServiceConnection remoteObjectProxy] fetchURL:urlToFetch withReply:^(BOOL ok) {
// This block will be invoked when the helper service replies.
}];
    // Even if the work is done asynchronously, we can resignCurrent here.
[progress resignCurrent];
}
В службе, реализующей fetchURL:withReply: метод, текущий объект прогресса уже является установкой для нас, и мы просто должны присоединить новый прогресс к нему для представления работы, которую мы будем выполнять.
- (void)fetchURL:(NSURL *)url withReply:(void (^)(BOOL))reply {
// Create a progress object to handle progress below
NSProgress *progress = [NSProgress progressWithTotalUnitCount:10];
progress.cancellationHandler = ^{
// handle a cancellation from the application
};
    // do work here, e.g.
progress.completedUnitCount = 1;
// more work
progress.completedUnitCount = 5;
// etc.
   reply(YES);
}

Изменение случая имени файла с NSFileManager

В предыдущих выпусках, методы NSFileManager-moveItemAtPath:toPath:error: и-moveItemAtURL:toURL:error: когда оба параметра относятся к тому же элементу на диске, перестал бы работать с NSFileWriteFileExistsError. Эта работа теперь успешно выполняется, который в нечувствительных к регистру но сохраняющих случай файловых системах (как HFS + на OS X) позволит изменять случай имени файла.

Больше принятия NSSecureCoding

NSIndexSet и NSIndexPath теперь оба реализуют протокол NSSecureCoding, позволяющий им использоваться с APIs NSXPC.

Уведомления изменения атрибута пакета файла NSFilePresenter

Когда только атрибуты того пакета были изменены, в предыдущих выпусках-presentedItemDidChange не был отправлен NSFilePresenters пакетов файла. Это было закреплено на OS X 10.0 и iOS 8.0.

Исправление ошибки в NSMetadataItem

В OS X 10.9, создавая NSMetadataItem с URL, для которого не существует никакой файл, вызвал бы последующий-valueForAttribute: обменивайтесь сообщениями для катастрофического отказа. Вместо катастрофического отказа,-initWithURL: теперь возвратит ноль в этой ситуации.

Увеличенная мягкость для NSDataBase64DecodingIgnoreUnknownCharacters

В OS X 10.9, декодируя основу 64 строки с «=» символы, прежде чем конец строки заставил бы всю работу декодирования перестать работать. Однако RFC 4648 в частности позволяет реализациям игнорировать эти символы, обрабатывая их как другие неизвестные символы. NSData базируются, 64 алгоритма декодирования были обновлены для обеспечения этого, когда используется NSDataBase64DecodingIgnoreUnknownCharacters.


NSFileCoordinatorReadingForUploading

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

Для использования этого API запросите скоординированное чтение на любом пользовательском документе, тот же способ, которым Вы были бы для нормального чтения, кроме использования NSFileCoordinatorReadingForUploading. Прежде чем Ваш блок средства доступа вызывается, NSFileCoordinator проверит, является ли файл каталогом или нет. Если это будет, то это создаст архив zip того каталога во временной папке, которая доступна Вашим приложением. Если файл не будет каталогом, то он будет скопирован в тот каталог вместо этого. URL к недавно создаваемому временному файлу будет доступен в Вашем блоке средства доступа.

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

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

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

Асинхронное ожидание NSFileCoordinator

До OS X 10.10 и iOS 8.0, рекомендуемый способ асинхронно ожидать скоординированного чтения или записи состоял в том, чтобы диспетчеризировать блок другой очереди, тогда вызывающей-coordinateReadingItemAtURL:options:error:byAccessor: (или один из трех других похожих методов), который тогда ожидает синхронно на той очереди. Однако этот образец был расточителен из очередей отгрузки и потоков.

Существует новый API, доступный на NSFileCoordinator, названном-coordinateAccessWithIntents:queue:byAccessor: это будет ожидать асинхронно доступа к требуемому URLs, не используя дополнительные очереди. Когда доступ был предоставлен, метод вызовет Ваш блок средства доступа на очередь, которую Вы указываете.

Как более старые методы, блок средства доступа, переданный этому методу, все еще выполняется синхронно — когда Вы возвратитесь из блока, скоординированный доступ к файлу закончится. В отличие от более старых методов, этот новый API позволяет Вам выполнять координацию для произвольного числа файлов путем передачи массива объектов NSFileAccessIntent. NSFileAccessIntent инкапсулирует URL, является ли доступ чтением или записью, и чтением или записью опций. Когда Ваш блок средства доступа вызывается, необходимо использовать свойство URL на объекте NSFileAccessIntent, не, NSURL возражают используемый созданию того NSFileAccessIntent. Если документ, к которому Вы пытаетесь получить доступ, будет перемещен или переименован, то NSFileCoordinator обновит свойство URL NSFileAccessIntent с новым значением. NSFileCoordinator неспособен изменить любой другой URLs, который Вы получили с блоком средства доступа. Вот пример надлежащего использования этого API:
NSFileAccessIntent *srcIntent = [NSFileAccessIntent readingIntentWithURL:url1 options:NSFileCoordinatorWritingForMoving];
NSFileAccessIntent *dstIntent = [NSFileAccessIntent writingIntentWithURL:url2 options:NSFileCoordinatorWritingForReplacing];
[fileCoordinator coordinateAccessWithIntents:@[srcIntent, dstIntent] queue:myQueue byAccessor:^(NSError *error) {
    BOOL success = error == nil;
    if (success) {
        success = [fileManager removeItemAtURL:dstIntent.URL error:&error];
    }
    if (success) {
        success = [fileManager moveItemAtURL:srcIntent.URL toItemAtURL:dstIntent.URL error:&error];
    }
    if (!success) {
        // present error on main queue
    }
}];
Обратите внимание на то, что, если ошибка происходит, NSError передается блоку средства доступа вместо того, чтобы быть возвращенным ссылкой через NSError ** параметр.

Отладка задержек координации файла

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

В OS X 10.10 и iOS 8.0, класс NSFileCoordinator теперь реагирует на метод, вызванный + (недействительный) _printDebugInfo. Этот метод распечатает всю доступную информацию о каждом файле или каталоге, вовлеченном в Координацию Файла в Вашей системе и каждый процесс, взаимодействующий с ним. Этот метод предназначается для использования в отладчике, не используйте этот метод в поставляющем коде. Это не объявляется ни в каких заголовках и может быть удалено или переименовано без предварительного уведомления.

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

Второй раздел вывода покажет каждый процесс, взаимодействующий с Координацией Файла. Это показывает действие NSFilePresenter, как то, какие сообщения NSFilePresenter были отправлены, но еще не ответили на, а также информация сериализации NSDocument, если применимо.

Используя всю эту информацию, должно стать намного проще понять и отладить проблемы, которые можно испытывать с Координацией Файла. На OS X вся эта та же информация предоставлена в архиве, создаваемом ‘sysdiagnose’ инструментом, который поможет Вам в отладке проблем, происходящих на компьютерах клиента. Обратите внимание на то, что эта информация включает файл и имена процесса, но не включает содержания файла.

Идентификаторы цели NSFileCoordinator

Идентификатор цели NSFileCoordinator является строкой, однозначно определяющей доступ к файлу, который будет сделан NSFileCoordinator. Каждый NSFileCoordinator имеет уникальный идентификатор цели, создающийся во время инициализации. Скоординированные чтения и записи, выполняемые NSFileCoordinators с тем же идентификатором цели никогда, не блокируют друг друга, даже если они происходят из различных процессов. При координировании доступа к файлу от имени NSFilePresenter необходимо использовать-initWithFilePresenter: и не должен пытаться установить пользовательский идентификатор цели. Каждый экземпляр NSFileCoordinator, инициализированный с тем же NSFilePresenter, будет иметь тот же идентификатор цели.

При использовании NSFileProviderExtension API необходимо предоставить ‘providerIdentifier’. Каждый раз, когда NSFileProviderExtension должен сделать координацию файла, он должен установить идентификатор цели NSFileCoordinator в providerIdentifier NSFileProviderExtension. Иначе, координация могла инициировать дополнительные неожиданные действия Вашим NSFileProviderExtension.

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

При создании пользовательских идентификаторов цели можно использовать обратную строку стиля DNS, такую как «com.mycompany.myapplication.mypurpose» или строка UUID. Ноль и строки нулевой длины не позволяются.

Идентификаторы цели могут быть установлены только один раз на NSFileCoordinator. При попытке установить идентификатор цели NSFileCoordinator, который Вы инициализировали с-initWithFilePresenter: или это, Вы уже присвоили идентификатор цели, исключение, будет брошено.


NSMetadataQuery и улучшения NSMetadataItem для повсеместных элементов

При использовании одного из «повсеместных» объемов NSMetadataQuery Вам теперь разрешают передать [NSPredicate predicateWithValue:YES] для простого соответствия всех файлов в объеме. Этот предикат является теперь также значением по умолчанию для повсеместных объемов. Явный предикат все еще требуется на OS X для неповсеместных объемов.

Атрибуты NSMetadataItemContentTypeKey и NSMetadataItemContentTypeTreeKey теперь доступны для использования на NSMetadataItems, создаваемом запросами с повсеместными объемами.

Символы NSMetadataQueryUpdateAddedItemsKey, NSMetadataQueryUpdateChangedItemsKey и NSMetadataQueryUpdateRemovedItemsKey, как первоначально объявляли, были доступны на iOS 7.0. Однако символы не существовали на iOS до 8.0. Объявление в заголовке было обновлено для отражения этого факта.

Обновление приложения iCloud для OS X 10.10 и iOS 8.0

До OS X 10.10 и iOS 8.0, файлы iCloud, о которых система знает, но еще не загрузила, были бы представлены в контейнере повсеместности приложения с видимым специальным пользователем файлом. Тот файл имел бы то же имя как файл в iCloud и мог использоваться для получения различных метаданных о файле. Тот файл мог также быть перемещен, переименован или удален локально, и те изменения будут отражены в состоянии сервера iCloud. Это больше не имеет место на OS X 10.10 или iOS 8.0 SDKs. Вместо этого невыполненные файлы представлены с невидимым файлом в том же каталоге, именовании и содержание которого является подробными данными реализации и подлежащий изменению. Это изменение имеет две импликации для приложений:

1) Не рекомендуется использовать перечисление каталога APIs (например, NSDirectoryEnumerator, CFURLEnumerator, readdir, и т.д.) для перечисления содержания контейнера повсеместности. Приложения должны вместо этого использовать NSMetadataQuery с NSMetadataQueryUbiquitousDataScope или NSMetadataQueryUbiquitousDocumentsScope, который перечислит все известные файлы данных или файлы документов в контейнере. Если необходимо перечислить содержание контейнера, необходимо проигнорировать любые скрытые файлы или файлы с расширениями, которые не распознает приложение.

2) Не возможно использовать стандартный APIs для получения атрибутов файла (например, значения ресурса NSURL, NSFileManager, статистика, getattrlist, и т.д.) на URLs невыполненных файлов, потому что нет никакого настоящего файла в URL, пока не был загружен файл. Приложения должны вместо этого использовать новый APIs, разработанный с этой целью, которые объяснены ниже.

Если Ваше приложение уже использует NSMetadataQuery для перечисления файлов iCloud, только получает атрибуты файла от NSMetadataItem, и всегда использует NSFileCoordinator для доступа к файлам iCloud, то Вы не должны должны быть изменять что-либо о своем приложении, чтобы позволить ему продолжать работать с iCloud на OS X 10.10 и iOS 8.0.

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

1. - [NSURL getPromisedItemResourceValue:forKey:error:] и - [NSURL promisedItemResourceValuesForKeys:error:]

Эти методы являются версиями существующего APIs NSURL, понимающего, как получить атрибуты от невыполненных файлов iCloud. Они могут использоваться с любыми значениями ресурса NSURL, не зависящими от присутствующего содержания файла (например, NSURLGenerationIdentifierKey, NSURLContentAccessDateKey и NSURLFileResourceIdentifierKey).

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

2. NSFileCoordinatorReadingImmediatelyAvailableMetadataOnly и NSFileCoordinatorWritingMetadataOnly

Обычно, использование NSFileCoordinator для выполнения скоординированного чтения заставит невыполненный файл iCloud быть загруженным, прежде чем будет вызван блок средства доступа. Если Вы просто хотите считать метаданные файла, можно избежать ожидать файла для загрузки при помощи этой опции в скоординированном чтении. При использовании этой опции необходимо все еще использовать методы «PromisedItem» NSURL в блоке средства доступа для безопасного чтения метаданных для файлов, которые не выполнены.

Точно так же, когда все, что Вы хотите сделать, установлено некоторые метаданные по потенциально невыполненным файлам iCloud, необходимо использовать NSFileCoordinatorWritingContentIndependentMetadataOnly. Нет никакого «PromisedItem» APIs для установки атрибутов, таким образом, можно использовать нормальный APIs как - [NSURL setResourceValue:forKey:error:]. Как имя указывает, снова устанавливая только содержание, независимые метаданные поддерживаются,

Для упрощения принятия этого нового APIs приложения создали использование OS X 10.9, или iOS 7.0 SDKs (или ранее) будет иметь все файлы в их контейнере повсеместности загруженными жадно.

NSFilePresenters для каталогов контейнера повсеместности будет продолжать получать-presentedSubitemDidChangeAtURL: и-presentedSubitemAtURL:didMoveToURL: уведомления для невыполненных файлов. Однако Ваше приложение должно знать что для этих невыполненных файлов, нет ничего в файловой системе в том URLs, таким образом, необходимо использовать NSFileCoordinator или «PromisedItem» APIs для взаимодействия с ними.

Наконец, объекты NSMetadataQuery с повсеместными объемами теперь сообщат о каталогах в результатах запроса. В случае необходимости можно использовать NSMetadataItemContentTypeKey в запросе для отфильтровывания чего-либо с типом ‘public.folder’.

Версии iCloud

приложения iCloud на OS X и iOS могут теперь получить доступ к предыдущим версиям документа в iCloud. Когда изменения загружаются на сервер, эти версии автоматически создаются iCloud. Для обнаружения этих версий вызовите + [NSFileVersion getNonlocalVersionsOfItemAtURL:completionHandler:]. Если успешный, обработчик завершения будет передан массив NSFileVersions.

Версии, возвращенные этим API, не будут первоначально иметь содержание версии в наличии локально. - [NSFileVersion hasLocalContents] возвратится НЕ для указания этого. Доступ к этому URLs очень походит на получающие доступ регулярные файлы iCloud. Можно использовать «promisedItem» APIs NSURL для получения метаданных о файле, как его NSURLFileSizeKey или NSURLTypeIdentifierKey. Для инициирования содержания, которое будет загружено, необходимо использовать NSFileCoordinator для выполнения скоординированного чтения на свойстве NSFileVersion’s URL.

Когда содержание версии будет загружено, это будет кэшироваться в локальном NSFileVersion, означая, что это начнет появляться в массиве, возвращенном + [NSFileVersion otherVersionsOfItemAtURL:]. Этот локальный NSFileVersion будет иметь-persistentIdentifier идентичное тем из NSFileVersion ранее возвращенный +getNonlocalVersionsOfItemAtURL:completionHandler:. Можно использовать в своих интересах этот факт для предотвращения двойных версий.

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

1. Выполните скоординированное чтение на желаемом файле.
2. Зарегистрируйте NSFilePresenter в + [NSFileCoordinator addFilePresenter:]
3. Вызовите + [NSFileVersion otherVersionsOfItemAtURL:] для получения локальных версий
4. Вызовите + [NSFileVersion getNonlocalVersionOfItemAtURL:completionHandler:] для получения нелокальных версий.
5. В реализации Вашим NSFilePresenter-presentedItemDidGainVersion: ищите версию с тем же значением-persistentIdentifier как переданный - в NSFileVersion (или это соответствует с-isEqual:) и замена, что версия с новой. В реализации Вашим NSFilePresenter-presentedItemDidLoseVersion: ищите NSFileVersion, соответствующий переданный - в NSFileVersion, и удалите его.

Повсеместные внешние документы

Если Ваше приложение для iOS будет использовать UIDocumentPickerViewController, то Ваше приложение будет в состоянии получить доступ к документам от за пределами контейнера повсеместности Вашего приложения. Когда пользователь предоставит Ваш доступ к приложениям к файлу от контейнера повсеместности другого приложения, Вашему приложению позволят вновь открыть тот документ о любом устройстве с помощью той же учетной записи iCloud, не требуя, чтобы пользователь прошел через средство выбора документа снова. Эти ранее открытые внешние повсеместные документы могут быть найдены с NSMetadataQueryAccessibleUbiquitousExternalDocumentsScope.

Результаты NSMetadataItem в этом объеме возвратят YES для атрибута NSMetadataUbiquitousItemIsExternalDocumentKey, чтобы указать что они извне контейнера приложения. Поскольку эти документы существуют вне песочницы Вашего приложения, атрибутом NSMetadataItemURLKey этих элементов является ограниченный по объему безопасностью URL. Для доступа к этим документам необходимо сначала вызвать - [NSURL startAccessingSecurityScopedResource]. Если этот метод возвращается ДА, то, когда Вы сделаны, получив доступ к документу, необходимо вызвать - [NSURL stopAccessingSecurityScopedResource].

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

Внешние повсеместные документы также представлены специальным файлом на диске. Расположение этих файлов доступно с NSMetadataUbiquitousItemURLInLocalContainerKey. Можно позволить пользователям перемещать эти файлы в другие каталоги в контейнере повсеместности приложения.

загрузка iCloud запросила состояние

Можно теперь использовать NSURLUbiquitousItemDownloadRequestedKey или NSMetadataQueryUbiquitousItemDownloadRequestedKey, чтобы обнаружить, требовали ли загрузку для файла iCloud уже или со скоординированным чтением или с - [NSFileManager startDownloadingUbiquitousItemAtURL:error:]. Можно использовать это состояние в UI, чтобы показать пользователям, что документ требовали и поставят, как только iCloud может поставить его.


Проверка версии операционной системы NSProcessInfo

NSProcessInfo имеет новый API:
- (BOOL) isOperatingSystemAtLeastVersion:(NSOperatingSystemVersion)version
который позволяет программам тестировать, являются ли они на определенной версии OS или более новый. Кроме того, существует новое свойство для получения версии OS, на котором в настоящее время работает приложение:
@property (readonly) NSOperatingSystemVersion operatingSystemVersion

+ [NSLocale autoupdatingCurrentLocale] Исправление ошибки

Автообновление NSLocales не было абсолютно бесплатное соединенный мостом с CFLocaleRef, приводящим к катастрофическим отказам, когда передано некоторым методам (в определенном lowercaseStringWithLocale:). Это было фиксировано.


- [NSUserDefaults синхронизируются] Изменения

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

Если Вы:

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

Тогда не делайте так теперь. Это должно просто работать, и синхронизация излишне замедлит Вашу программу.

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

Файлы NSUserDefaults Plist

Дисковые файлы списка свойств, используемые NSUserDefaults, всегда были частной подробностью реализации, но в предыдущих выпусках iOS и значительно более старых выпусках Mac OS X, непосредственно изменяя их главным образом работал (хотя существуют некоторые потенциальные проблемы потери данных для приложений, делающих так, даже в предыдущих системах). В iOS 8 и позже, процесс демона NSUserDefaults (cfprefsd) будет кэшировать информацию от этих файлов и асинхронно писать в них. Это означает, что непосредственно изменение plist файлы вряд ли будет иметь ожидаемые результаты (новые настройки будут не обязательно считаны и могут даже быть перезаписаны). Необходимо использовать NSUserDefaults или APIs CFPreferences, или (на Mac OS X) значения по умолчанию (1) команда, для взаимодействия с предпочтительной системой.

Компромиссы производительности NSUserDefaults

Чтение от NSUserDefaults чрезвычайно быстро. Это будет кэшировать значения, чтобы избежать читать из диска и занимает приблизительно 0,5 микросекунды, чтобы сделать [[NSUserDefaults standardUserDefaults] boolForKey:] на MacBook Pro 2012. Это является обычно ненужным (и даже нежелательный, так как это предотвращает берущие новые значения) кэшировать результат чтения от предпочтений.

Однако запись в NSUserDefaults немного медленнее. В целом ожидайте, что он возьмет примерно пока использование NSPropertyListSerialization, чтобы преобразовать Ваш ключ и оценить plist данным плюс несколько 10-х микросекунд. Поэтому, а также использование памяти, обычно лучше хранить относительно маленькие данные в CFPreferences.

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

значения по умолчанию (1) улучшения

‘Импорт значений по умолчанию’ и ‘команды’ экспорта значений по умолчанию теперь поддерживают stdin и stdout как цели путем передачи ‘-‘ как путь.



NSQualityOfService

Несколько новых классификаций Качества обслуживания (QoS) были добавлены, которые отображаются на новое базовое понятие OS в OS X 10.10 и iOS 8. Они используются для указания к системе природы и важности работы, и используются системой для управления множеством ресурсов. Более высокие классы QoS получают больше ресурсов, чем более низкие во время конкуренции ресурса.

NSQualityOfServiceUserInteractive: этот QoS используется для работы, непосредственно вовлеченной в обеспечение интерактивного UI, такого как обработка событий или рисование на экран.

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

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

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

NSQualityOfServiceDefault: это значение NSQualityOfService указывает отсутствие информации о QOS. Каждый раз, когда возможная информация о QOS будет выведена из других источников. Если такой вывод не будет возможен, то QoS между UserInitiated и Утилитой будет использоваться.


NSTask qualityOfService

NSTask имеет новое qualityOfService свойство.

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

• Если свойство не было установлено, Вы получаете поведение по умолчанию от OS.
• Если свойство было установлено в NSQualityOfServiceDefault, Вы получаете поведение по умолчанию от OS.
• Если свойство было установлено в другое значение, то значение дано OS при запуске нового процесса.

NSTasks не выводят QOS ни из какого контекста выполнения, хотя базовые способы поведения OS могли бы.


NSThread qualityOfService

NSThread имеет новое qualityOfService свойство.

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

• Если свойство не было установлено, Вы получаете поведение по умолчанию от OS.
• Если свойство было установлено в NSQualityOfServiceDefault, Вы получаете поведение по умолчанию от OS.
• Если свойство было установлено в другое значение, то значение дано OS при начинании новой дискуссии.

При чтении qualityOfService потока после того, как запустился поток, считает его текущую стоимость.

NSThreads не выводят QOS ни из какого контекста выполнения, хотя базовые способы поведения OS могли бы.

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


NSOperationQueue qualityOfService

NSOperationQueue имеет новое qualityOfService свойство.

В любое время можно изменить qualityOfService свойство.

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

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

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

Когда работа добавляется к очереди, эффективные значения QOS работы в то время могут влиять на эффективный QOS операций, которые уже находятся в очереди («перед нею»):

• Операции уже вперед в очереди недавно добавленной работы, работая или нет, продвинуты на эффективный QOS добавляемой работы.

Таким образом, если высокая операция QOS добавляется к очереди, операции уже в очереди повышены до того уровня (если они были ниже). Операции, добавленные после той работы высокого QOS, не затронуты ее присутствием в очереди.

Значение и взаимодействие продвижения работы QOS и эффективный QOS обсуждены в разделе по NSOperation qualityOfService.

NSOperationQueues не выводят QOS ни из какого контекста выполнения.

Если (dispatch_queue_t) underlyingQueue свойство NSOperationQueue установлен, qualityOfService значения свойств NSOperationQueues, и NSOperations не имеют никакого эффекта. Эффективный QOS операций, выполненных той очередью, определяется состоянием dispatch_queue_t.


NSOperation qualityOfService

NSOperation имеет новое qualityOfService свойство.

В любое время можно изменить qualityOfService свойство.

Существуют различные реальные и виртуальные значения QOS, касающиеся, как работает работа:

• qualityOfService значение свойства
• Выведенный QOS
• Продвижение QOSes
• Эффективный QOS

Когда объект операции создается, выведенное значение QOS вычислено из контекста выполнения:

• Если также:
    • работа создается в контексте выполнения другой работы (уже работающий на том потоке); или
    • работа создается в контексте выполнения определенного NSProcessInfo API;
тогда самый близкий из тех к текущему кадру активации стека вызовов текущего потока используется в качестве выведенного QOS новой работы:
    • эффективный QOS той работы в то время, когда это начало работать;
    • значения NSProcessInfo API's отображаются на значении QOS.
• Если работа создается на основном потоке, выведенным QOS является NSQualityOfServiceUserInitiated.
• Иначе, QOS текущего потока (который не может быть ни одним) читается и используется в качестве выведенного QOS новой работы.

Работа может быть продвинута (имейте продвижение, QOSes применился к нему) в нескольких контекстах:

• Когда работа добавляется к очереди, или когда изменяется qualityOfService свойство очереди, в которой находится работа,
    • (как обсуждено в разделе NSOperationQueue)
• Когда различная работа добавляется к очереди, в которой (рассматриваемая) работа уже находится
    • (как обсуждено в разделе NSOperationQueue)
• Когда различному позже (после рассматриваемой работы) работа в той же очереди повысили ее эффективный QOS
    • эффективный QOS другой работы продвигает работу
• Когда различная работа (dependee) становится зависящей от рассматриваемой работы
    • эффективный QOS dependee продвигает работу
• Когда dependee работе повысили ее эффективный QOS
    • новый эффективный QOS dependee продвигает работу
• Когда-waitUntilAllOperationsAreFinished метод очереди работы, используется, когда на работу ожидают с методом-waitUntilFinished, или косвенно
    • если поток ожидания является основным потоком, продвижение, QOS взят, чтобы быть NSQualityOfServiceUserInteractive;
    • иначе, если ожидание сделано в контексте выполнения другой работы, ее эффективный QOS продвигает работу;
    • иначе QOS текущего потока продвигает работу.

Их все коллективно вызывают продвижением QOSes; или для MAX () всех их, просто продвижение QOS.

Эти различные значения соединены в эффективный QOS. Эффективным QOS является MAX () всех этих значений QOS: {выведенный QOS, продвижение QOSes, qualityOfService значение свойства}, с этими квалификациями:

• Если qualityOfService свойство работы было явно установлено во что-нибудь, даже NSQualityOfServiceDefault, выведенный QOS проигнорирован.
• Если qualityOfService свойство работы ни во что не было явно установлено, оно проигнорировано (как будто никакое значение не существует).
• Все значения QOS NSQualityOfServiceDefault проигнорированы.
• Если нет никаких значений QOS после того, как все это игнорирование, эффективным QOS будет NSQualityOfServiceDefault.

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

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


threadPriority свойство NSOPERATION

threadPriority свойство было осуждено. Переместитесь в использование «qualityOfService» свойства и понятий вместо этого.


Имя NSOperation

NSOperation имеет новое свойство имени. Имя работы обнаружится как часть имени базовой очереди отгрузки, на которой работает работа, который обнаруживается в некоторых инструментах.


NSOperationQueue underlyingQueue

NSOperationQueue имеет новое underlyingQueue свойство. Когда установлено в, для выполнения операций NSOperationQueue диспетчеризирует блок этой очереди отгрузки, запускающей работу, а не NSOperationQueue, делающий сам выбор очереди отгрузки.

Исключение будет повышено, если dispatchQueue будет изменен, в то время как операции находятся в очереди работы. Просто не желательно попытаться сделать это. Установите значение один раз после создания NSOperationQueue и перед использованием его иначе.

Существует и не будет никакой способ «найти» NSOperationQueue с данной очередью отгрузки.

Для операций, помещенных в NSOperationQueue с присвоенным dispatch_queue_t, qualityOfService свойство не имеет никакого эффекта; эффективный QOS выполнения прибывает из dispatch_queue_t. Свойство имени NSOperationQueue и NSOperation не имеет никакого эффекта (dispatch_queue_t имеет имя).

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


NSString

NS/CFStrings теперь используют “маркированный указатель” формат, где строковое содержание сохранено в указателе непосредственно в некоторых случаях. Это происходит автоматически через существующий APIs, создающий строки без потребности использовать любой новый API.

Это изменение повредит любой код, обрабатывающий объекты NS/CFStrings как указатели.

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

Существуют другие связанные изменения в поведении вследствие этого изменения. Например,-UTFString и-cStringUsingEncoding: теперь должен произвести буфер, возвращающийся в противоположность возможному возврату внутреннего указателя (который был иногда возможен). Работа была оптимизирована, таким образом, нет значительного влияния производительности, но тем не менее, существует изменение поведения.

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

Это изменение включено только для приложений, соединяющихся против 10,10 SDK.


NSString теперь имеет следующие два удобных метода:
- (BOOL)containsString:(NSString *)str;
- (BOOL)localizedCaseInsensitiveContainsString:(NSString *)str;
containsString: YES возвратов, если целевая строка содержится в получателе. Это совпадает с вызовом rangeOfString:options: без опций, таким образом делая чувствительный к регистру, нелитеральный поиск. localizedCaseInsensitiveContainsString: нечувствительный к регистру вариант. Обратите внимание на то, что это берет текущую локаль в эффект также. Независимая от локали нечувствительная к регистру работа и другие потребности могут быть достигнуты путем вызова rangeOfString:options:range:locale: непосредственно.

Обратите внимание на то, что, как имеет место с существующим rangeOfString: если целевая строка будет пустой строкой, метод и варианты, эти методы возвратятся НЕ.


NSByteCountFormatter

Ошибка, где неадаптивный, дополняющее нуль средство форматирования, выводящее на экран количества байта, использовала бы десятичные разряды (например, выводящий на экран «12,0 байтов»), был фиксирован.