Нахавандипур Вандад
Шрифт:
• 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 секунд после того, как пользователь впервые открывает это приложение: