Доброго времени суток, дорогие читатели, новый выпуск про разработку нового мобильного приложения, перехожу к стадии разработки.
Содержание цикла статей
- Стадия разработки
- Результаты, цифры, доходы
Структура и архитектура
В первую очередь хочу рассказать об общей архитектуре той системы, что я разработал.
Мобильное приложения является интерфейсом для обращения к промежуточному серверу. В нём хранятся результаты распознавания для каждого пользователя, есть интерфейс выбора файла, а также задать настройки распознавания.
Защищенный сервер служит промежуточным звеном, но по сути основным действующим лицом. Здесь после получения файла от пользователя происходит его преобразование в наиболее удобный формат при помощи ffmpeg, если аудиофайл большой, то это происходит через очередь Gearman, чтобы не держать подключение открытым всё это время (процесс преобразования может быть очень долгим). Помимо очереди на преобразование в нужный формат аудиозаписи, есть очередь на само распознавание речи. В зависимости от длительности аудиофайла в разный момент идёт переход туда. Сама же очередь освобождается после выполнения запроса к Google STT и получения результатов, которые после этого сохраняются в БД на сервере. Когда результаты появились они отправляются пользователю в приложение и сохраняются там в истории.
Google Cloud STT — облачное решение для распознавания речи, предоставляющее API для этого, и требующее специальный сервисный ключ, чтобы определить для какого аккаунта выполняется распознавание, чтобы потом списать деньги с этого человека.
Мобильное приложение
Разработкой приложений под Android я занимаюсь уже давно, не сказать, что опытный специалист уровня middle или выше, но навыков хватает, чтобы делать вполне красивые приложения визуально и удобные, с точки зрения кода.
Material Design
Пред разработкой приложения я сделал небольшой макет в Adobe XD по канонам Material Design, чтобы было проще разрабатывать, вот так он выглядел:
Итоговое приложение выглядит немного иначе, но эти коррективы были внесены уже в моменте разработки.
Для Android есть много замечательных библиотек, позволяющих делать элементы Material Design, такие как EditText и Button. Если вы делаете приложение с нуля, то советую использовать их.
Model-View-ViewModel
Во время разработки я решил использовать новую для себя методологию Model-View-ViewModel, она незначительно отличается от ранее используемой мной MVP в реализации. В процессе я познакомился с технологией LiveData и всем советую обратить внимание, очень удобный инструмент.
В случае MVP (Model-View-Presenter) у нас есть три условных класса:
- Logic.java — здесь вся логика работы с БД, вычисления т.д. (название класса взято для примера, их может быть и несколько). Это Model.
- Fragment/Activity (+ .xml файла представления) — это наш View, почему я дописал в скобочках .xml, потому что мы можем создавать представление и без него, инициируя все виджеты интерфейса в самом классе.
- PresenterHome.java — это наш Presenter, который реагирует на действия в View и вызывает методы Model для решения определенных задач, таких, как получение данных из БД, вычисления и т.д.
В случае с MVVM (Model-View-ViewModel) у нас заменяется только класс Presenter на ViewModel, наверное с единственным основным отличием — использование databinding (вышеупомянутое LiveData в Android).
Постараюсь привести понятный пример из моего приложения. На экране истории распознанных аудиозаписей, когда инициируется мой HistoryFragment, то вызывается метод, который возвращает LiveData (по сути подписку на данные) списка распознанных аудиофайлов из БД, через эту подписку реализуется метод, который вызывается каждый раз, когда данные в БД изменяются и можно обработать эти изменения и отобразить пользователю. Например, когда пользователь удаляет данные, то вызывается соответствующий метод ViewModel, который в свою очередь обращается к API базы данных. После удаления из БД, она сигнализирует LiveData о том, что данные были изменены и этот сигнал возвращается в Fragment (View). Почему это так удобно, это слишком длинный вопрос, но жизнь разработчика сильно упрощает.
Navigation component
Ещё одним новым инструментом, который я решил изучить во время разработки этого приложения стал Navigation Component, который существует уже не первый год, но услышал я о нём почему-то совсем недавно.
По сути он намного упрощает работу с переходами между фрагментами/активити и не только. С первой версии он претерпел много изменений и теперь обладает целым рядом преимуществ.
Особенно понравилась возможность автоматического создания Drawer Menu (плашка с меню слева), а также улучшенный и быстрый переход между фрагментами с возможностью добавить нужную информацию. Всё это экономит кучу времени и избавляет от написания кода.
Единственный недостаток, который я нашел. Что когда в меню нужно, чтобы при клике на пункт меню происходило что-то, кроме открытия другого фрагмента/активити, то приходится писать костыль, что-то вроде:
navigationView.getMenu().findItem(R.id.act_write_developer).setOnMenuItemClickListener(item -> {
startActivity(Intent.createChooser(SupportUtil.getInfoIntent(this, null), getText(R.string.menu_write_developer)));
return true;
});
Выводы
Не смог тут рассказать о процессе разработки на сервере, там тоже пришлось поломать голову и изучить много нового для себя, прежде чем всё заработало как часы, если вам интересна эта тема, то пишите в комментариях и я обязательно освещу её в отдельной статье.
Жду от новых пользователей подписки, от старых лайков и комментариев. Ваша активность — провоцирует мою активность. А то в работе совсем погрузился и давно ничего не писал. В следующее статье поговори про ASO и публикацию приложения.
