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)
Ответ на: комментарий от umren

и да, в простых примерах у тебя все возможно будет работать норм, типа один экранчик который в QML рисует прямоугольник и проблем не будет на всех платформах, но когда тебе нужно будет общаться с android sdk или вызывать objc код в большом количестве, когда тебе нужны будут «нативные» анимации и прочее, вот тут начнется веселуха.

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

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

Не все продукты срочные, а разработчик вполне может быть в штате. Нужно быстрее? Значит будет N Qt разработчиков.

логику на сервере пиши

Offline приложение с синхронизацией.

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

Вся логика через JNI — это тушите свет просто.

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

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

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

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

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

Где ты там iOS увидел?

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

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

Убогий интерфейс можно сделать и на нативных компонентах, а писать на Java — уже страдать.

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

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

А можно чуть больше фактов, зачем придется вызывать JNI на каждый чих для среднестатистического приложения? Разве не ты только что писал о выносе логики в С++?

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

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

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

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

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

и да, в простых примерах у тебя все возможно будет работать норм, типа один экранчик который в QML рисует прямоугольник и проблем не будет на всех платформах, но когда тебе нужно будет общаться с android sdk или вызывать objc код в большом количестве, когда тебе нужны будут «нативные» анимации и прочее, вот тут начнется веселуха.

Общаться с android sdk и вызывать objc код проблем нет вообще. Что такое «нативные» анимации? Что «прочее»?

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

типа один экранчик который в QML рисует прямоугольник

Я же тебе пример выше привел: полный набор стандартных контролов выглядящих нативно на андроиде. Мне сейчас с трудом представляется ситуация, где этих контрлов для среднестатистического приложения не хватит. (И, да, это приложение будет выглядеть лучше, чем ряд «нативных» приложений, которые я видел (в которых «нативный интерфейс» времен андроида 2.3 ещё)).

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

И вообще, в этих ваших мобильных приложения такой зоопарк интерфейсов - про каждое приложение можно сказать «кто в лес, кто по дрова». У каждого свои свистоперделки, свои способы выводить информацию.

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

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

Фишка в том, что ты будешь сидеть изучать нативный сдк, а потом делать мартышкин труд перегоняя это в свой Qt, обмазывая и типизируя это. Писать тесты на все это. Тупая работа.

экономили времени на написании интерфейсов

И получили худший интерфейс который нигде не выглядит нормально

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

Я же тебе пример выше привел: полный набор стандартных контролов выглядящих нативно на андроиде

Они слабо похожи на андроидовые, но если ты собираешься писать только под андроид на Qt, игнорируя iOs, то какой в этом смысл? ты только потеряешь время, когда мог бы использовать «родной» интерфейс.

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

Общаться с android sdk и вызывать objc код проблем нет вообще. Что такое «нативные» анимации? Что «прочее»?

Поизучай на досуге

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

umren ★★★★★
()
Последнее исправление: umren (всего исправлений: 1)

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

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

Фишка в том, что ты будешь сидеть изучать нативный сдк, а потом делать мартышкин труд перегоняя это в свой Qt, обмазывая и типизируя это. Писать тесты на все это. Тупая работа.

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

И получили худший интерфейс который нигде не выглядит нормально

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

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

Они слабо похожи на андроидовые

Какой конкретно контрол не похож?

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

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

Хочу, и это работает, причем без особых усилий.

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

значит ты большой и способный молодец, раз ты шевелишь одним пальцем и все просто работает в продакшене на всех устройствах итд :)

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

Да, берите Qt mobile

Это не «Qt mobile». Это просто Qt.

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

хочешь мультмедию? камеру?

Не вижу проблемы:
http://doc.qt.io/qt-5/examples-android.html
http://doc.qt.io/qt-5/multimedia-examples.html

бекграунд сервисы? нотификации?

Ну напишу я себе сервис, не rocket science, ей богу (писал уже). Вопрос лишь в выборе IPC.

хочешь поработать со стореджом?

И в чём проблема? Пути - они и в африкеоффтопике пути.

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

Повторяюсь: цель потыкать Qt и QML, но чтобы было интересно - тыкать применительно к кросс-платформе и эмбеддед, кроме того у меня давно была идея написать одно мобильное(ведроид) приложение, но если оно будет кросс-платформенным - ещё лучше.

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

Вы на Qt/QML писали? а как решили проблему с размером итогового приложения под iOS - там же простейшее QML-приложение около 40 Мб занимает :(

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

там же простейшее QML-приложение около 40 Мб занимает :(

Ну так оно ж потом при усложнении в размере почти не растет. А насчет размера - у меня, например, примитивная программа для бега/статистики шагометра 111Мб занимает, причем она не на Qt, и как-то пофиг.

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

ребят устраивает.

Не все пишут под калькуляторы.

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

Вы на Qt/QML писали? а как решили проблему с размером итогового приложения под iOS - там же простейшее QML-приложение около 40 Мб занимает :(

На QML, никак не решали, весит 25 мегабайт.

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

Очень интересно, т.к. у меня намного больше. Использую последние XCode и Qt (5.6), какие есть в природе. Проверял размер на Qt Quick Controls Gallery - около 37 Мб релизная сборка занимает.

А так мое приложение еще с кучей других либ, то итоговый размер executable переваливает за разрешенные Apple 60 Мб :(

Видимо, я один такой.

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

Тупо захожу в папку с собранным Application Bundle (MyApp.app), путь к которой задается в настройках сборки. Ну и смотрю его размер в Finder (правой кнопкой -> Show package contents -> смотрим на исполняемый файл). У меня получилось, что именно исполняемый файл огромный, зараза. И кстати от версии Qt это оказывается не зависит, уже перепробовал несколько. Скорее видимо виновен clang. У меня XCode последняя установлена. Ну или мои кривые руки, да :)

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

А насчет стиля не заморачивался - в моем приложении это неважно. Вроде выглядит сносно, размеры всех контролов нормальные, кнопки тыкаются, текст вводится. Что еще надо

anonymous
()

Говоря о нативном и не очень. Но, внезапно, QGeoCoordinates на android'е (эмулятор и девайс) имеют всегда altitude=0. На десктопе с моим источником данных позиционирования (читающим gpx) высота высота правильная.

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

Я цифру 60 первый раз вижу, ссылки на пруфы битые, так что наверное можно не переживать за этот момент. Думаю в крайнем случае можно залинковать динамикой, у iOS 7 уже доля очень маленькая.

CrossFire ★★★★★
()
Последнее исправление: CrossFire (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.