iOS. Приемы программирования

[[UIScreen mainScreen] bounds]];
self.window.backgroundColor = [UIColor whiteColor];
[self.window makeKeyAndVisible];
return YES;
}

Данный код создает экземпляр класса NSThread и немедленно запускает поток. Поток в каждом цикле проводит 4 секунды в спящем режиме, а потом переходит к выполнению своей задачи. Тем не менее, прежде чем поток будет запущен, мы вызываем метод stopThread, относящийся к (написанному нами) контроллеру вида; это делается с трехсекундной задержкой. Данный метод вызывает метод cancel, относящийся к потоку, пытаясь заставить поток выйти из своего цикла. Теперь запустим приложение и посмотрим, что выводится в окне консоли:

…
Thread Entry Point
Cancelling the Thread
Releasing the thread
Thread Loop
Thread Finished

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

— (void) threadEntryPoint{

@autoreleasepool {
NSLog(@"Thread Entry Point");
while ([[NSThread currentThread] isCancelled] == NO){
[NSThread sleepForTimeInterval:4];
if ([[NSThread currentThread] isCancelled] == NO){
NSLog(@"Thread Loop");
}
}
NSLog(@"Thread Finished");
}

}

— (void) stopThread{
NSLog(@"Cancelling the Thread");
[self.myThread cancel];
NSLog(@"Releasing the thread");
self.myThread = nil;

}

— (BOOL) application:(UIApplication *)application
didFinishLaunchingWithOptions:(NSDictionary *)launchOptions{

self.myThread = [[NSThread alloc]
initWithTarget: self
selector:@selector(threadEntryPoint)
object: nil];

[self performSelector:@selector(stopThread)
withObject: nil
afterDelay:3.0f];

[self.myThread start];

self.window = [[UIWindow alloc] initWithFrame:
[[UIScreen mainScreen] bounds]];
self.window.backgroundColor = [UIColor whiteColor];
[self.window makeKeyAndVisible];
return YES;
}

Глава 8. Безопасность

8.0. Введение

Безопасность — центральный элемент операционных систем iOS и OS X. Можно пользоваться функциями безопасности в iOS, чтобы без опасений хранить файлы на различных накопителях. Например, можно приказать iOS заблокировать и защитить на диске файлы с информацией из вашего приложения, если пользователь активизировал на устройстве защиту с применением пароля, а устройство перешло в режим блокировки. Если вы явно этого не затребуете, iOS не будет использовать с вашим приложением какого-либо защищенного хранилища данных. В таком случае ваши данные будут открыты для считывания любому процессу, имеющему доступ на считывание файловой системы вашего устройства. Существуют разнообразные приложения Mac, способные исследовать файловую систему устройства с iOS, не вызывая при этом джейлбрейка.

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

В Mac OS X Apple уже давно используется программа Keychain Access. Это инструмент, обеспечивающий пользователям iOS безопасное хранение данных на компьютере. Разработчики могут пользоваться программой Keychain Access, а также другими функциями обеспечения безопасности, выстроенными на базе общей архитектуры защиты данных (CDSA). Keychain Access может управлять различными связками ключей. Каждая связка ключей, в свою очередь, может содержать защищенные данные, например пароли. Если на машине с операционной системой OS X вы заходите под своим именем на сайт через браузер Safari, то вам будут предложены две возможности: приказать Safari запомнить ваш пароль либо отклонить этот запрос. Если вы прикажете Safari запомнить пароль, то браузер сохранит указанный пароль в заданной по умолчанию связке ключей.

Связки ключей в OS X и iOS различаются во многих отношениях. В OS X:

• у пользователя может быть много связок ключей, в iOS же действует всего одна глобальная связка ключей;

• пользователь может блокировать связку ключей. В iOS та связка ключей, которая используется по умолчанию, блокируется и разблокируется вместе с самим устройством;

• существует концепция стандартной связки ключей (default keychain), которая автоматически разблокируется операционной системой, когда пользователь входит в эту систему. Дело в том, что пароль стандартной связки ключей совпадает с паролем к пользовательской учетной записи. Как было указано ранее, в iOS есть всего одна связка ключей и она разблокируется iOS по умолчанию.

Чтобы помочь вам лучше понять природу связки ключей в OS X, прежде чем углубиться в изучение концепций iOS, связанных со связкой ключей и безопасностью, я хотел бы привести один пример. Откройте окно терминала на компьютере с Mac, введите следующую команду и нажмите Enter:

security list-keychains

В зависимости от настроек машины и имени пользователя вы получите примерно такой вывод:

«/Users/vandadnp/Library/Keychains/login.keychain»
«/Library/Keychains/System.keychain»

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

security default-keychain

В типичной установке OS X эта команда вернет примерно такой результат:

«/Users/vandadnp/Library/Keychains/login.keychain»

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

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