Радость и грусть разработки на Qt под Android (и не только)

На хабре то и дело мелькают статьи об успешном опыте использования Qt для разработки под Android, а также под iOS и WP. Статьи наполнены достаточно большим энтузиазмом — ведь это так здорово: пишешь и тестируешь UI на десктопе, а потом просто собираешь с помощью нехитрых команд под Android, iOS, WP, заливаешь в сторы и готово. В этой же статье я хочу поделиться опытом «собирания грабель» преимущественно при разработке под Android.

Qt я использую достаточно давно, начиная с версии 4.1. Не сказать, что я «профессионально» его использую, но опыт был разный — и работы с виджетами и эволюции до версии 5.6.

Некоторые примеры проектов:

• Пульт управления караоке-центром (Android/iOS)
• Русско-Татарский словарь с кастомной клавиатурой (Android/iOS/WP), тогда ещё даже API для iOS кастомных клавиатур не было
• Cоциальная сеть с разными примбамбахами под Android (гео, блютуз, чаты, фотки, профили и т.д.)
• Приложение для быстрого заказа цветов (Android/iOS/WP)

Кроме того, на Qt написано Android приложение 2gis, на котором вы и можете проверить большинство описанного здесь.

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

Проблема №1

Первое и самое главное на сегодняшний момент: если вам нужно много работать с текстом, вводимым пользователем — не выбирайте Qt/Qml!

Крайне не люблю восклицательные знаки, но тут этот знак на своём месте: вам будет крайне сложно реализовать привычное для пользователей целевой платформы работы с полями ввода, а именно:

1. Выделение текста
2. Copy & Paste

Суть проблемы: баг работы с элементом редактирования ^[1] текста висит аж с 2014 года, отмечен как Important и зарегистрирован пользователем с Silver подпиской, но до сих пор не исправлен. В багтрекере описан обходной путь, но если вы хотите использовать не Quick.Controls а чистый Quick с TextEdit и TextInput — извините.

Возможно кто-то скажет, что я слишком многого хочу и TextEdit/TextInput это базовые компоненты, но, извините меня, отсутствие Copy & Paste в базовых компонентах и отсутствие его реализации в Controls не будут вам доставлять проблем до первого замечания Заказчика.

TextEdit не содержит сигналов работы с указателем, типичных для MouseArea, поэтому попытка реализовать показ контекстого меню через долгое нажатие (PressAndHold в терминах Qml) успехом не увенчается. Кроме того, попытка в лоб обернуть поле ввода в MouseArea подходит лишь для ограниченного числа сценариев, т.к. вам придётся долго и упорно реализовывать выставление курсора между буквами и словами.

Поэтому, остаётся либо лезть в исходники и кастомизировать поле ввода, либо смириться.

Проблема №2

Второе и самое любимое заказчиками приложений, содержащий социализацию: Emoji

Суть проблемы: отсутствует нативная обработка любимых всеми смайликов, что в полях ввода, что в тексте — развивайте фантазию и реализуйте сами.

Узнать, что такое на самом деле Emoji и какова нелёгкая судьба их реализации в различных ОС вам поможет статья в Википедии ^[2]. По факту же, какие есть варианты:

1. Использовать шрифт с поддержкой символов Emoji. Используйте FontForge для компиляции Roboto с Emoji!
2. RichText с заменой символов Emoji на цветные png'шки
3. Глубокая кастомизация поля ввода (можете посмотреть в исходниках телеграмма для десктопа ^[3])

Итого: либо оно выглядит некрасиво (вариант 1), либо глючит (вариант 2), либо требует отличных знаний внутренностей Qt (вариант 3 — а если они у вас есть, вам не стоит труда решить большинство проблем).

P.S. Забавная забавность — не выставляйте никаких inputMethodHints у поля ввода, иначе встроенная Android клавиатура с Emoji (iWinn IME) у вас просто не покажется.

Проблема №3

Третье и самое раздражающее: Мерцание и BlackScreen'ы — ваши лучшие друзья.

Это будет сопровождать вас при загрузке приложения, при попытке выставить windowSoftInputMode в AdjustResize, куски чёрного экрана будут тоже периодически появлятся. Поэтому тестируйте, тестируйте и ещё раз тестируйте на реальных девайсах.

Проблема №4

Четвёртое и самое трудноловимое: Шрифты

Суть проблемы: на разных девайсах каждый год всплывает одно и то же, симптомами похожее на закрытый баг ^[4]. Вы не узнаете об этом, пока счастливый обладатель андроид-девайсана начнёт жаловаться на то, что шрифт плывёт, ломается, невидимый и т.д. В основном, это китайско-корейские девайсы.

Выход здесь только один — брать исходники Qt и патчить под конкретный GPU.

Проблема №5

Пятое и самое спорное: продвинутые контролы Qml — Camera и иже с ними.

Суть проблемы: частые краши, нехватка функциональности и прочие несоответствия стандартного пользовательского опыта нативных приложений. Лечиться это всё очень просто — не стесняйтесь добавлять нативные компоненты (Activity в случае Android) в своё приложение. Да, от этого его кроссплатформенность снизится, а количество кода увеличится, но оно того стоит.

Бонус №1

Первое и самое важное: реальная кроссплатформенность.

Суть: после того, как ребята из SQLite портировали своё детище под WP, а скромный автор сего произведения указал на это ребятам из Qt, в порт Qt для WP был добавлен LocalStorage. Это счастье для всех любителей Qml.

Вы реально можете создавать приложения из одних исходников, реально под кучу платформ, при этом кастомизировать их в нужных местах исходя из возможностей и необходимостей платформы. Декларативный UI и js затягивают настолько сильно и позволяют писать настолько лаконичный код, что возвращаться после него на многословную Java + xml, либо спорный Swift + Storyboard'ы нет никакого желания.

Любые анимации, поддержка кастомных шрифтов, svg — это ли не счастье для мобильного разработчика?

Бонус №2

Второе и самое любимое заказчиками: нестандартность.

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

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

Бонус №3

Третье и самое любимое мной: скорость разработки.

Суть: в любом состоянии вы можете спроектировать UI практически любой сложности (исключая особенности взаимодействия с ОС, такие как поля ввода, обработка устройства ввода и т.д.). Если вы сам себе заказчик — то перед вами все дороги открыты.

Резюме

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

Спасибо за внимание! Поделитесь своим опытом использования Qt в разработке мобильных приложений в комментариях.

Автор: coursar

Источник ^[5]