Разработка мобильного приложения для петиций
Приложение для петиций — это инструмент гражданского действия: пользователи создают обращения, собирают подписи, отслеживают прогресс. Технически задача сводится к надёжной системе аутентификации, защите от накрутки подписей и прозрачному отображению данных.
Защита от накрутки: самое важное
Подписи под петицией имеют юридическую и общественную значимость. Одна подпись = один верифицированный человек — это требование, которое нужно решать на нескольких уровнях.
Верификация телефона. SMS с OTP через Twilio Verify или Firebase Phone Auth. Один номер — одна подпись на петицию. FirebaseAuth.verifyPhoneNumber() на клиенте, на сервере — проверка uid из Firebase token. Защита от автоматических регистраций: rate limiting на уровне API gateway (максимум 3 запроса в минуту с одного IP на endpoint верификации).
Email верификация как дополнительный слой. sendEmailVerification() в Firebase Auth. Неверифицированный email — нет права подписи.
Biometric confirmation для повторных подписей: если пользователь подписывает несколько петиций подряд, просим подтвердить через Face ID / Touch ID (LocalAuthentication.evaluatePolicy(.deviceOwnerAuthenticationWithBiometrics)). Это снижает риск случайных или автоматизированных действий.
На Android — BiometricPrompt из androidx.biometric. Всегда проверяем BiometricManager.canAuthenticate(BIOMETRIC_STRONG) перед показом — на эмуляторе и некоторых устройствах без сенсора это не SUCCESS.
Подписание: UX и технические детали
Форма подписи — минимум полей. Имя, локация (опционально, по согласию), email или телефон. Длинные формы снижают конверсию. На Android autofillHints в TextInputLayout заполняет данные из менеджера паролей.
Подпись сохраняется немедленно через URLSession / OkHttp с оптимистичным обновлением счётчика на UI. Если запрос упал — откатываем счётчик и показываем retry. Дублирование на стороне сервера предотвращается уникальным индексом (petition_id, user_id) в PostgreSQL — даже если клиент отправил два запроса одновременно.
Счётчик подписей в реальном времени — WebSocket или Server-Sent Events. SSE проще: URLSessionStreamTask (iOS) или EventSource библиотека (Android). При достижении порогов (1000, 10000, 100000 подписей) — push-уведомление всем подписавшимся через FCM topic.
Создание петиции
Редактор — заголовок, описание (rich text через UITextView с базовым форматированием или Lexical в WebView), изображение обложки, категория, целевое число подписей, адресат (организация, депутат, компания).
Модерация петиций перед публикацией — очередь в admin-панели. Статусы: draft → pending_moderation → published / rejected. Авторы получают push при изменении статуса.
Прогресс и дедлайн
Прогресс-бар к цели подписей — UIProgressView (iOS) / LinearProgressIndicator (Compose). Дедлайн петиции — DateComponentsFormatter для отображения «осталось 3 дня», CountdownTimer на экране с отсчётом последних часов.
По истечении дедлайна петиция переходит в статус closed. Если цель достигнута — статус successful, отправляется пакетное уведомление всем подписавшимся с призывом распространить результат.
Sharing
Петиция должна легко шериться. Динамические ссылки (Firebase Dynamic Links или Branch.io) открывают конкретную петицию в приложении или на веб-странице — через UIActivityViewController (iOS) или Intent.ACTION_SEND (Android). Open Graph теги для превью в мессенджерах — на стороне веб-страницы.
Сроки
Список петиций + просмотр + подпись с верификацией телефона — 3–5 недель. Создание петиций + модерация + real-time счётчик + sharing — 2–3 месяца. Стоимость рассчитывается после анализа требований.