Доброго времени суток. Часто задумываюсь об использовании 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 (вкратце - возможность подать на визуальные элементы объект, а в самих контролах задать маппинг, по которому нужные для отображения данные будут извлечены) и стилизирования (возможность создания таблиц стилей, а также переиспользуемых визуальных компонент).
Буду благодарен за помощь по выбору фреймворка и любые идеи, касающиеся разработки пакета.
Этот топик читают: Гость
Ответов: 1821
Рейтинг: 168
|
|||
карма: 5 |
|
Главный модератор
Ответов: 2999
Рейтинг: 396
|
|||
карма: 6 |
|
Ответов: 4628
Рейтинг: 749
|
|||
Прочитав выше изложенное понимаю как я отстаю от современных технологий программирования.
Редактировалось 1 раз(а), последний 2019-07-01 10:47:41 |
|||
карма: 26 |
|
Ответов: 1821
Рейтинг: 168
|
|||
Nic, тоже раньше рассматривал Xamarin, но теперь знакомые разработчики, которые работали з этим, отговаривают Видимо, на рынке мало Xamarin-вакансий относительно количества разработчиков Да и отсутствие опыта работы с C# скажется на качестве пакета.
Netspirit, создание мобильных приложений в 2019 сложно назвать программированием в принципе Скорее, использование (часто неуместное) модных технологий с примесью копипаста кода с самых различных и непроверенных источников. Конечно, в какой-то мере шутка, но и доля правды есть, особенно глядя на последние проекты, попавшие мне в руки от других разработчиков. |
|||
карма: 5 |
|
Ответов: 1821
Рейтинг: 168
|
|||
Прошу владельцев смарт-девайсов пройти опрос (всего один вопрос). Это позволит точнее выбрать технологию для будущего пакета. https://forms.gle/FrfdC3dAnhFo18t59
|
|||
карма: 5 |
|
Ответов: 1821
Рейтинг: 168
|
|||
По результатам голосования решено использовать React Native, обеспечивающий кроссплатформенность (Android + iOS) с возможностью использования нативных контролов.
Один из вопросов, ради которого создавалась тема. Как правильнее задавать ARGB цвета в свойствах элемента? Если я правильно понимаю, у нас поддерживается только RGB. Пока что вижу вариант с указанием цвета и прозрачности по отдельности. В таком случае возникает вопрос, какой диапазон лучше использовать: [0..1] или [0..255]? Возможно, у кого-то есть еще идеи? Редактировалось 2 раз(а), последний 2019-08-01 16:01:54 |
|||
карма: 5 |
|
Ответов: 4628
Рейтинг: 749
|
|||
sаmakacd писал(а): Пока что вижу вариант с указанием цвета и прозрачности по отдельностиsаmakacd писал(а): какой диапазон лучше использовать: [0..1] или [0..255] |
|||
карма: 26 |
|
Ответов: 1821
Рейтинг: 168
|
|||
Netspirit, в runtime цвет задается в виде hex (почти как в Android в xml-файлах), по этому ни одно из числовых значений напрямую не используется. Интересно, какой из вариантов будет интуитивнее пользователю пакета. [0..1] лучше, когда это значение задается как результат вычислений, когда как [0..255] подразумевает (по крайней мере мне), что используется целое число-байт (но есть ли толк от этого?).
Кроме этого, нужно ли групировать компоненты цвета (сам цвет и прозрачность) в свойствах? Большинство элементов будут содержать минимум два свойства-цвета, будут также и с большим количеством (к примеру, глобальная таблица стилей проекта). Редактировалось 1 раз(а), последний 2019-08-02 10:35:44 |
|||
карма: 5 |
|
Ответов: 4628
Рейтинг: 749
|
|||
sаmakacd писал(а): Кроме этого, нужно ли групировать компоненты цвета (сам цвет и прозрачность) в свойствах?- Color+Transparency - BgColor+BgTransparency (BgTransp) - TextColor+TextTransparency - Color1+Transp1, Color2+Transp2 А создавать группы по 2 свойства - ну, посмотри, удобно ли оно будет выглядеть в Панели. Думаю, не стоит. |
|||
карма: 26 |
|
Главный модератор
Ответов: 2999
Рейтинг: 396
|
|||
Небольшое уточнение. Значение цвета в среде HiAsm 4 хранится как 32-битное целое. То, как оно (значение цвета) интерпретируется в среде это в первую очередь её (среды) проблемы и уже потом проблемы разработчика насколько корректно и/или удобно пользоваться данным способом хранения. Разработчик пакета может сам решить в каком виде хранить данное свойство. Конечно, выбор здесь небольшой: integer или string или real. Например, можно использовать даже тип 3 (TData) - получится универсально: можно записать в любом из 3-х видов и даже как-нибудь использовать значение NULL.
P.S. offtop В проекте HiAsm.NET на данный момент помимо свойств, наследованных из сред 4-й и 5-й версий, используются также новые типы: data_time, data_bool, data_long, data_char, data_float, data_decimal и некоторые другие. Это позволило упростить разработку Core пакета проекта и расширить возможности по разработке элементов. Редактировалось 2 раз(а), последний 2019-08-02 13:02:30 |
|||
карма: 6 |
|
Ответов: 1821
Рейтинг: 168
|
|||
Nic, для работы с этими типами создавали кастомный редактор свойств?
|
|||
карма: 5 |
|
Главный модератор
Ответов: 2999
Рейтинг: 396
|
|||
sаmakacd писал(а): для работы с этими типами создавали кастомный редактор свойств?Неоднозначный вопрос. Если Вы говорите про возможности использования в ini-файле элемента ключа Handle, то нет. Но если это вопрос про редактор свойств, используемый в среде, то использование новых типов как раз и упрощает их редактирование средой. |
|||
карма: 6 |
|
Ответов: 1821
Рейтинг: 168
|
|||
Nic, получается, я имел ввиду и одно и другое, так как сначала подумал, что в HiAsm.NET Вы добавили поддержку этих типов через Handle в ini-файле.
Интересно, насколько реалистично реализовать диалог выбора цвета как пользовательское свойство. Редактировалось 2 раз(а), последний 2019-08-02 17:19:46 |
|||
карма: 5 |
|
Главный модератор
Ответов: 2999
Рейтинг: 396
|
|||
карма: 6 |
|
14