Читать онлайн «iOS. Приемы программирования». Страница 129

• 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.4). При поступлении этих уведомлений в приложение на них нужно правильно реагировать.

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

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

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

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

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

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

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