バージョン4.1からQtを長い間使用しています。 「専門的に」使用しているとは言いませんが、ウィジェットでの作業とバージョン5.6への進化の両方で、経験は異なっていました。
プロジェクトの例：
- カラオケコントロールセンター（Android / iOS）
- ロシア語-タタール語辞書とカスタムキーボード（Android / iOS / WP）、さらにiOSカスタムキーボード用のAPIも
- Android用のさまざまなガジェット（geo、bluetooth、チャット、写真、プロファイルなど）を含むソーシャルネットワーク
- 花をすばやく注文するためのアプリケーション（Android / iOS / WP）
さらに、Qtは2gis Androidアプリケーションで記述されており、ここで説明する内容のほとんどを確認できます。
ここで説明されているもののいずれにも解決策が見つからない場合は、事前に修正していただくようお願いします（ご指摘いただければ幸いです）。 以下はすべて、主にAndroidに適用されます。
問題番号1
現時点で最初で最も重要なこと：ユーザーが入力したテキストで多くの作業をする必要がある場合-Qt / Qmlを選択しないでください！
私は感嘆符が絶対に好きではありませんが、この記号はその場所にあります。入力プラットフォームでの作業をターゲットプラットフォームのユーザーに行うのは非常に困難です。
- テキスト選択
- コピー＆ペースト
問題の本質：テキスト編集要素のバグは 2014年以降ハングしており 、重要としてマークされ、Silverサブスクリプションでユーザーによって登録されていますが、まだ修正されていません。 バグトラッカーには回避策が記載されていますが、Quick.Controlsではなく、TextEditとTextInputで純粋なQuickを使用する場合はごめんなさい。
たぶん誰かが私がやりたいと言うだろうし、TextEdit / TextInputが基本コンポーネントですが、すみません、基本コンポーネントにコピー＆ペーストがなく、Controlsに実装されていないため、お客様に最初に通知されるまで問題は発生しません。
TextEditには、MouseAreaに典型的なポインター信号が含まれていないため、長押し（Qmlの観点ではPressAndHold）を介してコンテキストメニューを表示しようとしても成功しません。 さらに、MouseArea額で入力フィールドをラップする試みは、限られた数のシナリオにのみ適しています。 文字と単語の間にカーソルを実装するには、長くて難しい作業が必要になります。
したがって、ソースに登って入力フィールドをカスタマイズするか、調整するかのいずれかです。
問題番号2
ソーシャル化を含むアプリケーションの顧客に最も愛されている2番目：Emoji
問題の本質：入力フィールドまたはテキストのいずれかで、すべての人のお気に入りの絵文字をネイティブに処理することはありません。あなたの想像力を発達させ、それを自分で実現します。
絵文字が実際に何であり、さまざまなオペレーティングシステムでの実装の困難な運命を知るには、Wikipediaの記事が役立ちます。 実際、オプションは何ですか：
- 絵文字をサポートするフォントを使用します。 FontForgeを使用してRobotoを絵文字でコンパイルします！
- 絵文字を色付きのpngに置き換えたリッチテキスト
- 入力フィールドの詳細なカスタマイズ（ ソースでデスクトップの電報を見ることができます）
合計：looksい（オプション1）またはバグがある（オプション2）か、Qtの内部に関する優れた知識が必要です（オプション3-もしあれば、ほとんどの問題を解決できないはずです）。
PSおもしろい楽しみ-入力フィールドにinputMethodHintsを設定しないでください。設定しないと、絵文字（iWinn IME）が組み込まれたAndroidキーボードが表示されません。
問題番号3
3番目で最も迷惑なのは、フリッカーとブラックスクリーンがあなたの親友だということです。
これは、アプリケーションをダウンロードするときに付随します。windowSoftInputModeをAdjustResizeに設定しようとすると、黒い画面の断片も定期的に表示されます。 したがって、実際のデバイスでテスト、テスト、およびテストを繰り返します。
問題番号4
4番目で最も扱いにくいもの：フォント
問題の本質：毎年、さまざまなデバイスに同じ問題が発生し、 クローズドバグに似た症状が現れます。 Androidデバイスの幸運な所有者が、フォントが浮いている、壊れている、見えないなどの不満を訴え始めるまで、あなたはそれについて知りません。 基本的に、これらは中韓のデバイスです。
唯一の方法があります-Qtのソースコードを取得し、特定のGPUにパッチを適用することです。
問題番号5
5番目の、最も物議をかもしている：高度なコントロールQml-カメラなど。
問題の本質：頻繁なクラッシュ、機能の欠如、およびネイティブアプリケーションの標準的なユーザーエクスペリエンスのその他の矛盾。 これはすべて非常に簡単に処理されます-ネイティブコンポーネント（Androidの場合はアクティビティ）をアプリケーションに追加することをためらわないでください。 はい、これによりクロスプラットフォームは減少し、コードの量は増加しますが、それだけの価値はあります。
ボーナス番号1
最初で最も重要なのは、真のクロスプラットフォームです。
結論：SQLiteのメンバーが頭脳をWPに移植し、この作品の謙虚な著者がこれをQtの男性に指摘した後、LocalStorageがWPのQtポートに追加されました。 これはすべてのQml愛好家にとって幸福です。
プラットフォームの機能とニーズに基づいて適切な場所でカスタマイズしながら、実際に多くのプラットフォーム用に同じソースからアプリケーションを作成できます。 宣言型UIとjsは非常に中毒性があり、非常に簡潔なコードを記述できるため、冗長なJava + xmlまたは物議を醸すSwift + Storyboardに戻りたくありません。
アニメーション、カスタムフォントのサポート、svg-モバイル開発者にとってこれは幸せではないでしょうか？
ボーナス番号2
顧客に最も愛されている2番目：非標準。
一番下の行：顧客からのフレーズで、殺したいという欲求につながります-「iPhoneのようにします」。 これは問題ではなく、どこでもほとんど同じように見えます。 はい、これはガイドラインに違反しています。そうではありません。決して良くありません。しかし、顧客は、3つの方法でそうすることを望んでいます-彼を納得させる、彼に屈する、彼を捨てる、自分で選ぶ
さらに、十分な要望があれば、プラットフォームのソースコードを必要な方法でダウンロードできます。 そのため、いくつかのアプリケーションでは、キーボードを完全にオフにし、Qt Virtual Keyboardに基づいて独自に作成しましたが、組み込みアプリケーションにはそのような機能がありませんでした。
ボーナス番号3
3番目に最も愛されているのは、開発速度です。
結論：どんな状態でも、ほぼあらゆる複雑さのUIを設計できます（入力フィールド、入力デバイスの処理など、OSとの対話機能を除く）。 あなたがあなた自身の顧客であるなら、すべての道はあなたに開かれています。
まとめ
新しいプロジェクトを開始することは、まず自分でこのプロジェクトの開発の境界を評価するのに適しています。 プラットフォームのネイティブ機能をほとんど使用せず、多くの非標準機能がある場合は、Qtを使用します。 反対の場合-必要に応じて変更できるかどうかを検討してください。
ご清聴ありがとうございました！ コメントでモバイルアプリ開発でQtを使用した経験を共有してください。
2016年3月3日更新16:53
2gisチームの興味深いQtOffscreenViewsライブラリをポイントしてくれたユーザーzsilasに感謝します。このライブラリは、テキストの入力と入力フィールドでの絵文字の表示に関する問題を解決します。