Разработка мобильного приложения на RTPlatform

Облегчаем жизнь программисту и максимально ускоряем разработку проекта.

Рассказывает генеральный директор Bright Mobile.

Ранее я рассказывал о том, что мы реализовали платформу только для проектов в формате заказчик - исполнитель (статья). Но видя большой спрос на произвольные бизнес-приложения (знакомства, покупку товаров, кабинет для ЖКХ) на этой системе, пересобрали ядро так, чтобы программист во время реализации проекта самостоятельно выбирал какие модули использовать и подбирал конкретно те, которые нужны клиенту.

В этой статье хочу привести примеры нескольких модулей, рассказать и как они работают, так сказать, в новой парадигме и объяснить почему именно так.

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

На данный момент описали автотестами 3 вкладки, в ближайших обновлениях реализуем проверку всего функционала.

Модуль используется для любых списков, где предполагаются категории - каталог магазина, категории направлений услуг, категории объявлений для досок.

Думаю, что даже не программист увидит простоту создания новых категорий:

А вот пример создания тестовой категории с описанием полей:

Как мы видим, создаётся "Тестовая категория" с тремя полями - текстовая строка "Заголовок", многострочный текст "Подробнее о квартире" и текстовая строка "Общая площадь". Вот как это выглядит при сборке:

Обычно создание одной категории в приложении со своими полями - это 4-8 часов, в зависимости от сложности под обе платформы. В случае использования архитектуры RTPlatform можно уложиться в полчаса.

Очень часто обращаются стартапы, которые планируют выход сразу в нескольких странах. Только за последний месяц мы подписали договор с тремя такими. Для всех подобных проектов актуален вопрос локализации на произвольные языки. Т.е. не должно быть ограничений по количеству или видам языка.

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

Вот так выглядит вывод локализированного интерфейса:

В среднем, такая задача занимает неделю, в зависимости от сложности приложения и количества экранов. Например, в своё время, локализация приложения на 40 экранов заняла у нас около полумесяца. При использовании такой заготовки можно уложиться в 4-6 часов на всё приложение.

Увеличили производительность загрузки списков с потенциально большим количеством элементов. Например, в приложениях заказа бытовых услуг - это список заявок на ремонт и список мастеров, работающих в сервисе. Ориентир, в первую очередь, на владельцев слабых телефонов. За счёт кеширования подождать придётся только один раз, а далее списки появляются моментально. Это особенно актуально для мастеров в бытовых услугах, которые, чаще всего, имеют не самые навороченные и производительные телефоны.

Сделать само по себе кеширование занимает минут 15-20, однако, программисты часто не учитывают связанные "грабли" - моргание при отображении из кеша, подгрузка динамических данных и т.д. Здесь уже все эти нюансы уже продуманы.

Очень часто основатели стартапов возмущались что за каждого пользователя нужно платить 1,5 — 2 рубля, а если он зайдет на паре своих устройств, а еще и пару раз удалит приложение то и все 10 рублей. Но переходить на авторизацию через соц. сети и старый добрый логин+пароль, тоже не вариант, т.к. в этом случае будет неизвестен номер телефона пользователя, а он крайне нужен для связи с мастером или клиентом. Да и проверка телефона максимально серьезно устраняет спам. Преимуществам этого метода посвятил отдельную статью.

Если же стоит задача сделать авторизацию по СМС, логину/паролю и иными простыми средствами, то срок реализации такой авторизации сводится к 8-и часам.

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

Реализовали функцию пополнения и списания, а также раздел с балансом и транзакциями в разделе настроек. В ближайших обновлениях будет оплата подписки на объявления, т.к. это самый понятный и востребованный принцип оплаты такого сервиса. Как основу я вижу тестовый доступ на 14 дней для исполнителей, а далее ежемесячная оплата подписки. Само собой, логику по умолчанию можно изменить под идею того или иного проекта.

Обычно на интеграцию эквайринга закладывается 3-4 дня, на механику покупки, транзакций и списания ещё от 3-х дней до недели. В случае использования заготовки для баланса произвольная монетизация реализуется за 1-3 дня.

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