タブレットだけでなく携帯電話でも実行する必要があるプロジェクトを作成しています。これにはフラグメントを使用することを考えていました。しかし、私はそれらを使用した歴史はありません。
それらをすぐに実装する必要がありますか、それとも後で実装するのは簡単ですか? (最初に動作する電話アプリを作成し、後でタブレットアプリにすることができます)
初めてフラグメントを実装した経験のある人はいますか?
タブレットだけでなく携帯電話でも実行する必要があるプロジェクトを作成しています。これにはフラグメントを使用することを考えていました。しかし、私はそれらを使用した歴史はありません。
それらをすぐに実装する必要がありますか、それとも後で実装するのは簡単ですか? (最初に動作する電話アプリを作成し、後でタブレットアプリにすることができます)
初めてフラグメントを実装した経験のある人はいますか?
私は 2 週間にわたって Android アプリケーションを更新し、fragment を使用して作成する作業を行ってきたので、Fragment を直接使用する方が簡単になります。しかし、自分自身に尋ねなければならない質問は、アプリにフラグメントが必要ですか?
基本的に、フラグメントを使用すると、一度に複数の「アクティビティ」をユーザーに表示できます。これ必要でしたか??そうでない場合は、リソース修飾子を使用して、フラグメントが多い/少ない別のレイアウトを指す方が簡単です (例: layout-land-large)。file.xml 内の要素のサイズを更新できます。
2 つのアクティビティを表示する必要がある場合 (タブレットを使用している場合)、最善の解決策はフラグメントを使用することです。ここであなたはこう言います: Fragments は連携してユーザーに合理化されたエクスペリエンスを提供していますか? はいの場合、フラグメントは互いに引数を送信して通信するため(アクティビティとは異なります)、フラグメントを直接操作することは完璧です。アクティビティ内: インテント.putExtra() フラグメント内: たとえば、バンドルを使用できます。そのため、後でアプリケーションを更新する必要がある場合は、送信者エクストラを検索して別の方法で送信することに時間を浪費することになります.
UI コンポーネントには最初からフラグメントを使用することをお勧めします。これは、タブレットのファッションのようなマスター詳細で使用できますが、小型の電話では単一のアクティビティとして使用できます。小さい携帯電話ではわずかなオーバーヘッドが発生しますが (たとえば、アクティビティ コンテナーを 1 つのフラグメントだけ使用すると)、タブレットに切り替えると、そのオーバーヘッドから利益が得られます。また、小型の携帯電話とタブレットの間の一貫した UI デザインも改善されます。
フラグメント化前 (Android 2.x など) のデバイスをターゲットにする場合は、サポート ライブラリを使用します。サポート ライブラリに応じて、コメントを使用してクラスをマークすることもお勧めします。このようにして、将来サポート ライブラリから「ネイティブ」実装に切り替えるときに、それらを簡単に見つけることができます (サポート ライブラリは異なるパッケージを使用するため、少なくとも import ステートメントを変更する必要があります。まれに、メソッドを変更する必要があります)。 (例: に変更getSupportFragmentManager()
) getFragmentManager()
。