Розроблення історії заказів у мобільному додатку
Історія заказів виглядає просто: список з карточками, статус, дата, сума. Але за цією простотою скривається кілька нетривіальних задач — пагінація з різними стратегіями завантаження, коректне відображення статусів з 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)
- Карточка заказу: номер, дата, статус, сума, превю товарів
- Екран деталей заказу з повним складом й status-timeline
- Фільтрація по статусу (активні / завершені / скасовані)
- Кеширование останніх заказів для offline
- Кнопка «Повторити заказ»
- Deep link підтримка для відкриття конкретного заказу з push-сповіщення
Терміни
2–3 робочих дні — список з деталями й статусами. З real-time трекингом кур'єра на карті — плюс 1–2 дні. Вартість розраховується індивідуально.







