質問: リスト、検索、アイテムの表示アプリケーションに最適なページフローは何ですか? 次のシナリオを検討してください。androidアプリケーションの3つの画面:アイテムのリスト、検索結果画面、およびアイテムの表示画面があります。すべての画面で検索バーを呼び出すことができます。検索バーは、オートコンプリートで完全一致が見つかった場合は、検索結果画面または直接アイテム画面に移動します。さて、質問は、画面間のフローをどのように編成する必要があるかです単純なフローは簡単です:リスト>検索>結果>表示。どちらかの状態で[戻る]ボタンをクリックすると、1つのアイテムがスタックの下に移動します。ただし、検索がショー画面から呼び出された場合?スタックはlist> search> results> show> search> resultsになります。そして、検索結果と画面の表示が非常に多くなる可能性があります。検索バーを呼び出して検索を実行するたびに、表示画面がスタックから削除され、スタックが単純なものよりも複雑にならないようにフローを作成することを検討していますリスト>検索>結果>表示。質問の核心は、ユーザーがショー画面から検索バーを呼び出すのが精神的に「検索に戻る」か「次の検索に移動する」か、したがって最初のショー画面がアクセス可能かどうか。androidのimdbアプリは後者のアプローチに従い、数十の画面のスタックを簡単に構築します。私は個人的にこれに興奮していません。
回答: うーん、私はこれを3画面シナリオと見なします。 探す リスト/結果 項目 リストは実際には単なるプリセット検索です... select * from table 検索>結果>アイテム 追加のダイレクトパスを使用 検索>アイテム(完全一致の場合)