11

As Android documentation states: "An activity is a single, focused thing that the user can do."

However with Fragments we will be able to do many "things" within the same Activity as Reto Meier suggest. His suggestion is to replace a selection fragment by a content fragment within the same Activity (section "Within our code this produces a dilemma").

Lets say my application is a "bit" more complex, with many activities, with a complex navigation tree and designed with the "single, focused thing that the user can do" principle in mind.

Lets say now I have to adapt it to Fragments and large screens... and that I don't want to create a second application, neither have two completely different logics (one for phones other for tables) inside one application.

Should I have one Activity to manage all the application fragments and fragment transactions? Like Retro Meier suggest above. Is that the recommended path to follow? Thus breaking with the "single, focused thing that the user can do" principle for Activities?

Or am I missing something? I hope ;)

BTW, I think Fragments looks great, but from what I have seen till now, only if you are creating an application from the scratch. Because making applications to be compatible with phone and tablet looks like going to be a bit tedious. Hope to be wrong :)

Dianne Hackborn already has answered (thx for the link mgv):

you could put your entire application in one activity in which you change the fragment structure as its state changes

So then Activity becomes a sort of container where you will be able to plug Fragments. I like the approach, but... in my app there are about 30 different operations available, each one requires about 2 to 4 screens steps to be performed(forms and selection lists), all of them differ and there are also navigation restrictions. It works fine with Activities each one handling one screen/step behaviour.

So then to port to Fragments I should move each screen logic to Fragments and use Activities as containers for each operation. Thus leaving Activities as the ones managing the navigation between Fragments for every operation, right? Looks like going to be a pain to adapt long applications. :(

Current Activity definition should change a bit btw. :)

4

1 に答える 1

6

すべてのアプリケーション フラグメントとフラグメント トランザクションを管理するアクティビティは 1 つにする必要がありますか?

それは抽象的に答えることは不可能です。ただし、フラグメントベースの世界であっても、ほとんどのアプリケーションには複数のアクティビティがあります。その一部は、小さな画面サイズに対応するためのもので、アクティビティごとに 1 つのフラグメントになる傾向があります。その一部は、フレームワークで必要になります (たとえば、 からの継承PreferenceActivity)。そして、その一部は GUI 設計によるものです。

したがって、アクティビティの「ユーザーが実行できる単一の集中的なこと」の原則を破っていますか?

ドキュメントのその部分は 2008 年、おそらくそれ以前に書かれたものです。当時フラグメントが存在していたとしたら、ドキュメントには、フラグメントは「ユーザーが実行できる単一の焦点を絞ったもの」であり、アクティビティがオーケストレーション レイヤーとして機能し、どのフラグメントがどのような状況で表示されるかを決定すると記載されていたと思います。

ドキュメントはすべての場所でフラグメントを反映するように更新されるわけではなく、たとえ更新されたとしても、しばらく時間がかかります。2011 年の残りの部分については、少なくとも 2008 年の手順を独自に翻訳して、2011 年のフラグメントベースの UI に変換する必要があります。

フラグメントと大画面に適応させる必要があるとしましょう... 2 つ目のアプリケーションを作成したくなく、1 つのアプリケーション内に 2 つの完全に異なるロジック (1 つは電話用、もう 1 つはテーブル用) も必要としません。

あなたが「完全に異なる論理」を何と考えているのか、私にはわかりません。フラグメント ベースのアプリでは、ほとんどのビジネス ロジックはフラグメント自体にあります。ここでも、アクティビティはオーケストレーション レイヤーとして機能し、どのフラグメントを表示するかを決定し、イベント処理を調整します。画面サイズによっては、リスト内の項目をクリックすると新しいフラグメントが表示され、リスト内の項目をクリックすると新しいアクティビティが開始される場合があるため、後者は以前よりも少し複雑になります。

または、何か不足していますか？

正直なところ、あなたの質問には、合理的に答えられるようにするのに十分な具体性が欠けています。

于 2011-04-19T15:55:37.950 に答える