Как проверить нотификации в приложении
Какие именно устройства должно быть нотифицированы? Таможенные органы поясняют так: под требование о предоставлении нотификации попадают планшетные компьютеры, ноутбуки, смартфоны. Различные медиа-плееры, умные часы, bluetooth-гарнитуры под требование о нотификации не попадает. Также не попадают обычные сотовые телефоны (не-смартфоны). Подробно о нотификации можно почитать тут.
Для того, чтобы понять, имеет ли ваше устройство нотификацию, можно осуществить поиск в базе данных на этом сайте по производителю или по наименованию модели. По наименованию модели устройство найти не всегда просто, поскольку производитель может написать его по-разному, или вообще подать нотификацию на всю серию. Поэтому иногда приходится "поиграться" с фильтрами.
Если Вы уверены, что устройство официально поставляется в Россию, значит, с нотификацией на него все в порядке. Можете даже не тратить время на перепроверку. Но если устройство новое или редкое - обязательно пробейте его по базе, иначе проблем Вам не избежать.
Итак, Вы решили купить Nexus или умные часы Moto 360 на Google Play. Примеры, как искать Nexus в базе нотификаций:
1. Вы хотите найти нотификацию на Nexus 5. Поиск по наименованию "Nexus" вам ничего не даст. Вы знаете, что производитель LG, и что он использует альтернативное наименовании модели: D821. Поэтому нужно делать поиск с использованием двух фильтров: по производителю и номеру модели. В этом случае декларировать устройство надо не по маркетинговому наименованию модели, а по тому, которое указано в нотификации. А то придется доказывать, что это одно и то же.
2. Вы хотите найти нотификацию на Nexus 7. Ищете по производителю Asus и модели Nexus и видите, что Asus подает нотификации на свои устройства целыми сериями. То есть, на любые устройства производства Asus с названием Nexus (даже еще не вышедшие) уже подана нотификация, и действует она до конца 2016 года.
У меня есть нотификации (уведомления) которые приходят от GCM. Даже если моя программа закрыта, я кликаю на нотификашку и открываю прогу. В ней чищу кое-какие данные в бд, и показываю кое-что на экране.
Если пользователь получил уведомление, когда программа была закрыта, и не нажал на него, но потом открыл программу обычным способом, необходимые действия не выполняются.
Как мне определить при запуске программы, выводились уведомления или нет, если да, то каким образом?
Всё намного проще, чем пишут другие. Когда вы создаёте Notification, вы передаёте ему Intent, который содержит информацию о том, какую Activity запустить при клике на Notification.
Так вот, достаточно просто добавить в этот Intent какие-нибудь данные о том, что это запуск из Notification, например так:
Чтобы проверить это значение, делаем так:
В onCreate() у HomeActivity добавляем
Обычно, приложение получает уведомление через BroadcastReceiver . Можно из этого ресивера инициировать запись некой настройки.
Когда пользователь открывает программу "обычным способом", нужно проверить, есть ли запись о том что уведомление ждет
При этом когда пользователь открывает программу через уведомление, то этот код так же будет выполнен. Удачи!
в ваших рассуждениях есть 2 провала: 1) нотификацию можете размещать и не вы сами 2) запись в префы флага не поможет, потому, что если юзер "смахнет" нотификацию, то флаг в префах не перепишется - как быть в этом случае? Про 2) Скорее всего не важно, смахнет пользователь нотификацию или нет — если не рассматривать совсем диких юзкейсов, то действие по входу в активити все равно нужно будет выполнить. Про 1) не совсем понятно, а кто еще может размещать от имени "моего" приложения уведомления? И как это должно влиять на логику? @DeKaNszn, да спасибо. Но я хотел сказать о том, что это обычно этого не требуется. В дополнение я бы использовал бы статический ресивер, так как во время смахивания "нашего" приложения уже может не быть в живых.Мне кажется вот эта ссылка может помочь.
если вы прочитаете внимательно вопрос, поймете что оно итак получает нотификацию когда выключено. я нашел решение ниже отпишусь. спсВобщем всем спасибо за ответы. Ближе всех был @pepyakin Так как я юзаю БД у себя в проекте я сделал так. когда получаю нотификацию, то в своем сервисе делаю просто
тоесть тут моя проверка небольшая (открыто ли уже активити или нет). если открыто - я шлю обсервером нужное мне. если закрыто, то сохраняю данные нужные мне в БД. Дале два пути: 1. юзер тыкает на нотификацию 2. Юзер открывает через лаунчер В любом случае открывается активити, в котором я достаю данные из БД и если там чтото есть, делаю то что мне нужно. После этого очищаю табличку с этим данными. ВСЕ!)))
493 1 1 золотой знак 5 5 серебряных знаков 15 15 бронзовых знаковВообще штатными средствами для всех версий Android'а это сделать невозможно, остаются только хаки. Проблема в том, что к сервису управления нотификациями нет доступа штатными средствами.
Есть хак, через AccessibilityService , описан здесь, но проблема с ним, в том, что юзер должен сначала включить в телефоне этот сервис - то есть гарантии что это будет работать нет.
Второй вариант использование NotificationListener, но с ним проблема, что работает только для версии Android >= 4.3
Дальше остаются нудные варианты, если вы сами размещаете нотификацию, то можно в момент размещения нотификации где-то что-то сохранять, правда при этом совершенно неясно как убивать сохраненный флаг, когда юзер сам убьет нотификацию. А если не сами размещаете нотификацию, то тогда только хардкор типа вешать сервис, который просматривает список активных задач смотреть сервис нотификации, выискивать среди них свою нотификацию и все такое прочее.
В се просто, но не очень. В интернете куча статей про нотификации в иос. И в этом проблема - слишком много статей, часть из них уже не актуальны и большинство очень поверхностны. Поэтому, я решил добавить еще одну статью и хорошенько во всем разобраться.
Отправка соединений с помощью токена выглядит попроще - ей и займемся.
Вся логика будет реализована в классе Notifications . Перед началом работы с нотификациями импортируем UserNotifications
Запрашиваем разрешение у пользователя на отправку нотификаций. Для этого в классе Notifications добавляем метод
В классе AppDelegate добавим новое свойство notifications и вызовем метод requestAuthorisation при старте приложения
Создадим локальное уведомление. Для этого добавим метод scheduleNotification() в классе AppDelegate`. В нем будем задавать нотификации по расписанию.
Для создания уведомления используем класс UNMutableNotificationContent . Подробней о возможностях этого класса в документации.
Триггер для показа уведомления может срабатывать по времени, календарю или местоположению. Можно отправлять уведомления каждый день в определенное время или раз в неделю.
Мы будем слать уведомления по времени. Создадим соответствующий триггер.
Сначала создаем trigger - триггер, который будет срабатывать через 5 секунд. Задаем идентификатор для нашего уведомления id . Он должен быть уникальным для каждого уведомления.
Теперь у нас есть все, чтобы создать запрос на показ уведомления и добавить его в центр уведомлений UNUserNotificationCenter . Для этого делаем вызов notifications.add(request)
Осталось вызвать метод scheduleNotification(type: String) . В любой контроллер добавим делегат:
Добавим кнопку и по нажатию вызовем нужный метод
Если нажать кнопку, то через 5 секунд появится уведомление как на картинке. Не забывайте, что нужно свернуть приложение, чтобы увидеть уведомление.
На иконке появился бейджик. Сейчас он остается на всегда и не пропадает. Давайте это поправим - добавим несколько строчек кода в AppDelegate
При каждом запуске приложения количество непрочитанных уведомлений будет обнуляться.
Уведомления когда приложение не в бекграунде
Есть возможность получать уведомления, даже когда приложение на переднем плане. Реализуем протокол UNUserNotificationCenterDelegate . Для этого добавим новый экстеншен.
В документации по протоколу UNUserNotificationCenterDelegate сказано
Use the methods of the UNUserNotificationCenterDelegate protocol to handle user-selected actions from notifications, and to process notifications that arrive when your app is running in the foreground.
Нам нужно использовать метод func userNotificationCenter(UNUserNotificationCenter, willPresent: UNNotification, withCompletionHandler: (UNNotificationPresentationOptions) -> Void) про который написано
Asks the delegate how to handle a notification that arrived while the app was running in the foreground.
Это как раз то, чего мы хотим добиться. Подпишем класс Notifications под протокол UNUserNotificationCenterDelegate .
И укажем делегат перед вызовом метода requestAuthorisation() в классе AppDelegate .
При тапе на уведомление открывается приложение. Это поведение по умолчанию. Чтобы мы могли как-то реагировать на нажатия по уведомлениям - нужно реализовать еще один метод протокола UNUserNotificationCenterDelegate .
Действия для уведомлений
Чтобы добавить кастомные действий в уведомлениях, сначала нужно нужно добавить категории уведомлений.
Добавляем кастомные экшены в методе scheduleNotification() .
Теперь создаем категорию с уникальным идентификатором.
Метод setNotificationCategories() регистрирует нашу новую категорию в центре уведомлений.
Осталось указать категорию при создании нашего уведомления. В месте, где мы создаем экземпляр класса UNMutableNotificationContent , нужно установить параметр categoryIdentifier .
У нас появились кастомные действия. Их будет видно, если потянуть уведомление вниз. Но они пока ничего не делают.
Добавим обработку стандартных и кастомных действий в экстеншене.
UNNotificationDefaultActionIdentifier - срабатывает при нажатии по уведомлению. UNNotificationDismissActionIdentifier - срабатывает, когда мы смахиваем уведомление вниз. С Dismiss есть один неочевидный момент - он не будет работать, если при создании категории не указать опцию .customDismissAction :
На сайте документации есть две статьи по теме кастомных действий:
Для уведомлений можно устанавливать кастомные изображения. Добавим его в методе scheduleNotification(type: String)
Картинка должна быть в файлах проекта, не в папке Assets.xcassets. Иначе, метод Bundle.main.url вернет nil . Если все сделано правильно – уведомление будет выглядеть как-то так:
На этом с локальными уведомлениями все.
Для работы с такими уведомлениями вам нужен платный аккаунт разработчика.
Для отправки пуш-уведомлений необходимо выполнить дополнительные манипуляции. Схема ниже показывает нужные шаги.
Существует 2 вида пуш-уведомлений: тестовые(sandbox) и реальные(production). Для разных видов уведомлений используются разные APNs сервера.
Чтобы приложение могло зарегистрироваться для оправки соединения - нужно включить поддержку поддержку пуш-уведомлений. Проще всего это сделать с помощью Xcode. Раньше это был довольно замороченный процесс, но сейчас достаточно выбрать Push Notifications.
И сразу добавьте поддержку бэкграунд обработку задач. Должно быть как на картинке.
В настройках этого идентификатора уже должна быть указана поддержка пуш-уведомлений.
И в проекте появляется новый файл Notifications.entitlements. Этот файл имеет расширение .entitlements и называется как и проект.
Теперь нам нужно создать CertificateSigningRequest для генерации SSL сертификата пуш-уведомлений. Это делается с помощью программы Keychain Access
Скачайте сгенерированный сертификат и установите его в системе(просто кликните по нему). В программе Keychain Access должен показаться этот серт:
Отлично! Теперь экспортируем сертификат с помощью все той же программы Keychain Access. Нажимаем правой кнопкой по сертификату и выбираем экспорт:
При экспорте нужно выбрать расширение файла .p12. Этот экспортированный сертификат понадобится нам в будущем.
Я назову ключ Push Notification Key. После создания ключа, обязательно скачайте его, нажав на кнопку Done
С подготовкой закончили, вернемся к коду. В методе getNotificationSettings() регистрируем наше приложение в APNs для получения пуш-уведомлений.
Теперь в классе AppDelegate нужно добавить пару методов. Получаем девайс токен:
Этот токен нам нужен для отправки уведомлений. Он работает как адрес приложения. В реальном приложении мы отправим его наш бекенд и сохраним в базе.
Обработаем ситуацию когда что-то пошло не так и нам не получилось зарегистрироваться в APNs.
Забавно, но у меня ничего не заработало сразу. Ни метод didRegisterForRemoteNotificationsWithDeviceToken , ни didFailToRegisterForRemoteNotificationsWithError не срабатывали. Я потратил на поиск проблемы несколько часов, пока случайно не наткнулся на это обсуждение. Выключите и включите вай-фай. Да. Не спрашивайте.
Все готово для отправки и получения уведомлений. Давайте протестируем.
Приложений для тестирования уведомлений целая куча, но мне больше всего нравится PushNotifications. Переключитесь на вкладку TOKEN и укажите нужные данные.
- f6c10036b6203ebf40a246ce5a741c3b17778063c78aa1016c6474d3dfef46e2 – Токен, который мы получаем при запуске приложения. Он выводится в консоль.
- YYS33CP3HU – Идентификатор ключа, который мы сгенерировали выше и назвали Push Notification Key
- 25K6PDW2HY – Team ID, идентификатор аккаунта разработчика
Тело самого уведомления - обычный JSON
alert может быть объектом с заголовком и телом. В уведомление можно указывать звук, бейдж. thread-id позволяет группировать уведомления. Ключ category позволяет использовать кастомные экшены. content-available обозначает досупность обновления для уведомления в бэкграунд режиме.
Для отправки нотификаций можно использовать не только .p8 ключ, но и наш SSL сертификат, который мы сгенерировали ранее. Для этого в приложении PushNotifications есть вкладка CERTIFICATE. Она работает точно так же, только нужно использовать сертификат .p12, указать пароль и не нужно указывать Team ID.
Обработка кастомных параметров
Для получения данных из пуш-уведомления нужно реализовать метод в AppDelegate .
Но этот метод позволяет получить данные уже после показа уведомления. А в iOS есть возможность кастомизировать контент уведомления с помощью экстеншенов. Например, можно задавать кастомную картинку для каждого уведомления. Для этого нужно создать расширение Notification Content Extension как показано на скриншотах.
Также, можно менять данные в нотификациях перед их показом с помощью Notification Service Extension. Но тема создания таких расширений слишком обширна и тянет на отдельную статью.
Используем Go библиотеку
И теперь самое простое - отправка уведомлений с использованием Go. Уже есть множество готовых библиотек, нам нужно выбрать самую удобную и научится с ней работать.
Мне больше всего понравился пакет APNS/2. В этом пакете уже есть готовая консольная утилита для отправки уведомлений. И у него очень простое АПИ.
В предыдущей статье мы говорили о выборе устройств, подготовке тестовой документации. А сегодня расскажем, на что стоит обратить внимание при тестировании, дадим советы, которые упростят жизнь мобильного тестировщика, в первую очередь – начинающего.
Интернет-соединение
Как проверить работу приложения при различном интернет-соединении? Не нужно, сидеть и ждать, пока на стороне провайдера случится сбой и соединение пропадет. Есть вариант получше. Используйте утилиту Charles, которая позволяет эмулировать разный уровень сигнала и прерывать его. Главное, чтобы ваш ПК и телефон были подключены к одной сети.
Помимо проверок прерывания и медленного соединения, надо еще знать, какие места приложения тестировать.
Проверьте, как обрабатывается разрыв соединения на различных страницах; попробуйте войти в приложение при выключенном соединении; обратите внимание на то, как ведет себя приложение при выполнении каких-то процессов, например, во время обработки платежа.
Также нельзя забывать про мобильный интернет и переключение между ним и Wi-Fi. Так как телефон – это, в первую очередь, носимый гаджет, то очень часто возникают ситуации, когда происходит смена подключений во время работы приложения. Проверку прерывания приложения нужно делать не один раз, а покрывать все процессы приложения.
Важно различать нотификации сторонних приложений и системные, так как они обрабатываются по-разному. Сторонние приложения – скайп, будильник – позволяют быстро сэмулировать нотификацию; системные приложения могут оповещать о недостаточном уровне заряда или наличии обновлений, и их нотификации сэмулировать немного сложнее.
Также необходимо проверять переход в режим ожидания автоматически и после намеренной блокировки экрана пользователем. Как и все проверки, это необходимо делать во время работы с основной функциональностью приложения, поскольку блокировка может значительно влиять на обработку процессов.
Стоит отдельно упомянуть звонки. Обязательно проверяйте не только, как ваше приложение реагирует на завершение вызова, но и когда звонок находится в фоне, то есть с приложением продолжают работать.
Анализ работы приложения на подзарядке
Подключите устройство к подзарядке. Проверьте, не снижается ли производительность, не нагревается ли устройство слишком сильно. Эта проверка особенно актуальна для приложений, связанных с геолокацией (навигаторы, сервисы по заказу такси), а также игр, поскольку пользователи часто ставят на зарядку устройство во время игрового сеанса.
Тестирование при нехватке памяти
Смартфон – это давно уже не просто телефон, а устройство для хранения музыки, фото, документов. Проблемы нехватки памяти возникают у пользователей регулярно. Обязательно проверьте установку приложения и обновление его файлов, когда память устройства переполнена и когда ее осталось совсем немного.
Здесь у вас может возникнуть вопрос: как заполнить 250 гб памяти айфона?
Конечно, всегда можно снять 250 гб видео и стать популярным блоггером, но у кого время ограничено есть способ проще: создайте в командной строке «липовые» файлы нужного размера (команда FSutil), после этого с помощью iTunes перенесите их на девайс.
И не забывайте освобождать память после завершения тестирования. Коллеги будут вам благодарны.
Учитываем гайдлайны Android и iOS
Очень важно делать проверки на соответствие гайдлайнам ОС. Это снизит вероятность того, что приложение не будет допущено для размещения в сторе. Повторное размещение приложения требует времени. Если, к примеру, время обработки запроса на добавление в Google Play занимает пару часов, то Apple Store может рассматривать его в течение двух недель. И будет обидно, если после этих 2 недель ваше приложение будет отклонено из-за какой-то мелочи. У нас на проекте был пример того, когда приложение отклонили из-за того, что иконка на устройстве незначительно отличалась от иконки в магазине. И Apple посчитал, что это будет вводить пользователей в заблуждение.
Гайдлайны можно посмотреть на официальных сайтах Apple и Google.
В качестве десерта
После успешного тестирования настала пора собирать трофеи. Приложение выпущено в релиз, пользователи ставят высокие оценки. Что может быть приятнее?
Но даже сейчас не стоит расслабляться. Может случиться, что на некоторых устройствах что-то пойдет не так, и будут выскакивать ошибки. Поэтому периодически просматривайте отзывы пользователей в магазинах приложений и оперативно реагируйте на возможные дефекты. Да, работа тестировщика требует бдительности. Не забывайте об этом.
Читайте также: