Содержание


Push-уведомления

добавьте в нативное мобильное iOS-приложение возможность подписки на push-уведомления

с помощью нативного API–интерфейса iOS IBM Worklight

Comments

Серия контента:

Этот контент является частью # из серии # статей: Push-уведомления

Следите за выходом новых статей этой серии.

Этот контент является частью серии:Push-уведомления

Следите за выходом новых статей этой серии.

Push-уведомления стали важным, эффективным и ожидаемым элементом многих современных мобильных приложений. Доставка push-сообщений на мобильные устройства клиентов не только обеспечивает канал для представления целевого контента, но и позволяет немедленно, в режиме реального времени, установить связь с клиентами.

Первый шаг на пути к предоставлению клиентам возможности подписаться на push-уведомления через ваше нативное мобильное приложение – аутентификация устройства. В этом руководстве демонстрируется типичный сценарий входа, в котором пользователь нативного мобильного iOS-приложения заполняет форму входа при запуске приложения для аутентификации на сервере IBM Worklight. Успешная аутентификация приводит к возобновлению процедуры запуска приложения и переходу к настройке подписки на push-уведомления Worklight.

В этом руководстве предполагается, что читатель знаком с разработкой мобильных iOS-приложений с помощью Worklight. Чтобы следовать описанным здесь примерам, необходимо следующее:

  • среда разработки iOS, состоящая из Xcode, учетной записи Apple Developer и устройства iOS 7.x, такого как iPhone или iPad;
  • интерфейс командной строки IBM Worklight (CLI). (См. инструкцию Установка инструментов командной строки для разработчиков на сайте Worklight Foundation Knowledge Center.);
  • пример iOS-приложения по крайней мере с одним контроллером представлений (далее – LoginViewController) и двумя текстовыми полями имени пользователя и пароля.

Это руководство также опирается на ряд вспомогательных классов, которые мы создадим по ходу дела. Это следующие классы:

  • NotificationsChallengeHandler: класс, наследуемый от API Worklight Challenge Handler;
  • ResponseListener: обратный вызов в ответ на запросы сервера;
  • ReadyToSubscribeListener: обратный вызов для подписки на push-уведомления;
  • EventSourceListener: приемник, требуемый API.

1. Настройка проекта IBM Worklight

Чтобы использовать IBM Worklight в проекте разработки нативного iOS-приложения с поддержкой Adapter Authentication, необходимо создать следующие артефакты:

  • проект Worklight;
  • Worklight iOS API.

Также потребуется сервер Worklight, на котором будет развернут проект Worklight. Сервер Worklight входит по умолчанию в состав Worklight Studio, но его экземпляр можно также создать и с помощью CLI.

  1. Создание сервера Worklight

    Чтобы создать экземпляр сервера Worklight, просто откройте терминал и подайте следующую команду:

    wl create-server

    для создания проверочного сервера Worklight по умолчанию в каталоге ~/.worklight Путь по умолчанию к журналам сервера и server.xml:

    ~/.worklight/6.2.0/server/wlp/usr/servers/worklight/

    Выполните:

    wl start

    для запуска проверочного сервера. Если нужно контролировать результат, можно также использовать команду wl run.

  2. Создание проекта Worklight

    В окне терминала перейдите в папку, где вы хотите создать проект Worklight, и введите следующую команду:

    wl create <project-name>

    где <project-name> — это имя вашего проекта Worklight (рисунок 1).

    Рисунок 1. Пример команды
    Пример команды
    Пример команды
  3. Создание нативного API

    Перейдите в каталог своего проекта Worklight и введите следующую команду:

    wl add api <name> -e <environment>

    где <name> – имя для вашего нативного API (например, iOSWorklightNotificationsTutorial), а <environment> - ios (рисунок 2).

    Рисунок 2. Пример команды
    Пример команды
    Пример команды
  4. Создание HTTP-адаптера Worklight

    Адаптер будет использоваться для проверки подлинности, а также для отправки push-уведомлений в устройство. Чтобы создать адаптер, используйте следующую команду:

    wl add adapter <name> -t <adaptertype>

    где <name> — имя вашего адаптера (например, PushAdapter), а <adaptertype> – http (рисунок 3).

    Рисунок 3. Пример команды
    Пример команды
    Пример команды
  5. Создание и развертывание

    Создав артефакты Worklight, необходимо перезапустить сервер, выполнив следующую команду:

    wl stop
    wl start
    (или wl run, если нужен вывод на консоль).

    Для создания и развертывания артефактов выполните следующую команду:

    wl build
    wl deploy

Чтобы выполнить сборку и развернуть все артефакты, выполните перечисленные выше команды из корневой папки своего проекта Worklight. Если нужно собрать и развернуть один артефакт, просто перейдите в этот корневой каталог и выполните команду оттуда.

2. Добавление API Worklight в проект iOS

  1. Копирование файлов

    Скопируйте в свой проект iOS <ios_project>/WorklightAPI папку WorklightAPI из каталога <worklight_project>/apps/<ios_api_name>/.

    Затем скопируйте worklight.plist из каталога <worklight_project>/apps/<ios_api_name>/ в <ios_project>/.

  2. Добавление библиотек

    Свяжите со своим нативным iOS-приложением следующие библиотеки (рисунок 4):

    • SystemConfiguration.framework
    • MobileCoreServices.framework
    • CoreData.framework
    • Security.framework
    • libz.dylib
    • sqlcipher.framework
    • libc++.dylib
    • libstdc++.6.dylib
    • CoreLocation.framework
    Рисунок 4. Добавление библиотек
    Добавление библиотек
    Добавление библиотек
  3. Параметры сборки

    Добавьте следующую запись в поле HEADER_SEARCH_PATH раздела Build Settings:

    $(SRCROOT)/WorklightAPI/include

    В поле Other Linker Flags введите следующее значение:

    -ObjC

    В поле iOS Deployment Target раздела Deployment выберите значение, большее или равное 5,0.

3. Настройка аутентификации адаптера: сервер

  1. Изменение файла конфигурации

    Отредактируйте файл <worklight_project>/server/conf/authenticationConfig.xml. Удалите содержимое файла loginConfiguration и замените его кодом из листинга 1.

    Листинг 1.
           <securityTests> 
           <customSecurityTest name="PushApplication-web-securityTest"> 
           <test realm="PushAppRealm" isInternalUserID="true" isInternalDeviceID="true"/> 
           </customSecurityTest> 
    
           <mobileSecurityTest name="PushApplication-mobile-securityTest"> 
           <testUser realm="PushAppRealm"/> 
           <testDeviceId provisioningType="none"/> 
           </mobileSecurityTest> 
           </securityTests> 
    
           <realms> 
           <realm loginModule="PushAppLoginModule" name="PushAppRealm"> 
           <className>com.worklight.integration.auth.AdapterAuthenticator</className> 
           <parameter name="login-function" value="PushAdapter.onAuthRequired"/> 
           <parameter name="logout-function" value="PushAdapter.onLogout"/> 
           </realm> 
           </realms> 
    
           <loginModules> 
           <loginModule name="PushAppLoginModule"> 
           <className>com.worklight.core.auth.ext.NonValidatingLoginModule</className> 
           </loginModule> 
           </loginModules>

    За подробной информацией по модели безопасности Worklight и аутентификации адаптера обращайтесь к документации Worklight. Также для понимания различных элементов, настроенных в файле authenticationConfig.xml, полезно прочесть руководство Аутентификация на основе адаптера в гибридных приложениях.

    Имейте в виду, что использование com.worklight.core.auth.ext.NonValidatingLoginModule означает, что платформа Worklight не будет выполнять никакой дополнительной проверки имени пользователя и пароля; ответственность за проверку учетных данных возлагается на разработчика и приложение.

  2. Настройка адаптера

    Отредактируйте xml-файл адаптера <worklight_project>/adapters/PushAdapter/PushAdapter.xml. В этом файле:

    • замените <domain> на localhost;
    • замените <port> на 10080 (порт сервера Worklight по умолчанию; это значение может меняться);
    • удалите существующие элементы <procedure> и добавьте код из листинга 2.
    Листинг 2.
           <procedure name="login" securityTest="PushApplication-web-securityTest"/> 
           <procedure name="submitNotification" /> 
           <procedure name="submitAuthentication"/>

    Настройка процедур в XML-файле адаптера, по существу, сводится к их регистрации в качестве public-процедур и позволяет клиентам и другим адаптерам вызывать их:

    • login – это защищенная процедура, доступная только для авторизованных пользователей. Эта процедура будет использоваться для инициирования процесса проверки подлинности;
    • submitAuthentication – это часть процесса проверки подлинности Worklight и не требует защиты;
    • submitNotification — это вспомогательная функция для отправки push-уведомления в устройство. В данном случае эта процедура не защищена, так как для упрощения тестирования мы будем отправлять уведомления без проверки подлинности.
    .

    Схема процесса проверки подлинности приведена на рисунке 5.

    Рисунок 5. Схема процесса проверки подлинности
    Схема процесса проверки подлинности
    Схема процесса проверки подлинности
  3. Настройка адаптера

    Далее, настройте реализацию адаптера, отредактировав файл <worklight_project>/adapters/PushAdapter/PushAdapter-impl.js. Удалите из файла реализации содержимое по умолчанию и добавьте функции из листинга 3.

    Листинг 3.
           function onAuthRequired(headers, errorMessage){ 
           errorMessage = errorMessage ? errorMessage : null; 
    
           return { 
           authRequired: true, 
           errorMessage: errorMessage 
           }; 
           }

    Всякий раз, когда среда Worklight обнаруживает попытку доступа к защищенному ресурсу без проверки подлинности, вызывается функция onAuthRequired (как определено в файле authenticationConfig.xml). Объект, возвращаемый этой функцией, направляется в клиентское приложение. В обработчике запросов клиента для обнаружения того, что сервер запрашивает проверку подлинности, используется свойство authRequired: true

    .

    Функция login – это защищенная функция, которая инициирует процесс аутентификации (листинг 4).

    Листинг 4.
           function login(){ 
           return {	 
           secretData: "The user is now authenticated" 
           }; 
           }

    Для проверки имени и пароля пользователя клиент вызывает процесс submitAuthentication (рисунок 5). Этот пример проверяет, что имя пользователя и пароль соответствуют жестко запрограммированным значениям.

    Листинг 5.
           function submitAuthentication(username, password){ 
           if (username==="user" && password === "password"){ 
    
           var userIdentity = { 
           userId: username, 
           displayName: username,  
           attributes: { 
           foo: "bar" 
           } 
           }; 
    
           WL.Server.setActiveUser("PushAppRealm", userIdentity); 
    
           return {  
           authRequired: false  
           }; 
           } 
           return onAuthRequired(null, "Invalid login credentials"); 
           }

    Функция submitNotification (листинг 6) позволят отправлять push-уведомления определенному пользователю.

    Листинг 6.
           function submitNotification(userId, notificationText){ 
           var userSubscription = WL.Server.getUserNotificationSubscription( 
           'PushAdapter.PushEventSource', userId); 
    
           if (userSubscription==null){ 
           return { result: "No subscription found for user :: " + userId }; 
           } 
    
           var badgeDigit = 1; 
    
           var notification = WL.Server.createDefaultNotification(notificationText,  
           badgeDigit, {custom:"data"}); 
    
           WL.Logger.debug("submitNotification >> userId :: " + userId + ",  
           text :: " + notificationText); 
    
           WL.Server.notifyAllDevices(userSubscription, notification); 
    
           return {  
           result: "Notification sent to user :: " + userId  
           }; 
           }

    Теперь нужно выполнить команды wl build и wl deploy, чтобы сервер мог развернуть новую конфигурацию и измененный адаптер.

4. Настройка аутентификации адаптера: клиент

Для проверки подлинности на сервере необходимо выполнить три основных шага. Нужно:

  1. Зарегистрировать обработчик запросов в клиенте и подключить его к серверу.
  2. Вызвать процедуру защищенного входа для запуска процесса проверки подлинности.
  3. Обработать запрос проверки подлинности, возвращенный сервером Worklight.

Для этого необходимо сначала создать обработчик запросов проверки подлинности сервера.

  1. Создание обработчика запросов

    Создайте новый исходный файл и заголовок, определяющий обработчик запросов; например, NotificationsChallengeHandler.h и NotificationsChallengeHandler.m.

    Импортируйте в этот файл следующие заголовки:

    • Foundation.h
    • WLClient.h
    • ChallengeHandler.h
    • WLDelegate.h

    Добавьте в файл заголовка код из листинга 7.

    Листинг 7.
          @interface NotificationsChallengeHandler : ChallengeHandler <WLDelegate> 
    
           - (BOOL)isCustomResponse: (WLResponse *)response; 
           - (void)handleChallenge: (WLResponse *)response; 
    
           @end
  2. Управление запросом аутентификации

    Для обработки запроса, возвращенного сервером, добавьте в файл NotificationsChallengeHander.m код из листинга 8.

    Листинг 8.
        - (BOOL)isCustomResponse: (WLResponse *)response { 
        if(response == nil || [response responseText] == nil || [[response responseText]  
        rangeOfString:@"authRequired"].location == NSNotFound){ 
        return false; 
        } 
        return true; 
        }

    Каждый раз при получении ответа от сервера вызывается метод обработчика запросов isCustomResponse. Этот метод используется для определения того, содержит ли ответ сведения, относящиеся к данному обработчику запросов. Метод возвращает значение true или false.

    Если isCustomResponse возвращает значение true, то среда вызывает метод handleChallenge (листинг 9).

    Листинг 9.
         - (void)handleChallenge: (WLResponse *)response { 
         NSDictionary *responseJSON = [response getResponseJson]; 
         BOOL authRequired = [[responseJSON objectForKey:@"authRequired"] boolValue]; 
         NSString *errMessage = [responseJSON objectForKey:@"errorMessage"]; 
    
         if (authRequired && ![errMessage isKindOfClass:[NSNull class]]){ 
         [self submitFailure:response]; 
         } else if (!authRequired) { 
         [self submitSuccess:response]; 
         } else { 
         NSString *name = [[NSUserDefaults standardUserDefaults] stringForKey:@"username"]; 
         NSString *password =[[NSUserDefaults standardUserDefaults] stringForKey:@"password"]; 
         NSLog(@"%@",[NSString stringWithFormat:@"Logging in with Username :: %@\n\t Password ::  
         %@", name,password]); 
    
         NSArray *params = @[name, password]; 
         WLProcedureInvocationData *invocationData = [[WLProcedureInvocationData alloc]  
         initWithAdapterName:@"PushAdapter" procedureName:@"submitAuthentication"]; 
         [invocationData setParameters:params]; 
         [self submitAdapterAuthentication: invocationData options:nil]; 
         } 
         }

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

    Для выполнения необходимых действий, зависящих от ответа сервера, используется метод handleChallenge. В этом примере этот метод выполняет одно из следующих действий:

    • ввод и передача реквизитов доступа для проверки подлинности;
    • передача отрицательного результата проверки подлинности;
    • передача положительного результата проверки подлинности.

    После того как реквизиты доступа приняты, адаптер проверяет учетные данные.

  3. Регистрация обработчика запросов

    Теперь нужно зарегистрировать клиент и подключить его к серверу. Опять же, вы сами выбираете наилучшее место в коде для подачи команды подключения. В этом примере подключение инициируется нажатием кнопки Login.

    Начнем с создания приемника ответов для регистрации ответов, полученных от сервера (листинги 10 и 11).

    Листинг 10. ResponseListener.h
        #import "WLClient.h" 
        #import "WLDelegate.h" 
    
        @interface ResponseListener : NSObject <WLDelegate>  
         @end
    Листинг 11. ResponseListener.m
        #import "ResponseListener.h" 
    
        @implementation ResponseListener 
    
        -(void)onSuccess:(WLResponse *)response{ 
        NSLog(@"%@",[NSString stringWithFormat:@"onSuccess response from  
        the server:: %@\n\t", response.description]); 
        } 
    
        -(void)onFailure:(WLFailResponse *)response{ 
        NSLog(@"%@",[NSString stringWithFormat:@"onFailure logged in ::  
        %@\n\t", response.errorMsg]); 
        } 
        @end

    Обязательно импортируйте в свой LoginViewController заголовки, приведенные в листинге 12.

    Листинг 12.
        #import "WLClient.h" 
        #import "ResponseListener.h" 
        #import "NotificationsChallengeHandler.h"

    Чтобы инициировать соединение, добавьте в свой контроллер представлений код из листинга 13 внутри метода действия кнопки Login.

    Листинг 13.
        ResponseListener *connectListener = [[ResponseListener alloc] init]; 
        NotificationsChallengeHandler *challengeHandler =  
        [[NotificationsChallengeHandler alloc] init]; 
        [[WLClient sharedInstance] registerChallengeHandler: 
        [challengeHandler initWithRealm:@”PushAppRealm”]]; 
        [[WLClient sharedInstance] wlConnectWithDelegate:connectListener];

    Приведенный выше код создает новый экземпляр ResponseListener, который используется для взаимодействия с сервером Worklight и регистрирует экземпляр NotificationsChallengeHandler. Для регистрации обработчика требуется область безопасности. Мы уже определили область безопасности на сервере (PushAppRealm) и теперь можем зарегистрировать там NotificationsChallengeHandler.

    Код создаст обработчик запросов и установит соединение с сервером. Однако он не будет пытаться выполнить аутентификацию, потому что еще не вызвана защищенная процедура адаптера. Необходимо вызвать защищенную процедуру сеанса проверки подлинности.

  4. Вызов процедур адаптера

    Код из листинга 14 вызывает защищенную процедуру входа адаптера Worklight и инициирует проверку подлинности.

    Листинг 14.
        WLProcedureInvocationData *myInvocationData = [[WLProcedureInvocationData alloc]  
        initWithAdapterName:self.adapterName procedureName:@"login"]; 
        ResponseListener *invokeListener = [[ResponseListener alloc] init];  
        [[WLClient sharedInstance] invokeProcedure:myInvocationData withDelegate:invokeListener];

    Вызов процедуры входа инициирует проверку подлинности и возвращает запрос от сервера. Этот запрос обрабатывается обработчиком запросов.

5. Настройка push-уведомлений: клиент

  1. Получение сертификата APNS>

    Для отправки push-уведомлений на iOS-устройства используется служба Apple Push Notifications Service (APNS). Для получения сертификата Apple APNS для своего приложения нужно быть зарегистрированным разработчиком Apple iOS. Сертификаты APNS должны иметь непустой пароль. (Подробнее об APNS см. в документации Apple Push Notification Service).

    Получив сертификат, переименуйте его в apns-certificate-sandbox.p12 (разработка) или apns-certificate-production.p12 (производство) и поместите в корневую папку среды iOS Worklight; например, для среды разработки это выглядит примерно так:

    <workspace>/apps/iOSWorklightNotificationsTutorial/apns-certificate-sandbox.p12.

  2. Редактирование проекта Worklight

    Добавив сертификат в приложение, необходимо отредактировать файл application-descriptor.xml. Дескриптор приложения — это артефакт Worklight, в котором хранится пароль сертификата APNS для выбранного идентификатора комплекта. Файл дескриптора своего приложения можно найти в нативной среде iOS Worklight (например, <workspace>/apps/iOSWorklightNotificationsTutorial/application-descriptor.xml). Отредактируйте дескриптор своего приложения следующим образом:

    <pushSender password="<password>"/>

    где >password< — это пароль сертификата APNS.

    Убедитесь, что идентификатор bundleId, определенный в файле application-descriptor.xml, совпадает с идентификатором bundleId вашего приложения, который использовался для получения сертификата APNS.

    Кроме того, после внесения этих изменений заново выполните сборку и развертывание своего проекта Worklight Native API.

  3. Подписка на уведомления: маркер APNS

    Инициализируйте WLPush sharedInstance в своем методе LoginViewController LoginViewController.m (листинг 15).

    Листинг 15. LoginViewController.m
        AppDelegate *appDelegate = [[UIApplication sharedApplication]delegate]; 
        appDelegate.appDelegateVC = self; 
        [[WLPush sharedInstance]init];

    Свяжите LoginViewController со своим AppDelegate:

    1. Импортируйте LoginViewController.h:
      #import "LoginViewController.h"
    2. Измените интерфейс AppDelegate на:
      @interface AppDelegate : UIResponder <UIApplicationDelegate>{ LoginViewController* _appDelegateVC; }
    3. Добавьте к AppDeligate.h следующие свойства:
      @property (nonatomic, retain) IBOutlet LoginViewController *appDelegateVC;
    4. Синтезируйте appDelegateVC в AppDelegate.m:
      @synthesize appDelegateVC=_appDelegateVC;
    5. Импортируйте AppDelegate.h и WLPush.h в свой контроллер представления Login:
      #import "WLPush.h"
      #import "AppDelegate.h"

    Теперь нужно получить маркер APNS, когда он станет доступен. Добавьте в AppDeligate.m метод, показанный в листинге 16.

    Листинг 16.
        -(void)application:(UIApplication *)application  
        didRegisterForRemoteNotificationsWithDeviceToken:(NSData *)deviceToken{ 
        NSLog(@"APNS Token : %@", deviceToken); 
        _appDelegateVC.myToken = deviceToken.description; 
        }

    Добавьте в файл заголовка контроллера представления свойство myToken:

    @property (nonatomic, strong)NSString *myToken;

    Наконец, перед подключением к серверу Worklight нужно передать myToken в экземпляр WLPush:

    [[WLPush sharedInstance] setTokenFromClient:self.myToken];

  4. Подписка на уведомления: ReadyToSubscribeListener

    Далее, создайте приемник, который подпишет вас на уведомления, когда платформа будет готова. Для этого создайте заголовки и методы, показанные в листингах 17-20.

    Листинг 17. EventSourceListener.h
        #import <Foundation/Foundation.h> 
         #import "WLEventSourceListener.h" 
    
         @interface EventSourceListener : NSObject <WLEventSourceListener> 
          @end
    Листинг 18. EventSourceListener.m
        #import "EventSourceListener.h" 
    
        @implementation EventSourceListener 
    
        -(void)onReceive:(NSString *)props :(NSString *)payload{} 
    
        @end
    Листинг 19. ReadyToSubscribeListener.h
        #import <Foundation/Foundation.h> 
         #import "WLPush.h" 
         #import "WLOnReadyToSubscribeListener.h" 
    
         @interface ReadyToSubscribeListener : NSObject <WLOnReadyToSubscribeListener> 
    
          @property (nonatomic, strong)NSString *alias; 
          @property (nonatomic, strong)NSString *adapterName; 
          @property (nonatomic, strong)NSString *eventSourceName; 
    
          @end
    Листинг 20. ReadyToSubscribeListener.m
        #import "ReadyToSubscribeListener.h" 
        #import "EventSourceListener.h" 
        #import "ResponseListener.h" 
        #import "WLProcedureInvocationData.h" 
    
        @implementation ReadyToSubscribeListener 
    
        -(void)OnReadyToSubscribe{ 
        NSLog(@"OnReadyToSubscribe entered"); 
        ResponseListener *subscribeListener = [[ResponseListener alloc] init]; 
        EventSourceListener *eventListener = [[EventSourceListener alloc] init]; 
    
        [[WLPush sharedInstance] registerEventSourceCallback:self.alias :self.adapterName 
        :self.eventSourceName :eventListener]; 
    
        NSLog(@"Subscribing"); 
        [[WLPush sharedInstance]subscribe:self.alias :nil :subscribeListener]; 
    
        @end

    После регистрации источника событий (Event Source) можно подписаться на уведомления с помощью API подписки. Уведомления поступают непосредственно в AppDelegate, так что добавьте туда обработчик (листинг 21).

    Листинг 21.
        -(void)application:(UIApplication *)application  
        didReceiveRemoteNotification:(NSDictionary *)userInfo{ 
        NSLog(@"Received Notification %@",userInfo.description); 
        //    обработчик в пользовательском интерфейсе 
        }

    Добавьте обратный вызов к AppDelegate для перехвата ошибок с помощью APNS (листинг 22).

    Листинг 22.
        -(void)application:(UIApplication *)application  
        didFailToRegisterForRemoteNotificationsWithError:(NSError *)error{ 
        NSLog(@"Failed to get token from APNS, error: %@", error); 
        }

6. Настройка push-уведомлений: сервер

Чтобы настроить push-уведомления на сервере, добавьте в файл файл PushAdapter-impl.js код из листинга 23.

Листинг 23.
  WL.Server.createEventSource({ 
  name: 'PushEventSource', 
  onDeviceSubscribe: 'deviceSubscribeFunc', 
  onDeviceUnsubscribe: 'deviceUnsubscribeFunc', 
  securityTest:'PushApplication-mobile-securityTest' 
  }); 

  function deviceSubscribeFunc(userSubscription, deviceSubscription){ 
  WL.Logger.debug(">> deviceSubscribeFunc"); 
  } 

  function deviceUnsubscribeFunc(userSubscription, deviceSubscription){ 
  WL.Logger.debug(">> deviceUnsubscribeFunc"); 
  }

6. Тестирование

Чтобы проверить, что приложение может получать push-уведомления, используйте следующую команду CLI:

  • wl invoke
Листинг 24.
  [?] Which procedure do you want to invoke? submitNotification 
  [?] Enter the comma-separated parameters: "user","Hello!"

Заключение

Реализация push-уведомлений – не самый простой процесс, и чаще всего он требует предварительного знания платформы. Используя Worklight для управления всем сложным кодом для клиента и для сервера, можно сосредоточиться на логике отправки и обработки push-сообщений, вместо того чтобы тратить время на «шаблонный» код. Надеюсь, что теперь вы знаете, как добавить функциональность push-уведомлений Worklight к своим нативным мобильным приложениям и как работать с простым сценарием входа/подписки. Это должно помочь вам перейти к более сложным случаям.


Ресурсы для скачивания


Похожие темы


Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=WebSphere, Облачные вычисления, Мобильные приложения
ArticleID=1021141
ArticleTitle=Push-уведомления: добавьте в нативное мобильное iOS-приложение возможность подписки на push-уведомления
publish-date=11162015