QtQuick/QML для Android в 2021

делать приложение на C++/QtQuick/QML

И при этом получить немного опыта в разработке для Android.

Крестик либо трусы…

На Qt имеет смысл затевать мобильную разработку, только когда у тебя много ещё другого кода уже есть или планируется на Qt и/или на плюсах.

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

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

Есть конечно ещё вариант, что ты кутишников просто потроллить хочешь, но это то всегда пожалуйста, тут любые средства хороши.

QML говно и не нужно, делай на виджетах, будет одинаковый вид с десктопом :)

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

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

Т.е. на java? Или Kotlin?

Есть конечно ещё вариант, что ты кутишников просто потроллить хочешь

Все по чесноку. Сегодня несколько часов убил на настройку сборки.

Скоро придет EXL и аргументированно ответит на твой вопрос)

Перекрестись, помолись, сплюнь три раза и постучи по ближайшему дереву. Android разработка давно перешла на Kotlin + RxJava и вполне себе перестала быть костыльной. Использовать что-то за пределами данный инфраструктуры это стрелять себе в ногу из гранатомета.

RxJava уже тоже считается костылём и ненужным легаси.

Давно замечательно работают корутины.

Зачем смотреть в сторону нативной разработки, так и в сторону кривых фреймворков, если есть Flutter, который активно развивается и имеет более низкий порог входа, чем все традиционные подходы.

Flutter куда проще и эффективнее.

Android разработка давно перешла на Kotlin + RxJava и вполне себе перестала быть костыльной

Я тебя искал по всему лору. Нахрена нужно RxJava? По отзывам, которые я получал, это наколенная поделка с безумно сырой и замороченной отладкой. То есть, что-то близкое к определению костыля.

Имхо, Котлин после крестов это как чаша воды после ада?

Щас эту херню RxSwift, RxJS пихают везде, тупо, чтобы корпорациям было проще находить болванчиков на асинхронные UI, без этих UI вся эта херота Rx нафиг не упёрлась, а до дебага гланд через попу им похрен, этим менеджерам, не им же «кодить»

ты искал юзера rxjava, чтобы спросить его ЗАЧЕМ ОН ЭТО ДЕЛАЕТ? )

Пытались делать, но истории успеха не получилось. Это примерно как проводить компьютерную диагностику нового porshe caynenne китайским универсальным прибором

Т.е. на java? Или Kotlin?

Ага. Дальше вопрос, ты хочешь мобильную разработку или Android разработку например? Это ведь вопрос уровня ты хочешь под онтопик, под винду или под десктоп.

Только Android. И пока это скорее всего разовая акция для личных нужд.

Как так выходит что для ведроида еще кто-то что-то пилит? На телефонах же ничего нельзя делать, ну серьезно, вот что на них вообще можно?! Установить энгри бердс и продвинутый аудиоплеер? Зачем нужны программисты на андроид/ios? Я правда не догоняю. Ну разве что донатные дрочильни еще пилят, а так в плей маркете и так уже клон на клоне. Но игры не берем в расчет. Объясните.

Это примерно как проводить компьютерную диагностику нового porshe caynenne китайским универсальным прибором

Это ты щас андроид с порше сравнил, а культю с китайским прибором? Всгаркнул с неадеквата. Андроид - это максимум audi 100 avant, а культя - весьма специфичный прибор.

Flutter и Dart - это самый простой и лёгкий способ написать приложение под Android.

Писать на чистом Java/Kotlin - это как писать на C++ и чистом Win32 API. Сразу прочувствуешь всё убожество Android.

Ну а на счёт Qt/QML под Android, у меня сложилось в впечатление что opensource версия очень глючная(возможно специально). Костыли и грабли там на каждом шагу.

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

Это про удобство, производительность и результат разработки

Писать на чистом Java/Kotlin - это как писать на C++ и чистом Win32 API.

Даже так? Я то думал, что там как-то относительно высокоуровнево, типа как писать на Qt под десктоп.

Примерно так и есть - относительно высокоуровнево.

Во флаттере просто декларативный способ описания интерфейса, как в swiftui под macos/ios.

На QT собрал пяток демок для андроида - интерфейс довольно убогий, но диких глюков не заметил. Хотя демки ничего особенного не делали.

карты, навигаторы, плееры, спортивные трекеры/пульсометры, календари, мессенджеры

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

Короче пока что я насчитал 32 программиста на все юзкейсы андроида.

анализаторы сети.

щето?

Вот пример - есть потребность в разработке приложения для отечественного тонометра. С мониторингом давления, пульса и отсылкой результатов в ИС поликлиники/больницы лечащему врачу. Причем у этой ИС свой формат и протокол обмена. Есть подходящий вариант из гугл-плея?

анализаторы сети.

щето?

Ну это уже больше для сисадминов конечно. Ну там собранные в одном ping/nslookup и прочее.

Короче пока что я насчитал 32 программиста на все юзкейсы андроида.

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

Импортозамещение не в расчет. А если в расчет - просто нанимаем клонов уже известных 32 программистов.

С мониторингом давления, пульса и отсылкой результатов в ИС поликлиники/больницы лечащему врачу. Причем у этой ИС свой формат и протокол обмена.

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

Это очень интересно, учитывая что в реальном мире на проекты все хотят Rx разработчиков) Не очень понятно как корутины бьются с RxJava. Корутины это как раз и есть костыль над императивным программированием, потому что многие разработчики не погут понять простого факта - все приложение может быть представлено в виде многоуровневего хорошо декомпозированного реактивного потока событий. Без понимания этого факта они начинают костылить, пытаются использовать rx как фьючи или корутины. В итоге получается тонна говна вместо кода. И корутины по сути заменяют одно говно на другое. Сколько можно писать qt подобный код и обмазывать его плохо стыкуемыми между собой императивными конструкциями?

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

Ну да, свистоперделки конечно пилить кому-то нужно, с этим спорить не буду. Может я переоцениваю рельное кол-во мобильных программистов, но порой меня попросту удивляет их существование как класс. Наверное я какой-то аутист не умеющий в реальность.

Ну смотри, я с RxJava знаком по верхам (писал на нем небольшой пет проект для дроида), но я использовал его по сути клон Project Reactor. Мы на нем сделали агрегатор платежей, 28 микросервисов, 50 миллионов платежей в сутки с довольно замороченными интеграциями с банком. Работало нас там 6 человек, ни у кого особых проблем эта технология не вызывала. Даже я бы сказал наоборот, большая часть согласилась с тем что rx подход действительно эффективнеие прочих. Я лично взял rx как core технологию для работы на последующих проектах.

Наверное отчечу так же как и ранее - непонимане технологии разработчиком не делает из этой технологии костыль.

З. Ы. Это конечно все уход от темы топика. Я вообще хотел сказать изначально что не нужно пилить доски дрелью. Для каждого места сейчас существует принятая устоявшаяся и хорошо проверенная технология. На android это kotlin+sdk+(что сами хотите, rx, co, callback hell). Но никак не qt и с++.

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

Да, много. Предприятия хотят софт для планшетов, с интеграцией в их АСУТП.

на плечах разработчика тонометра только поддержка Health Device Profile.

на примере казначейства - их ваще не волнует проблема своего протокола обмена платежками и прочим. они тебе описание и формат дали - реализация за тобой :)

Сколько можно писать qt подобный код и обмазывать его плохо стыкуемыми между собой императивными конструкциями?

В чем по твоему проблема Qt кода?

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

Смотря для чего ты это все хочешь делать. Если по фану ради поковыряться именно с этими технологиями - делай на них. Если задача сделать нормальное работоспособное приложение - бери натив, ИМХО,

Я вот сейчас буду писать приложения для сервера своего под обе оси - и яблоко, и робот. Долго думал тоже, но решил писать на нативных языках под оба: оно тогда гарантированно будет работать как надо без непредсказуемых косяков.

Как так выходит что для ведроида еще кто-то что-то пилит?

Да сейчас у каждого магазина есть приложение, даже если оно не нужно.

Интересное обсуждение здесь https://forum.qt.io/topic/112466/qt-quick-vs-flutter/16. Человек пишет про то что разрабатывал несколько коммерческих приложений для мобильных устройств именно на QtQuick.

Проблема в отсутсвии возможности полноценной интероперабельности за пределеми самого qt, или попросту крайне низкая экстенсивность. Наверняка тебе приходилось слышать такие термины как промисификация, фючеризация, реактивизация. Это когда мы берем интерфейчас какого-то внешнего апи, и путем навешивания фасада подгоняем его под концепцию работы основного фреймфорка. Если язык программирования поддерживает расширения, наподобие scala или kotlin, то это позволяет создать вообще бесшовный интерфейс между приложением и библиотечным апи. Вот как пример из андроида:

button.setReactiveOnClickListener().<stream processing>

Навесили реактивный фасад на кнопку в виде расширения. Никаких коллбеков, теперь у нас одним вызовом есть стрим с событиями нажания на кнопку, который мы можем обрабатывать, комбинировать с другими стримами и т. д. Это вот как раз и есть пример высокой экстенсиовности фреймворка. В Qt с его сигналами и слотами и очень жесткой ориентированности на ООП эти возможности очень ограничены. Т е я не могу просто так взять какую-то стороннюю библиотеку и заставить ее работать в рамках парадигмы слот-сигнал без создания очень массивного адаптера. А без такого адаптетра будет окостыливание кода, потому что придется inPlace работать с библиотекой создавая callback hell. Короче говоря пока мы работаем внутри инфраструктуры qt у нас все замечательно, но как только мы за нее выходит, начинается жесть.

Да сейчас у каждого магазина есть приложение, даже если оно не нужно.

Пожалуй это я еще могу понять. Но на поддержку и написание всего этого ипользуются говнопрограммисты. По сути, достаточно было бы 33-го программиста-чэда, который бы написал конструктор говноприложений для магазинов, в котором бы дезигнеры и дресированные вэб-макакичи рисовали бы свой гуй как им вздумается. А базами данных занимался бы 34 чел, который занимается базами данных. То есть то что у каждого магазина свое приложение - это искуственная проблема, с реальностью нужного программного обеспечения имеющая мало чего общего.

нужного программного обеспечения

Определение «нужности» в студию.

Я уже предложил как решить эту проблему - через 33-го и 34-го программиста. Ненужно - это когда магазины какие-то пердольные фичи хотят, которые на самом деле не нужны, но, к примеру, усложняли бы задачу двум названным программистом. Вряд ли бы на самом деле нашлись бы такие фичи, но если они есть, то они и есть ненужно.

Возможно для тебя, как разработчика привычней думать на более высоком уровне абстракции и Kotlin (наверное и Java) это хорошо позволяет делать. И в принципе честь и хвала за это. И поэтому в обсуждении в данном случае Qt (да собственно пожалуй вообще C/C++-ой инфроструктуры) ты приводишь аргументы в смысле оценки того, что уровень абстракции здесь гораздо ниже чем в Kotlin/Java. Но тут уж ничего не поделаешь: да C/C++ состоят из функций/калбэков/указателей и т.п. Это цена того, что эти языки стоят на лестнице абстраций ближе к ассемблеру чем Kotlin/Java.

А без такого адаптетра будет окостыливание кода, потому что придется inPlace работать с библиотекой создавая callback hell. Короче говоря пока мы работаем внутри инфраструктуры qt у нас все замечательно, но как только мы за нее выходит, начинается жесть.

Ну тут варианты есть. Например в текущем проекте мы используем Qt, PyTorch, OpenCV и еще несколько библиотек рангом поменьше. Так вот рулит конечно всем Qt. В основном все операции выполняются в слотах Qt. Некоторые затратные операции выполняются в отдельных потоках, организованных опять же через функционал Qt. Данные между потоками гоняются либо посредством Qt-шных сигналов/слотов (при этом типы могут быть отличные от Qt-шных) либо посредством QFuture (опять же типы могут быть не исключительно Qt-шные). Собственно никаких других калбэков кроме Qt-слотов не использовали.

Мы на нем сделали агрегатор платежей, 28 микросервисов, 50 миллионов платежей в сутки с довольно замороченными интеграциями с банком

Тысяча запросов в секунду в пике — это не та нагрузка, которой хвастаются. У меня под боком есть сервис на PHP+MySQL, который примерно такую же нагрузку поднимает. Да, там есть очередь и мускуль зеркалирован, но факт остается фактом.

ни у кого особых проблем эта технология не вызывала. Даже я бы сказал наоборот, большая часть согласилась с тем что rx подход действительно эффективнеие прочих

У вас там была какая-то действительно сложная реактивность с backpressure? Обычно в микросервисах такой не возникает, поскольку каждый сервис выполняет простую задачу, а backpressure реализуется предельно тупо в лоб — что меня и удивляет в твоем описании.

Это конечно все уход от темы топика. Я вообще хотел сказать изначально что не нужно пилить доски дрелью

Я не просто так интересуюсь асинхронщиной — я всю свою карьеру вскользь мимо нее проходит в моих GUI и фронтенде, но каких-то по-настоящему годных решений не находил. Вот гештальт и не закрыт. Краткое содержание предыдущих серий:

Недостатки реактивного программирования (комментарий)
Мода на RxJava RxJS RxSwift (комментарий)
Как превратить негативное отношение в позитивное? (комментарий)

У меня по прежнему нет ощущения, что я понимаю преимущества и недостатки Rx (хотя, с чего бы оно возникло, если я на нем не писал). Да, мне нравится радужная идея фреймворка для реализации сложных реактивных алгоритмов, но, вот беда, пока что я не увидел решения проблем ОРГАНИЗАЦИИ этих реактивных алгоритмов.

Например, у нас отменяется некая задача, при этом должны оперативно отменятся и зависящие от нее, и высвобождаться ресурсы. В том числе отменяется из-за банальной ошибки выполнения, которая может идти не только прямо, но и в обратном направлении — backpressure является типичным примером, который, однако, реализован не какими-то штатными инструментами, а, кажется, сплошными костылями, дополнительными аргументами для передачи размеров буферов, и радостями класса MissingBackpressureException, из-за которых теперь Observable отделен от Flowable.

Вторая проблема организации, которая не решена в Rx и которую я упомянул — это отладка. То есть, какой поток откуда притек и куда держит путь.

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

Как ни странно, эти проблемы более-менее решены для узкого круга задач в реактивных фреймворках, вроде React.js или (в меньшей степени) Vue.js, где для их решения, прежде всего, разработка переведена на декларативную колею, когда конкретный алгоритм выполнения определяет фреймворк, и даже функция render на самом деле скорее генерирует параметризованное декларативное описание, чем выполняет какие-то действия по отрисовке. Одним из первых исторических проектов реактивного програмирования, к слову, была именно библиотека для реактивной анимации, которая в декларативном стиле описывала поведение, а потом уже либа-исполнитель сидела и думала, как эти описания выполнять.

Интересное обсуждение здесь https://forum.qt.io/topic/112466/qt-quick-vs-flutter/16. Человек пишет про то что разрабатывал несколько коммерческих приложений для мобильных устройств именно на QtQuick

Очень приторное описание. Особенно настораживает тот факт, что он рекламирует свою книгу про Qt6-for-mobile.

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

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

Особенно настораживает тот факт, что он рекламирует свою книгу про Qt6-for-mobile.

Ну а может годная книга будет.

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

У нас тоже CRM/документы с сохранением истории. Люди уже совсем забыли, что одно ядро процессора умеет выполнять миллиарды операций в секунду, таких ядер на сервере могут быть десятки, а это значит десятки-сотни миллиардов операций на одном компьютере. В банках до сих пор процессинг работает на коболе, который некогда исполнялся на железе по производительности где-то на уровне 8086.

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

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

Мы уходили в прод с несколькими простыми QML програмами на iOS, там поддержка Qt хуже, чем на андроиде и других юзеров меньше. В целом жить можно. А на андроиде и лучше поддержка Qt, и коммьнити есть. Сам на андроиде только личную небольшую прогу писал, мне было норм.

Опиши грубо что тебе нужно от проги.

З.Ы. на твой вопрос в другой теме я писал ответ, но не отправил и текст провтыкался. Сори, писать ещё раз влом.

На С конечно

https://github.com/cnlohr/rawdrawandroid

Зачем нужны программисты на андроид/ios?

Затем, что уже сейчас для школьников андроид — это дефолтная ось, а ещё через несколько лет человек с ПК будет восприниматься примерно как сейчас человек с серверной стойкой в квартире. Будет, как было 10 лет назад с виндой («А что, бывает что-то ещё?»), только хуже. Потому, что ПК был на открытой архитектуре. А смартфоны и планшеты, как говорят знающие люди — огороженный зоопарк.

Что с этим делать — не знаю. Разве что появятся новые RMS и новые Линусы и сделают в дополнение к открытом софту открытое железо. Но понятно, сделать его гораздо сложнее, ибо стоимость тиражирования совсем не нулевая, и правительства с корпорациями палки в колёся будут совать намного активнее.