LINUX.ORG.RU

Qt for Android, но не для людей?

 ,


1

2

Имеем: android ndk & sdk, Qt 5.6 for Android, QtCreator.

Создаю QtQuick хэлоуворлд для андроида. Всё компилируется на десктопе и кросскомпилируется для андроида. Дальше начинается:

  • При попытке запустить на эмуляторе android 5.1 - отваливается при деплойменте.
    20:22:32: The process "/media/igor/data/devel/Qt5.6.0/5.6/android_x86/bin/androiddeployqt" exited normally.
    Error while building/deploying project qmldroid (kit: Android for x86 (GCC 4.9, Qt 5.6.0))
    When executing step "Deploy to Android device"
    Приложение на эмулятооре не появляется. Прочитал тут, что может Qt 5.4 не очень хорошо деплоится с 5.1. Ок, думаю, наверное для Qt 5.6 еще не починили...
  • Пробую собирать и задеплоить на 4.4... Компилируется, вроде даже деплоится, но видимо как-то не полностью. В итоге приложение вылетает.
    20:07:38: Packaging error: Command "/media/igor/data/devel/android_sdk/android-sdk-linux/platform-tools/adb -s emulator-5554 pull /system/bin/app_process32 /home/igor/projects/qml/build-qmldroid-Android_for_x86_GCC_4_9_Qt_5_6_0-Release/app_process" failed.Exit code: 1
    и
    F/libc    ( 1961): Fatal signal 8 (SIGFPE) at 0xb77c9ac8 (code=1), thread 1985 (xample.qmldroid)
    

Что я делаю не так?... Есть те, у кого оно работает? :)

upd: Ради прикола попробовал под ведной поставить чистое окружение - заработало. Теперь вот думаю... что ж я поломал под онтопиком.

upd1: Всё, разобрался. Проблема была очоевидно о в том, что Qt не правильно установился. Когда ставил первый раз, то использовал offline installer. Сейчас переставил с помощью online-instaler'а и таки всё заработало.

★★★★★

Последнее исправление: invy (всего исправлений: 2)
Ответ на: комментарий от CrossFire

QtCreator -> File -> New File or Project -> Qt Quick Application ... Выбрать в качестве Kit'а Android for ..., собрать и запустить.

invy ★★★★★
() автор топика
Ответ на: комментарий от CrossFire

Вот и вопрос ЧЯДНТ?...

invy ★★★★★
() автор топика

я смотрел поверхностно, но трогать _это_ не стал.

смотри в сторону нативной разработки и не майся ерундой.

umren ★★★★★
()
Ответ на: комментарий от umren

смотри в сторону нативной разработки и не майся ерундой.

Ага, и под каждую платформу всё переписывать. Спасибо за совет, я уж лучше разберусь, почему у меня не работает.

invy ★★★★★
() автор топика

Я сделал себе вот такую записульку про Qt 5.2.0 for Android:

Как установить среду разработки Qt 5.2 под Android в Linux и как скомпилировать первую программу

Посмотри, может тебе поможет, может ты что-то забыл.

К сожалению, по моему опыту, приложения под Андроид собранные из Qt работают очень нестабильно. Вылетают в тех местах, где вылетать не должны. Есть несколько багов, которые зависят даже не от версии Андроида, а от устройства. Я уже столкнулся с неработоспособностью некоторых вызовов и на Samsung Galaxy Tab 3, и на Honor 6, и закрывать эти проблемы не собираются. Так что с Qt+Android все очень грустно, хотя идея практически работоспособна, и много чего сделано, но не до конца.

Xintrea ★★★★★
()
Ответ на: комментарий от invy

Тут вопрос больше в том, к кому ты относишься лучше. К себе или к юзерам. Если к себе, да, не парься и используй кути.(они неюзабельные на андроид почти совсем, но это не принципиально в моём примере)

Если к юзерам, то ты напишешь всё нативно для андроида, т.е. на жабке. Юзерам это будет хорошо тем, что твоё приложение будет весить 5 мегабайт вместо 50 мегабайт(а то и 100, если всевозможные платформы врубить). А приложения в говнодроиде ставятся до сих пор во внутреннюю память, лишь часть можно на карту памяти перенести.

a1batross ★★★★★
()
Ответ на: комментарий от invy

Что именно неюзабельно там?

Возможно, то, что ты сделаешь на QtQuick будет юзабельно.

Но приложения с нативным Qt-интерфейсом без специальных ухищрений юзабельны весьма условно. Просто потому, что они рассчитаны на десктоп с мышкой и клавиатурой, а не на тоуч-экраны. На планшетах 10" еще кое-как можно управиться с Qt-приложениями, но на 5" уже практически нереально, ибо все виджеты не будут помещаться на экран.

Например, для десктопа нормально, когда 3 виджета размещены на одной линии через QHBoxLayout:

Название [___Поле_ввода___] [?]


Но для Андроида даже 3 виджета - слишком много, лучше делать так:

Название [?]
[___Поле_ввода___]


И так на каждом шагу. Особенно доставляют поля редактирования QTextEdit. Даже не на ретина-дисплеях курсор практически невиден.

Нативные размеры кнопок слишком маленькие, и чтобы их сделать большими, нужно пользоваться стилями QSS. Проблема в том, что вся подсистема стилей не доделана. Кнопки еще можно беспроблемно сделать нужного размера. А вот выпадающие списки, выбираторы int-значений с кнопками вверх-вниз или кнопки горизонтальной-вертикальной прокрутки (знаю, что в андроиде они не нужны, но с ними ведь удобнее) - сделать эти элементы нужного вида практически невозможно.

Xintrea ★★★★★
()
Ответ на: комментарий от invy

Ну тогда пусть тебе a1batross объяснит.

Я у QtQuick проблем с юзабилити на мобильном сегменте не вижу.

Xintrea ★★★★★
()
Ответ на: комментарий от invy

HelloWorld apk - 11 метров для x86. Для arm - 8.

Вполне терпимо, если софт стоящий или специализированный - поставят и рады будут (кому надо).

I-Love-Microsoft ★★★★★
()

Около года использую QtQuick для разработки под Android и пока ни разу не сталкивался с проблемой с пользовательским интерфейсом, которую нельзя было бы исправить за 45минут. Нативные элементы Qt использую по минимуму, но это и не нужно в 90% случаев. Единственная сложность была первоначально все собрать и довести до рабочего состояние, где-то пару вечеров на это пришлось потратить.

anonymous
()
Ответ на: комментарий от I-Love-Microsoft

Ну это такая цена портабельности. Зато у тебя твое приложение потенциально работает везде: онтопик, оффтопик, ведроид, огрызок и всякие другие разные эмбеддеды с qnx.

invy ★★★★★
() автор топика
Ответ на: комментарий от invy

Ага, и под каждую платформу всё переписывать.

Ну так как ты только «начал», то через год поймешь что я был прав. Я рассматривал все кросс платформенные варианты, все говно.

Только нейтив, только хардкор.

Кроме того «под каждую платформу» ? есть 2 мобильные платформы только, iOs и Android, все остальное сдохло, ну и зачем придумывать велосипед?

umren ★★★★★
()
Ответ на: комментарий от umren

Кроме того «под каждую платформу» ?

linux, windows, android, ios и прочее эмбеддед.

Ну так как ты только «начал»

У меня цели не «начинать», а потыкать QML, но тыкать его исключительно на десктопе скучно.

все говно.

В каком месте?

invy ★★★★★
() автор топика
Ответ на: комментарий от invy

linux, windows, android, ios и прочее эмбеддед.

А зачем тут нужен Qt, простите?

под андроид есть ндк - компиль свой код, под iOs плюсы и си поддерживаются буквально нативно, в каком месте тебе нужен Qt?

umren ★★★★★
()
Ответ на: комментарий от umren

А под онтопик и венду? Вот я сейчас балуюсь с QGeoPositionInfo - Qt спокойно подхватило GPS из GeoClue на моём ноутбуке. Запущу на андроиде - подхватит андроидовский источник позиционирования. Удобно же... А так под каждую платформу свои велосипеды...

invy ★★★★★
() автор топика
Последнее исправление: invy (всего исправлений: 2)
Ответ на: комментарий от umren

под андроид есть ндк

во-первых, ндк сам по себе не умеет в гуй, особенно кроссплатформенно

во-вторых, человек вроде понятно объяснил, что хочет один раз код написать, а потом везде запускать, поэтому переписывать ему все с жабы на objc/swift и т.п. не с руки.

а в остальном согласен. мобильной кроссплатформы нормальной не бывает. только под каждую отдельно пилить. но если сильно надо — то и qt, и xamarin, и прочие всякие cordova подойдут.

waker ★★★★★
()
Ответ на: комментарий от waker

во-первых, ндк сам по себе не умеет в гуй, особенно кроссплатформенно

гуй и кросстформа? no way, тебя никто никогда незафьючерит, весь топ сторов только нейтив, материал дизайн и Qt? нативные виджеты итд? не, не слышали

если только подделки какие то делать на заказ специализированные, где будут пользоваться 3 колеки

umren ★★★★★
()
Ответ на: комментарий от umren

если только подделки какие то делать на заказ специализированные, где будут пользоваться 3 колеки

думаю, ТСу именно это и надо. вероятнее даже «чисто для себя».

waker ★★★★★
()
Ответ на: комментарий от waker

qt, и xamarin, и прочие всякие cordova подойдут.

cordova подойдет если у тебя примитивное приложение на заказ для 100 человек

xamarin - в теории пишем «один код» - на практике трахаемся с биндингами, пишем свои биндинги, ловим миллион багов (в итоге быстрее сделать под две платформы, чем это)

Qt Mobile если из аппстора поставить, то в примерах он крашится, карл, крашится в официальном приложении, что можно подумать о Qt для мобилок?

umren ★★★★★
()
Ответ на: комментарий от umren

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

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

waker ★★★★★
()
Ответ на: комментарий от umren

в итоге быстрее сделать под две платформы, чем это

я писал «отдельный нативный гуй под ведроид», и это нихера не быстро.

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

waker ★★★★★
()
Ответ на: комментарий от waker

ТС просто

Я уже написал же. Мне хочется потыкать QML, но тыкать его просто так на десктопе - скучно.

invy ★★★★★
() автор топика
Ответ на: комментарий от umren

весь топ сторов

это говно, которое я даже себе в жизни не поставлю наверное :D

invy ★★★★★
() автор топика
Ответ на: комментарий от umren

И что дальше? Либа есть, работает, при желании можно использовать. Кто бы спорил, что нативное лучше, но и дороже в N раз, если деньги есть — однозначно нативное.

CrossFire ★★★★★
()
Ответ на: комментарий от CrossFire

дороже в N раз

Зачем так себя обманывать? цена наоборот зачастую ниже какого-нибудь Qt или Xamarin если нормально просчитать «косты» на двух (минимум допустим) программистов и времени потраченное для качественного результата.

umren ★★★★★
()
Ответ на: комментарий от umren

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

Ну либо мы держим трех разрабов, которые сделают все явно не в три раза быстрее, но добавят в три раза больше багов (одна и та же логика три раза написана), поддержка соответственно тоже дороже.

CrossFire ★★★★★
()
Ответ на: комментарий от CrossFire

Можно же на плюсах написать бэкенд, а фронт под каждую из платформ, полагаю. Интересно как вяжется бекенд на куте и нейтив фронтенд, или это совсем извращение?

Blastbit
()
Ответ на: комментарий от Blastbit

Ну там всё равно JNI и возможность использовать перегруженное Activity есть (судя по тому, что говорит google).

Опять же, можно написать бэкэнд на Qt, прототип гуя на qml, а потом, если дело пойдет, заменить qml гуйю на нативное, оставив qt как бэкэнд.

invy ★★★★★
() автор топика
Последнее исправление: invy (всего исправлений: 2)
Ответ на: комментарий от Blastbit

Можно же на плюсах написать бэкенд, а фронт под каждую из платформ, полагаю. Интересно как вяжется бекенд на куте и нейтив фронтенд, или это совсем извращение?

Ну вот у 2Gis так и сделано, Qt UI только на Android, но у них специфика в том, что основа интерфейса — карта, которая рисуется в плюсах, а остальное уже не такой большой объем.

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

CrossFire ★★★★★
()
Ответ на: комментарий от CrossFire

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

ты не шутишь? «заказчик» будет ждать год продукт, который будет завязан на код одного разработчика? где заменяемость? где скорость?

одна и та же логика три раза написана

логику на сервере пиши, либо если клиентская - выноси в кресты и обобщай (но это для супер больших приложений только которые в любом случае твой один разраб будет делать не год, а лет 5 когда оно никому не нужно будет)

umren ★★★★★
()
Ответ на: комментарий от CrossFire

Ну вот у 2Gis так и сделано

у 2Gis который приводят в 100500 примерах как единственная «история успеха» свой форк Qt лет 5 уже и куча людей которая этим форком занимается, странно что нужно форкать и допиливать переделывать все, Qt же так классно везде работает

umren ★★★★★
()
Ответ на: комментарий от umren

либо если клиентская - выноси в кресты

Внезапно - Qt. Так почему же сразу не заюзать qml для презентации, если логику пишешь на плюсах?

invy ★★★★★
() автор топика
Последнее исправление: invy (всего исправлений: 1)
Ответ на: комментарий от invy

Внезапно - Qt

Qt тут не нужен, виджеты и Qml не нужны, а логику ты собрался на Qt писать? зачем он нужен? интерфейс на могилках в Qt говно еще то, биндинги всякие к сдк ты будешь ждать пока прикрутят?

umren ★★★★★
()
Ответ на: комментарий от umren

Не пойму, ты уже забыл что выше писал или как? А то как-то твои вопросы не сходятся с твоими предыдущими ответами.

либо если клиентская - выноси в кресты
а логику ты собрался на Qt писать? зачем он нужен?

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

интерфейс на могилках в Qt говно еще то

В каком месте QtQuick Controls говно? На вид - очень даже симпотично.
http://doc.qt.io/qt-5/qtquickcontrols-gallery-example.html

биндинги всякие к сдк ты будешь ждать пока прикрутят?

Какие биндинги и sdk? Кто куда прикрутит? Если ты уже на плюсах клиентская логику пишешь, то всё равно будешь использовать JNI. Если на Qt вдруг приспичит использовать что-то, чего нет в Qt, используешь всё то же JNI, я не вижу особой разницы.

invy ★★★★★
() автор топика
Последнее исправление: invy (всего исправлений: 1)
Ответ на: комментарий от invy

В каком месте QtQuick Controls говно? На вид - очень даже симпотично.

Лол, к твоему сведению данный пример пытается эмулировать «старый» iOs который уже года 3 как не в обиходе, интерфейсы на iOs выглядят значительно иначе.

umren ★★★★★
()
Ответ на: комментарий от invy

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

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

umren ★★★★★
()
Ответ на: комментарий от invy

Если ты уже на плюсах клиентская логику пишешь, то всё равно будешь использовать JNI.

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

Потом делать тоже самое для iOs, потому что функции там и там разные.

Итого: времени ты потратишь в два раза больше, чем написав и то и то нативно.

umren ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.