【问题标题】:Passing objects extending an abstract class between activities在活动之间传递扩展抽象类的对象
【发布时间】:2013-04-11 09:41:00
【问题描述】:

我正在尝试通过为我玩的棋盘游戏制作一个帮助程序来学习 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(&lt;long list of arguments that describe Chip A&gt;)。我需要将这些筹码的集合从一个活动传递到另一个活动。我已经在我的代码中解决了这个问题,方法是按照this article 中的描述存储我想要在全球范围内传递的芯片,但是文章的结尾建议使用intent extras 来代替这种操作。有人可以更清楚地解释为什么吗?这只是约定吗?如果只是可读性的问题,这个方法看起来比较简洁易读。

通过阅读,很明显,使用 Intent extra 在活动之间传递任意类的预期方法是让它们实现 Parcelable。但是,由于我正在处理相关类的许多子类,这意味着将writeToParcelParcelable.Creator 添加到每个子类。 (describeContents() 似乎并不重要,据我了解,我可以在基本抽象类中实现它。)我可能会在这里有很多子类,这意味着添加大量重复代码。在这种情况下,实施Parcelable 是否仍被视为首选方法?我是否遗漏了一些可以让我减少冗余代码的东西?如果可能的话,我宁愿保持我的 Chip 子类相当紧凑。

请轻点,我是 Stack Overflow 和 Android 开发的新手。

【问题讨论】:

    标签: java android oop android-intent android-activity


    【解决方案1】:

    您不会错过任何东西,Parcelable 是执行此操作的首选方式。
    我同意它会导致一些样板代码,但这是处理这个问题的干净方法。

    可以通过扩展Application类来跳过这个,但是会导致一些复杂性:Application对象在某些情况下可以被删除,这会导致非常麻烦的错误。以预期的方式处理此问题并为您以这种方式移动的每个对象创建构造函数(包裹)会更容易。

    还有一点,Singleton 模式本身越来越受到诟病。我不会详细介绍,这些讨论涵盖了该主题:
    https://softwareengineering.stackexchange.com/questions/40373/so-singletons-are-bad-then-what
    What is so bad about singletons?

    更糟糕的是,在 Android 中,你甚至不能指望真正的 Singleton;您没有任何保证您正在操作的应用程序对象(或您自己创建的单例)将在应用程序的生命周期中保持其状态。 (随机参考:http://portabledroid.wordpress.com/2012/05/04/singletons-in-android/

    所以请不要使用 Singleton 来避免编写几个 Parcel。它稍后会回来咬你。

    编辑:这里很好地解释了如何重现可怕的应用程序类崩溃:http://www.developerphil.com/dont-store-data-in-the-application-object/

    【讨论】:

    • 您能否举一些可能导致应用程序被删除的示例或链接到描述更多内容的文章?我实际上考虑过使用 Application 类来保存选项菜单中的信息;这似乎是自然的方式。如果它真的那么不可靠,我将不得不改变我的选项菜单计划。
    • 对不起,没有链接,我只是根据经验知道这一点,因为我必须考虑很多关于如何处理这种模式的问题。我想 Application 对象被销毁的主要原因只是内存不足。为了解决这个问题,你必须实现 Parcelable 来保存/恢复你的应用程序状态。在第一次简单地实现它会节省你一些时间。
    • 我会相信你的话,然后重构我的代码以使用 Parcelable。我仍然想在某个时候听到更具体的原因。感谢您的宝贵时间。
    猜你喜欢
    • 2014-12-08
    • 1970-01-01
    • 1970-01-01
    • 2023-03-23
    • 2013-06-11
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多