4

ボードゲームのヘルパープログラムを作って Android 開発を学ぼうとしています。Pass custom object between activitiesで回答されたものと非常によく似た状況に遭遇しました。私の状況の違いは、問題のカスタム オブジェクトがすべて抽象クラスを拡張していることです。

抽象クラスはチップを表し (カード ゲームプレイに相当)、次のとおりです。

import java.util.ArrayList;

public abstract class Chip{
    protected String name;
    protected int imageID;
    protected ArrayList<String> chipColors;
    protected ArrayList<String> chipTypes;

    public String toString(){
        return name;    
    }

    //Getters
    public String getName(){ return name; }
    public int getImageID() { return imageID; }
    public String getSet() { return set; }
    //Figure out how I need to deal with colors/types when I get there
}

Chip を拡張するクラスの例:

public class ChipA extends Chip{
    public ChipA (){
        super();
        name = "Chip A";
        imageID = R.drawable.chipa;
        set = "Basic";
        chipTypes = new ArrayList<String>();
        chipTypes.add("typeA");
        chipColors = new ArrayList<String>();
        chipColors.add("red");
        chipColors.add("green");
    }
}

私はこのアプローチを取っているので、new ChipA()必要な場所を呼び出すだけで、適切なタイプの新しいチップを作成できますnew Chip(<long list of arguments that describe Chip A>)。これらのチップのコレクションをあるアクティビティから別のアクティビティに渡す必要があります。この記事で説明されているように、グローバルに渡したいチップを格納することで、コードでこの問題を解決しましたが、記事の最後では、代わりにこの種の操作にインテント エクストラを使用することをお勧めします。誰かが理由をもっと明確に説明できますか? コンベンションだけですか?読みやすさだけの問題であれば、この方法は比較的コンパクトで読みやすいように見えます。

読んでみると、インテントエクストラを使用してアクティビティ間で任意のクラスを渡す意図された方法は、それらに実装させることであることは明らかですParcelable。ただし、問題のクラスの多くのサブクラスを扱っているため、すべてのサブクラスにawriteToParcelと aを追加することになります。Parcelable.CreatordescribeContents()重要ではないように見えます。私が理解しているように、それを基本的な抽象クラスに実装するだけで済みます。)ここに多くのサブクラスを作成する可能性があります。これは、多くの繰り返しコードを追加することを意味します。この場合、実装はParcelable依然として推奨される方法と見なされますか? 冗長なコードを削減できる何かが欠けていますか? 可能であれば、Chip サブクラスをかなりコンパクトに保ちたいと思います。

優しくしてください。私はスタック オーバーフローと Android 開発の両方に不慣れです。

4

1 に答える 1

2

これを行うには、Parcelable を使用することをお勧めします。
定型コードにつながることには同意しますが、これはこれを処理するためのクリーンな方法です。

Application クラスを拡張することでこれをスキップすることは可能ですが、いくつかの複雑さにつながります: Application オブジェクトは状況によっては削除される可能性があり、非常に厄介なバグにつながる可能性があります。これを意図した方法で処理し、移動するオブジェクトごとにコンストラクター (パーセル) を作成する方が簡単です。

もう 1 つの点は、Singleton パターン自体がますます批判されていることです。詳細については触れませんが、これらの議論はそのトピックをカバーしています:
https://softwareengineering.stackexchange.com/questions/40373/so-singletons-are-bad-then-what

さらに悪いことに、Android では、実際のシングルトンを当てにすることさえできません。操作しているアプリケーション オブジェクト (または自分で作成したシングルトン) がアプリのライフサイクルを通じてその状態を保持するという保証はありません。(ランダム参照: http://portabledroid.wordpress.com/2012/05/04/singletons-in-android/ )

そのため、複数のパーセルを作成する必要がないようにするためにシングルトンを使用しないでください。それは戻ってきて、後であなたのお尻を噛みます。

編集:恐ろしいアプリケーションクラスのクラッシュを再現する方法の良い説明は次のとおりです:http://www.developerphil.com/dont-store-data-in-the-application-object/

于 2013-04-18T11:04:31.920 に答える