Как отправлял push уведомления на устройство

Как отправлял push уведомления на устройство

В моей практике отправка push-уведомлений была связана с интеграцией и тестированием взаимодействия между серверной частью приложения и сторонними Push Notification Services (PNS), такими как Firebase Cloud Messaging (FCM) для Android и Apple Push Notification Service (APNS) для iOS. Процесс включал несколько ключевых этапов, от подготовки серверной среды до валидации поведения клиентской части.

Архитектура и основные компоненты

Для отправки уведомлений необходимо понимать общую схему работы:

1. Backend Server: Наш сервер (например, на Node.js или Python) генерировал сообщение.
2. Push Notification Service (PNS): Сервер отправлял сообщение через официальный PNS (FCM/APNS).
3. Client Device: Мобильное приложение (Android/iOS) получало уведомление через свои системные сервисы.

Процесс отправки с сервера (Backend)

На сервере мы использовали официальные SDK или REST API PNS. Вот пример отправки через FCM REST API на Python:

import requests
import json

def send_fcm_push(device_token, title, body):
    # URL FCM API
    url = 'https://fcm.googleapis.com/fcm/send'
    
    # Заголовки с ключом авторизации сервера
    headers = {
        'Authorization': 'key=YOUR_SERVER_KEY_FROM_FIREBASE_CONSOLE',
        'Content-Type': 'application/json'
    }
    
    # Тело запроса (payload)
    payload = {
        'to': device_token,  # Токен конкретного устройства
        'notification': {
            'title': title,
            'body': body,
            'sound': 'default'
        },
        'data': {  # Дополнительные данные для приложения
            'custom_key': 'custom_value',
            'action': 'open_screen'
        }
    }
    
    response = requests.post(url, headers=headers, data=json.dumps(payload))
    return response.json()

Для APNS процесс был аналогичным, но требовал использования сертификатов или ключей (p8 файл) для аутентификации и другого формата payload.

Работа с токенами устройств

Критически важным элементом был Device Token (или Registration Token в FCM). Это уникальный идентификатор, который клиентское приложение получает от PNS и передаёт нашему серверу. Сервер хранит эти токены (часто в связке с user_id в БД) и использует их для целевой отправки. Токены могут меняться, поэтому необходимы механизмы их обновления на сервере.

Тестирование отправки и получения

Как QA Engineer, моя работа была сосредоточена на валидации всего цикла:

• Интеграционные тесты сервера: Проверял, что сервер корректно формирует запрос к PNS, обрабатывает ответы (успех, ошибки типа "InvalidRegistration") и логирует их.
• Функциональное тестирование на устройстве:

    *   Проверял, что приложение правильно регистрируется в PNS и отправляет токен на наш сервер.
    *   Валидировал получение уведомления: видимость в системной шторке, правильные **title**, **body**, **icon**.
    *   Проверял обработку **data payload**: при открытии уведомления приложение должно корректно парсить дополнительные данные и выполнять соответствующее действие (например, открыть конкретный экран).
    *   Тестировал различные сценарии: уведомления при запущенном и закрытом приложении, группировка уведомлений, настройки звука и вибрации.

• Тестирование граничных условий и ошибок:

    *   Отправка на невалидный/старый токен.
    *   Уведомления при отсутствии сети (должны быть получены позже).
    *   Проверка лимитов на размер payload (например, 4KB для FCM).
    *   Обработка состояния "Doze Mode" на Android.

Инструменты и утилиты для тестирования

Для упрощения процесса использовал:

• Консоль Firebase или Postman для быстрой отправки тестовых уведомлений через FCM API.
• Apple Developer Console и сторонние инструменты для тестовых отправок в APNS.
• Логирование на сервере и в мобильном приложении (с помощью adb logcat или Xcode Console) для отслеживания всего пути сообщения.

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