Мобильное приложение под заказ в Перми

Карта, точки и маршруты

Приложения с картой выглядят простыми, пока точек немного. На нескольких сотнях объектов карта начинает тормозить, если рисовать каждую метку отдельно. Поэтому точки группируются в кластеры, данные загружаются по видимой области, а подробности подтягиваются при открытии карточки. Фильтры считаются на сервере, чтобы телефон не перебирал весь список. Такие решения не видны пользователю, но именно от них зависит, захочет ли он открыть приложение второй раз.

• 1кластеризация точек на карте
• 2загрузка данных по видимой области
• 3фильтры и поиск на стороне сервера
• 4карточка объекта с фотографиями и описанием
• 5маршрут через установленный навигатор

Размер, запуск и заряд

Три вещи, из-за которых приложения удаляют: много весит, долго запускается, быстро расходует заряд. Я держу размер сборки небольшим, изображения отдаю в подходящем разрешении, тяжёлые экраны загружаю по требованию. Геопозиция и фоновые обновления включаются только там, где без них не обойтись, и это обсуждается на этапе сценариев. Размер сборки я проверяю перед каждой отправкой в стор. Тяжёлые экраны при этом загружаются только при переходе на них.

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

Контент и админка

Городской сервис живёт содержанием: расписание меняется, события добавляются, точки закрываются. Поэтому админка делается частью проекта: редактирование объектов, загрузка изображений с автоматическим сжатием, черновики и дата публикации, push-рассылки по сегментам. Правки делает ваш редактор, участие разработчика для обычного обновления не требуется. Отдельно настраиваются роли: редактор правит только свой раздел, администратор всё. Это важно, когда наполнением занимаются несколько человек из разных подразделений.

• 1редактирование объектов и расписания
• 2черновики и отложенная публикация
• 3push-рассылки по сегментам
• 4роли редакторов с разными правами

Техническая часть

Клиент на React и TypeScript, одна кодовая база под iOS и Android. Сервер на Node.js, база PostgreSQL. При необходимости подключаю обмен с 1С или amoCRM, если приложение связано с продажами или заявками. Отчёты по использованию разделов можно вывести в браузер, чтобы решения о развитии опирались на данные, а не на предположения. Набор отчётов согласуем заранее, под решения о развитии.

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

Публикация, цена, связь

Сборки, карточку и политику конфиденциальности готовлю я, отправляю на проверку и отвечаю на замечания. Правила площадок свои и обновляются, срок рассмотрения от меня не зависит, поэтому дат я не называю. Цена от 300 000 ₽, итог после разбора объёма. Работаю один и удалённо, по этапам с оплатой по факту сдачи. Исходный код, доступы и инструкция по обновлению передаются заказчику. Писать в Telegram @inter1ark или на vitoscarasel@gmail.com.