Как переопределить основанный на данных метод чтения

Можно переопределить readFromData:ofType:error: метод для преобразования NSData объект, содержащий данные документа во внутренние структуры данных и дисплей документа, что данные в окне документа. Вызовы архитектуры документа readFromData:ofType:error:, передача в NSData объект, во время его процесса инициализации документа.

Перечисление 4-1 показывает реализацию в качестве примера readFromData:ofType:error: читающий документ метод. Этот пример предполагает, что приложение имеет NSTextView объект, сконфигурированный с NSTextStorage возразите для содержания текстовых данных представления. NSDocument объект имеет a setMString: метод доступа для документа NSAttributedString модель данных, объявленную как свойство, называют mString.

Перечисление 4-1  Основанная на данных читающая документ реализация метода

- (BOOL)readFromData:(NSData *)data ofType:(NSString *)typeName

                                     error:(NSError **)outError {

    BOOL readSuccess = NO;

    NSAttributedString *fileContents = [[NSAttributedString alloc]

            initWithData:data options:NULL documentAttributes:NULL

            error:outError];

    if (!fileContents && outError) {

        *outError = [NSError errorWithDomain:NSCocoaErrorDomain

                                code:NSFileReadUnknownError userInfo:nil];

    }

    if (fileContents) {

        readSuccess = YES;

        [self setMString:fileContents];

    }

    return readSuccess;

}

Если необходимо иметь дело с расположением файла, переопределите чтение URL и методы записи вместо этого. Если Ваше приложение должно управлять файлами документов, которые являются пакетами файла, переопределяют чтение обертки файла и методы записи вместо этого. Для получения информации о переопределении ОСНОВАННЫХ НА URL и основанных на файле-оберткой методов чтения посмотрите Переопределение URL и Методов Чтения Пакета Файла.

Поток сообщений во время считывания данных документа показан на рисунке 6-5.

Просто поддерживать параллельное открытие документа

Метод класса NSDocument, canConcurrentlyReadDocumentsOfType:, включает Ваш NSDocument разделите на подклассы для загрузки документов одновременно, с помощью фоновых потоков. Это переопределение позволяет параллельное чтение многократных документов и также позволяет приложению быть быстро реагирующим при чтении большого документа. Можно переопределить canConcurrentlyReadDocumentsOfType: возвратиться YES включить эту возможность. Когда Вы делаете, initWithContentsOfURL:ofType:error: выполняется на фоновом потоке когда вводные файлы через Открытое диалоговое окно или от Средства поиска.

Реализация по умолчанию этого метода возвраты NO. Переопределение подкласса должно возвратиться YES только для типов документов, чтение которых кода может быть безопасно выполнено одновременно на неосновных потоках. Если тип документа полагается на информацию об общем состоянии, необходимо возвратиться NO для того типа.

Не полагайтесь на методов get свойства документа в переопределениях чтения методов

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

Если Ваше переопределение не может определить всю информацию, этому нужно от передаваемых параметров, рассмотрите переопределение другого метода. Например, если Вы видите потребность вызвать fileURL из переопределения readFromData:ofType:error:, необходимо вместо этого переопределить readFromURL:ofType:error: и используйте переданный - в значении URL.

Определение, Включен ли iCloud

Рано в выполнении Вашего приложения, прежде чем Вы попытаетесь использовать любые другие интерфейсы iCloud, необходимо вызвать NSFileManager метод URLForUbiquityContainerIdentifier: определить, включено ли хранение iCloud. Этот метод возвращает допустимый URL, когда iCloud включен (и указанный контейнерный каталог доступен), или nil когда отключен iCloud. URLForUbiquityContainerIdentifier: также возвраты nil при указании контейнерного ID, к которому приложению не позволяют получить доступ, или это не существует. В этом случае, NSFileManager возразите регистрирует сообщение к консоли, чтобы помочь диагностировать ошибку.

Перечисление 4-3 иллюстрирует, как определить, включен ли iCloud для файла документа URL, представив сообщение об ошибке пользователю в противном случае и установив значение целевого URL документа к тому из его контейнера iCloud иначе (в подготовке к перемещению документа iCloud с помощью setUbiquitous:itemAtURL:destinationURL:error: метод).

Перечисление 4-3  , Определяющее, включен ли iCloud

NSURL *src = [self fileURL];

NSURL *dest = NULL;

NSURL *ubiquityContainerURL = [[[NSFileManager defaultManager]

                                 URLForUbiquityContainerIdentifier:nil]

                                 URLByAppendingPathComponent:@"Documents"];

    if (ubiquityContainerURL == nil) {

        NSDictionary *dict = [NSDictionary dictionaryWithObjectsAndKeys:

              NSLocalizedString(@"iCloud does not appear to be configured.", @""),

                              NSLocalizedFailureReasonErrorKey, nil];

        NSError *error = [NSError errorWithDomain:@"Application" code:404

                                         userInfo:dict];

        [self presentError:error modalForWindow:[self windowForSheet] delegate:nil

                             didPresentSelector:NULL contextInfo:NULL];

        return;

        }

        dest = [ubiquityContainerURL URLByAppendingPathComponent:

                                                          [src lastPathComponent]];

Поскольку сообщение указывает nil для контейнерного параметра идентификатора, URLForUbiquityContainerIdentifier: возвращает первый контейнер, перечисленный в com.apple.developer.ubiquity-container-identifiers право и создает соответствующий каталог, если это еще не существует. Также Вы могли указать контейнерный идентификатор своего приложения — связь команды ID и комплект приложений ID, разделенный периодом для основного контейнерного идентификатора приложения или различного контейнерного каталога. Например, Вы могли объявить строковую константу для контейнерного идентификатора, как в следующем примере, и передать постоянное имя с сообщением.

static NSString *UbiquityContainerIdentifier = @"A1B2C3D4E5.com.domainname.appname";

Метод также добавляет имя файла документа к целевому URL.

Поиск Документов в iCloud

Приложения должны использовать NSMetadataQuery объекты искать элементы в каталогах контейнера iCloud. Метаданные запрашивают результаты возврата только, когда хранение iCloud включено, и соответствующие контейнерные каталоги были созданы. Для получения информации о том, как создать и сконфигурировать поисковые запросы метаданных, видит Руководство по программированию Поиска Метаданных Файла. Для получения информации о том, как выполнить итерации использования каталогов NSFileManager, см. Руководство по программированию Файловой системы.

Перемещение Документа в Хранение iCloud

Для сохранения нового документа к каталогу контейнера iCloud сначала сохраните его локально и затем вызовите NSFileManager метод setUbiquitous:itemAtURL:destinationURL:error: перемещать файл документа в iCloud.

Перечисление 4-4 показывает реализацию в качестве примера метода, перемещающего файл в хранение iCloud. Это принимает источник и целевой URLs от Перечисления 4-3.

Перечисление 4-4  , Перемещающее документ iCloud

dispatch_queue_t globalQueue =

        dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);

dispatch_async(globalQueue, ^(void) {

    NSFileManager *fileManager = [[NSFileManager alloc] init];

    NSError *error = nil;

    // Move the file.

    BOOL success = [fileManager setUbiquitous:YES itemAtURL:src

                               destinationURL:dest error:&error];

    dispatch_async(dispatch_get_main_queue(), ^(void) {

        if (! success) {

            [self presentError:error modalForWindow:[self windowForSheet]

                  delegate:nil didPresentSelector:NULL contextInfo:NULL];

        }

    });

});

[self setFileURL:dest];

[self setFileModificationDate:nil];

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

Удаление Документа от Хранения iCloud

Для перемещения файла документа из каталога контейнера iCloud выполните ту же процедуру, описанную в Перемещении Документа в Хранение iCloud, кроме переключателя источник URL (теперь файл документа в каталоге контейнера iCloud) и целевой URL (расположение файла документа в локальной файловой системе). Кроме того, первый параметр setUbiquitous:itemAtURL:destinationURL:error: метод должен теперь быть NO.

Для ясности в этом примере называют URL файла в хранении iCloud cloudsrc и локальный URL, в который перемещен файл, называют localdest.

dispatch_queue_t globalQueue =

        dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);

dispatch_async(globalQueue, ^(void) {

    NSFileManager *fileManager = [[NSFileManager alloc] init];

    NSError *error = nil;

    // Move the file.

    BOOL success = [fileManager setUbiquitous:NO itemAtURL:cloudsrc

                               destinationURL:localdest error:&error];

    dispatch_async(dispatch_get_main_queue(), ^(void) {

        if (! success) {

            [self presentError:error modalForWindow:[self windowForSheet]

                  delegate:nil didPresentSelector:NULL contextInfo:NULL];

        }

    });

});

Для получения дополнительной информации о iCloud, см. Руководство по проектированию iCloud.

NSDocument обрабатывает разрешение конфликтов среди версий документа

NSDocument разрешение конфликтов дескрипторов автоматически, таким образом, Вы не должны реализовывать его сами. В то время как документ открыт, если входит конфликт NSDocument представляет лист, прося, чтобы пользователь разрешил конфликт (или проигнорировать, который отмечает его, как разрешено и принимает автоматического победителя конфликта, обычно тот с новой датой модификации). Щелчок по Resolve вызывает пользовательский интерфейс Версий (см., что Пользователи Могут Просмотреть Версии документа) с только конфликтными видимыми версиями. Пользователь может выбрать определенную версию и нажать Restore, чтобы сделать его победителем конфликта, или просто выбрать Done для принятия автоматического победителя.

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

Создание контроллера окна

NSDocument подклассы должны создать свои контроллеры окна. Они могут сделать это косвенно или непосредственно. Если документ имеет только один файл пера с одним окном в нем, подкласс может переопределить windowNibName возвратить имя файла пера окна. Как следствие архитектура документа создает значение по умолчанию NSWindowController экземпляр для документа, с документом как владелец файла пера. Если документ имеет многократные окна, или если экземпляр пользовательского NSWindowController подкласс используется, NSDocument подкласс должен переопределить makeWindowControllers создать эти объекты.

Если Ваш документ имеет только одно окно, шаблон проекта обеспечивает реализацию по умолчанию NSDocument метод windowNibName:

- (NSString *)windowNibName {

    return @"MyDocument";

}

Если у Вас есть пользовательский подкласс, если Ваш документ имеет больше чем одно окно, или NSWindowController, переопределение makeWindowControllers вместо этого. Удостоверьтесь, что Вы добавляете каждый создаваемый контроллер окна к списку таких объектов, которыми управляет использование документа addWindowController:.

Загрузка файла пера окна

Можно реализовать windowControllerWillLoadNib: и windowControllerDidLoadNib: выполнять любые необходимые задачи имело отношение к окну прежде и после того, как оно загружается из файла пера. Например, Вы, возможно, должны выполнить операции установки на объектах пользовательского интерфейса, таких как установка содержания представления, после того, как были загружены данные модели приложения. В этом случае необходимо помнить что NSDocument методы считывания данных, такой как readFromData:ofType:error:, вызываются, прежде чем объекты пользовательского интерфейса документа, содержавшиеся в его файле пера, загружаются. Конечно, Вы не можете отправить сообщения в объекты пользовательского интерфейса до окончания загрузок файла пера. Так, можно выполнить в таких операциях windowControllerDidLoadNib:.

Вот пример:

- (void)windowControllerDidLoadNib:(NSWindowController *)windowController {

    [super windowControllerDidLoadNib:windowController];

    [textView setAllowsUndo:YES];

    if (fileContents != nil) {

        [textView setString:fileContents];

        fileContents = nil;

    }

}

Печать и макет страницы

Основанное на документе приложение может изменить информацию, которую оно использует, чтобы определить, как распечатаны данные документа. Эта информация инкапсулируется в NSPrintInfo объект. Если Вы хотите, чтобы пользователи были в состоянии распечатать документ, необходимо переопределить printOperationWithSettings:error:, возможно обеспечение измененного NSPrintInfo объект.

Изменение диалогового представления аксессуара сохранения

По умолчанию, когда NSDocument выполняет диалоговое окно Сохранения, и документ имеет многократные перезаписываемые типы документов, это вставляет вспомогательное представление около нижней части диалогового окна. Это представление содержит всплывающее меню перезаписываемых типов. Если Вы не хотите это всплывающее меню, переопределение shouldRunSavePanelWithAccessoryView возвратиться NO. Можно также переопределить prepareSavePanel: сделать дальнейшую настройку диалогового окна Сохранения.

Проверка пунктов меню

NSDocument реализации validateUserInterfaceItem: управлять включенным состоянием пунктов меню Revert Document и Save. Если Вы хотите проверить другие пункты меню, Вы можете переопределить этот метод, но, несомненно, вызовете реализацию суперкласса. Для получения дополнительной информации о проверке пункта меню посмотрите Меню приложения и Раскрывающийся Список, Программируя Темы.