Розробка мобільного додатку для петицій
Додаток для петицій — це інструмент громадянської дії: користувачі створюють звернення, збирають підписи, відстежують прогрес. Технічно задача зводиться до надійної системи аутентифікації, захисту від накрутки підписей та прозорого відображення даних.
Захист від накрутки: найважливіше
Підписи під петицією мають юридичну та громадську значущість. Одна підпис = один верифікований людина — це вимога, яку потрібно вирішувати на кількох рівнях.
Верифікація телефону. SMS з OTP через Twilio Verify або Firebase Phone Auth. Один номер — одна підпис на петицію. FirebaseAuth.verifyPhoneNumber() на клієнті, на сервері — перевірка uid з Firebase token. Захист від автоматичних реєстрацій: rate limiting на рівні API gateway (максимум 3 запити за хвилину з одної IP на endpoint верифікації).
Email верифікація як додатковий шар. sendEmailVerification() у Firebase Auth. Невeрифікований 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) — навіть якщо клієнт відправив два запити одночасно.
Лічильник підписів в реальному часі — 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 при зміні статусу.
Прогрес та дедлайн
Progress-бар до цілі підписів — UIProgressView (iOS) / LinearProgressIndicator (Compose). Дедлайн петиції — DateComponentsFormatter для відображення «осталось 3 дня», CountdownTimer на екрані з відлічуванням останніх годин.
По істеченню дедлайну петиція переходить у статус closed. Якщо ціль досягнута — статус successful, пакетне сповіщення всім підписавшимся з закликом розповсюджувати результат.
Sharing
Петиція повинна легко шеритись. Динамічні посилання (Firebase Dynamic Links або Branch.io) відкривають конкретну петицію в додатку або на веб-сторінці — через UIActivityViewController (iOS) або Intent.ACTION_SEND (Android). Open Graph теги для превью в мессенджерах — на стороні web-сторінки.
Терміни
Список петицій + перегляд + підпис з верифікацією телефону — 3–5 тижнів. Створення петицій + модерація + real-time лічильник + sharing — 2–3 місяці. Вартість розраховується після аналізу вимог.