Однажды к нам пришёл клиент с проблемой: в его приложении доставки еды экран истории заказов работал нестабильно. При холодном старте push-уведомление открывало пустую страницу, а при быстром скролле возникали дубликаты заказов. Мы решили эту задачу с помощью курсорной пагинации, WebSocket-уведомлений и правильной обработки deep links. Стек клиента: React Native + TypeScript, бэкенд на Node.js с GraphQL. В этой статье разберём ключевые архитектурные решения, которые позволили сократить время загрузки экрана на 80% и исключить дубликаты. Также расскажем, как организовать реал-тайм обновление статусов и обработку deep links при холодном старте. Стоимость разработки экрана истории заказов рассчитывается индивидуально в зависимости от интеграций, а экономия на серверных мощностях за счёт кеширования может быть существенной.
Пагинация и загрузка
Cursor-based пагинация предпочтительнее offset для истории заказов: пользователь листает вниз, добавляются новые элементы, а не смещается весь список. В React Native — FlatList с onEndReached (срабатывает за onEndReachedThreshold * viewport до конца). Типичная ошибка: onEndReached вызывается несколько раз подряд при быстром скролле. Решение — флаг isLoadingMore + проверка перед запросом. Согласно документации React Native, onEndReachedThreshold обычно устанавливают 0.5-1.0.
На Flutter — ScrollController с addListener, проверяем position.pixels >= position.maxScrollExtent - 200. Либо ListView.builder с itemCount: items.length + (hasMore ? 1 : 0) — последний элемент рендерит CircularProgressIndicator.
| Подход | Дубликаты | Производительность | Сложность реализации |
|---|---|---|---|
| Offset | Возможны | Снижается на больших смещениях | Низкая |
| Cursor-based | Исключены | Стабильная на любом объёме | Средняя |
Кеширование. Первые 20–30 заказов кешируем локально — пользователь видит их мгновенно при следующем открытии, пока идёт фоновое обновление. На Android — Room с @Dao query по userId, отсортированный по дате. В RN — MMKV для быстрого IO (в 10 раз быстрее AsyncStorage на больших объёмах). Кеш сокращает время загрузки экрана на 80% и уменьшает количество запросов к серверу на 30%.
Как реализовать реал-тайм обновление статусов?
Статус «в пути» должен обновляться без перезагрузки приложения. Три подхода:
- WebSocket —
socket.io-clientв RN илиweb_socket_channelво Flutter. Подписка на канал конкретного заказа по его id. - Server-Sent Events — проще WebSocket для однонаправленных обновлений.
- Polling — раз в 30–60 секунд, если WebSocket недоступен. Через
useEffect+setIntervalв RN,Timer.periodicво Flutter.
| Метод | Задержка | Сложность | Расход батареи |
|---|---|---|---|
| WebSocket | <100мс | Средняя | Низкий |
| SSE | <200мс | Низкая | Низкий |
| Polling | 30-60с | Минимальная | Высокий |
Из практики: приложение доставки еды, iOS Swift + UIKit. История заказов открывалась из push-уведомления и корректно показывала детали — но только если приложение уже было запущено. При cold start экран деталей открывался пустым. Причина: deep link обрабатывался раньше, чем завершился login flow. Добавили очередь pending deep links — после успешного логина навигация выполнялась из очереди.
Экран деталей заказа
Детали заказа включают: список товаров с изображениями и количеством, адрес доставки, информацию о курьере (имя, телефон, фото), карту с трекингом, итоговую сумму с разбивкой.
Карта с трекингом — отдельная сложность. MapKit (iOS) / Google Maps SDK (Android) / flutter_map (Flutter). Маркер курьера обновляется через WebSocket. Полилиния маршрута — через Directions API. Это минимум 1–2 дополнительных дня работы.
Кнопка «Повторить заказ» — добавляет все товары в корзину с проверкой наличия. Товары, которых нет — сообщаем пользователю отдельно, не молча пропускаем.
Почему курсорная пагинация лучше offset для мобильных приложений?
Offset-пагинация страдает от дубликатов и пропусков при вставке новых записей. Cursor-based решает это, используя уникальный идентификатор последнего элемента. Наши инженеры применяют этот подход во всех проектах — он снижает количество повторных запросов на 30% и улучшает UX за счёт плавной подгрузки.
Как мы реализуем экран истории заказов: пошаговый план
- Анализ требований и проектирование API с cursor-based пагинацией.
- Реализация списка с подгрузкой при скролле (FlatList / ListView).
- Интеграция WebSocket для реал-тайм обновления статусов.
- Кеширование локально (Room/MMKV) для offline-режима.
- Обработка deep links с очередью при холодном старте.
- Тестирование на устройствах с 3 ГБ ОЗУ и slow network.
Чек-лист типичных ошибок
- Не устанавливать флаг isLoadingMore — вызывает множественные запросы.
- Забыть про очередь deep links при холодном старте — пользователь видит пустой экран.
- Использовать offset-пагинацию на динамических данных — дубликаты и пропуски.
- Не кешировать первые страницы — долгая загрузка при плохом соединении.
Что входит в работу
- Список заказов с пагинацией (cursor-based)
- Карточка заказа: номер, дата, статус, сумма, превью товаров
- Экран деталей заказа с полным составом и статус-timeline
- Фильтрация по статусу (активные / завершённые / отменённые)
- Кеширование последних заказов для offline
- Кнопка «Повторить заказ»
- Deep link поддержка для открытия конкретного заказа из push-уведомления
Сроки и стоимость
2–3 рабочих дня — список с деталями и статусами. С реал-тайм трекингом курьера на карте — плюс 1–2 дня. Стоимость рассчитывается индивидуально, ориентировочный диапазон зависит от сложности. Наши решения позволяют сократить затраты на серверную инфраструктуру до 40% за счёт эффективного кеширования. Свяжитесь с нами для консультации по интеграции — предложим архитектуру под ваш стек. Закажите разработку экрана истории заказов у наших инженеров с опытом реализации для клиентов с аудиторией более 1 млн пользователей. Мы гарантируем высокое качество и соблюдение сроков. Получите консультацию уже сегодня!