iOS. Приемы программирования Нахавандипур Вандад
/* Настройки ярлыка */
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.
15.7. Настройка приложения для получения пуш-уведомлений
Постановка задачи
Требуется сконфигурировать приложение таким образом, чтобы сервер мог по своей инициативе отправлять уведомления на различные устройства.
Решение
Выполните следующие шаги.
1. Настройте профиль инициализации для вашего приложения, активизировав в нем возможность получения пуш-уведомлений.
2. В приложении зарегистрируйте устройство для получения пуш-уведомлений для этого приложения.
3. Возьмите идентификатор пуш-уведомлений данного устройства для вашего приложения и отошлите этот идентификатор на сервер.
В этом разделе мы поговорим о приложении, применяемом для внесения настроек и регистрации вашего приложения для получения пуш-уведомлений. Серверную часть этой технологии затрагивать не будем, этим вопросам будет посвящен отдельный раздел.
Обсуждение
Пуш-уведомления похожи на локальные уведомления тем, что позволяют сообщать пользователю определенную информацию, даже если ваше приложение неактивно при поступлении уведомления. В то время как локальные уведомления назначаются самим приложением, пуш-уведомления конфигурируются на сервере и отсылаются с него в Apple, а Apple сама раздает эти уведомления на разные устройства, работающие по всему миру. Мы должны выполнять серверную часть работы, поэтому сами составляем пуш-уведомления и отправляем их на серверы APNS (Apple Push Notifications Services). Затем APNS пытается доставлять наши пуш-уведомления по защищенным каналам на устройства, которые зарегистрированы для получения таких уведомлений.
Чтобы приложение для iOS могли получать пуш-уведомления, у него должен быть валидный профиль инициализации, в котором активизирована возможность получения пуш-уведомлений. Чтобы правильно сконфигурировать профиль, выполните следующие шаги.
Предполагается, что вы уже настроили на портале разработчика ваши сертификаты для разработки и распространения приложения. Чтобы автоматически сконфигурировать сертификаты, можете воспользоваться новой настройкой Accounts (Учетные записи), появившейся в Xcode. Просто перейдите в раздел Xcode Preferences (Настройки), в нем откройте область Accounts (Учетные записи). Добавьте в список учетных записей ваш идентификатор Apple ID, а далее Xcode сконфигурирует сертификаты за вас.
1. Войдите в центр для разработки для iOS.
2. Перейдите в раздел Certificates, Identifiers & Profiles (Сертификаты, идентификаторы и профили) — он расположен справа.
3. В разделе Identifiers (Идентификаторы) создайте для себя новый идентификатор App ID. Он должен иметь валидный Explicit App ID (явный идентификатор приложения), например com.pixolity.ios.cookbook.PushNotificationApp. Обратите внимание: это имя построено по принципу обратной записи домена в стиле, который я выбрал для этого приложения. Выберите такой идентификатор приложения в стиле обратной записи домена, который подходит вам и вашей организации.
4. В разделе App Services (Сервисы приложения) на странице идентификатора приложения убедитесь, что установили флажок для пуш-уведомлений (Push Notifications) (рис. 15.5).
Рис. 15.5. Активизация пуш-уведомлений для App ID
5. Как только вас устроит конфигурация идентификатора приложения (рис. 15.6), отправьте ваш App ID в Apple.
Рис. 15.6. Создание идентификатора приложения с поддержкой пуш-уведомлений
6. После того как настроите все детали конфигурации идентификатора приложения, перейдите в раздел Provisioning Profiles (Профили инициализации) вашего iOS-портала.
7. Создайте профиль инициализации для разработки (Development). Позже вы можете создать и другие профили — Ad Hoc и App Store, так что об этом не волнуйтесь. Когда будете готовы отправить ваше приложение в App Store, можете просто вернуться к этому шагу и сгенерировать профили Ad Hoc и App Store.
8. Убедитесь, что новый профиль инициализации для разработки приложения связан с идентификатором приложения, который вы сгенерировали ранее. Это первый вопрос, который у вас попытается выяснить система при генерации профиля инициализации.
9. Когда профиль будет готов, скачайте его и перетащите в программу iTunes на своем компьютере, чтобы установить. При установке профиля не делайте двойных щелчков на нем. При двойном щелчке кнопкой мыши имя файла установленного профиля будет сброшено и заменено хеш-именем MD5, по которому файл очень сложно идентифицировать на диске. Если вы аккуратно перетащите профиль в iTunes, то iTunes установит профиль под его оригинальным именем.
10. В Xcode в настройках сборки вашего приложения просто выберите сборку в соответствии с тем профилем, который только что создали. Убедитесь, что при разработке (схема Development) вы используете именно этот профиль, а затем примените в схеме Release (Релиз) профиль App Store или Ad Hoc, созданием которых займетесь позже.
11. Перетащите ваш профиль инициализации в текстовый редактор для OS X — например, в TextEdit. Найдите в файле профиля ключ Enh2ments. Весь этот раздел моего профиля инициализации выглядит так:
<key>Enh2ments</key>
<dict>
<key>application-identifier</key>
<string>F3FU372W5M.com.pixolity.ios.cookbook.PushNotificationApp</string>
<key>aps-environment</key>
<string>development</string>
<key>get-task-allow</key>
<true/>
<key>keychain-access-groups</key>
<array>
<string>F3FU372W5M.*</string>
</array>
</dict>
12. Создайте новый PLIST-файл для вашего проекта в Xcode, назовите этот файл Enh2ments.plist. В Xcode щелкните на этом файле правой кнопкой мыши, выберите Open As (Открыть как) и далее Source Code (Исходный код). Содержимое вашего файла изначально будет выглядеть вот так:
<plist version="1.0">
<dict/>
</plist>
13. Поместите разрешения вашего профиля инициализации прямо в файл Enh2ments.plist, чтобы его содержимое выглядело вот так:
<plist version="1.0">