Доброго времени суток. Часто задумываюсь об использовании HiAsm разработчиками мобильных приложений в работе, особенно, видя множество однотипных проектов, где CRUD-приложение имеет малое количество логики и взаимодействует с бэкендом или Firebase. Обычно тратится много времени на рутинные действия, как написание однотипных участков кода или “сование кнопочек”. Считаю, что HiAsm отлично может решить эти проблемы, ускорить разработку и сократить количество багов при использовании отлаженных компонент, написанных разработчиками пакета.

Есть идея определиться с основным набором технологий и подходов создания мобильных приложений в HiAsm, и на основе этого создать Mobile или Android. Основные критерии и технологии, которые сейчас требуются для разработки типичного приложения:
- многоэкранность, поддержка stack, tab-навигации + deep-linking;
- простое стилизирование с возможностью переиспользования компонент;
- наличие простых элементов для работы по HTTP с возможностью описать вызов одним компонентом;
- наличие элементов для работы с Websocket и Socket.io;
- поддержка SQLite/Realm/хранилища типа ключ-значение;
- поддержка Bluetooth Low Energy;
- элементы для работы с Firebase и Google APIs;
- работа с уведомлениями;
Буду благодарен за пополнения этого списка идеями.

Рассмотрим популярные на данный момент фреймворки мобильных приложений:
- Нативные Android-приложения. Языки программирования: Java/Kotlin. Нативные приложения имеют наивысшие показатели производительности, все контролы нативные и рисуются системой. Есть возможность использования всего функционала, что предоставляет Android SDK, а также огромного количества готовых решений и библиотек. Основными недостатками является отсутствие кроссплатформенности, что часто требуется типичным заказчиком из Upwork, а так же долгое время сборки проекта - от 30 секунд до десятка минут в зависимости от размера и характеристик компьютера.
- React Native. Язык программирования JavaScript. Популярный фреймворк для разработки кроссплатформенных мобильных приложений. Разрабатывается Facebook с 2015 года, с этого времени получил множество библиотек для работы как и с визуальной составляющей приложений, так и физических интерфейсов смартфона. Также есть возможность сборки приложений под Windows, но поддержка этого ограничена разработчиками сторонних библиотек. Во время разработки приложение требуется собирать только при добавлении новых библиотек, последующие изменения подгружаются “на ходу”. Основные минусы: требует много времени для создания приложения с нативным видом (поэтому часто разработчики и рисуют самодельные контролы, да и дизайнерам это часто нравится ); временами, нестабильная работа, которая лечится от очистки кеша сборщика до перезагрузки и перестановки компьютера на другое место; при управлении вьюшками используется декларативный подход (JSX) и неясно, как это можно грамотно совместить с управлением ими через методы (но можно использовать ref, хоть и это будет не совсем правильно в рамках React Native).
- Flutter. Язык программирования Dart. Новый фреймворк для разработки кроссплатформенных приложений, разрабатываемый Google, также есть поддержка Windows. Достоинства и недостатки такие же, как у React Native, с отличием, что Flutter появился позднее, соответственно есть меньшее количество доступных библиотек. Но сейчас разработчики активно переходят с React Native на Flutter, и есть вероятность, что технология от Google заменит предшественника уже через несколько лет.

Так как объекты, которые возвращает API, имеют древовидную структуру, предлагается расширить имеющийся набор стандартных типов типом Object или Map. Но на данный момент у меня нет четких представлений о том, как должны выглядеть элементы для работы с этим типом, чтобы с ним можно было максимально удобно работать. Основной функционал для работы с объектами/мапами:
чтение и запись по ключу;
извлечение массива ключей, значений или записей (аналоги Object.keys(), Object.values() и Object.entries() из JavaScript);
возможность производить чтение или запись на разном уровне вложенности объектов.

Также хотелось бы рассмотреть идеи касательно возможности использовать Data Binding (вкратце - возможность подать на визуальные элементы объект, а в самих контролах задать маппинг, по которому нужные для отображения данные будут извлечены) и стилизирования (возможность создания таблиц стилей, а также переиспользуемых визуальных компонент).

Буду благодарен за помощь по выбору фреймворка и любые идеи, касающиеся разработки пакета.