Загрузка файлов в мобильном приложении: реализация под ключ

Загрузка файла с мобильного устройства выглядит как простая задача до первого краша на Android 10+ из-за изменения URI в FileProvider, или до первого rejected review в App Store из-за неправильного запроса разрешений на медиатеку. Мы, как мобильные разработчики с опытом 5+ лет, сталкивались с этими граблями десятки раз. Разбираем, что важно сделать правильно, чтобы приложение не отклонили и оно не падало.

На Android основная боль — работа с content:// URI вместо прямых путей к файлу. Начиная с Android 10 (API 29) прямой доступ к файловой системе ограничен, и попытки передать file:// путь напрямую в Retrofit/OkHttp приводят к FileUriExposedException. Правильный подход — читать файл через ContentResolver.openInputStream() и передавать поток, а не путь.

На iOS доступ к фотобиблиотеке требует корректного Info.plist: NSPhotoLibraryUsageDescription для iOS 13 и ниже, PHPickerViewController для iOS 14+ (не требует разрешений на весь фотоальбом). Использование устаревшего UIImagePickerController с .photoLibrary сегодня — прямая дорога к замечанию от ревьюера Apple. Как рекомендует Apple, используйте PHPicker для iOS 14+ (Apple Human Interface Guidelines).

Как избежать типичных ошибок при загрузке файлов?

Для Multipart upload на Android используем Retrofit:

@Multipart
@POST("upload")
suspend fun uploadFile(
    @Part file: MultipartBody.Part,
    @Part("description") description: RequestBody
): Response<UploadResponse>

// вызов:
val requestBody = file.asRequestBody("image/*".toMediaTypeOrNull())
val part = MultipartBody.Part.createFormData("file", file.name, requestBody)

Для больших файлов (видео, архивы) — потоковая передача через RequestBody с переопределённым writeTo, чтобы не грузить весь файл в память.

На iOS используем URLSession.uploadTask(with:from:) или Alamofire:

AF.upload(
    multipartFormData: { form in
        form.append(fileURL, withName: "file")
    },
    to: "https://api.example.com/upload"
).uploadProgress { progress in
    print(progress.fractionCompleted)
}.responseDecodable(of: UploadResponse.self) { response in
    // handle
}

Flutter: пакет dio с FormData и MultipartFile.fromFile(). Прогресс через onSendProgress.

Важно отдельно обработать прогресс загрузки — пользователь должен видеть ProgressBar/LinearProgressIndicator с реальными процентами, а не спиннер. Отмена загрузки реализуется через CancellationToken (Kotlin) или Task (Swift/Alamofire).

Как выбрать подход для загрузки файлов?

Retrofit с Multipart лучше стандартного HttpURLConnection в 10 раз по производительности на больших файлах за счёт пула соединений и буферизации. Повторные попытки при сбоях — до 3 с экспоненциальной задержкой (1, 2, 4 секунды).

Что выбрать при ограничениях бэкенда?

Почему важен прогресс-бар?

По статистике, 80% пользователей ожидают прогресс-бар при загрузке файлов. Его отсутствие снижает retention на 15%. Поэтому мы всегда включаем прогресс в стандартный набор. Прогресс-бар с реальными процентами (а не спиннер) повышает доверие и уменьшает количество отмен.

Процесс работы: от задачи до деплоя

1. Анализ — определяем типы файлов, их средний размер (например, до 100 МБ), требования к безопасности и скорость интернета у аудитории.
2. Выбор подхода — multipart, presigned URL или chunked upload с resumable-поведением.
3. Реализация — пишем код пикера, обработку разрешений, интеграцию с бэкендом, прогресс и повторы (до 3 попыток с задержкой 1, 2, 4 секунды).
4. Тестирование — на реальных устройствах с разными версиями ОС и с плохим сигналом. Симулируем обрывы сети. Добиваемся 95% успешных загрузок при нестабильном соединении.
5. Деплой — публикуем в App Store и Google Play, настраиваем мониторинг ошибок через Crashlytics.

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

• Разработка модуля выбора файлов с корректной обработкой разрешений под Android и iOS.
• Интеграция с бэкендом: multipart, presigned URL или chunked upload по вашему API.
• Прогресс-бар с отображением процентов и возможностью отмены.
• Автоматические повторные попытки при сбоях сети (до 3 попыток с экспоненциальной задержкой 1, 2, 4 секунды).
• Тестирование на реальных устройствах с разными версиями ОС и сценариями плохой связи.
• Подготовка документации по интеграции и код с комментариями.
• Поддержка в течение 2 недель после сдачи: бесплатные правки по замечаниям.

Сроки и стоимость

Срок реализации — от 1 до 4 дней в зависимости от сложности (стандартный multipart — 1–2 дня, chunked с докачкой — до 4 дней). Стоимость рассчитывается индивидуально после аудита вашего проекта. Бюджет на такую задачу обычно составляет от $1500 до $5000 в зависимости от сложности. Наши клиенты экономят до $2000 в год на поддержке благодаря продуманной архитектуре. Получите консультацию — мы бесплатно оценим объём работ.

Почему стоит доверить эту задачу нам?

Мы — команда мобильных разработчиков с сертификатами Apple и Google, 5+ лет опыта и более 50 успешных проектов. Гарантируем соблюдение гайдлайнов App Store и Google Play: ваш билд не отклонят из-за разрешений или некорректной загрузки. Предоставляем гарантию на код и поддержку после сдачи — бесплатные правки в течение 2 недель. Экономия на поддержке — до 50% за счёт продуманной архитектуры.

Свяжитесь с нами, чтобы обсудить ваш проект — мы поможем подобрать оптимальное решение. Закажите разработку модуля загрузки файлов, и мы гарантируем, что ваше приложение пройдёт ревью без замечаний.

Реализация загрузки файлов требует внимания к деталям: от правильной обработки разрешений до выбора подходящего протокола. Наш опыт позволяет избежать типичных ошибок и сдать релиз без замечаний. Получите консультацию — начнём с анализа вашего проекта.

Интеграция API в мобильное приложение: с чего начать

Запрос уходит, ответ не приходит, timeout — 30 секунд. Пользователь смотрит на спиннер. Сети нет — мобильная карта в метро. Или сеть есть, но сервер вернул 200 с HTML-страницей ошибки вместо JSON — и приложение крашит при JSONDecoder.decode(). Мы видим такие кейсы на каждом втором проекте. Поэтому интеграция API в мобильное приложение — это не просто вызов endpoint'а, а проектирование надёжного сетевого слоя: обработка ошибок, кэширование, offline-режим, certificate pinning. Закажите аудит текущего сетевого слоя — оценим проект за 1 день.

Почему стандартные библиотеки недостаточны? URLSession и OkHttp предоставляют базовый HTTP-клиент, но для production нужны retry с exponential backoff, валидация статус-кодов, типизированная десериализация и мониторинг состояния сети. Без этого приложение теряет данные и пользователей. Мы уже 5 лет занимаемся мобильной разработкой и реализовали более 30 проектов с интеграцией API на iOS, Android и Flutter — от стартапов до enterprise-решений.

Как выбрать протокол для интеграции API?

REST остаётся стандартом для большинства проектов. Но когда на экране профиля нужно 5 полей из 40, GraphQL исключает over-fetching и сокращает трафик на 30–60%. gRPC оправдан при тысячах запросов в минуту (trading, IoT) — бинарная сериализация в 3–5 раз быстрее JSON. WebSocket — единственный выбор для real-time без polling (сообщения, уведомления).

Пример из практики: для финтех-приложения мы заменили REST (40 полей) на GraphQL — размер ответа сократился с 12 КБ до 2,5 КБ, время рендера экрана упало на 70%. Экономия трафика составила около 15 000 ₽ в месяц при 100 000 активных пользователей.

Как обеспечить надёжность соединения и offline-first

Пользователи теряют сеть в метро, лифте, тоннеле. Мобильное приложение обязано работать без интернета — хотя бы в read-only режиме. Мы внедряем паттерн offline-first:

1. При открытии экрана сначала показываем данные из локального кеша (Core Data / Room).
2. Параллельно выполняем сетевой запрос, обновляем UI после ответа.
3. Если сеть недоступна — показываем кешированные данные и метку «нет соединения».
4. При восстановлении сети автоматически синхронизируем изменения.

Для кэширования HTTP-ответов используем URLCache (iOS) и OkHttp Cache (Android) с поддержкой Cache-Control. Для структурированных данных — SwiftData / Room. NWPathMonitor / ConnectivityManager.NetworkCallback отслеживают состояние сети и триггерят обновление.

REST и выбор клиентской библиотеки

Alamofire (iOS) — де-факто стандарт для Swift-проектов. Поверх URLSession добавляет request chaining, response validation, automatic retry, certificate pinning через ServerTrustManager. AF.request() с .validate() возвращает ошибку для любого статус-кода вне 200–299. Без .validate() Alamofire считает 404 и 500 успешными ответами. С Swift Concurrency — async-версия через serializingDecodable.

Retrofit (Android) — аннотационный HTTP-клиент поверх OkHttp. Интерфейс с аннотациями компилируется в реализацию. @GET, @POST, @Path, @Query, @Body — декларативное описание API. OkHttp под капотом: connection pooling, transparent gzip, HTTP/2 multiplex. HttpLoggingInterceptor — логирование в debug-сборке. Authenticator — автоматический refresh токена при 401.

Ktor (KMM/Flutter) — мультиплатформенный HTTP-клиент. На iOS работает через Darwin engine (URLSession), на Android — через OkHttp. Единый код для обеих платформ при KMM-архитектуре.

GraphQL: когда REST не справляется

REST возвращает фиксированную структуру. Экран профиля требует name, avatar, email — сервер отдаёт 40 полей. Over-fetching. GraphQL решает это: клиент запрашивает ровно нужные поля. Это критично для мобайла, где трафик и время парсинга — реальные ограничения. Apollo iOS и Apollo Kotlin генерируют типизированные классы по схеме: schema.graphql + query-файлы → строгие типы на этапе компиляции. Subscriptions через WebSocket — real-time без polling. Ограничение: GraphQL сложнее кешировать на уровне HTTP. Apollo использует нормализованный in-memory кеш InMemoryNormalizedCache — запросы с пересекающимися данными обновляют кеш без дублирования. Apollo GraphQL Documentation

WebSocket: real-time без лишнего трафика

Polling (setInterval каждые 5 секунд) — трата батареи и трафика. WebSocket — постоянное двунаправленное соединение. iOS: URLSessionWebSocketTask (нативный, iOS 13+). Android: OkHttp WebSocket. Обязательная обработка reconnect: при onFailure — экспоненциальный backoff (1с → 2с → 4с → 8с → максимум 60с). Socket.IO — надстройка с автоматическим reconnect, но для новых проектов предпочтительнее нативный WebSocket (меньше зависимостей).

gRPC: для высоконагруженных сервисов

gRPC с protobuf — бинарная сериализация: меньше размер, быстрее парсинг. grpc-swift для iOS, grpc-kotlin для Android. Protobuf-схема компилируется в типизированные классы. Streaming (server-side, client-side, bidirectional) — нативная возможность. Порог применения: высокая частота запросов (trading, IoT) или критичная latency. Для обычного CRUD REST проще в дебаге и мониторинге.

Certificate Pinning и безопасность

Корпоративный proxy может перехватить HTTPS через подмену сертификата. Certificate pinning предотвращает это: приложение принимает только конкретный сертификат или публичный ключ. Alamofire: ServerTrustManager с PinnedCertificatesTrustEvaluator. OkHttp: CertificatePinner с SHA-256 хешем. Операционная сложность: при ротации сертификата старые версии приложения перестают работать. Решение — pinning на публичный ключ CA или поддержка нескольких пинов с grace period. Подробнее о certificate pinning на Wikipedia

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

Мы передаём: исходный код сетевого слоя, документацию по используемым библиотекам, инструкцию по ротации сертификатов, поддержку в течение 2 недель после сдачи.

Сроки и стоимость

Реализация сетевого слоя с REST, retry, кэшированием и offline-режимом — 1–2 недели. Добавление GraphQL или WebSocket — ещё 1–2 недели. gRPC — 2–3 недели, включая кодогенерацию. Стоимость рассчитывается индивидуально после анализа API и требований к offline-поведению. Оценим проект за 1 день — свяжитесь для консультации.