iOS. Приемы программирования - Вандад Нахавандипур

2. Загрузить с диска тот уровень, на котором пользователь прервал игру.

3. Возобновить работу игрового движка.

А теперь предположим, что делегат нашего приложения — это игровой движок. Определим в заголовочном файле делегата приложения несколько методов:

#import <UIKit/UIKit.h>

@interface AppDelegate: UIResponder <UIApplicationDelegate>

@property (nonatomic, strong) UIWindow *window;

/* Сохраняем состояние нашего приложения. */

— (void) saveUserScore;

— (void) saveLevelToDisk;

— (void) pauseGameEngine;

/* Загружаем состояние нашего приложения. */

— (void) loadUserScore;

— (void) loadLevelFromDisk;

— (void) resumeGameEngine;

@end

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

#import «AppDelegate.h»

@implementation AppDelegate

— (void) saveUserScore{

/* Здесь сохраняем очки, заработанные пользователем. */

}

— (void) saveLevelToDisk{

/* Сохраняем на диске текущий уровень и положение игрока

на карте этого уровня. */

}

— (void) pauseGameEngine{

/* Здесь приостанавливаем работу игрового движка. */

}

— (void) loadUserScore{

/* Загружаем обратно в память местонахождение игрока. */

}

— (void) loadLevelFromDisk{

/* Загружаем последнее местонахождение игрока на карте. */

}

— (void) resumeGameEngine{

/* Здесь возобновляем работу игрового движка. */

}

<# Остаток вашего кода находится здесь #>

Теперь нужно удостовериться, что наше приложение способно обрабатывать прерывания, в частности входящие звонки, поступающие на iPhone. В таких случаях приложение не будет переходить в фоновый режим, но тем не менее станет неактивным. Если, например, пользователь закончит телефонный разговор, то iOS вернет наше приложение в активное состояние. Итак, когда приложение становится неактивным, нужно убедиться, что приостановлена работа игрового движка. Когда приложение снова активизируется, работу игрового движка можно возобновить. На самом деле, когда приложение становится неактивным, перед нами не стоит необходимость сохранять все на диске (как минимум в этом примере), так как iOS вернет приложение в предыдущее состояние лишь после того, как приложение вновь станет активным:

— (void)applicationWillResignActive:(UIApplication *)application{

[self pauseGameEngine];

}

— (void)applicationDidBecomeActive:(UIApplication *)application{

[self resumeGameEngine];

}

Теперь все просто. Как только наше приложение уйдет в фоновый режим, мы сохраним состояние этой программы, а когда она вернется в приоритетный режим — вновь загрузим это состояние:

— (void)applicationDidEnterBackground:(UIApplication *)application{

[self saveUserScore];

[self saveLevelToDisk];

[self pauseGameEngine];

}

— (void)applicationWillEnterForeground:(UIApplication *)application{

[self loadUserScore];

[self loadLevelFromDisk];

[self resumeGameEngine];

}

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

См. также

Раздел 14.2.

14.7. Управление сетевыми соединениями в фоновом режиме

Постановка задачи

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

Решение

Следует обеспечить обработку ошибок соединения в блоковых объектах, передаваемых вашим объектам соединений.

Обсуждение

При работе с приложениями, которые используют класс NSURLConnection, но, уходя в фоновый режим, не запрашивают у iOS дополнительного времени, обращаться с соединениями не составляет никакого труда. Рассмотрим на примере, как будет действовать асинхронное соединение, если приложение сначала уходит в фоновый режим, а потом возвращается в приоритетный. Итак, сделаем запрос на асинхронное соединение, чтобы получить контент, расположенный по определенному URL (например, на домашней странице Apple):

— (BOOL) application:(UIApplication *)application

didFinishLaunchingWithOptions:(NSDictionary *)launchOptions{

NSString *urlAsString = @"http://www.apple.com";

NSURL *url = [NSURL URLWithString: urlAsString];

NSURLRequest *urlRequest = [NSURLRequest requestWithURL: url];

NSOperationQueue *queue = [[NSOperationQueue alloc] init];

[NSURLConnection

sendAsynchronousRequest: urlRequest

queue: queue

completionHandler: ^(NSURLResponse *response, NSData *data, NSError

*error) {

if ([data length] > 0 &&

error!= nil){

/* Данные вернулись. */

}

else if ([data length] == 0 &&

error!= nil){

/* Никаких данных от сервера не пришло. */

}

else if (error!= nil){

/* Произошла ошибка. Ее обязательно нужно правильно обработать. */

}

}];

self.window = [[UIWindow alloc] initWithFrame:

[[UIScreen mainScreen] bounds]];

self.window.backgroundColor = [UIColor whiteColor];

[self.window makeKeyAndVisible];

return YES;

}

В этом примере целесообразно заменить URL домашней страницы Apple другим интернет-адресом, по которому расположен какой-нибудь крупный файл. Причина заключается в том, что, пока ваше приложение будет скачивать большой файл, у вас будет больше времени поэкспериментировать с приложением — отправить его в фоновый режим, а потом вернуть в приоритетный. Если же у вас довольно быстрое соединение с Интернетом, а вы загружаете всего одну страницу Apple, то вполне вероятно, что на это уйдет всего 1–2 секунды.

Будучи в приоритетном режиме, наше приложение продолжит загрузку файла. В ходе загрузки пользователь может нажать кнопку Home (Домой) и отправить приложение в фоновый режим. И тогда вы увидите настоящее волшебство! iOS автоматически приостановит процесс загрузки без всякого вашего вмешательства. Когда же пользователь вновь переведет программу в приоритетный режим, загрузка возобновится и вам не придется писать ни единой строки кода для обработки многозадачности в такой ситуации.

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

— (BOOL) application:(UIApplication *)application

didFinishLaunchingWithOptions:(NSDictionary *)launchOptions{

/* Заменяем этот URL ссылкой на крупный файл. */

NSString *urlAsString = @"http://www.apple.com";

NSURL *url = [NSURL URLWithString: urlAsString];

NSURLRequest *urlRequest = [NSURLRequest requestWithURL: url];

NSError *error = nil;

NSData *connectionData =

[NSURLConnection sendSynchronousRequest: urlRequest

returningResponse: nil

error:&error];

if ([connectionData length] > 0 &&

error == nil){

}

else if ([connectionData length] == 0 &&

error == nil){

}

else if (error!= nil){

}

self.window = [[UIWindow alloc] initWithFrame:

[[UIScreen mainScreen] bounds]];

self.window.backgroundColor = [UIColor whiteColor];

[self.window makeKeyAndVisible];

return YES;

}

Если вы запустите это приложение и переведете его в фоновый режим, то заметите, что на задний план отходит только графический пользовательский интерфейс, но вот ядро приложения никуда из приоритетного режима не уходит и нужные сообщения делегата — applicationWillResignActive: и applicationDidEnterBackground: — так и не будут получены. Я проводил такой опыт на iPhone.

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

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