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

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

 

Решение

Вызовите метод экземпляра isMultitaskingSupported, относящийся к классу UIDevice:

— (BOOL) isMultitaskingSupported{

BOOL result = NO;

if ([[UIDevice currentDevice]

respondsToSelector:@selector(isMultitaskingSupported)]){

result = [[UIDevice currentDevice] isMultitaskingSupported];

}

return result;

}

— (BOOL) application:(UIApplication *)application

didFinishLaunchingWithOptions:(NSDictionary *)launchOptions{

if ([self isMultitaskingSupported]){

NSLog(@"Multitasking is supported.");

} else {

NSLog(@"Multitasking is not supported.");

}

self.window = [[UIWindow alloc] initWithFrame:

[[UIScreen mainScreen] bounds]];

self.window.backgroundColor = [UIColor whiteColor];

[self.window makeKeyAndVisible];

return YES;

}

 

Обсуждение

В зависимости от того, на работу в какой версии iOS рассчитано ваше приложение, его можно запускать и выполнять на различных устройствах, где установлены разные версии iOS. Например, вы можете разрабатывать приложение в последней версии iOS SDK, но в качестве целевой (наиболее ранняя версия iOS, в которой сможет работать ваше приложение) задать более низкую версию. В этом случае приложение сможет работать на устройстве с более ранней версией операционной системы, но, возможно, это устройство не будет поддерживать многозадачность. Золотое правило, действующее как в программировании, так и в жизни вообще (не подумайте, что я берусь философствовать), таково: если вы пытаетесь гадать, то рано или поздно ошибетесь. Поэтому не пытайтесь угадать, на каких устройствах в данное время работает ваше приложение. Ведь если iOS-разработчик указывает в Xcode минимальную поддерживаемую версию iOS, он тем самым автоматически ограничивает свою пользовательскую аудиторию. Наша цель — добиться, чтобы обладатели любых устройств с iOS, существующих в настоящее время, могли пользоваться нашим приложением. Поэтому если вы хотите задействовать в приложении для iOS новейшие возможности многозадачности, обязательно проверяйте, доступна ли многозадачность на данном устройстве. Если многозадачность недоступна, необходимо гарантировать, что приложение корректно отреагирует на это, например выберет альтернативный режим выполнения.

 

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

Требуется «занять» немного времени у iOS и выполнить долгосрочную задачу, пока приложение находится в фоновом режиме.

 

Решение

Воспользуйтесь методом экземпляра beginBackgroundTaskWithExpirationHandler:, относящимся к классу UIApplication. После того как задача будет решена, вызовите метод экземпляра endBackgroundTask:, относящийся к классу UIApplication.

 

Обсуждение

Когда приложение переходит в фоновый режим, работа его основного потока приостанавливается. Потоки, которые вы создаете в своем приложении с помощью метода класса detachNewThreadSelector: toTarget: withObject:, относящегося к классу NSThread, также приостанавливаются. Если вы пытаетесь решить долгосрочную задачу за то время, пока приложение находится в фоновом режиме, необходимо вызвать метод экземпляра beginBackgroundTaskWithExpirationHandler:, относящийся к классу UIApplication, чтобы «занять» немного времени у системы iOS. Свойство backgroundTimeRemaining класса UIApplication содержит количество секунд, которые требуются приложению для завершения той или иной задачи. Если приложение не успеет завершить долгосрочную задачу до того, как истечет отведенный временной промежуток, iOS завершит приложение. За каждым вызовом метода beginBackgroundTaskWithExpirationHandler: должен следовать соответствующий вызов метода endBackgroundTask: (другой метод экземпляра UIApplication). Иными словами, если вы просите у iOS дополнительное время на завершение задачи, то должны и сообщить iOS, когда закончите эту задачу. Когда это будет сделано и окажется, что больше нет задач, которые следовало бы выполнить в фоновом режиме, ваше приложение перейдет в фоновый режим целиком и все его потоки будут приостановлены.

Когда приложение работает на переднем плане, свойство backgroundTimeRemaining класса UIApplication равно константе DBL_MAX, означающей максимальную величину, которая может содержаться в значении типа double (число с двойной точностью). В данном случае целочисленное значение, равное такому двойному вещественному числу, обычно составляет –1. После того как у iOS запрашивается дополнительное время перед полной приостановкой приложения, в этом свойстве указывается количество секунд, требуемое программе для завершения задачи (или всех текущих задач).

Можно вызывать в приложении метод beginBackgroundTaskWithExpirationHandler: столько раз, сколько потребуется. Но важно учитывать, что, когда iOS возвращает в этом методе вашей программе метку (токен) или идентификатор задачи, вы должны вызвать метод endBackgroundTask:, и сделать это сразу же, как программа закончит выполнять задачу. Если не сделать этого, операционная система iOS может завершить приложение.

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

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

Рассмотрим пример. Начнем с того, что определим в делегате приложения свойство типа UIBackgroundTaskIdentifier. Кроме того, определим таймер типа NSTimer, который будет использоваться при ежесекундном выводе сообщений на консоль, после того как приложение уйдет в фоновый режим:

#import «AppDelegate.h»

@interface AppDelegate ()

@property (nonatomic, unsafe_unretained)

UIBackgroundTaskIdentifier backgroundTaskIdentifier;

@property (nonatomic, strong) NSTimer *myTimer;

@end

@implementation AppDelegate

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

Теперь создадим таймер и назначим время перехода приложения в фоновый режим:

— (BOOL) isMultitaskingSupported{

BOOL result = NO;

if ([[UIDevice currentDevice]

respondsToSelector:@selector(isMultitaskingSupported)]){

result = [[UIDevice currentDevice] isMultitaskingSupported];

}

return result;

}

— (void) timerMethod:(NSTimer *)paramSender{

NSTimeInterval backgroundTimeRemaining =

[[UIApplication sharedApplication] backgroundTimeRemaining];

if (backgroundTimeRemaining == DBL_MAX){

NSLog(@"Background Time Remaining = Undetermined");

} else {

NSLog(@"Background Time Remaining = %.02f Seconds",

backgroundTimeRemaining);

}

}

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

if ([self isMultitaskingSupported] == NO){

return;

}

self.myTimer =

[NSTimer scheduledTimerWithTimeInterval:1.0f

target: self

selector:@selector(timerMethod:)

userInfo: nil

repeats: YES];

self.backgroundTaskIdentifier =

[application beginBackgroundTaskWithExpirationHandler: ^(void) {

[self endBackgroundTask];

}];

}

Как видите, в обработчике завершения (Completion Handler) фоновой задачи мы вызываем метод endBackgroundTask делегата приложения. Этот метод написали мы сами, и выглядит он так:

— (void) endBackgroundTask{

dispatch_queue_t mainQueue = dispatch_get_main_queue();

__weak AppDelegate *weakSelf = self;

dispatch_async(mainQueue, ^(void) {

AppDelegate

*strongSelf = weakSelf;

if (strongSelf!= nil){

[strongSelf.myTimer invalidate];

[[UIApplication sharedApplication]

endBackgroundTask: self.backgroundTaskIdentifier];

strongSelf.backgroundTaskIdentifier = UIBackgroundTaskInvalid;

}

});

}

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

• завершить все потоки и таймеры независимо от того, являются они таймерами из фреймворка Core Foundation или созданы с помощью GCD;

• завершить фоновую задачу, вызвав метод endBackgroundTask: класса UIApplication;

• пометить задачу как завершенную, присвоив значение UIBackgroundTaskInvalid идентификаторам задачи.

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

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

if (self.backgroundTaskIdentifier!= UIBackgroundTaskInvalid){

[self endBackgroundTask];

}

}

В нашем примере, как только приложение переходит в фоновый режим, мы запрашиваем дополнительное время на завершение долгосрочной задачи (в данном случае, например, для выполнения кода нашего таймера). В то время мы регулярно считываем значение свойства backgroundTimeRemaining экземпляра класса UIApplication и выводим найденное значение на консоль. В методе экземпляра beginBackgroundTaskWithExpirationHandler:, который относится к классу UIApplication, мы записали код, который будет выполнен прямо перед тем, как закончится дополнительное время, выделенное приложению на выполнение долгосрочной задачи. (Как правило, это происходит за 5–10 секунд до истечения времени, выделенного на выполнение задачи.) Здесь мы можем просто завершить задачу, вызвав метод экземпляра endBackgroundTask:, относящийся к классу UIApplication.

Если приложение перешло в фоновый режим и запросило у операционной системы дополнительное время на исполнение кода еще до того, как отведенное время истекло, пользователь может «оживить» приложение и вернуть его в приоритетный режим. Если до этого вы приказали исполнять долгосрочную задачу в фоновом режиме и как раз для этого приложение было переведено в фоновый режим, то нужно завершить долгосрочную задачу с помощью метода экземпляра endBackgroundTask:, относящегося к классу UIApplication.

 

См. также

Раздел 14.1.

 

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

Требуется, чтобы ваше приложение могло обновлять контент в фоновом режиме, пользуясь новыми возможностями, появившимися в последнем iOS SDK.

 

Решение

Добавьте в приложение возможность фонового обновления (background fetch).

 

Обсуждение

Многие приложения, ежедневно поступающие на рынок App Store, обладают возможностями соединения с теми или иными серверами. Некоторые выбирают с сервера данные для обновления, другие отсылают информацию на сервер и т. д. В течение долгого времени в iOS существовал лишь один способ обновлять контент в фоновом режиме. Требовалось «занять» у iOS некоторое количество времени (об этом мы говорили в разделе 14.2), и приложение могло потратить это время на завершение своей работы в фоновом режиме. Но такой способ работы является активным. Существует и пассивный способ решения аналогичных задач, когда приложение просто «сидит», а iOS сама выделяет приложению некоторое время на обработку данных в фоновом режиме. Итак, вам требуется просто подключить к приложению такую возможность и приказать системе iOS разбудить ваше приложение в относительно спокойный момент, когда будет удобно обработать данные в фоновом режиме. Обычно при этом происходит фоновое обновление информации.

Например, вам может потребоваться загрузить новый контент. Предположим, у нас есть приложение для работы с Twitter. Открывая это приложение, пользователь в первую очередь хочет просмотреть новые твиты. До недавнего времени это можно было реализовать лишь одним способом: открыть приложение, а потом потратить некоторое время на обновление списка твитов. Но теперь система iOS может активизировать твиттерное приложение в фоновом режиме и приказать ему обновить ленту сообщений. Таким образом, когда пользователь откроет это приложение, твиты на экране уже будут обновлены.

Чтобы задействовать в приложении возможность фонового обновления, нужно перейти на вкладку Capabilities (Возможности) в настройках вашего проекта, а в области Background Modes (Фоновые режимы) установить флажок Background fetch (Фоновое обновление) (рис. 14.1).

Рис. 14.1. Активизация фонового обновления в приложении

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

Для этого нужно вызвать метод экземпляра setMinimumBackgroundFetchInterval:, относящийся к классу UIApplication. В качестве параметра этому методу передаются временной интервал и частота, с которой iOS должна будить ваше приложение в фоновом режиме и приказывать ему получать новые данные для обновления. По умолчанию это свойство имеет значение UIApplicationBackgroundFetchIntervalNever. При таком значении iOS вообще не активизирует ваше приложение в фоновом режиме. Но значение этого свойства можно установить вручную, сообщив количество секунд, образующих интервал, либо просто передать значение UIApplicationBackgroundFetchIntervalMinimum, при котором iOS будет «прилагать минимальные усилия» — будить ваше приложение, но делать это очень редко.

— (BOOL) application:(UIApplication *)application

didFinishLaunchingWithOptions:(NSDictionary *)launchOptions{

[application setMinimumBackgroundFetchInterval:

UIApplicationBackgroundFetchIntervalMinimum];

return YES;

}

Сделав это, реализуйте метод экземпляра application: performFetchWithCompletionHandler, относящийся к делегату вашего приложения. Параметр performFetchWithCompletionHandler: этого метода дает нам блоковый объект, который нужно будет вызвать, как только приложение закончит обновлять данные. Вообще этот метод вызывается в делегате приложения, когда iOS приказывает приложению получить в фоновом режиме новый контент для обновления. Поэтому вам придется отреагировать на это и вызвать обработчик завершения, как только все будет готово. Блоковый объект, который вам потребуется вызвать, будет принимать значение типа UIBackgroundFetchResult:

typedef NS_ENUM(NSUInteger, UIBackgroundFetchResult) {

UIBackgroundFetchResultNewData,

UIBackgroundFetchResultNoData,

UIBackgroundFetchResultFailed

} NS_ENUM_AVAILABLE_IOS(7_0);

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

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

#import 

@interface NewsItem: NSObject

@property (nonatomic, strong) NSDate *date;

@property (nonatomic, copy) NSString *text;

@end

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

#import 

@interface AppDelegate: UIResponder 

@property (nonatomic, strong) UIWindow *window;

@property (nonatomic, strong) NSMutableArray *allNewsItems;

@end

Теперь выполним отложенное выделение массива. Это означает, что массив не будет выделяться и инициализироваться до тех пор, пока приложение прямо к нему не обратится. Так экономится память. Как только массив будет выделен, мы добавим к нему один новый элемент:

#import «AppDelegate.h»

#import «NewsItem.h»

@implementation AppDelegate

— (NSMutableArray *) allNewsItems{

if (_allNewsItems == nil){

_allNewsItems = [[NSMutableArray alloc] init];

/* Заранее записываем в массив один элемент */

NewsItem *item = [[NewsItem alloc] init];

item.date = [NSDate date];

item.text = [NSString stringWithFormat:@"News text 1"];

[_allNewsItems addObject: item];

}

return _allNewsItems;

}

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

Теперь реализуем в нашем приложении метод, который будет имитировать вызов сервера. Можно сказать, что здесь мы играем в орлянку. Точнее, метод случайным образом генерирует одно из двух чисел — 0 или 1. Получив 1, мы считаем, что на сервере есть новые новостные материалы для загрузки. Получив 0, считаем, что такая новая информация на сервере отсутствует. Если мы получили 1, то сразу после этого добавляем в список новый элемент:

— (void) fetchNewsItems:(BOOL *)paramFetchedNewItems{

if (arc4random_uniform(2)!= 1){

if (paramFetchedNewItems!= nil){

*paramFetchedNewItems = NO;

}

return;

}

[self willChangeValueForKey:@"allNewsItems"];

/* Генерируем новый элемент */

NewsItem *item = [[NewsItem alloc] init];

item.date = [NSDate date];

item.text = [NSString stringWithFormat:@"News text %lu",

(unsigned long)self.allNewsItems.count + 1];

[self.allNewsItems addObject: item];

if (paramFetchedNewItems!= nil){

*paramFetchedNewItems = YES;

}

[self didChangeValueForKey:@"allNewsItems"];

}

Логический параметр указателя этого метода сообщит нам, появилась ли новая информация, добавленная в массив.

Теперь реализуем механизм фонового обновления в делегате нашего приложения, так, как было объяснено ранее:

— (void) application:(UIApplication *)application

performFetchWithCompletionHandler:(void (^)(UIBackgroundFetchResult))

completionHandler{

BOOL haveNewContent = NO;

[self fetchNewsItems:&haveNewContent];

if (haveNewContent){

completionHandler(UIBackgroundFetchResultNewData);

} else {

completionHandler(UIBackgroundFetchResultNoData);

}

}

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

#import «TableViewController.h»

#import «AppDelegate.h»

#import «NewsItem.h»

@interface TableViewController ()

@property (nonatomic, weak) NSArray *allNewsItems;

@property (nonatomic, unsafe_unretained) BOOL mustReloadView;

@end

@implementation TableViewController

— (void)viewDidLoad{

[super viewDidLoad];

AppDelegate *appDelegate = [UIApplication sharedApplication].delegate;

self.allNewsItems = appDelegate.allNewsItems;

[appDelegate addObserver: self

forKeyPath:@"allNewsItems"

options: NSKeyValueObservingOptionNew

context: NULL];

[[NSNotificationCenter defaultCenter]

addObserver: self

selector:@selector(handleAppIsBroughtToForeground:)

name: UIApplicationWillEnterForegroundNotification

object: nil];

}

— (void) observeValueForKeyPath:(NSString *)keyPath

ofObject:(id)object

change:(NSDictionary *)change

context:(void *)context{

if ([keyPath isEqualToString:@"allNewsItems"]){

if ([self isBeingPresented]){

[self.tableView reloadData];

} else {

self.mustReloadView = YES;

}

}

}

— (void) handleAppIsBroughtToForeground:(NSNotification *)paramNotification{

if (self.mustReloadView){

self.mustReloadView = NO;

[self.tableView reloadData];

}

}

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

— (NSInteger)tableView:(UITableView *)tableView

numberOfRowsInSection:(NSInteger)section{

return self.allNewsItems.count;

}

— (UITableViewCell *)tableView:(UITableView *)tableView

cellForRowAtIndexPath:(NSIndexPath *)indexPath{

static NSString *CellIdentifier = @"Cell";

UITableViewCell *cell = [tableView

dequeueReusableCellWithIdentifier: CellIdentifier

forIndexPath: indexPath];

NewsItem *newsItem = self.allNewsItems[indexPath.row];

cell.textLabel.text = newsItem.text;

return cell;

}

— (void) dealloc{

AppDelegate *appDelegate = [UIApplication sharedApplication].delegate;

[appDelegate removeObserver: self forKeyPath:@"allNewsItems"];

[[NSNotificationCenter defaultCenter] removeObserver: self];

}

В данном примере кода мы извлекаем из очереди те ячейки табличного вида, которые имеют идентификатор Cell. Метод dequeueReusableCellWithIdentifier: forIndexPath: нашего табличного вида возвращает валидные ячейки, а не nil, потому что в файле раскадровки мы уже задали этот идентификатор для прототипа ячейки в табличном виде. Во время исполнения раскадровка регистрирует для iOS эту ячейку-прототип с заданным идентификатором. Поэтому мы можем извлекать ячейки из очереди, просто опираясь на данный идентификатор, и не регистрируем ячейки заранее.

Табличные виды подробно рассмотрены в главе 4.

Теперь запустите ваше приложение и нажмите кнопку Home (Главная), чтобы перевести ваше приложение в фоновый режим. Вернитесь в Xcode и в меню Debug (Отладка) выберите Simulate Background Fetch (Имитировать обновление в фоновом режиме) (рис. 14.2). Теперь вновь откройте приложение, не завершая его, и посмотрите, появится ли в табличном виде новый контент. Если не появится — то именно по той причине, что запрограммированная нами логика напоминает игру в орлянку. Приложение случайным образом «определяет», есть ли на «сервере» новый контент. Так имитируются вызовы сервера. Если не получите никакого «нового контента», просто повторите имитацию фонового обновления в меню Debug (Отладка), пока «информация» не будет «получена».

Рис. 14.2. Имитация фонового обновления в Xcode

До сих пор мы обрабатывали в системе iOS запросы на фоновое обновление, пока приложение находилось в фоновом режиме. Но что, если работа приложения полностью завершена и фонового режима в данный момент не существует? Как нам сымитировать описанную ситуацию и определить, сработает ли наша программа? Оказывается, Apple уже и об этом позаботилась. Выберите пункт Manage Schemes (Управление схемами) в меню Product (Продукт) в Xcode. Здесь скопируйте основную схему вашего приложения, нажав кнопку с плюсиком, а затем установив флажок Duplicate Scheme (Дублировать схему) (рис. 14.3).

Рис. 14.3. Дублирование схемы для обеспечения имитации фонового обновления в период, когда приложение не работает даже в фоновом режиме

Теперь перед вами откроется новое диалоговое окно, примерно такое, как на рис. 14.4. Здесь будет предложено установить различные свойства новой схемы. В этом диалоговом окне установите флажок Launch due to a background fetch event (Запуск, обусловленный событием фонового обновления данных), а потом нажмите ОК.

Рис. 14.4. Активизация схемы для запуска приложения с целью фонового обновления

Итак, теперь в Xcode записаны две схемы для приложения (рис. 14.5). Чтобы активизировать приложение с целью фонового обновления, вам просто понадобится выбрать только что созданную вторую схему и запустить приложение в симуляторе или на устройстве. В таком случае ваше приложение не перейдет в приоритетный режим. Вместо этого будет выдан сигнал для обновления данных в фоновом режиме, который, в свою очередь, вызовет метод application: performFetchWithCompletionHandler: делегата нашего приложения. Если вы правильно выполнили все шаги, описанные в этом разделе, то в обоих сценариях у вас будет полностью работоспособное приложение: и когда iOS вызывает программу из фонового режима, и когда приложение запускается с нуля, только для фонового обновления.

Рис. 14.5. Использование новой схемы для запуска вашего приложения и имитации фонового обновления данных

 

См. также

Раздел 14.2.

 

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

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

 

Решение

Выберите приложение в навигаторе (Navigator) в Xcode. Затем в разделе Capabilities (Возможности) перейдите в подраздел Background Modes (Фоновые режимы). После того как система выведет список фоновых режимов, нажмите переключатель Audio (Аудио).

Теперь можно использовать фреймворк AV Foundation для воспроизведения аудиофайлов. Аудиофайлы будут проигрываться, даже если приложение работает в фоновом режиме.

Учтите, что фоновое воспроизведение аудио может не сработать в симуляторе iOS. Этот раздел нужно тестировать на реальном устройстве. Вполне возможно, что на симуляторе воспроизведение аудио прекратится, как только приложение перейдет в фоновый режим.

 

Обсуждение

В iOS приложение может запросить продолжить воспроизведение своих аудиофайлов, даже если оно само переходит в фоновый режим. В этом разделе мы воспользуемся плеером AVAudioPlayer, который прост и удобен в обращении. Наша задача — запустить аудиоплеер и воспроизвести простой трек, а пока играет музыка — нажать кнопку Home (Домой) и перевести приложение в фоновый режим. Если мы внесем в файл. plist нашего приложения ключ UIBackgroundModes, iOS продолжит воспроизводить музыку из аудиоплеера приложения, действующего в фоновом режиме. Пока плеер работает в фоновом режиме, мы должны просто воспроизводить музыку и предоставлять плееру те данные, которые необходимы ему для работы. Нам не придется выполнять никаких иных задач, например отображать новые экраны.

Вот объявление простого делегата приложения, запускающего AVAudioPlayer:

#import «AppDelegate.h»

#import 

@interface AppDelegate () 

@property (nonatomic, strong) AVAudioPlayer *audioPlayer;

@end

@implementation AppDelegate

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

Когда приложение откроется, мы выделим и инициализируем аудиоплеер, считаем содержимое файла MySong.mp4 в экземпляр NSData и используем эти данные в процессе инициализации аудиоплеера:

— (BOOL) application:(UIApplication *)application

didFinishLaunchingWithOptions:(NSDictionary *)launchOptions{

dispatch_queue_t dispatchQueue =

dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);

dispatch_async(dispatchQueue, ^(void) {

NSError *audioSessionError = nil;

AVAudioSession *audioSession = [AVAudioSession sharedInstance];

if ([audioSession setCategory: AVAudioSessionCategoryPlayback

error:&audioSessionError]){

NSLog(@"Successfully set the audio session.");

} else {

NSLog(@"Could not set the audio session");

}

NSBundle *mainBundle = [NSBundle mainBundle];

NSString *filePath = [mainBundle pathForResource:@"MySong"

ofType:@"mp3"];

NSData *fileData = [NSData dataWithContentsOfFile: filePath];

NSError *error = nil;

/* Запускаем аудиоплеер. */

self.audioPlayer = [[AVAudioPlayer alloc] initWithData: fileData

error:&error];

/* Получили ли мы экземпляр AVAudioPlayer? */

if (self.audioPlayer!= nil){

/* Задаем делегат и начинаем воспроизведение. */

self.audioPlayer.delegate = self;

if ([self.audioPlayer prepareToPlay] &&

[self.audioPlayer play]){

NSLog(@"Successfully started playing…");

} else {

NSLog(@"Failed to play.");

}

} else {

/* Не удалось инстанцировать AVAudioPlayer. */

}

});

self.window = [[UIWindow alloc] initWithFrame:

[[UIScreen mainScreen] bounds]];

self.window.backgroundColor = [UIColor whiteColor];

[self.window makeKeyAndVisible];

return YES;

}

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

Вы, наверное, заметили, что в приведенном примере кода мы делаем делегат нашего приложения делегатом аудиоплеера. Мы реализуем методы делегата аудиоплеера вот так:

— (void)audioPlayerBeginInterruption:(AVAudioPlayer *)player{

/* Аудиосессия прервана.

Здесь мы ставим плеер на паузу */

}

— (void)audioPlayerEndInterruption:(AVAudioPlayer *)player

withOptions:(NSUInteger)flags{

/* Проверяем по флагам, можем ли мы возобновить воспроизведение аудио.

Если да, то делаем это здесь */

if (flags == AVAudioSessionInterruptionOptionShouldResume){

[player play];

}

}

— (void)audioPlayerDidFinishPlaying:(AVAudioPlayer *)player

successfully:(BOOL)flag{

NSLog(@"Finished playing the song");

/* Параметр flag сообщает, удалось ли успешно закончить воспроизведение */

if ([player isEqual: self.audioPlayer]){

self.audioPlayer = nil;

} else {

/* Это не наш аудиоплеер! */

}

}

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

 

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

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

 

Решение

Выберите приложение в навигаторе (Navigator) в Xcode. Затем в разделе Capabilities (Возможности) перейдите в подраздел Background Modes (Фоновые режимы). После того как система выведет список фоновых режимов, нажмите переключатель Location (Местоположение).

 

Обсуждение

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

Если для работы приложения вам необходима возможность получать информацию об изменении местоположения пользовательского устройства, даже если программа работает в фоновом режиме, то нужно добавить значение location к ключу UIBackgroundModes в основной файл. plist вашего приложения, как показано в подразделе «Решение» данного раздела. В таком случае, даже будучи в фоновом режиме, ваше приложение продолжит получать информацию об изменении местоположения устройства. Протестируем простое приложение, в котором у нас будет только делегат.

В этом приложении я собираюсь сохранить логическое значение в делегате приложения, которое будет называться executingInBackground. Когда приложение переходит в фоновый режим, задам этому делегату значение YES, а когда оно вернется в приоритетный режим — изменю данное значение на NO. Когда будут получены данные об изменении геолокационной информации от Core Location, мы проверим этот флаг. Если флаг установлен в YES, то мы не будем заниматься никакими энергоемкими вычислениями или любыми обновлениями пользовательского интерфейса, поскольку наше приложение сейчас работает в фоновом режиме. Мы, будучи ответственными программистами, не будем нагружать приложение никакими тяжелыми задачами. Но если программа действует в приоритетном режиме, то в нашем распоряжении вся вычислительная мощность устройства, которую мы можем бросить на обработку необходимых функций. Кроме того, попытаемся добиться максимальной точности при определении местоположения, если наша программа работает в приоритетном режиме. Когда же программа уходит в фоновый режим, эту точность можно смело снизить, чтобы уменьшить нагрузку на геолокационные сенсоры. Итак, определим делегат приложения:

#import 

#import 

@interface AppDelegate () 

@property (nonatomic, strong) UIWindow *window;

@property (nonatomic, strong) CLLocationManager *myLocationManager;

@property (nonatomic, unsafe_unretained, getter=isExecutingInBackground)

BOOL executingInBackground;

@end

@implementation AppDelegate

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

Продолжим. Создадим диспетчер местоположения и запустим его сразу после запуска приложения:

— (BOOL) application:(UIApplication *)application

didFinishLaunchingWithOptions:(NSDictionary *)launchOptions{

self.myLocationManager = [[CLLocationManager alloc] init];

self.myLocationManager.desiredAccuracy = kCLLocationAccuracyBest;

self.myLocationManager.delegate = self;

[self.myLocationManager startUpdatingLocation];

self.window = [[UIWindow alloc] initWithFrame:

[[UIScreen mainScreen] bounds]];

self.window.backgroundColor = [UIColor whiteColor];

[self.window makeKeyAndVisible];

return YES;

}

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

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

self.executingInBackground = YES;

/* Снижаем точность определения местоположения и нагрузку

на iOS, пока работаем в фоновом режиме. */

self.myLocationManager.desiredAccuracy = kCLLocationAccuracyHundredMeters;

}

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

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

self.executingInBackground = NO;

/* Теперь, когда приложение вернулось в приоритетный режим, повышаем

точность определения местоположения. */

self.myLocationManager.desiredAccuracy = kCLLocationAccuracyBest;

}

Кроме того, целесообразно было бы избежать любой интенсивной обработки в такой ситуации: приложение находится в фоновом режиме, и тут диспетчер местоположения получает обновление. Поэтому необходимо обработать метод locationManager: didUpdateToLocation: fromLocation: делегата нашего приложения следующим образом:

— (void)locationManager:(CLLocationManager *)manager

didUpdateToLocation:(CLLocation *)newLocation

fromLocation:(CLLocation *)oldLocation{

if ([self isExecutingInBackground]){

/* Работаем в фоновом режиме.

Не выполняем никакой сложной обработки. */

} else {

/* Работаем в приоритетном режиме. Запускаем любые вычисления,

какие требуются */

}

}

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

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

 

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

Необходимо, чтобы при отправке приложения для iOS в фоновый режим его состояние сохранялось и восстанавливалось, как только приложение вернется в приоритетный режим.

 

Решение

Комбинируйте сообщения протокола UIApplicationDelegate, отправляемые делегату вашего приложения, и уведомления, которые посылает система iOS. Так вы сможете сохранять состояние приложений.

 

Обсуждение

Допустим, пустое приложение iOS (то есть приложение всего с одним окном, для которого еще не написан код) впервые запускается на устройстве с iOS, поддерживающем работу в многозадачном режиме. Оно запускается именно впервые, а не возвращается из фонового режима в приоритетный. В таком случае делегат приложения UIApplicationDelegate будет получать следующие сообщения именно в таком порядке.

1. application: didFinishLaunchingWithOptions:.

2. applicationDidBecomeActive:.

Если пользователь нажимает кнопку Home (Домой) на своем устройстве с iOS, то делегат приложения получит следующие сообщения в таком порядке.

1. applicationWillResignActive:.

2. applicationDidEnterBackground:.

Когда приложение находится в фоновом режиме, пользователь может дважды нажать кнопку Home (Домой) и выбрать нашу программу из списка фоновых приложений. (При этом не так уж важно, каким именно образом программа оказалась в фоновом режиме. Насколько мне известно, другое приложение может запустить наше посредством различных URI-схем, которые мы можем предоставить в нашей программе.) Как только программа вернется в приоритетный режим, делегат приложения получит следующие сообщения в таком порядке.

1. applicationWillEnterForeground:.

2. applicationDidBecomeActive:.

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

Чтобы можно было сохранять и вновь загружать состояние наших приложений, нужно тщательно взвешивать, выполнение каких задач следует приостановить, переходя в фоновый режим, а возобновить — лишь когда программа вернется в приоритетный режим. Рассмотрим пример. Сама система может с легкостью восстанавливать сетевые соединения. Поэтому мы можем ничего специально не предпринимать, если качаем файл из Сети. Но когда мы, например, пишем игру, лучше слушать те уведомления, которые iOS направляет нашей программе, работающей в фоновом режиме, и адекватно на них реагировать. В таком случае можно просто «поставить на паузу» игровой движок. Это же при необходимости можно проделать и со звуковым движком.

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

Рассмотрим сохранение состояния на примере. Предположим, мы пишем игру для iOS. Когда игра отправляется в фоновый режим, нам нужно сделать следующее.

1. Приостановить игровой движок.

2. Сохранить на диск очки, заработанные пользователем.

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

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

1. Загрузить с диска заработанные пользователем очки.

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

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

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

#import 

@interface AppDelegate: UIResponder 

@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.

 

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

Вы применяете экземпляры класса 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.

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

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

— (BOOL) application:(UIApplication *)application

didFinishLaunchingWithOptions:(NSDictionary *)launchOptions{

dispatch_queue_t dispatchQueue =

dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);

dispatch_async(dispatchQueue, ^(void) {

/* Заменяем этот 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;

}

 

См. также

Раздел 14.2.

 

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

Требуется исключить использование в вашем приложении многозадачности.

 

Решение

Добавьте в главный файл. plist приложения ключ UIApplicationExitsOnSuspend и задайте ему значение true:

<# Некоторые ключи и значения #>

UIApplicationExitsOnSuspend

<# Остальные ключи и значения #>

 

Обсуждение

Иногда бывает необходимо исключить возможность многозадачности в приложениях для iOS. (Хотя я настоятельно рекомендую разрабатывать программы с поддержкой многозадачности.) В таких случаях нужно добавить ключ UIApplicationExitsOnSuspend в главный файл. plist приложения. Устройства с самыми новыми версиями системы iOS понимают это значение, и операционная система будет завершать приложения, не переводя их в фоновый режим, если в файле. plist того или иного приложения этот ключ будет иметь значение true. В более ранних версиях iOS, где не поддерживается многозадачность, операционная система будет просто игнорировать это значение.

Когда подобное приложение работает в новой версии iOS, оно получит следующие сообщения делегата.

1. application: didFinishLaunchingWithOptions:.

2. applicationDidBecomeActive:.

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

1. applicationDidEnterBackground:.

2. applicationWillTerminate:.