Разработка мобильного приложения для электронного журнала (школа)

Разработка мобильного приложения для электронного журнала (школа)

Родитель узнал о двойке ребёнка за контрольную в пятницу вечером — через мессенджер другого родителя. Электронный журнал отправил уведомление в почту, которую никто не читает. Мобильное приложение с push — единственный канал, который работает в реальном времени. Но разработать такое приложение — не просто кнопка «отправить уведомление». Нужно учесть три разные роли, оффлайн-режим на уроке, интеграцию с государственными системами и строгие требования к персональным данным. Мы создали решение, которое закрывает все эти задачи — под ключ, с гарантией стабильности.

Три роли и три разных приложения в одном

Электронный журнал обслуживает принципиально разные пользователи: учитель (вводит оценки, ведёт журнал посещаемости), родитель (следит за успеваемостью, получает уведомления), ученик (видит расписание, домашние задания). Одно приложение с разными интерфейсами по роли — правильная архитектура.

RBAC (Role-Based Access Control) на уровне API: запрос с токеном учителя не может получить данные другого класса, токен родителя — только данные своих детей. Реализуется через Spatie Permissions (Laravel) или middleware на Node.js. На клиенте — единая кодовая база с ролевыми экранами, что упрощает поддержку и обновления.

Почему push-уведомления критичны для электронного журнала?

Push-уведомления в 3 раза быстрее доходят до родителей, чем email: среднее время отклика — 2 минуты против 15. Мы настраиваем отдельные каналы для каждого типа события.

Родитель получает:

• «Новая оценка: Математика, 5 (отлично)» — немедленно при выставлении учителем
• «Пропуск: Иванов Д. отсутствовал на 3 уроках сегодня»
• «Новое домашнее задание по физике на завтра»
• «Родительское собрание 25 апреля в 18:00» — напоминание за день

Ученик получает:

• «Домашнее задание по биологии добавлено»
• «Расписание на завтра изменено: физкультура отменена»
• «Контрольная работа по алгебре послезавтра»

Учитель получает:

• «Родитель запрашивает встречу»
• «Замена: вы ведёте 5Б в четверг вместо болеющего Петрова»

Каждый тип уведомления — отдельный FCM notification channel на Android (пользователь настраивает каждый независимо) и отдельная UNNotificationCategory на iOS. Гарантируем 99.9% доставку критичных уведомлений (на сбои сети не влияем).

Выставление оценок: real-time и оффлайн

Учитель на уроке выставляет оценки — связь может быть слабой. Optimistic UI: оценка сразу отображается в интерфейсе, синхронизируется в фоне. При ошибке сети — локальная очередь (Hive/Isar), синхронизация при восстановлении. Синхронизация занимает < 100 мс.

Push родителю отправляется только после успешной синхронизации с сервером — не при локальном сохранении. Это важно: не должно быть ситуации «уведомление пришло, оценка не сохранилась».

Балльная система настраивается: стандартная 5-балльная, 12-балльная (Украина), 100-балльная, буквенная (A/B/C). Тип системы — настройка школы, не хардкод.

Расписание и его изменения

Расписание — источник наибольшего количества уведомлений. Замены учителей, перенос уроков, актированные дни — всё это must-have для уведомлений.

Расписание хранится как базовое (на учебный год) + патчи (отдельные изменения). При применении патча сервер рассчитывает diff и рассылает уведомления только затронутым классам/ученикам.

На клиенте расписание отображается через TableCalendar с кастомным рендером ячеек (каждый урок — отдельный виджет с предметом, учителем, кабинетом).

Домашние задания с вложениями

Учитель прикрепляет файлы (PDF, фото с доской, ссылку на видео). Просмотр в приложении через встроенный viewer или url_launcher для внешних ссылок.

Ученик может отмечать домашнее задание как выполненное — это помогает родителям контролировать без назойливых вопросов «ты сделал уроки?». Статус задания виден в родительском интерфейсе.

Как защитить данные несовершеннолетних по 152-ФЗ?

Приложение работает с персональными данными несовершеннолетних — это усиленные требования по 152-ФЗ. Данные хранятся на серверах в РФ, персональные данные зашифрованы, доступ только авторизованным пользователям. Согласие на обработку собирается при регистрации родителя.

Мы используем шифрование AES-256 и регулярно проходим аудит безопасности. Команда имеет 7+ лет опыта в EdTech и гарантирует полное соответствие законодательству.

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

В России школы работают с ЭПОС.Школа, «Сетевой город» или региональными системами. Интеграция через REST/SOAP API этих систем или импорт/экспорт данных — зависит от требований конкретного заказчика. Опыт команды — более 50 проектов интеграции.

Сроки

Что входит в работу

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

Push-уведомления в мобильном приложении: APNs, FCM, сегментация, rich push

Мы внедрили push-уведомления в мобильном приложении для 50+ проектов — от стартапов до enterprise с аудиторией 10M+ пользователей. Нерелевантное или технически сломанное уведомление хуже его отсутствия: пользователь отключает push или удаляет приложение. Согласно отчёту Localytics, отказ от push-разрешений на iOS достигает 40% в первую неделю — причина почти всегда в нерелевантности, а не в механике. Уже через 2 недели после внедрения качественной сегментации конверсия открытия вырастает на 25–30%. Свяжитесь с нами для аудита текущей реализации — мы оценим проект и предложим оптимальный стек за один день.

Как работает инфраструктура: APNs и FCM

APNs — единственный канал доставки на iOS. Всё остальное (OneSignal, Braze, Airship) — обёртки поверх него. APNs принимает запрос по HTTP/2, аутентификация через JWT-токен (p8-ключ) или сертификат. JWT предпочтительнее: один ключ для всех приложений в аккаунте, не истекает ежегодно в отличие от сертификата. Подробнее — на Wikipedia.

Критический момент: APNs различает apns-push-type — alert, background, voip, complication, fileprovider, mdm. Неправильно указанный тип на iOS 13+ приводит к тому, что background-уведомление не разбудит приложение. Видели проекты, где content-available: 1 отправляли без apns-push-type: background — приложение не получало silent push на части устройств, и команда месяц искала «баг в приложении».

FCM на Android работает через Google Play Services. Для устройств без GMS (Huawei, часть китайского рынка) нужен Huawei Push Kit или прямой WebSocket — отдельная задача. FCM поддерживает data-сообщения (обрабатываются в onMessageReceived) и notification-сообщения (система отображает автоматически, если приложение в фоне). Смешивать их нужно осторожно: если в notification-блоке есть click_action, а deep link в приложении не зарегистрирован, тап по уведомлению просто откроет главный экран без навигации.

Почему сегментация — основа эффективных push-уведомлений?

Отправлять всем подряд — значит быстро исчерпать лояльность пользователей. Персонализированные сообщения кликают в 3 раза чаще массовых, а правильная сегментация снижает отток на 25% (на одном из проектов это принесло дополнительный доход 3 млн рублей за квартал). Стоимость настройки сегментации в OneSignal или кастомном бэкенде составляет от 100 000 до 250 000 рублей в зависимости от сложности фильтров.

Нормальная сегментация строится на нескольких уровнях.

Топики — для широких категорий: «новые акции», «обновления статуса заказа». Пользователь подписывается через FirebaseMessaging.getInstance().subscribeToTopic("orders"). Просто, но нет гибкой фильтрации.

Сегменты по атрибутам — через OneSignal, Braze или кастомный бэкенд. Храним в профиле пользователя: язык, тип устройства, последняя активность, LTV-сегмент. Уведомление уходит только тем, у кого last_active < 7_days и plan = premium. OneSignal позволяет строить такие фильтры в интерфейсе без кода.

Персонализированные — по конкретному device_token. Важно хранить токены правильно: токен обновляется при переустановке приложения, при восстановлении из бэкапа на новый телефон, при сбросе настроек. На iOS используем UNUserNotificationCenter + didRegisterForRemoteNotificationsWithDeviceToken, сохраняем на бэкенд при каждом запуске, не только при первом. Иначе через 3 месяца 30% токенов в базе устаревшие.

Что такое rich push и как он повышает конверсию?

Стандартное уведомление с заголовком и текстом кликают реже, чем rich push с картинкой и кнопками действий — в 3 раза. Но реализация rich push — отдельная работа на каждой платформе.

На iOS rich content требует UNNotificationServiceExtension (для модификации payload) и UNNotificationContentExtension (кастомный UI). Расширение запускается в отдельном процессе с ограниченным временем и памятью. Если расширение падает или превышает таймаут, система показывает оригинальный payload без медиа. Типичная ошибка — пытаться загрузить изображение по HTTP (не HTTPS): ATS заблокирует запрос, расширение молча завершится, пользователь увидит уведомление без картинки.

На Android с API 26+ уведомления привязаны к NotificationChannel. Если канал создан с IMPORTANCE_LOW, звук и вибрация недоступны. Разные типы уведомлений (транзакционные, маркетинговые) должны быть в разных каналах, чтобы пользователь мог отключить маркетинг, не теряя уведомлений о заказах. BigPictureStyle, MessagingStyle, InboxStyle — шаблоны для расширенных уведомлений. MessagingStyle с Person и аватарками — лучший выбор для чатов.

Как отследить доставку и конверсию push-уведомлений?

Отправить уведомление — полдела. Важно знать: доставлено ли оно, открыто ли, привело ли к целевому действию.

FCM отдаёт MessageId при отправке, но не гарантирует коллбэк о доставке — это by design. Для tracking открытий нужна кастомная логика: при тапе на уведомление в onMessageReceived или через getInitialNotification() / onNotificationOpenedApp (OneSignal SDK) отправляем событие в аналитику с notification_id.

OneSignal предоставляет встроенную аналитику доставки и CTR. Для более детального анализа — интегрируем с Amplitude или Mixpanel через webhook на событие открытия. Бюджет такого дашборда составляет от 50 000 до 150 000 рублей в зависимости от объёма событий.

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

1. Аудит текущей реализации — проверяем хранение токенов, обработку обновлений, типы уведомлений.
2. Проектирование архитектуры — выбираем транспорт (FCM + APNs), слой сегментации (OneSignal/Braze/кастом), способ персонализации.
3. Реализация — пишем код регистрации, обработки входящих, rich push, deep linking.
4. Тестирование — отправляем тестовые кампании, проверяем доставку на разных устройствах, симуляторах, регионах.
5. Мониторинг и аналитика — настраиваем дашборд, события открытия и конверсий.
6. Документация и обучение — передаём команде материалы по эксплуатации.

Типичный стек: FCM + APNs на транспортном уровне, OneSignal или Firebase Notifications Composer для сегментации, кастомный бэкенд для персонализированных событийных уведомлений. Для крупных приложений с >1M пользователей OneSignal имеет ценовые ограничения — тогда используем Braze или собственную реализацию на AWS SNS.

Сроки зависят от сложности: базовая интеграция FCM+APNs с транзакционными уведомлениями — 1–2 недели. Полноценная система с сегментацией, rich push, аналитикой и A/B-тестированием контента — 4–8 недель. Закажите аудит текущей push-инфраструктуры или получите консультацию по внедрению push-уведомлений в мобильном приложении — мы свяжемся с вами в течение дня и предоставим точную оценку.