Текст книги "iOS. Приемы программирования"

См. также

Разделы 1.19 и 1.20.

15.4. Планирование локальных уведомлений

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

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

Решение

Инстанцируйте объект типа UILocalNotification, сконфигурируйте его (далее будет рассказано о том, как это делается) и запланируйте с помощью метода экземпляра scheduleLocalNotification:, относящегося к классу UIApplication. Чтобы получить экземпляр объекта вашего приложения, воспользуйтесь методом класса sharedApplication, относящимся к классу UIApplication.

Обсуждение

Если в данный момент приложение работает в фоновом режиме или не работает вообще, система выдает пользователю так называемое локальное уведомление. Чтобы запланировать доставку локального уведомления, используется метод экземпляра scheduleLocalNotification:, относящийся к классу UIApplication. Если приложение работает в приоритетном режиме и в это время срабатывает запланированное локальное уведомление, пользователь не получает никакого оповещения об этом. Вместо этого iOS бесшумно дает вам знать о том, что было выдано уведомление, – это делается через делегат приложения. Пока не будем вдаваться в детали этого процесса, рассмотрим его чуть позже.

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

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

Уведомление типа UILocalNotification имеет много свойств. Наиболее важными из них являются следующие:

• fireDate – это свойство типа NSDate, сообщающее iOS, когда должен быть запущен экземпляр локального уведомления. Данное свойство является обязательным;

• timeZone – это свойство типа NSTimeZone сообщает iOS, к какому часовому поясу относится конкретная дата запуска. Для получения актуального часового пояса используется метод экземпляра timeZone, относящийся к классу NSCalendar. Вы можете получить актуальный календарь, воспользовавшись методом класса currentCalendar, относящимся к вышеупомянутому классу;

• alertBody – это свойство относится к типу NSString и задает текст, который должен выводиться для пользователя при отображении вашего уведомления на экране;

• hasAction – логическое свойство. Сообщает iOS, собирается ли ваше приложение предпринимать какое-либо действие, когда происходит уведомление. Если установить его в YES, iOS отобразит для пользователя диалоговое окно, указанное в свойстве alertAction (описано далее). Если установить его в NO, iOS выдаст пользователю диалоговое окно с простым сообщением о том, что пришло уведомление;

• alertAction – если свойство hasAction установлено в YES, то значением этого свойства должна быть локализованная строка, описывающая действие, которое пользователь может совершить над вашим уведомлением в случаях, когда уведомление произошло, но в этот момент приложение не работает в приоритетном режиме. После этого iOS выведет уведомление в центре уведомлений или на экране блокировки. Если свойство hasAction имеет значение NO, то свойство alertAction должно иметь значение nil;

• applicationIconBadgeNumber – если при срабатывании данного уведомления обязательно должен измениться номер ярлыка вашего приложения, то в этом свойстве можно задать желаемый номер. Значением этого свойства всегда является целое число. Когда вы присваиваете новое значение этому свойству, оно, как правило, должно представлять собой актуальный номер ярлыка вашего приложения плюс 1. Чтобы узнать текущий номер ярлыка приложения, пользуйтесь свойством applicationIconBadgeNumber класса UIApplication;

• userInfo – это экземпляр словаря NSDictionary, прикрепляемый к вашему уведомлению и получаемый приложением при доставке этого уведомления. Обычно такие словари используются для сообщения дополнительной информации о локальном уведомлении.

Благодаря суммарному эффекту свойств hasAction и alertAction пользователь может жестом смахивания запустить ваше уведомление в центре уведомлений. После этого iOS откроет приложение. Именно так пользователь может воздействовать на локальные уведомления. Это очень удобно, особенно если вы разрабатываете приложение-календарь. В таком приложении вы можете выдавать пользователю локальное уведомление за несколько дней до наступления дня рождения друга этого пользователя. Затем вы предоставляете пользователю возможность выполнить какую-то операцию над этим уведомлением. Например, когда пользователь открывает ваше приложение, вы можете предложить на выбор несколько виртуальных подарков, которые можно рассылать друзьям ко дню рождения.

Предположим, что в Лондоне сейчас 13:00, лондонец работает с вашим приложением на своем устройстве. Очевидно, что он находится в гринвичском часовом поясе (GMT + 0). Вы хотите доставить пользователю определенное уведомление в 14:00, даже если в этот момент ваше приложение не будет работать. И вот наш пользователь садится на самолет в лондонском аэропорту Гэтвик и собирается лететь в Стокгольм, то есть в часовой пояс GMT + 1. Допустим, полет длится полчаса. Тогда пользователь окажется в Стокгольме в 13:30 по лондонскому времени. Но когда самолет приземлится, iOS обнаружит, что часовой пояс изменился, и время на пользовательском устройстве также изменится – теперь будет 14:30. Вслед за этим iOS обнаружит, что необходимо отобразить уведомление (и так уже с опозданием на 30 минут, поскольку изменился часовой пояс), и отобразит его.

Проблема заключается в том, что ваше уведомление должно было быть отображено в 14:00 по времени GMT + 0 или в 15:00 по времени GMT + 1, но не в 14:30 по GMT + 1. Чтобы избежать подобных ситуаций (а ведь они довольно часты при нынешнем темпе жизни), при указании даты и времени для вывода на экран локальных уведомлений нужно также сообщать часовой пояс.

Теперь все это протестируем на практике. Напишем простое приложение, доставляющее локальное уведомление через 8 секунд после того, как пользователь впервые открывает это приложение:

#import «AppDelegate.h»

@implementation AppDelegate

– (BOOL) application:(UIApplication *)application

didFinishLaunchingWithOptions:(NSDictionary *)launchOptions{

UILocalNotification *notification = [[UILocalNotification alloc] init];

/* Настройки времени и часового пояса */

notification.fireDate = [NSDate dateWithTimeIntervalSinceNow:8.0];

notification.timeZone = [[NSCalendar currentCalendar] timeZone];

notification.alertBody =

NSLocalizedString(@"A new item is downloaded.", nil);

/* Настройки действий */

notification.hasAction = YES;

notification.alertAction = NSLocalizedString(@"View", nil);

/* Настройки ярлыка */

notification.applicationIconBadgeNumber =

[UIApplication sharedApplication].applicationIconBadgeNumber + 1;

/* Дополнительная информация, пользовательский словарь */

notification.userInfo = @{@"Key 1": @"Value 1",

@"Key 2": @"Value 2"};

/* Назначаем уведомление */

[[UIApplication sharedApplication] scheduleLocalNotification: notification];

self.window = [[UIWindow alloc]

initWithFrame: [[UIScreen mainScreen] bounds]];

self.window.backgroundColor = [UIColor whiteColor];

[self.window makeKeyAndVisible];

return YES;

}

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

См. также

Раздел 15.0.

15.5. Слушание локальных уведомлений и реагирование на них

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

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

Решение

Реализуйте метод application: didReceiveLocalNotification: делегата вашего приложения и считайте ключ UIApplicationLaunchOptionsLocalNotificationKey, относящийся к словарю параметров запуска вашего приложения при вызове метода application: didFinishLaunchingWithOptions: в делегате приложения. В подразделе «Обсуждение» данного раздела подробнее объяснено, почему приходится обрабатывать локальное уведомление в двух местах, а не в одном.

Обсуждение

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

• В момент прихода локального уведомления приложение открыто и пользователь работает с ним. В таком случае при доставке уведомления вызывается метод application: didReceiveLocalNotification:.

• Локальное уведомление доставлено, но пользователь перевел приложение в фоновый режим. Как только пользователь дотрагивается до появившегося на экране уведомления, iOS может запустить приложение. В таком случае опять же вызывается метод application: didReceiveLocalNotification: делегата вашего приложения.

• В момент доставки локального уведомления приложение вообще неактивно. В данном случае вызывается метод application: didFinishLaunchingWithOptions: делегата приложения. Ключ UIApplicationLaunchOptionsLocalNotificationKey в словарном параметре didFinishLaunchingWithOptions этого метода содержит локальное уведомление, которое и привело к активизации приложения.

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

Разовьем код, рассмотренный в качестве примера в разделе 15.4. При запуске уведомления независимо от того, в каком состоянии в этот момент находится приложение, мы обработаем это уведомление (выведем для пользователя окно с предупреждением). Сначала используем код, изученный в разделе 15.4, в отдельном методе. Так мы сможем просто вызвать этот метод и назначить новое локальное уведомление. Вот почему поступаем именно так: в данном случае мы сможем посмотреть в центре уведомлений iOS, открылось ли приложение после того, как пользователь нажал появившееся на экране локальное уведомление. Если приложение открылось, то мы не будем запускать другое локальное уведомление. Однако если локальное уведомление не открыло наше приложение, то запланируем новое локальное уведомление. Далее приведен метод приложения, назначающий локальные уведомления, которые должны доставляться приложению через 8 секунд после вызова метода:

– (void) scheduleLocalNotification{

UILocalNotification *notification = [[UILocalNotification alloc] init];

/* Настройки времени и часового пояса */

notification.fireDate = [NSDate dateWithTimeIntervalSinceNow:8.0];

notification.timeZone = [[NSCalendar currentCalendar] timeZone];

notification.alertBody =

NSLocalizedString(@"A new item is downloaded.", nil);

/* Настройки действий */

notification.hasAction = YES;

notification.alertAction = NSLocalizedString(@"View", nil);

/* Настройки ярлыка */

notification.applicationIconBadgeNumber =

[UIApplication sharedApplication].applicationIconBadgeNumber + 1;

/* Дополнительная информация, пользовательский словарь */

notification.userInfo = @{@"Key 1": @"Value 1",

@"Key 2": @"Value 2"};

/* Назначаем уведомление */

[[UIApplication sharedApplication] scheduleLocalNotification: notification];

}

Метод, который мы здесь написали, называется scheduleLocalNotification. Как понятно из его названия, он просто создает объект уведомления и запрашивает iOS назначить это уведомление. Не путайте наш собственный метод scheduleLocalNotification с методом iOS, который называется scheduleLocalNotification: и относится к классу UIApplication (как и у всех методов iOS, в конце названия этого метода стоит двоеточие). Этот метод можно считать удобным вспомогательным инструментом, выполняющим сложную задачу назначения локального уведомления. При этом сам он просто создает объект уведомления, а назначение этого уведомления делегирует iOS.

Теперь в методе application: didFinishLaunchingWithOptions мы проверим, открылось ли приложение именно по причине поступления имеющегося уведомления. Если это так, то будем работать с имеющимся локальным уведомлением. В противном случае назначим новое:

– (BOOL) application:(UIApplication *)application

didFinishLaunchingWithOptions:(NSDictionary *)launchOptions{

if (launchOptions[UIApplicationLaunchOptionsLocalNotificationKey]!= nil){

UILocalNotification *notification =

launchOptions[UIApplicationLaunchOptionsLocalNotificationKey];

[self application: application didReceiveLocalNotification: notification];

} else {

[self scheduleLocalNotification];

}

self.window = [[UIWindow alloc]

initWithFrame: [[UIScreen mainScreen] bounds]];

self.window.backgroundColor = [UIColor whiteColor];

[self.window makeKeyAndVisible];

return YES;

}

Когда в предыдущем коде наше приложение запускалось в результате поступления локального уведомления, мы перенаправляли локальное уведомление в метод application: didReceiveLocalNotification:, где оперировали имеющимся уведомлением и отображали для пользователя предупреждение. Вот простая реализация вышеупомянутого метода:

– (void) application:(UIApplication *)application

didReceiveLocalNotification:(UILocalNotification *)notification{

NSString *key1Value = notification.userInfo[@"Key 1"];

NSString *key2Value = notification.userInfo[@"Key 2"];

if ([key1Value length] > 0 &&

[key2Value length] > 0){

UIAlertView *alert =

[[UIAlertView alloc] initWithTitle: nil

message:@"Handling the local notification"

delegate: nil

cancelButtonTitle:@"OK"

otherButtonTitles: nil];

[alert show];

}

}

Теперь испытайте его. Опробуйте разные комбинации. Откройте приложение и поработайте с ним в приоритетном режиме, потом переведите его в фоновый режим, можете даже вообще закрыть. Посмотрите, как приложение функционирует в разных условиях.

См. также

Разделы 15.0 и 15.4.

15.6. Обработка локальных системных уведомлений

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

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

Решение

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

• NSCurrentLocaleDidChangeNotification – доставляется приложениям, когда изменяется локализация устройства. Например, на странице Settings (Настройки) пользователь активизирует испанский язык вместо английского;

• NSUserDefaultsDidChangeNotification – запускается, когда пользователь изменяет настройки приложения на странице Settings (Настройки) устройства с iOS – при условии, что пользователь может изменить какую-либо настройку в вашем приложении;

• UIDeviceBatteryStateDidChangeNotification – запускается всякий раз, когда на устройстве с iOS изменяется состояние батареи. Например, если устройство подключается к компьютеру, когда приложение работает в приоритетном режиме, а потом отключается от компьютера, но приложение к этому моменту уже находится в фоновом режиме, то приложение получит такое уведомление (предполагается, что оно зарегистрировано на получение таких уведомлений). В подобном случае для считывания состояния можно узнать значение свойства batteryState экземпляра класса UIDevice;

• UIDeviceProximityStateDidChangeNotification – направляется приложению всякий раз, когда изменяется состояние датчика близости (Proximity Sensor). Последнее состояние можно узнать в свойстве proximityState экземпляра UIDevice.

Обсуждение

Пока ваше приложение работает в фоновом режиме, может произойти многое! Например, пользователь может вдруг изменить локализацию устройства с iOS на странице Settings (Настройки) и задать, к примеру, испанский язык вместо английского. Приложения могут регистрироваться для получения таких уведомлений. Эти уведомления будут объединяться, а потом вместе доставляться приложению, переходящему в приоритетный режим. Объясню, что я понимаю в данном случае под объединением). Предположим, что ваше приложение работает в приоритетном режиме и вы зарегистрировали его для получения уведомлений UIDeviceOrientationDidChangeNotification. Вот пользователь нажимает кнопку Home (Домой), и ваше приложение уходит в фоновый режим. Потом пользователь изменяет ориентацию устройства с книжной на альбомную правую, затем возвращает книжную ориентацию и, наконец, переводит в альбомную левую. И когда пользователь вернет ваше приложение в приоритетный режим, оно получит всего одно уведомление типа UIDeviceOrientationDidChangeNotification. Это и есть объединение. Все остальные изменения ориентации, которые происходили, пока ваше приложение не было открыто, игнорируются (действительно, они не имеют значения, раз программы не было на экране, когда они происходили), и система не будет сообщать информацию о них вашему приложению. Тем не менее система доставит вам как минимум одно уведомление по каждому аспекту, связанному с устройством, – в частности, по ориентации. Так вы сможете узнать самую актуальную информацию о том, в каком положении находится устройство.

Вот реализация простого контроллера вида, в котором эта техника используется для определения изменений ориентации:

#import «ViewController.h»

@implementation ViewController

– (void) orientationChanged:(NSNotification *)paramNotification{

NSLog(@"Orientation Changed");

}

– (void)viewDidAppear:(BOOL)paramAnimated{

[super viewDidAppear: paramAnimated];

/* Слушаем уведомление */

[[NSNotificationCenter defaultCenter]

addObserver: self

selector:@selector(orientationChanged:)

name: UIDeviceOrientationDidChangeNotification

object: nil];

}

– (void) viewDidDisappear:(BOOL)paramAnimated{

[super viewDidDisappear: paramAnimated];

/* Прекращаем слушать уведомление */

[[NSNotificationCenter defaultCenter]

removeObserver: self

name: UIDeviceOrientationDidChangeNotification

object: nil];

}

@end

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

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

Решение

Зарегистрируйтесь для получения уведомлений NSUserDefaultsDidChangeNotification.

Обсуждение

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

1. В Xcode выберите File – New File (Файл -Новый файл).

2. Убедитесь, что слева задана категория iOS.

3. Выберите подкатегорию Resources (Ресурсы).

4. В качестве типа файла укажите пакет настроек (Settings Bundle), а потом нажмите Next (Далее).

5. Назовите файл Settings.bundle.

6. Нажмите Save (Сохранить).

Итак, теперь у вас в Xcode есть файл под названием Settings.bundle. Оставьте этот файл как есть, не вносите в него никаких изменений. Нажмите кнопку Home (Домой) и перейдите в приложение Settings (Настройки). Если вы назовете свое приложение foo, то в окне настроек, показанном на рис. 15.4, также будет указано Foo. (Мое приложение я назвал Handling local System Notifications, это название вы видите на рисунке.)

Рис. 15.4. Пакет Settings.bundle отображается в приложении Settings (Настройки) в симуляторе iOS

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

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

#import «AppDelegate.h»

@implementation AppDelegate

– (void) handleSettingsChanged:(NSNotification *)paramNotification{

NSLog(@"Settings changed");

NSLog(@"Notification Object = %@", paramNotification.object);

}

– (BOOL) application:(UIApplication *)application

didFinishLaunchingWithOptions:(NSDictionary *)launchOptions{

[[NSNotificationCenter defaultCenter]

addObserver: self

selector:@selector(settingsChanged:)

name: NSUserDefaultsDidChangeNotification

object: nil];

return YES;

}

– (void)applicationWillTerminate:(UIApplication *)application{

[[NSNotificationCenter defaultCenter] removeObserver: self];

}

@end

А теперь попробуйте изменить некоторые из этих настроек, пока приложение работает в фоновом режиме. Когда закончите, переведите приложение в приоритетный режим – и увидите, что программе доставлено уведомление NSUserDefaultsDidChangeNotification. Объект, прикрепленный к этому уведомлению, будет относиться к типу NSUserDefaults и содержать настройки вашего приложения user defaults.