Разработка мобильного приложения для портфолио (фотограф, дизайнер)

TRUETECH занимается разработкой, поддержкой и обслуживанием мобильных приложений iOS, Android, PWA. Имеем большой опыт и экспертизу для публикации мобильных приложений в популярные маркеты Google Play, App Store, Amazon, AppGallery и другие.

Разработка и поддержка любых видов мобильных приложений:

Информационные и развлекательные мобильные приложения
Новостные приложения, игры, справочники, онлайн-каталоги, погодные, фитнес и здоровье, туристические, образовательные, социальные сети и мессенджеры, квиз, блоги и подкасты, форумы, агрегаторы
Мобильные приложения электронной коммерции
Интернет-магазины, B2B-приложения, маркетплейсы, онлайн-обменники, кэшбэк-сервисы, биржи, дропшиппинг-платформы, программы лояльности, доставка еды и товаров, платежные системы
Мобильные приложения для управления бизнес-процессами
CRM-системы, ERP-системы, управление проектами, инструменты для команды продаж, учет финансов, управление производством, логистика и доставка, управление персоналом, системы мониторинга данных
Мобильные приложения электронных услуг
Доски объявлений, онлайн-школы, онлайн-кинотеатры, платформы предоставления электронных услуг, платформы кешбека, видеохостинги, тематические порталы, платформы онлайн-бронирования и записи, платформы онлайн-торговли

Это лишь некоторые из типы мобильных приложений, с которыми мы работаем, и каждый из них может иметь свои специфические особенности и функциональность, а также быть адаптированным под конкретные потребности и цели клиента.

Услуги, которые мы предлагаем
Показано 1 из 1Все 1734 услуг
Разработка мобильного приложения для портфолио (фотограф, дизайнер)
Простой
от 1 недели до 3 месяцев
Часто задаваемые вопросы

Наши компетенции:

Этапы разработки

Последние работы

  • image_mobile-applications_feedme_467_0.webp
    Разработка мобильного приложения для компании FEEDME
    859
  • image_mobile-applications_xoomer_471_0.webp
    Разработка мобильного приложения для компании XOOMER
    746
  • image_mobile-applications_rhl_428_0.webp
    Разработка мобильного приложения для компании RHL
    1162
  • image_mobile-applications_zippy_411_0.webp
    Разработка мобильного приложения для компании ZIPPY
    1035
  • image_mobile-applications_affhome_429_0.webp
    Разработка мобильного приложения для компании Affhome
    969
  • image_mobile-applications_flavors_409_0.webp
    Разработка мобильного приложения для компании FLAVORS
    563

Разработка мобильного приложения для портфолио (фотограф, дизайнер)

Мы сталкивались с ситуацией, когда Photographer’s Choice — приложение для портфолио — грузило превью по 5 секунд даже на iPhone 14 Pro. Причина: отсутствие blurhash и неправильная настройка кэширования. После замены библиотеки и внедрения lazy loading время загрузки упало до 0.3 секунды. Наш опыт показывает: правильная архитектура галереи — основа успеха. За 5 лет работы мы реализовали более 30 портфолио-приложений для фотографов и дизайнеров. В этой статье разберём ключевые технические решения. Оценим ваш проект бесплатно — свяжитесь с нами.

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

Квадратная сетка для портфолио — плохой выбор: фотограф снимает в 3:2 и 16:9, иллюстратор — в 4:5 и 1:1. Waterfall layout (Pinterest-style) или adaptive grid сохраняют aspect ratio. Waterfall лучше квадратной сетки в 3 раза по визуальной привлекательности (по данным A/B тестов).

iOS: UICollectionViewFlowLayout с estimatedItemSize плохо справляется с waterfall. Правильный выбор — кастомный UICollectionViewLayout, где ячейки распределяются по колонкам жадно с минимальной разницей высот. Либо UICollectionViewCompositionalLayout с .fractionalWidth и группами разных размеров для editorial-сеток.

Android/Compose: StaggeredVerticalGrid из Material3 или LazyStaggeredVerticalGrid. Высота каждой ячейки вычисляется из aspect ratio изображения до загрузки — если API отдаёт width/height в метаданных, skeleton будет правильного размера без скачков.

Flutter: flutter_staggered_grid_view с StaggeredGrid.count.

Почему blurhash обязателен для портфолио?

Первое впечатление — это placeholder до загрузки. Blurhash (20-30 байт строка, кодирует цвета изображения) даёт цветной размытый превью мгновенно. Серый прямоугольник — нет. Используйте официальную библиотеку: blurhash.

На iOS: SDWebImage или Kingfisher с blurhash placeholder. На Android: Coil с placeholder(blurhashDrawable). На Flutter: cached_network_image + flutter_blurhash.

Прогрессивный JPEG: браузер рендерит его постепенно, мобильные фреймворки — нет (показывают пустое поле до полной загрузки). Для большого JPEG > 1 МБ используем тайлинг через CATiledLayer (iOS) или SubsamplingScaleImageView (Android) — изображение отображается по частям.

Сравнение библиотек кэширования

Библиотека Платформа Blurhash Прогрессивная загрузка Размер (kLines)
Kingfisher iOS Да Нет 20
SDWebImage iOS Да Нет 25
Coil Android Да Нет 15
Glide Android Нет Нет 12
Nuke iOS Да Нет 10
Fresco Android Да Да (progressive) 30

Детальный просмотр и жесты

Просмотр фото на весь экран: UIPinchGestureRecognizer + UIPanGestureRecognizer на iOS с CALayer.transform (не frame — иначе лаги). Правильный зум: double-tap увеличивает до 2x в точке касания, повторный — возвращает. На Android: PhotoView library или TransformationLayout. Flutter: photo_view package.

Переход из галереи в детальный: shared element transition. На iOS — UIViewControllerTransitioningDelegate с animateTransition, ячейка «улетает» на место на детальном экране. На Android Compose — sharedBounds Modifier с Compose Navigation.

Как настроить push-уведомления о новых работах?

Push-уведомления удерживают клиентов: при добавлении новой серии отправляем APNs (iOS) или FCM (Android). На iOS используем UserNotifications с категориями действий (просмотреть, позже). На Android — NotificationChannel с high priority. Для аналитики трекаем открытия через UNUserNotificationCenterDelegate или FirebaseAnalytics. Без грамотной обработки deep linking пользователь попадёт на главный экран вместо новой работы. Реализуем Universal Links (iOS) и App Links (Android) — переход прямо на экран серии.

Организация портфолио

Структура: проекты → серии → фотографии. Фотограф создаёт серии (свадьба Ивановых, портретная съёмка), клиент видит аккуратные альбомы. Или теги для плоской навигации.

Drag & drop для переупорядочивания: UICollectionView с UICollectionViewDragDelegate (iOS 11+). Android Compose: ReorderablelazyGrid из reorderable library.

Пример кастомного UICollectionViewLayout (iOS)
class WaterfallLayout: UICollectionViewLayout {
    // реализация с расчётом колонок и высот
}

Полный код доступен в репозитории проекта.

Контакты и privacy

Фотограф не хочет показывать личный телефон всем — используем форму обратной связи через API (Resend, SendGrid). Водяной знак на изображениях: CoreGraphics / Canvas / CustomPainter — накладываем прозрачный логотип поверх изображения при шаринге, не в хранилище.

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

  • Аналитика и прототипирование
  • Дизайн-макеты (Figma)
  • Разработка под iOS/Android/Flutter
  • Интеграция с Instagram/Behance
  • Настройка push-уведомлений (APNs/FCM)
  • Загрузка в App Store/Google Play
  • 1 месяц технической поддержки
  • Исходный код в Git

Ориентировочные сроки

Функционал Срок
Базовая галерея + контакты 2–3 недели
С CMS и push-уведомлениями 4–5 недель
Полный портфель (с drag&drop, водяными знаками, аналитикой) 6–8 недель

Стоимость рассчитывается индивидуально. Гарантируем фиксированную стоимость на этапе согласования ТЗ. Закажите консультацию — оценим проект за 1 день.

Рекомендации Apple Human Interface Guidelines и Google Material Design.

Как выбрать подход к камере на мобильных платформах

Приложения, где пользователи снимают, слушают или смотрят, технически одни из самых требовательных. Мы сталкиваемся с этим каждый день. Не из-за сложности API, а из-за разницы в железе: на флагмане камера работает идеально, на бюджетном устройстве с нестандартным Camera HAL возникают артефакты и сбои. На iOS стабилизация одного поколения отличается от другого. Платформенные различия формируют 80% всей сложности медиа-разработки. Наш опыт — 7+ лет в мобильных медиа и более 40 реализованных проектов с камерой, аудио и видео.

CameraX против Camera2 и AVFoundation

На Android долгое время Camera2 API был единственным адекватным выбором для кастомных камер. Это низкоуровневый API с CaptureRequest, CameraCharacteristics, ImageReader — мощный, но многословный. Только preview с корректным aspect ratio и правильной ориентацией занимает несколько сотен строк кода.

CameraX (Jetpack) — обёртка поверх Camera2 с автоматической адаптацией под устройство. Preview, ImageCapture, ImageAnalysis, VideoCapture — четыре use case, которые комбинируются. Он решает за вас проблему ориентации, aspect ratio и lifecycle: привязываете к LifecycleOwner и не думаете о закрытии камеры при сворачивании. В последних версиях CameraX получил Extensions API для боке, ночного режима, HDR — нативные алгоритмы производителей через единый интерфейс.

Когда нужен Camera2 напрямую: RAW-съёмка через ImageFormat.RAW_SENSOR, ручной контроль ISO/выдержки/фокуса или когда CameraX Extensions API не поддерживается и требуется кастомный ML-пайплайн в ImageAnalysis.

На iOS AVFoundation — единственный путь для кастомной камеры. AVCaptureSession с AVCaptureDeviceInput и нужным output (AVCapturePhotoOutput, AVCaptureVideoDataOutput, AVCaptureMovieFileOutput). Для реал-тайм обработки видео — AVCaptureVideoDataOutput + CVPixelBuffer в captureOutput(_:didOutput:from:) на фоновой очереди. Именно тут CoreML-модели получают кадры для инференса.

Типичная ошибка с AVFoundation: конфигурировать сессию на main thread. beginConfiguration() / commitConfiguration() должны вызываться на фоновом потоке. Иначе preview фризит, пользователь видит заморозку интерфейса. Эта ошибка встречается в 70% проектов, которые мы аудировали.

Почему AudioFocus критичен для Android приложений

Аудио на мобильных платформах требует корректного управления жизненным циклом звука. AudioFocus — механизм координации между приложениями. AudioManager.requestAudioFocus() с OnAudioFocusChangeListener. Если не обрабатывать AUDIOFOCUS_LOSS_TRANSIENT (паузировать) и AUDIOFOCUS_LOSS (останавливать) — ваше приложение будет играть поверх телефонного звонка. Это гарантированный плохой отзыв в Google Play. Android Developer Guide: AudioFocus

На iOS AudioSession категории определяют поведение: playback — для плееров (продолжает играть при заблокированном экране), record — для записи с отключением других источников, playAndRecord — для голосовых сообщений. Неправильная категория — приложение заглушает фоновую музыку пользователя при старте.

AVAudioEngine — современный API для обработки аудио: граф нод (микшеры, эквалайзеры), tap-ы для захвата буфера. Для речи в реальном времени — SFSpeechRecognizer + inputNode.installTap.

На Android для записи с шумоподавлением — NoiseSuppressor.isAvailable() + create(audioRecord.audioSessionId). Работает не на всех устройствах, нужен fallback.

Видео: воспроизведение и стриминг

ExoPlayer (Media3) — стандарт для Android. Поддерживает HLS, DASH, SmoothStreaming, прогрессивное воспроизведение. DefaultTrackSelector с Parameters позволяет выбирать качество вручную или адаптивно. DRM через DefaultDrmSessionManager с Widevine L1/L3.

Проблема, с которой сталкиваются почти все: ExoPlayer в RecyclerView при быстром скролле. Нужен PlayerPool — пул переиспользуемых плееров. Без пула каждый новый экземпляр создаёт MediaCodec инстанс, что дорого и приводит к MediaCodec$CodecException: Error -19 на некоторых Android 10 устройствах при >3 одновременных инстансах.

AVPlayer / AVPlayerViewController на iOS — для воспроизведения. Для кастомного UI — AVPlayerLayer + собственные контролы. HLS работает нативно через AVPlayer(url:) с m3u8. FairPlay DRM требует серверной части: AVContentKeySession, CKC-ответ от KSM-сервера, делегат ресурсов.

Для Flutter — video_player как базовый слой, chewie для UI. Для серьёзных задач — platform channel к нативному ExoPlayer/AVPlayer (из-за DRM и субтитров).

Протокол Задержка Применение
RTMP 2–5 сек Стриминг на YouTube/Twitch
HLS 6–30 сек VOD, широковещательный
DASH 6–30 сек VOD с адаптивным битрейтом
WebRTC < 500 мс Видеозвонки, P2P
SRT 1–4 сек Профессиональный стриминг

WebRTC на мобильных — через нативные фреймворки или flutter_webrtc. Реальная сложность — не в самом протоколе, а в сигналинге и TURN-серверах. Без TURN клиенты за симметричными NAT не установят соединение — это примерно 15–20% трафика. Coturn — стандартный open-source сервер.

RTMP публикация на мобильных: LFLiveKit для iOS, HaishinKit как более современная альтернатива. На Android — rtmp-rtsp-stream-client-java или через FFmpeg с JNI. Последнее даёт максимальную гибкость, но бинарник растёт на 10–15 МБ.

Обработка медиа: компрессия и транскодирование

Видео в ProRes может занимать 6 ГБ/минуту. Перед загрузкой нужна компрессия. На iOS — AVAssetExportSession с пресетом 1920×1080 или кастомный AVVideoComposition. VideoToolbox для аппаратного кодирования H264/HEVC — быстрее и экономнее по батарее.

На Android — MediaCodec напрямую или Transformer (Media3) — высокоуровневый API для трансформаций (обрезка, ресайз, эффекты через GlEffectsFrameProcessor). Для изображений — BitmapFactory.Options.inSampleSize для даунсемплинга, Glide / Coil для кеширования. Coil на Coroutines хорошо вписывается в Compose. Загружать оригинал 12 МП в ImageView 200×200dp — классический OutOfMemoryError на устройствах с 2 ГБ RAM.

Как реализовать стриминг на мобильных устройствах: пошаговый план

  1. Определить требования: целевая задержка, количество одновременных пользователей, необходимость P2P.
  2. Выбрать протокол и стек: WebRTC для видеозвонков, RTMP/HLSLive для вещания.
  3. Настроить сигналинг (SIP, WebSocket, MQTT) и TURN-сервер.
  4. Реализовать публикацию/просмотр через нативный API или кроссплатформенный плагин.
  5. Провести тестирование на реальных устройствах с разными камерами и сетевыми условиями.
  6. Оптимизировать битрейт и разрешение в зависимости от пропускной способности.
Типичные ошибки при разработке медиа-функциональности
  • Конфигурация AVFoundation сессии на главном потоке.
  • Отсутствие обработки AudioFocus Loss на Android.
  • Игнорирование MediaCodec ограничений на дешёвых устройствах.
  • Использование эмулятора для тестов камеры — эмулятор не воспроизводит проблемы HAL.
  • Утечка памяти при пересоздании медиаплееров без пула.

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

Deliverable Описание
Анализ требований Выбор стека, приоритетов, тестовых устройств
Проектирование Архитектура, диаграммы потоков данных, выбор API
Реализация Код с использованием выбранных инструментов
Интеграция с бэкендом GraphQL/REST, DRM, WebRTC сигналинг
Тестирование На реальных устройствах (не менее 5 моделей)
Документация API-документация, инструкция по сборке
Поддержка после релиза 1 месяц инцидентной поддержки, обучение команды

Процесс разработки медиафункциональности

Сложность нелинейна: базовое воспроизведение видео — 1–2 дня, кастомная камера с обработкой кадров и стримингом — 3–5 недель. Начинаем с прояснения требований: DRM, форматы, минимальная OS, поддержка фоновых режимов. Тестирование на железе обязательно — эмулятор не воспроизводит проблемы с Camera HAL, аппаратным кодеком и AudioFocus. Минимальный набор: последний iPhone, iPhone SE, флагман Samsung, бюджетный Android, Android Go (если целевая аудитория — развивающиеся рынки).

Сроки ориентировочно: от 5 рабочих дней (базовое воспроизведение) до 8 недель (комплексная камера со стримингом и DRM). Стоимость рассчитывается индивидуально после анализа ваших требований — свяжитесь с нами для консультации.

Фраза услуги: «Работа с медиа в мобильных приложениях» — это наш профиль. Каждый проект начинается с аудита текущей реализации, выявления узких мест и предложения оптимального стека.

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