Разработка истории заказов в мобильном приложении

Разработка истории заказов в мобильном приложении

История заказов выглядит просто: список с карточками, статус, дата, сумма. Но за этой простотой скрывается несколько нетривиальных задач — пагинация с разными стратегиями загрузки, корректное отображение статусов с real-time обновлениями, и экран детали заказа, который нужно открывать в том числе из push-уведомления.

Пагинация и загрузка

Cursor-based пагинация предпочтительнее offset для истории заказов: пользователь листает вниз, добавляются новые элементы, а не смещается весь список. В React Native — FlatList с onEndReached (срабатывает за onEndReachedThreshold * viewport до конца). Типичная ошибка: onEndReached вызывается несколько раз подряд при быстром скролле. Решение — флаг isLoadingMore + проверка перед запросом.

На Flutter — ScrollController с addListener, проверяем position.pixels >= position.maxScrollExtent - 200. Либо ListView.builder с itemCount: items.length + (hasMore ? 1 : 0) — последний элемент рендерит CircularProgressIndicator.

Кеширование. Первые 20–30 заказов кешируем локально — пользователь видит их мгновенно при следующем открытии, пока идёт фоновое обновление. На Android — Room с @Dao query по userId, отсортированный по дате. В RN — MMKV для быстрого IO (в 10 раз быстрее AsyncStorage на больших объёмах).

Статусы заказов и real-time

Статус «в пути» должен обновляться без перезагрузки приложения. Три подхода:

• WebSocket — socket.io-client в RN или web_socket_channel во Flutter. Подписка на канал конкретного заказа по его id.
• Server-Sent Events — проще WebSocket для однонаправленных обновлений.
• Polling — раз в 30–60 секунд, если WebSocket недоступен. Через useEffect + setInterval в RN, Timer.periodic во Flutter.

Визуальное отображение статусов — timeline с шагами (оформлен → подтверждён → в сборке → передан курьеру → доставлен). Каждый шаг с иконкой и временной меткой. Цветовое кодирование: зелёный — выполнено, синий — текущий, серый — предстоит, красный — отменён/ошибка.

Из практики: приложение доставки еды, 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 дополнительных дня работы.

Кнопка «Повторить заказ» — добавляет все товары в корзину с проверкой наличия. Товары, которых нет — сообщаем пользователю отдельно, не молча пропускаем.

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

• Список заказов с пагинацией (cursor-based)
• Карточка заказа: номер, дата, статус, сумма, превью товаров
• Экран деталей заказа с полным составом и статус-timeline
• Фильтрация по статусу (активные / завершённые / отменённые)
• Кеширование последних заказов для offline
• Кнопка «Повторить заказ»
• Deep link поддержка для открытия конкретного заказа из push-уведомления

Сроки

2–3 рабочих дня — список с деталями и статусами. С real-time трекингом курьера на карте — плюс 1–2 дня. Стоимость рассчитывается индивидуально.