iOS. Приемы программирования Нахавандипур Вандад
}
Следующий метод, с которым необходимо разобраться, называется parser: didEndElement: namespaceURI: qualifiedName:. Он вызывается, когда парсер доходит до конца элемента. Здесь нам нужно просто вернуть указатель XML-элементов на уровень выше, к тому элементу, который является родительским для только что проанализированного. Все довольно просто:
— (void) parser:(NSXMLParser *)parser
didEndElement:(NSString *)elementName
namespaceURI:(NSString *)namespaceURI
qualifiedName:(NSString *)qName{
self.currentElementPointer = self.currentElementPointer.parent;
}
И последний, но немаловажный момент. Нужно также обработать метод parserDidEndDocument: и избавиться от текущего свойства currentElementPointer:
— (void)parserDidEndDocument:(NSXMLParser *)parser{
self.currentElementPointer = nil;
}
Вот и все. Теперь можете выполнить синтаксический разбор нашего документа:
— (BOOL) application:(UIApplication *)application
didFinishLaunchingWithOptions:(NSDictionary *)launchOptions{
NSString *xmlFilePath = [[NSBundle mainBundle] pathForResource:@"MyXML"
ofType:@"xml"];
NSData *xml = [[NSData alloc] initWithContentsOfFile: xmlFilePath];
self.xmlParser = [[NSXMLParser alloc] initWithData: xml];
self.xmlParser.delegate = self;
if ([self.xmlParser parse]){
NSLog(@"The XML is parsed.");
/* self.rootElement сейчас является корневым элементом XML-документа. */
} else{
NSLog(@"Failed to parse the XML");
}
self.window = [[UIWindow alloc] initWithFrame:
[[UIScreen mainScreen] bounds]];
self.window.backgroundColor = [UIColor whiteColor];
[self.window makeKeyAndVisible];
return YES;
}
Теперь можно использовать свойство rootElement для обхода всей структуры нашего XML-документа.
Глава 12. Управление файлами и каталогами
12.0. Введение
Операционная система iOS основана на MacOS X, которая, в свою очередь, построена на базе операционной системы Unix. В iOS полная структура каталогов остается невидимой для приложения, поскольку каждое приложение, написанное iOS-разработчиком, существует в собственной песочнице. Эта защищенная среда не случайно называется песочницей: она действительно представляет собой жестко ограниченную область, и содержимое каталога песочницы доступно лишь тому приложению, которое владеет ею. У каждого приложения есть собственный каталог-песочница, по умолчанию у таких песочниц есть подкаталоги, к которым могут обращаться приложения.
Когда приложение для iOS устанавливается на устройстве, система создает для этого приложения структуру каталогов (рис. 12.1).
Рис. 12.1. Структура файловой системы в iOS
• Name.app — несмотря на странное название с расширением. app, это каталог. Все содержимое вашего основного пакета оказывается здесь. Например, все пиктограммы приложения, двоичный файл приложения, различные брендинговые изображения, шрифты, звуки и пр. автоматически отправятся в этот каталог, когда система iOS будет устанавливать приложение на устройстве. Name — это имя продукта, которое вы задали для приложения. Итак, если вы назвали приложение MyApp, то его каталог. app будет называться MyApp.app.
• Documents/ — этот каталог является местом назначения для всего контента, создаваемого пользователем. Содержимое, которое заполняется, скачивается или создается вашим приложением, не должно храниться в этом каталоге.
• Library/ — этот каталог используется для хранения кэшированных файлов, пользовательских настроек и т. д. Как правило, он не содержит никаких файлов, а только подкаталоги, в которых уже находятся другие файлы.
В корневом каталоге каждого приложения содержатся различные другие каталоги, о которых я расскажу далее.
• Library/Caches/ — в этом каталоге хранится информация, которую ваше приложение позже сможет воссоздать, если возникнет такая необходимость. iOS не выполняет резервного копирования этого каталога. Кроме того, iOS может удалить его содержимое, если дисковое пространство заканчивается, а ваше приложение в данный момент не работает! Поэтому работа приложения не должна слишком зависеть от этого каталога — будьте готовы к тому, что его содержимое потребуется создавать заново. Повторю: iOS не выполняет резервного копирования информации из этого каталога, так что, когда работа вашего приложения приостановлена, данная информация вполне может быть удалена.
Если работа приложения напрямую зависит от файлов и каталогов, которые должны создаваться на диске, то этот каталог не лучшее место для хранения информации. Такую важную информацию лучше хранить в папке /tmp.
• Library/Preferences/ — как понятно из названия, в этом приложении хранятся настройки, которые приложение должно запоминать и активизировать от запуска к запуску. Мы подробнее поговорим об этом в дальнейшем. iOS выполняет резервное копирование информации из этого каталога.
• Library/Application Support/ — данные, создаваемые вашим приложением (за исключением тех данных, которые создает сам пользователь), должны храниться в этом каталоге. Приятно отметить, что iOS выполняет резервное копирование данного каталога. Возможно, этот каталог не будет создаваться автоматически и вам придется создавать его самостоятельно, если его не существует. О создании этого каталога мы поговорим позже в данной главе.
• tmp/ — это временные файлы, которые ваше приложение может скачивать, создавать и т. д. iOS не выполняет резервного копирования данного каталога. Например, вы можете скачать из Интернета несколько фотографий и сохранить их в каталоге, чтобы повысить производительность вашего приложения, ведь в таком случае эти фотографии не придется скачивать заново при каждом запуске приложения. Каталог служит именно для этой цели. Убедитесь, что в нем не будут храниться документы или файлы, создаваемые пользователем.
Итак, теперь вы знаете, какие каталоги автоматически создаются операционной системой при установке приложения на устройстве с iOS. Далее найдем пути к остальным полезным каталогам, которые мы здесь уже упоминали. Воспользуемся теми API, которые Apple предоставляет специально для этих целей (о таких API пойдет речь в дальнейшем в этой главе).
12.1. Определение пути к самым полезным каталогам на диске
Постановка задачи
Требуется определить путь к некоторым наиболее полезным каталогам, доступ к которым есть у вашего приложения (например, к каталогам, рассмотренным во введении). Мы должны знать эти пути, чтобы иметь возможность обращаться к каталогам или создавать в них новое содержимое.
Программистам требуется использовать API, предоставляемые в iOS SDK, для нахождения путей к каталогам и/или файлам. Иными словами, путь к файлу или каталогу никогда не следует угадывать. Если, например, вы ищете пути, один из которых ведет к каталогу Documents (Документы), то нужно гарантировать, что для этого применяются правильные API. Никогда, ни в коем случае не рассчитывайте на то, что этот каталог будет называться в пакете вашего приложения именно Documents и никак иначе. Для нахождения пути к этому каталогу достаточно воспользоваться подходящими API. Если вас интересует не сам каталог, а отдельные содержащиеся в нем файлы, добавьте к концу обнаруженного пути имена тех или иных файлов.
Решение
Используйте метод экземпляра URLsForDirectory: inDomains:, относящийся к классу NSFileManager.
Обсуждение
Класс NSFileManager обеспечивает множество операций, связанных с файлами и каталогами, выполняемых в iOS. Все такие операции осуществляются прямо внутри ваших приложений, от вас требуется всего лишь создать экземпляр этого класса. Не рекомендую пользоваться разделяемым файловым менеджером, который предоставляется этим классом с помощью метода класса defaultManager, поскольку этот менеджер не является потокобезопасным. Лучше самостоятельно создать экземпляр класса NSFileManager и управлять им.
Метод экземпляра URLsForDirectory: inDomains:, относящийся к классу NSFileManager, позволяет искать конкретные каталоги в файловой системе iOS, в основном в песочнице вашего приложения. Этот метод имеет два параметра:
• URLsForDirectory: — это каталог, который вы хотите найти. Передайте этому параметру значение типа NSSearchPathDirectory (оно является перечислением). Далее поговорим о нем подробнее;
• inDomains — параметр указывает, где вы собираетесь искать конкретный каталог. Значение этого параметра должно относиться к типу NSSearchPathDomainMask (это тоже перечисление).
Предположим, вы хотите найти путь к каталогу Documents (Документы) вашего приложения. Вот как просто это делается:
NSFileManager *fileManager = [[NSFileManager alloc] init];
NSArray *urls = [fileManager URLsForDirectory: NSDocumentDirectory
inDomains: NSUserDomainMask];
if ([urls count] > 0){
NSURL *documentsFolder = urls[0];
NSLog(@"%@", documentsFolder);
} else {
NSLog(@"Could not find the Documents folder.");
}
Как видите, создав собственный экземпляр NSFileManager, мы передали значение NSDocumentDirectory в качестве искомого каталога и NSUserDomainMask — в качестве области поиска. Рассмотрим некоторые наиболее важные значения, которые можно передать каждому из параметров метода экземпляра URLsForDirectory: inDomains:, относящегося к классу NSFileManager:
• URLsForDirectory;
• NSLibraryDirectory — библиотечный каталог приложения;
• NSCachesDirectory — каталог кэша — о нем рассказано ранее;
• NSDocumentDirectory — каталог документов;
• inDomains;
• NSUserDomainMask.
Данное значение указывает, что поиск должен выполняться в актуальном пользовательском каталоге. В системе OS X этот каталог обозначался бы ~/.
С помощью этого метода мы можем найти и другие каталоги, например caches, как показано далее:
NSFileManager *fileManager = [[NSFileManager alloc] init];
NSArray *urls = [fileManager URLsForDirectory: NSCachesDirectory
inDomains: NSUserDomainMask];
if ([urls count] > 0){
NSURL *cachesFolder = urls[0];
NSLog(@"%@", cachesFolder);
} else {
NSLog(@"Could not find the Caches folder.");
}
Если вы хотите найти каталог tmp, воспользуйтесь функцией NSTemporaryDirectory() на языке C, вот так:
NSString *tempDirectory = NSTemporaryDirectory();
NSLog(@"Temp Directory = %@", tempDirectory);
Выполнив эту команду на устройстве, получим примерно следующий вывод:
Temp Directory = /private/var/mobile/
Applications/<# Здесь находится ID вашего приложения #>/tmp/
См. также
Раздел 12.0.
12.2. Запись информации в файлы и считывание информации из файлов
Постановка задачи
Требуется сохранить на диске информацию (например, текст, данные, изображения и т. д.).
Решение
Все классы Cocoa, обеспечивающие сохранение информации, например NSString, UIImage и NSData, предоставляют методы экземпляра, позволяющие сохранять данные на диске по заданному пути.
Обсуждение
Чтобы сохранять текст на диске (предполагается, что ваш текст сохранен в экземпляре NSString или неизменяемой версии этого класса), можно воспользоваться методом экземпляра writeToFile: atomically: encoding: error:, относящимся к этому классу. Этот метод применяется со строками, представляющими собой пути назначения. Вот его отдельные параметры.
• writeToFile — путь к файлу, в который нужно записать информацию, указывается в виде строки.
• atomically — логическое значение. Если оно установлено в YES, то файл сначала будет записываться во временное пространство, а потом перемещаться на тот адрес, где вы хотите его расположить. Так гарантируется, что содержимое файла, которое требуется сохранить, сначала будет просто перенесено на диск, а уже затем пересохранено в месте назначения. Поэтому, если вдруг отказ системы iOS произойдет прежде, чем файл будет сохранен в месте назначения, контент будет доступен и позднее, когда операционная система возобновит работу. И вы сможете сохранить информацию куда следует. При сохранении информации рекомендуется устанавливать данное значение в YES, чтобы ни при каких обстоятельствах не терять информацию работающего приложения безвозвратно.
• encoding — кодировка текста, который вы хотите сохранить по указанному адресу. Обычно в данном случае используется кодировка UTF-8, задаваемая с помощью константы NSUTF8StringEncoding.
• error — принимает указатель на объект NSError. Поэтому если операция сохранения завершится ошибкой и будет прервана, то вы сможете выяснить, какая именно ошибка произошла. Этому параметру можно передать значение nil, если вас не интересуют ошибки, которые могут возникнуть в процессе сохранения. Не забывайте, что эта функция возвращает логическое значение и вы можете воспользоваться им, чтобы просто определить, произошла какая-либо ошибка или нет.
Например, если у вас есть некий текст, который вы хотите сохранить в приложении, но резервно копировать его на уровне системы iOS не требуется, то можно поступить так:
NSString *someText = @"Random string that won't be backed up.";
NSString *destinationPath =
[NSTemporaryDirectory()
stringByAppendingPathComponent:@"MyFile.txt"];
NSError *error = nil;
BOOL succeeded = [someText writeToFile: destinationPath
atomically: YES
encoding: NSUTF8StringEncoding
error:&error];
if (succeeded) {
NSLog(@"Successfully stored the file at: %@", destinationPath);
} else {
NSLog(@"Failed to store the file. Error = %@", error);
}
Кроме того, когда сделаете все это, можете дополнительно убедиться, что вся работа выполнена верно. Попытайтесь считать ту же строку из файла назначения в память. Для этого используется метод класса stringWithContentsOfFile: encoding: error:, относящийся к классу NSString. В ответ вы должны получить автоматически высвобожденную строку, которая представляет собой содержимое указанного файла. Если вы хотите явно инстанцировать объект типа NSString с содержимым файла, просто примените метод экземпляра initWithContentsOfFile: encoding: error:, относящийся к классу NSString, вот так:
— (BOOL) writeText:(NSString *)paramText toPath:(NSString *)paramPath{
return [paramText writeToFile: paramPath
atomically: YES
encoding: NSUTF8StringEncoding
error: nil];
}
— (NSString *) readTextFromPath:(NSString *)paramPath{
return [[NSString alloc] initWithContentsOfFile: paramPath
encoding: NSUTF8StringEncoding
error: nil];
}
— (BOOL) application:(UIApplication *)application
didFinishLaunchingWithOptions:(NSDictionary *)launchOptions{
NSString *filePath = [NSTemporaryDirectory()
stringByAppendingPathComponent:@"MyFile.txt"];
if ([self writeText:@"Hello, World!" toPath: filePath]){
NSString *readText = [self readTextFromPath: filePath];
if ([readText length] > 0){
NSLog(@"Text read from disk = %@", readText);
} else {
NSLog(@"Failed to read the text from disk.");
}
} else {
NSLog(@"Failed to write the file.");
}
self.window = [[UIWindow alloc]
initWithFrame: [[UIScreen mainScreen] bounds]];
self.window.backgroundColor = [UIColor whiteColor];
[self.window makeKeyAndVisible];
return YES;
}
Здесь мы создали два удобных метода, позволяющих нам записывать текст и считывать его из указанного места. Затем используем эти методы в делегате нашего приложения, чтобы записать определенный текст в каталог temp, а потом считаем этот текст обратно в память и так убедимся, что методы работают нормально.
Если вы хотите работать с URL, инкапсулированными в экземпляры NSURL (или в экземпляры изменяемой версии этого класса), используйте в данном случае метод экземпляра writeToURL: atomically: encoding: error:.
Экземпляры NSURL могут указывать на ресурсы (файлы, каталоги и т. д.), расположенные в локальной системе или на удаленных устройствах. Так, экземпляр NSURL может представлять локальный файл в каталоге Documents (Документы) в вашем приложении, а другой NSURL — соответствовать URL сайта www.apple.com. Этот класс просто предоставляет вам функции, необходимые для доступа к URL и для работы с ними, независимо от типа конкретного URL.
Другие основополагающие классы обладают примерно такими же методами, как и NSString. Возьмем, к примеру, NSArray. Чтобы сохранить содержимое массива, пользуйтесь методом экземпляра writeToFile: atomically:, относящимся к классу NSArray. Чтобы считать с диска содержимое любого массива, можно просто выделить экземпляр массива, а потом инициализировать его с помощью initWithContentsOfFile: — это метод-инициализатор для работы с массивами. Вот примеры использования обоих методов:
NSString *filePath = [NSTemporaryDirectory()
stringByAppendingPathComponent:@"MyFile.txt"];
NSArray *arrayOfNames = @[@"Steve", @"John", @"Edward"];
if ([arrayOfNames writeToFile: filePath atomically: YES]){
NSArray *readArray = [[NSArray alloc] initWithContentsOfFile: filePath];
if ([readArray count] == [arrayOfNames count]){
NSLog(@"Read the array back from disk just fine.");
} else {
NSLog(@"Failed to read the array back from disk.");
}
} else {
NSLog(@"Failed to save the array to disk.");
}
Метод экземпляра writeToFile: atomically:, относящийся к классу NSArray, может сохранять лишь массивы, содержащие объекты следующих типов:
• NSString;
• NSDictionary;
• NSArray;
• NSData;
• NSNumber;
• NSDate.
Если вы попытаетесь вставить в массив какие-либо другие объекты, то ваши данные не будут сохранены на диске, поскольку этот метод первым делом проверяет, относятся ли все объекты в составе массива к одному из вышеупомянутых типов. Это делается по той простой причине, что в противном случае среда времени исполнения Objective-C просто не разберется, как сохранять данные на диске. Предположим, мы инстанцируем класс под названием Person, создаем для этого класса два свойства, одно из которых соответствует имени, другое — фамилии. Затем инстанцируем экземпляр этого класса и добавим его к массиву. Как же массив сможет сохранить эту информацию о персоне на диск? Никак, поскольку система не будет знать, что именно требуется сохранять. Эта проблема называется «маршалинг». В операционной системе iOS она решена только для перечисленных типов.
Словари также очень похожи на массивы. Сохранение их данных на диске и считывание информации из словаря происходит практически так же, как и в случае с массивами. Имена методов такие же, как и в предыдущем примере, правила сохранения словарей не отличаются от правил сохранения массивов. Вот пример:
NSString *filePath = [NSTemporaryDirectory()
stringByAppendingPathComponent:@"MyFile.txt"];
NSDictionary *dict = @{
@"first name": @"Steven",
@"middle name": @"Paul",
@"last name": @"Jobs",
};
if ([dict writeToFile: filePath atomically: YES]){
NSDictionary *readDictionary = [[NSDictionary alloc]
initWithContentsOfFile: filePath];
/* Теперь сравним словари и проверим, является ли словарь, считываемый
нами с диска, тем самым, который мы сохранили на диске */
if ([readDictionary isEqualToDictionary: dict]){
NSLog(@"The file we read is the same one as the one we saved.");
} else {
NSLog(@"Failed to read the dictionary from disk.");
}
} else {
NSLog(@"Failed to write the dictionary to disk.");
}
Как видите, в этом примере словарь записывается на диск, после чего считывается из этого самого места. После считывания мы сравниваем реальный словарь с тем, который сохранили на диске. Так мы должны убедиться, что оба словаря содержат одни и те же данные.