Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 7
Не понимаю, зачем Qt на телефоне, за исключением того, что компания зарабатывает на подписке таких любителей. Одно дело писать для десктопа, совсем другое — для телефонов. Не знаю, как с iOS, но в Android при разработке на Qt придётся делать JNI-обёртки, много. И ещё объём внешних зависимостей напрягает. Вот скриншот структуры:
Вариант справа подразумевает запаковку всех зависимостей в APK, что добавит 30-40мб сверху. И это не ассеты для игры, а рантайм для вашего калькулятора.
Вариант слева требует установки внешнего хелпера Ministro, что возвращает нас в 2004 год, когда в PalmOS нужно было устанавливать всякие рантаймы вроде PocketC Runtime. Типичная реакция современного пользователя
Если, разумеется, вы не раздаёте планшеты с вшитым Ministro и самим приложением всяким ведомствам под заказ.
Имхо, единственная фича от всего стека Qt, которая реально пригодилась бы на телефонах — это Qml/QtQuick для действительно сложных приложений, которые и не должны копировать нативный интерфейс. Как Photoshop на ПК — не копирует нативный интерфейс, а работать удобно. Таким и +30мб на рантайм не жалко.
Причём для работы QtQuick достаточно лишь NativeActivity и сюрфейса, по которому рисовать. Разработка таких приложений будет идти легче. В основном из-за заранее низких ожиданий — мол, что вы хотите, это же NativeActivity. А надеяться на идеальный порт Qt, с его-то виджетами и модулями вроде QtXml, при разработке под Android (.., iOS, ..) — это удел особо упоротых.
Вариант справа подразумевает запаковку всех зависимостей в APK, что добавит 30-40мб сверху. И это не ассеты для игры, а рантайм для вашего калькулятора.
Вариант слева требует установки внешнего хелпера Ministro, что возвращает нас в 2004 год, когда в PalmOS нужно было устанавливать всякие рантаймы вроде PocketC Runtime. Типичная реакция современного пользователя
Если, разумеется, вы не раздаёте планшеты с вшитым Ministro и самим приложением всяким ведомствам под заказ.
Имхо, единственная фича от всего стека Qt, которая реально пригодилась бы на телефонах — это Qml/QtQuick для действительно сложных приложений, которые и не должны копировать нативный интерфейс. Как Photoshop на ПК — не копирует нативный интерфейс, а работать удобно. Таким и +30мб на рантайм не жалко.
Причём для работы QtQuick достаточно лишь NativeActivity и сюрфейса, по которому рисовать. Разработка таких приложений будет идти легче. В основном из-за заранее низких ожиданий — мол, что вы хотите, это же NativeActivity. А надеяться на идеальный порт Qt, с его-то виджетами и модулями вроде QtXml, при разработке под Android (.., iOS, ..) — это удел особо упоротых.
Никто и не предлагает использовать Qt Widgets на телефоне, они ведь не подходят для сенсорно-ориентированных интерфейсов, да и ведут себя по-другому.
Ну, всё равно порт Qt на Android включает в себя и это в том числе.
А вообще, может быть два подхода с QtQuick — первый, это когда QtQuick используется как часть приложения, а всякие диалоги/меню и так далее вызываются стандартными средствами Android. Второй — когда используется NativeActivity, то есть в режиме для игр, когда взаимодействие с пользователем лежит на плечах программиста QML.
И их отказ от NativeActivity был следствием углубления в первый.
Но, как я уже наисал выше, если требуется хорошая интеграция и нативные контролы — лучше уж сразу идти учить Android SDK и забить на возню с Qt. Xamarin уже давно всё умеют, и C# приятней C++/Qt, однако когда дело доходит до приложений и до взаимодейтсвия с Android SDK — начинается боль.
Screen 1
А вообще, может быть два подхода с QtQuick — первый, это когда QtQuick используется как часть приложения, а всякие диалоги/меню и так далее вызываются стандартными средствами Android. Второй — когда используется NativeActivity, то есть в режиме для игр, когда взаимодействие с пользователем лежит на плечах программиста QML.
И их отказ от NativeActivity был следствием углубления в первый.
Screen 2
Но, как я уже наисал выше, если требуется хорошая интеграция и нативные контролы — лучше уж сразу идти учить Android SDK и забить на возню с Qt. Xamarin уже давно всё умеют, и C# приятней C++/Qt, однако когда дело доходит до приложений и до взаимодейтсвия с Android SDK — начинается боль.
Процесс кодинга Xamarin/C# под Android
Причём для работы QtQuick достаточно лишь NativeActivity...
И их отказ от NativeActivity был следствием...Я запутался, вроде как верно первое, и NativeActivity и используют. Клавиатура есть, лейоуты тоже, мультимедиа поддерживается. Другое дело, что контролов/стилей нет, потому до написания стандартных приложений еще далеко, но интеграция будет как в Xamarin, это да.
Причём для работы QtQuick достаточно лишь NativeActivityЭто верно технически.
NativeActivity и используютНет, они сделали QtActivity.java. Слайд про минусы NativeActivity не мой, это из вебкаста «Qt on Android: Is it right for you?» от авторов порта, вероятно они что-то скрывают. ;)
Тут скорее вопрос в адаптации. В свое время на платформе Meego Qt-приложения выглядели и работали очень по-мобильному. Я когда ради интереса написал клиент к mpd (точнее даже не написал, а скомпилировал написанный ранее под десктоп), он выглядел и работал лучше, чем другие, написанные на gtk-mm. Так что если разработчики Qt поднатужатся и сделают так, чтобы все стандартные контролы выглядели и работали как нативные, получится натуральная конфетка.
вкусно… пошел обновляться!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Версия Qt 5.3 доступна для загрузки