1

ほとんどすべての要素がオプションである複雑なフォームを作成しようとしています。単一のフィールドと「要素の追加」ボタンから始まります。[追加] をクリックすると、フォームにSpinner追加できる要素の種類 (場所、写真、詳細なメモ、「今」以外のタイムスタンプなど) がフォームに表示されます。アイテムを選択すると が起動しActivity、各アイテムには異なるが関連付けられていActivityます。

さらに、各選択肢にはいくつかのデータ ビットが含まれますActivity。

  • のアイコンと表示名Spinner
  • データベースにデータを格納するためのキー (および Web サービスに渡すため)
  • 結果を元のフォームに表示する方法のレイアウト (つまり、写真のサムネイル、場所の緯度/経度など)

私は、すべてが抽象FormElementクラスを拡張し、上記の余分なデータのそれぞれに静的要素を持つ一連のクラスを検討していました。(このソリューションの追加のバンプはResources、静的なコンテキストでの苦痛の程度です。)

これを可能な限りクリーンで保守しやすくするにはどうすればよいですか? このフォームに新しいタイプの要素を追加するために 5 つの異なるファイルを編集するのは本当に好きではありません。(主に、1 つを見逃して、バグのないものを追跡するのに何時間も費やすことを保証できるためです。)

4

1 に答える 1

1

いくつかのヒント...

  1. ユニットテストは「バグのない」ことを防ぎます:)

  2. それぞれActivityがユーザーから必要な情報を取得したら、タイプごとのデータを含む Activity＃setResult（）を呼び出します。すべてのメソッドをサポートしているため、必要に応じてさまざまなタイプのデータを設定できます。IntentIntentBundle

  3. ＃2をサポートするActivity#startActivityForResult(Intent,int)には、それを起動するために使用していることを確認し、結果をリッスンします。Activity#onActivityResult(int,Intent)

  4. 何を表示し、どのアクティビティを起動するかを決定するために、アダプタのメソッドで（、、、などのSpinnerAdapter静的メソッドArrayList<Class<? extends AbstractFormElement>>を呼び出すなど）で使用できる「要素」タイプのリストを維持することになるでしょう。.getDisplayName().getActivityClass()getView()

    このように、リストには実際には{ MyPhotoElement.class, MyTextElement.class, MyDateElement.class, ...}）のようなものが含まれます。

  5. 各要素がフォームに追加されたら、それをに追加しますArrayList<AbstractFormElement>。これは、の別のアダプターをバックアップするために使用されますListView。そのアダプターは、カスタムビューレイアウトのインフレーションと、オブジェクトのタイプに基づいたViewHolderAbstractFormElementの作成をディスパッチします。これには、アダプターによると、各個別に独自の「ビュータイプ」が必要になります。 。BaseAdapter＃getItemViewType（int）および関連するを参照してくださいgetViewTypeCount()。

    一方を他方に変換できない場合にのみ、これらに異なるビュータイプが必要になることに注意してください...たとえば、リストにテキストの文字列を表示するだけでよい2つの「要素」がある場合、両方で共有できます。 「テキストのみ」のビュータイプ。同様に、写真のみを表示する、または一方を他方に簡単に変換できる2つの要素（たとえば、キャプション付きのアイコンとキャプションなしの写真サムネイル）は、単一の「画像とキャプション」ビュータイプを共有できます。

上記を念頭に置いて、実際には、新しいタイプを追加するためにさまざまなファイルを変更する必要があります（技術的には、内部クラスとしてすべてを1つのファイルに含めることができると思いますが、それを行うための良い議論はありません） 、しかし、インターフェースAPIを正しく実行し、適切なOOプラクティスに従い、適切な単体テストを実装すると、バグを見つけるために必要な労力を大幅に削減できます。 typeを誤って実行すると、実際にはコンパイラエラーが強制されます。それに加えて、適切なユニットテストスイートがプログラムですべての可能なタイプを追加し、すべてが適切に表示されることを確認できるという事実に加えて、簡単に拡張できるようにかなり合理化されたプロセスが必要です:)

大変な作業のように聞こえますが、最初は退屈で冗長に見えるかもしれません...しかし、特に要素タイプのリストがかなり広範囲になる場合は、最終結果は実際にははるかに保守しやすくなります。

于 2011-06-14T02:15:37.890 に答える