Разработка мобильного приложения для доставки товаров
Доставка товаров отличается от доставки еды несколькими принципиальными моментами: товары могут быть крупногабаритными и тяжёлыми (что влияет на расчёт тарифа), время доставки измеряется не часами, а интервалами («с 14 до 16»), часто нужна подпись при получении или проверка содержимого. И главное — каталог товаров и логика склада обычно интегрируется с внешними ERP/WMS-системами, а не живёт внутри приложения.
Архитектура и интеграции
Типичная структура для интернет-магазина с собственной доставкой: мобильное приложение клиента, приложение курьера, панель диспетчера, интеграция с 1С/МойСклад/другой учётной системой через API или очередь сообщений.
Каталог товаров — не в мобильной базе данных. Синхронизация с ERP через REST API или RabbitMQ/Kafka-события при обновлении. Приложение хранит кэш каталога в Room/Core Data с TTL и инвалидацией при получении события «обновление ассортимента».
Остатки — критичный момент. Товар, которого нет на складе, не должен быть доступен для заказа. Отдельный API-эндпоинт для проверки доступности при добавлении в корзину и при финальном подтверждении заказа — двойная проверка обязательна.
Расчёт тарифа с учётом параметров товара
Для курьерской доставки товаров тариф зависит не только от расстояния, но и от характеристик груза:
- Вес — основной параметр. Шаги: до 1 кг, 1-5 кг, 5-20 кг, свыше 20 кг
- Габариты — «негабаритный» груз (не влезает в легковой автомобиль) требует другой тип транспорта
- Хрупкость — дополнительная страховка, специальная упаковка
- Температурный режим — продукты питания, медикаменты
Матрица тарифов лучше хранить на сервере (не хардкодить в приложении). Запрос стоимости: POST /delivery/calculate с параметрами заказа, ответ — список доступных типов доставки с ценой и ориентировочным сроком.
Временные слоты доставки
Клиент выбирает интервал доставки, а не конкретное время. Система слотов:
Слоты генерируются на N дней вперёд, каждый имеет лимит заказов (ёмкость). При заполнении — слот недоступен. Ёмкость зависит от количества активных курьеров в этот период.
data class DeliverySlot(
val date: LocalDate,
val startTime: LocalTime,
val endTime: LocalTime,
val available: Boolean,
val remainingCapacity: Int
)
На экране выбора — горизонтальный скролл по датам, под ним — сетка слотов. Недоступные слоты — серые, неинтерактивные. Популярный паттерн: сначала показываем «ближайшее доступное время» как рекомендацию.
Приложение курьера для доставки товаров
Существенно отличается от курьера такси. Курьер по доставке товаров обычно имеет несколько заказов на одном маршруте, и ему нужна оптимизация маршрута.
Маршрутный лист — список точек доставки на сегодня, отсортированных по оптимальному маршруту. Оптимизацию маршрута считает сервер (Google Optimization API, OR-Tools или простой жадный алгоритм для небольших маршрутов) и передаёт курьеру упорядоченный список.
Подтверждение доставки — фото получателя с товаром или QR-сканирование кода заказа. Подпись на экране через UIBezierPath / Canvas API. Эти данные сохраняются как доказательство доставки.
Частичный отказ — клиент принял 3 из 4 товаров. Курьер отмечает отказавшиеся позиции в приложении, сервер создаёт возврат.
Отслеживание для клиента
Клиент получает push-уведомление, когда курьер начал движение к нему. Отображение на карте — упрощённый трекинг: маркер курьера + маршрут + расчётное время прибытия. Не нужна секундная точность, как в такси — достаточно обновления раз в минуту.
SMS/WhatsApp-уведомление с ссылкой на трекинг — для клиентов, которые не пользуются приложением. Ссылка ведёт на веб-страницу трекинга (PWA или простой HTML).
Возвраты и рекламации
Механика возврата товара — отдельный флоу: клиент инициирует возврат в приложении, указывает причину, прикладывает фото. Сервер создаёт заявку в CRM/ERP. Возврат денег — через тот же платёжный шлюз методом refund.
Срок хранения чека и документов доставки: архивируем на S3/MinIO с метаданными заказа.
Сроки
MVP (одна платформа клиента + приложение курьера, базовый каталог, один тип доставки): восемь-четырнадцать недель.
Полная платформа (iOS + Android, интеграция с 1С, временные слоты, возвраты, панель диспетчера): четыре-восемь месяцев.
Стоимость определяется после анализа требований, состава интеграций и декомпозиции на задачи.