Содержание


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

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

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

Comments

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

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

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

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

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

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

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

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

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

  • Constants.java: список статических констант;
  • NotificationsChallengeHandler.java: класс расширения API Worklight Challenge Handler;
  • ResponseListener.java: класс расширения API Worklight Response Listener;
  • WorklightUtils.java: одноэлементный singleton-класс управления соединением с сервером, подпиской на push-уведомления и получением уведомлений.

1. Создание Android-проекта

Для начала нужно создать простое Android-приложение (WorklightNotificationsTutorial) с двумя черными действиями:

  • LoginActivity (activity_login.xml)
  • MainActivity (activity_main.xml).

Добавьте к LoginActivity два текстовых поля для имени пользователя и пароля, а также кнопку входа:

  • EditText with id ”loginName.“
  • EditText with id “loginPassword.”
  • Button with id “loginButton.”

Можно добавить и некоторое стилевое оформление страницы входа. Пример страницы входа показан на рисунке 1.

Рисунок 1. Пример страницы входа
Пример страницы входа
Пример страницы входа

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

Рисунок 2. Пример индикатора выполнения
Пример индикатора выполнения
Пример индикатора выполнения

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

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

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

Также потребуется сервер 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 (рисунок 3).

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

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

    wl add api <name> -e <environment>

    где name — это имя вашего Native API (например, AndroidPushTutorial), а environment - android (рисунок 4).

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

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

    wl add adapter <name> -t <adaptertype>

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

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

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

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

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

    wl build
    wl deploy

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

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

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

    Скопируйте следующие файлы JAR из <worklight_project>/apps/<android_api_name>/ в свой Android-проект <andoid_project>/app/libs:

    • android-async-http.jar
    • gcm.jar
    • worklight-android.jar
    • bcprov.jar

    Затем скопируйте push.png из <worklight_project>/apps/<android_api_name>/ в папку drawables.

    Наконец, скопируйте wlclient.properties из <worklight_project>/apps/<android_api_name>/ в assets/wlclient.properties. Если у вас нет папки assets, создайте ее в каталоге <android_project>/app/src/main/.

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

  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.

    Рисунок 6. Схема процесса проверки подлинности
    Схема процесса проверки подлинности
    Схема процесса проверки подлинности
  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, чтобы сервер мог развернуть новую конфигурацию и измененный адаптер.

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

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

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

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

  1. Добавление разрешений

    Добавьте в манифест Android разрешения из листинга 7.

    Листинг 7.
           <uses-permission android:name="android.permission.INTERNET" /> 
           <uses-permission android:name="android.permission.ACCESS_WIFI_STATE" /> 
           <uses-permission android:name="android.permission.GET_TASKS" />
  2. Создание обработчика запросов

    Создайте новый класс (NotificationsChallengeHandler), расширяющий класс ChallengeHandler. Реализуйте все абстрактные методы, определенные в классе ChallengeHandler, и добавьте Context в конструктор. Обработчик запросов должен выглядеть как в листинге 8.

    Листинг 8.
           public class NotificationsChallengeHandler extends ChallengeHandler{ 
           private Context context; 
           private final static String TAG = NotificationsChallengeHandler.class.getName(); 
           public NotificationsChallengeHandler(String realm, Context context) { 
           super(realm); 
           this.context = context; 
           } 
           @Override 
           public boolean isCustomResponse(WLResponse wlResponse) { 
           return false; 
           } 
           @Override 
           public void handleChallenge(WLResponse wlResponse) {} 
    
           @Override 
           public void onSuccess(WLResponse wlResponse) {} 
    
           @Override 
           public void onFailure(WLFailResponse wlFailResponse) {} 
           }
  3. Регистрация обработчика запросов

    Теперь нужно зарегистрировать клиент и подключить его к серверу. Как разработчик, вы сами выбираете наилучшее место в коде для подачи команды подключения. Учитывая, что позже вам придется реализовать API Push Notification IBM Worklight, который очень тесно переплетен с API подключения, рекомендуется создать служебный класс для размещения клиента и подключить его к серверу.

    Создайте служебный singleton-класс WorklightUtils.java и добавьте в него код, приведенный в листинге 9.

    Листинг 9.
           WLClient client = WLClient.createInstance(context); 
           ResponseListener responseListener = new ResponseListener(); 
           client = WLClient.getInstance(); 
           client.registerChallengeHandler(new NotificationsChallengeHandler("PushAppRealm", context)); 
           client.connect(responseListener);

    Этот код создает новый экземпляр WLClient, который используется для взаимодействия с сервером Worklight и регистрирует экземпляр NotificationChallengeHandler. Кроме того, создается экземпляр ResponseListener для его передачи в метод connect в качестве обратного вызова. ResponseListener – это еще один специальный служебный класс, который реализует метод WLResponseListener. Этот класс может содержать переменную типа поданного запроса и обрабатывать ответ сервера в зависимости от типа первоначального вызова. Рекомендуется как минимум записать текст ответа, полученный от сервера (листинг 10).

    Листинг 10.
           public class ResponseListener implements WLResponseListener { 
    
           private final static String TAG = ResponseListener.class.getName(); 
    
           public ResponseListener() { 
           super(); 
           } 
    
           @Override 
           public void onSuccess(WLResponse wlResponse) { 
           Log.d(TAG, "onSuccess() entered"); 
           Log.d(TAG, wlResponse.getResponseText()); 
           } 
    
           @Override 
           public void onFailure(WLFailResponse wlFailResponse) { 
           Log.d(TAG, "onFailure() entered"); 
           Log.e(TAG,wlFailResponse.getErrorMsg()); 
           } 
           }

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

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

    Перед началом процедуры входа сохраните реквизиты доступа в памяти, чтобы класс обработчика запросов мог при необходимости извлечь их. Класс Application нужно расширить для совместного использования переменных на глобальном уровне. Этот класс приведен в листинге 11.

    Листинг 11.
           public class WorklightNotificationsTutorialApplication extends Application { 
    
           private String name; 
           private String password; 
    
           @Override 
           public void onCreate() { super.onCreate(); } 
    
           public String getName() { return name; } 
    
           public void setName(String name) { this.name = name; } 
    
           public String getPassword() { return password; } 
    
           public void setPassword(String password) { this.password = password; } 
           }

    Теперь используем метод кнопки входа onClick для временного хранения реквизитов входа в виде параметров класса WorklightNotificationsTutorialApplication (листинг 12).

    Листинг 12.
           WorklightNotificationsTutorialApplication app =  
           (WorklightNotificationsTutorialApplication) getApplicationContext(); 
           app.setName(nameView.getText().toString()); 
           app.setPassword(passwordView.getText().toString());

    Затем вызовем процедуру входа внутри того же метода. (Листинг 12).

    Листинг 13.
           ResponseListener responseListener = new ResponseListener(); 
           WLClient client = WLClient.getInstance(); 
           WLProcedureInvocationData invocationData = new  
           WLProcedureInvocationData("PushAdapter","login"); 
           client.invokeProcedure(invocationData, responseListener);

    Убедитесь, что перед WLClient.getInstance() вызывается WLClient.createInstance(context).

    В этом примере WLClient.createInstance(context) представляет собой часть конструктора класса WorklightUtils и должен вызваться внутри метода запуска действия onCreate.

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

  5. Управление запросом аутентификации

    Для обработки запроса, возвращенного сервером, необходимо расширить существующий обработчик NotificationsChallengeHandler (листинг 14).

    Листинг 14.
           @Override 
           public boolean isCustomResponse(WLResponse response) { 
           Log.d(TAG, ".isCustomResponse() entered"); 
           if (response == null || response.getResponseText() == null || 
           response.getResponseText().indexOf("authRequired") == -1) { 
           return false; 
           } 
           return true; 
           }

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

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

    Листинг 15.
           @Override 
           public void handleChallenge(WLResponse response) { 
           Log.d(TAG, ".handleChallenge() entered"); 
           try { 
           JSONObject responseJSON = response.getResponseJSON(); 
           boolean authRequired = responseJSON.getBoolean("authRequired"); 
           String errorMessage = responseJSON.has("errorMessage") ?  
           responseJSON.getString("errorMessage") : null; 
           if (errorMessage != null && errorMessage.equals("null")) errorMessage = null; 
    
           if (authRequired && errorMessage != null) { 
           submitFailure(response); 
           publishResult(errorMessage,Constants.ERROR); 
           } else if (!authRequired) { 
           submitSuccess(response); 
           publishResult(response.getResponseText(),Constants.SUCCESS); 
           } else { 
           WLProcedureInvocationData invocationData= 
           new WLProcedureInvocationData("PushAdapter","submitAuthentication"); 
           WorklightNotificationsTutorialApplication app = 
           (WorklightNotificationsTutorialApplication) context.getApplicationContext(); 
           Object [] params = {app.getName(),app.getPassword()}; 
           invocationData.setParameters(params); 
           submitAdapterAuthentication(invocationData,null); 
           } 
           } catch (JSONException e) { 
           Log.e(TAG,"Exception caught while processing the JSON response", e.getCause()); 
           } 
           }

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

    • ввод и передача реквизитов доступа для проверки подлинности;
    • подача сигнала об отказе при аутентификации и отправка сообщения с подробной информацией;
    • подача сигнала об успешной аутентификации и отправка сообщения с подробной информацией.

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

    publishResult – это простой вспомогательный метод для отправки сообщения (листинг 16).

    Листинг 16.
           private void publishResult(String message, String type) { 
           Intent actionIntent = new Intent 
           (WorklightNotificationsTutorialApplication.CHALLENGE_HANDLER_RETURNED); 
           actionIntent.putExtra(WorklightNotificationsTutorialApplication.TYPE,type); 
           actionIntent.putExtra(WorklightNotificationsTutorialApplication.DETAILS,message); 
           context.sendBroadcast(actionIntent); 
           }

    Последним шагом по обработке запроса аутентификации является создание приемника BroadcastReceiver для получения результата аутентификации. Чтобы упростить этот пример, зарегистрируйте в LoginActivity приемник широковещательных сообщений (листинг 17).

    Листинг 17.
           @Override 
           protected void onResume() { 
           super.onResume(); 
           if (challengeHandlerReceiver == null) { 
           challengeHandlerReceiver = new BroadcastReceiver() { 
           @Override 
           public void onReceive(Context context, Intent intent) { 
           showToast(intent.getStringExtra(Constants.DETAILS)); 
           if (intent.getStringExtra(Constants.TYPE) 
           .equals(Constants.SUCCESS)) { 
           loginSuccessful(); 
           } 
           } 
           }; 
           } 
           getApplicationContext().registerReceiver(challengeHandlerReceiver, 
           new IntentFilter(Constants.CHALLENGE_HANDLER_RETURNED)); 
           }

    Не забудьте отменить регистрацию приемников onPause.

    Получив широковещательное сообщение, можно проверить его тип. Если это сообщение об успешной аутентификации, значит пользователь аутентифицирован на сервере, и можно переходить к следующему действию.

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

  1. Внесение изменений в AndroidManifest.xml>

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

    Листинг 18.
           <permission android:name= 
           "com.ibm.worklightnotificationstutorial.permission.C2D_MESSAGE"  
           android:protectionLevel="signature"/> 
    
           <uses-permission android:name= 
           "com.ibm.worklightnotificationstutorial.permission.C2D_MESSAGE"/> 
           <uses-permission android:name="com.google.android.c2dm.permission.C2D_MESSAGE"/> 
           <uses-permission android:name="android.permission.WAKE_LOCK"/> 
           <uses-permission android:name="android.permission.USE_CREDENTIALS"/> 
           <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>

    Установите режим запуска действия launcher singleTask (листинг 19).

    Листинг 19.
           <activity android:name=".LoginActivity" android:launchMode= 
           "singleTask"android:label="@string/app_name" > 
           <intent-filter> 
           <action android:name="android.intent.action.MAIN" /> 
           <category android:name="android.intent.category.LAUNCHER" /> 
           </intent-filter> 
           </activity>

    Добавьте GCMIntentService и фильтр намерений для уведомлений RECEIVE и REGISTRATION (листинг 20).

    Листинг 20.
           <service android:name="com.worklight.wlclient.push.GCMIntentService" /> 
    
           <receiver 
           android:name="com.worklight.wlclient.push.WLBroadcastReceiver" 
           android:permission="com.google.android.c2dm.permission.SEND" > 
    
           <intent-filter> 
           <action android:name="com.google.android.c2dm.intent.RECEIVE" /> 
           <category android:name="com.ibm.worklightnotificationstutorial" /> 
           </intent-filter> 
           <intent-filter> 
           <action android:name="com.google.android.c2dm.intent.REGISTRATION" /> 
           <category android:name="com.ibm.worklightnotificationstutorial" /> 
           </intent-filter> 
           </receiver>
  2. Получение ключа GCM

    Для отправки push-уведомлений в Android-устройства необходимо использовать службу Google Cloud Messaging (GCM). Чтобы зарегистрироваться в Google GCM, нужна действительная учетная запись Google. (Дополнительную информацию по настройке реализации GCM см. в документации Android).

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

    После создания проекта GCM и получения ключа GCM необходимо выполнить следующие шаги по редактированию файлов.

    1. Добавьте в файл wlclient.properties ID проекта GCM GcmSenderId. Этот файл должен находиться в папке assets проекта Android.
    2. Добавьте в файл application-descriptor.xml <pushSender key="GCM_key" senderId="GCM_project_id"/>, где GCM_key – это ключ, полученный от Google, а GCM_project_id — это идентификатор проекта, в котором зарегистрирован ключ GCM.
    3. Добавьте в файл application-descriptor.xml<publicSigningKey>key</publicSigningKey>, где key – это открытый ключ сертификата, который использовался для входа в APK (в среде разработки это сертификат отладки).

    Имейте в виду, что файл application-descriptor.xml должен находиться в каталоге apps/<android_native_api_name> проекта Worklight.

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

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

    При подключении к серверу Worklight приложение пытается зарегистрироваться на сервере GCM для получения push-уведомлений. Чтобы подписаться на уведомления после подключения к серверу, перед попыткой подключения нужно запустить setOnReadyToSubscribeListener.

    Добавьте в класс WorklightUtils перед подачей команды client.connect(responseListener) код из листинга 21.

    Листинг 21.
           client.getPush().setOnReadyToSubscribeListener(new 
           WLOnReadyToSubscribeListener() { 
           @Override 
           public void onReadyToSubscribe() { 
    
           } 
           });

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

    Листинг 22.
           public void onReadyToSubscribe() { 
           client.getPush().registerEventSourceCallback(Constants.PUSH_ALIAS,"PushAdapter", 
           "PushEventSource",new WLEventSourceListener() { 
           @Override 
           public void onReceive(String s, String s2) { 
    
           } 
           }); 
           client.getPush().subscribe(Constants.PUSH_ALIAS, new WLPushOptions(), responseListener); 
           }

    Внутри метода onReceive будут обрабатываться входящие уведомления путем их отправки внутри широковещательного сообщения (листинг 23).

    Листинг 23.
           Log.d(TAG, "onReceive() entered"); 
           Intent notificationReceivedIntent = new Intent(Constants.NOTIFICATION_RECEIVED); 
           notificationReceivedIntent.putExtra(Constants.DETAILS,s); 
           context.sendBroadcast(notificationReceivedIntent);

    Имейте в виду, что приведенная выше реализация не сохраняет уведомления, так что если на устройстве не открыто действие, способное получать широковещательные сообщения, то уведомление может быть потеряно.

  5. Жизненный цикл уведомлений

    Реализация Push-уведомления с использованием Worklight для получения и обработки уведомлений опирается на WLClient GCMIntentService. Чтобы получать уведомления, когда приложение не активно, необходимо использовать метод setForeground() из API WLPush. Убедитесь, что ваш общий уровень активностей содержит код, показанный в листинге 24. Например, это может быть специальный класс, расширяющий класс Activity, который используется в вашем приложении.

    Листинг 24. ActivityWrapper.java
           @Override 
           protected void onPause() { 
           super.onPause(); 
           if (WorklightUtils.getInstance(this).getPushClient() != null) { 
           WorklightUtils.getInstance(this).getPushClient().setForeground(false); 
           } 
           } 
    
           @Override 
           protected void onResume() { 
           super.onResume(); 
           if (WorklightUtils.getInstance(this).getPushClient() != null) { 
           WorklightUtils.getInstance(this).getPushClient().setForeground(true); 
           } 
           }

    getPushClient — это вспомогательный метод внутри WorklightUtils, который возвращает текущий экземпляр WLPush (листинг 25).

    Листинг 25.
           public WLPush getPushClient() { 
           return (client != null) ? client.getPush():null; 
           }

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

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

Листинг 26.
     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

Листинг 27.
     [?] 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=1021143
ArticleTitle=Push-уведомления: добавьте в нативное мобильное Android-приложение возможность подписки на push-уведомления
publish-date=11162015