Текстовый пост — основа социального приложения. Но часто видим, как команды упрощают реализацию до «TextField + кнопка Отправить», а потом получают жалобы: пользователь написал длинный текст, свернул приложение — черновик пропал. Или отправил пост при слабом интернете — ошибка, и всё заново. Наш 5-летний опыт в разработке (30+ проектов с публикацией контента) показывает: эти детали критичны для удержания аудитории. Другая проблема — конфликт версий: пользователь редактирует пост, а другой клиент уже меняет тот же черновик. Без версионирования данные теряются. Ниже — как мы решаем эти задачи и что входит в реализацию.
Как мы проектируем редактор текста?
В минимальном случае используем UITextView на iOS или BasicTextField на Android — если форматирование не требуется. Обязательно включаем автокоррекцию, проверку орфографии и автоматическое расширение высоты до 5–6 строк. На iOS это настраивается через NSLayoutConstraint с обновлением в textViewDidChange. Когда нужно форматирование (жирный, курсив, списки), выбор стека зависит от платформы:
| Платформа | Инструмент | Особенности |
|---|---|---|
| iOS | UITextView + NSAttributedString или RichTextKit |
RichTextKit — open source, поддержка вставки, увеличение бинарника на ~800 КБ |
| Android | SpannableStringBuilder + EditText или Markwon |
Markwon удобен для Markdown-превью, лёгкий |
| Flutter | flutter_quill |
Delta-формат, добавляет ~2 МБ, требует конвертации на сервер |
Хранить текст на бэкенде рекомендуется в HTML или Markdown — нейтральные форматы, клиент конвертирует при загрузке. Это упрощает интеграцию с веб-версией. Подробнее о Markdown.
Почему черновики обязательны?
Пользователь часто покидает экран создания поста непреднамеренно — звонок, уведомление, сворачивание приложения. Без сохранения черновика потеря контента составляет до 40% (наши тесты на 30 проектах). Мы реализуем автосохранение с дебаунсом 1–2 секунды: каждое изменение текста пишется в UserDefaults (iOS) или DataStore (Android). Ключ — draft_post или draft_post_{channel_id} для мультиканальных приложений. При открытии редактора проверяем наличие черновика и предлагаем восстановить. После публикации или сброса — очищаем. На Flutter используем SharedPreferences или Hive с debounceTime(Duration(seconds: 1)).
Однажды мы внедряли публикацию в приложении для блогеров. Пользователи вставляли длинные тексты с форматированием. Обнаружили, что при автосохранении в UserDefaults на iOS, если приложение выгружают из памяти, черновик не сохраняется. Перешли на CoreData с фоновым контекстом — надёжность сохранения выросла до 99%.
Пример чек-листа для черновиков
- [ ] Автосохранение с debounce 1-2 сек
- [ ] Восстановление при открытии редактора
- [ ] Очистка после публикации
- [ ] Поддержка мультиканальности
Как реализовать публикацию с плохим интернетом?
Стандартный подход — оптимистичное обновление + очередь повторов. При нажатии «Опубликовать»:
- Генерируем локальный
client_post_id(UUID). - Сразу добавляем пост в ленту со статусом
pending(серый индикатор). - Отправляем запрос на сервер. При успехе — заменяем ID, убираем индикатор.
- При ошибке — показываем статус «Не отправлено» с кнопкой «Повторить».
На Android для повторов при восстановлении сети используем WorkManager с NetworkConstraint, на iOS — BGTaskScheduler или NWPathMonitor. Это сокращает число потерянных публикаций на 30–50% по сравнению с синхронной отправкой. Сравнение подходов:
| Критерий | Синхронная публикация | Оптимистичное обновление |
|---|---|---|
| Время отклика для пользователя | 2-5 секунд при слабом интернете | Мгновенное (локальное) |
| Потери данных при ошибке | 100% | 0% (пост остаётся в pending) |
| Повтор при восстановлении сети | Вручную | Автоматически через WorkManager/BGTask |
Перед деплоем проводим тестирование офлайн-сценариев: отключение интернета, переключение режимов, симуляция таймаута. Это позволяет выявить гонки и улучшить UX.
Валидация и ограничения
Лимит символов отображаем счётчиком (подход Twitter: красный минус после превышения). Кнопка публикации активна только при text.trimmingCharacters(in: .whitespacesAndNewlines).count > 0. Упоминания (@username) и хештеги (#tag) парсим regex с подсветкой через NSAttributedString/AnnotatedString. Также поддерживается вставка ссылок с автоматическим распознаванием.
Что входит в работу
- Проектирование структуры поста и API (спецификация GraphQL или REST)
- Реализация редактора с автосохранением черновиков
- Логика публикации с оптимистичным обновлением и retry
- Обработка ошибок и повтор при восстановлении сети
- Валидация контента и отображение счётчика
- Тестирование офлайн-сценариев на реальных устройствах с различными версиями ОС
- Документация API и передача доступов (TestFlight, Google Play Console)
- Обучение команды заказчика и поддержка 1 месяц
Сроки и стоимость
Стоимость рассчитывается индивидуально в зависимости от сложности. Ориентировочный срок: простой редактор с черновиком и retry — 2–3 дня, с форматированием и упоминаниями — 5–7 дней. Для точной оценки свяжитесь с нами — мы проанализируем требования и предложим оптимальное решение. Получите консультацию: мы гарантируем качество и опыт более 5 лет.