iOS. Приемы программирования
Шрифт:
См. также
Разделы 1.19 и 1.20.
15.4. Планирование локальных уведомлений
Постановка задачи
Вы разрабатываете приложение, оперирующее данными о времени, например программу-будильник или программу-календарь. Это приложение должно информировать пользователя о событии в определенный момент времени, даже если в данный момент это приложение работает в фоновом режиме или вообще не запущено.
Решение
Инстанцируйте
Обсуждение
Если в данный момент приложение работает в фоновом режиме или не работает вообще, система выдает пользователю так называемое локальное уведомление. Чтобы запланировать доставку локального уведомления, используется метод экземпляра 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 должно иметь
• 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 секунд после того, как пользователь впервые открывает это приложение: