DejavooSystemsのMalyuginPlaton AndroidLeadを紹介します。この物語は、私たちが1年間戦ってきた「痛み」と、私たちの建築の進化についてです。主なプロファイルは小売業者やレストランのキャッシュターミナルであるため、多くは業界の詳細に関係しています。
いずれにせよ、アプリケーションのアーキテクチャを変更すると、アプリケーションが複雑になるだけでなく、ドキュメントの量が増え、サポートが必要になります。したがって、今これを行う必要があるかどうかを検討する価値がありますか？十分な経験とブロッキングタスクの数がありますか？
なぜ今なのか？この画面は機能するので、苦しみ続けてこの画面に触れることをできるだけ少なくすることができます。なぜ現在機能しているものを壊すのですか？すべてが単純で、多数のブロッキングタスクが蓄積されているため、現在の注文構造をより複雑で柔軟なものに作り直す必要があります。変更なしではできません。
問題の説明
注文には1つのアクティビティを使用します。これは、タブレットバージョンと電話バージョンの両方をサポートします。ダイアログ（ダイアログはアクティビティ）を操作する方が簡単で、この画面には多くのダイアログが表示されるため、複製したくありません。
タブレットバージョンは次のようになります。
同じ要素から、ただしナビゲーターが異なる電話のバージョンを収集します。
画面の構成について説明します。
- アイテム-フラグメント
- 部門-フラグメント
- ラインアイテムと金額-フラグメント
- 注文パラメータは別のビューです
50, , , OrderPresenter .
, Use case, . . , , , .
, , , , , . , ( Use case).
:
- ,
- ,
- , ,
- ,
- , , ""
- ,
" " — , 2- . :
- "" ( )
- ,
- ,
, , , , .
, , . :
- ( 2 ) ,
- UI
- Rx
, "" , , ( ), . .
ここで、ユーザーが画面上で非常にすばやく「ハンマー」を打つ場合。そうすれば、わずかな遅延はありますが、すべての操作を処理できるようになります（ただし、これは画面の「フリーズ」よりも目立たなくなります）。
リポジトリの簡単なUML図：
結果
私たちは自転車を発明したかもしれませんが、私の意見では、アーキテクチャは作業を簡素化し、より複雑なケースをサポートできるようにします。引き続き取り組んでいきます。