Passing objects extending an abstract class between activities

Question

I am attempting to learn Android development by making a helper program to a board game I play. I have run into a situation very similar to the one answered in Pass custom object between activities. The difference in my situation is that the custom objects in question are all extending an abstract class.

The abstract class represents a chip (comparable to a card gameplay wise), and is as follows:

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
}

An example of a class that would extend 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");
    }
}

I'm taking this approach so that I can create new chips of the appropriate type by just calling new ChipA() where I need to, as opposed to new Chip(<long list of arguments that describe Chip A>). I need to pass a collection of these chips from one activity to another. I have already solved this problem in my code by storing the Chips I want to pass around globally as described in this article, but the end of the article advises using intent extras for this kind of operation instead. Could someone more clearly explain why? Is it just convention? If it's just a matter of readability, this method seems relatively compact and readable.

From reading around, it's clear that the intended way to pass arbitrary classes between activities using Intent extras is to have them implement Parcelable. However, since I am working with many subclasses of the class in question, that would mean adding a writeToParcel and a Parcelable.Creator to every single subclass. (describeContents() appears unimportant, and as I understand it I could just implement that in the basic abstract class.) I'm potentially going to have a lot of subclasses here, which will mean adding a lot of repetitive code. Is implementing Parcelable still considered the preferred method in this case? Am I missing something that would allow me to cut down on redundant code? If at all possible I would prefer to keep my Chip subclasses fairly compact.

Please be gentle, I'm new to both Stack Overflow and Android development.

Answer 1

You are not missing anything, Parcelable is the preferred way to do this.
I agree that it leads to some boilerplate code, but that's the clean way to handle this.

It is possible to skip this by extending the Application class but it will lead to some complications : the Application object can be deleted in some circumstances and it will lead to very troublesome bugs. It is way easier to just handle this the intended way and create Constructor (Parcel) for each of the objects you are moving that way.

Another point is that the Singleton pattern itself is more and more criticized. I won't go into the details, these discussions cover that topic :
https://softwareengineering.stackexchange.com/questions/40373/so-singletons-are-bad-then-what
What is so bad about singletons?

What's even worse is that in Android, you can't even count on a real Singleton; you don't have any insurance that the Application Object you are manipulating (or a Singleton you have created yourself) will retain its state through the lifecycle of the app. (random ref : http://portabledroid.wordpress.com/2012/05/04/singletons-in-android/)

So please don't use a Singleton as a way to avoid having to write a couple of Parcels. It will come back and bite you in the ass later.

Edit : here is a good explanation of how to reproduce the dreaded Application class crash : http://www.developerphil.com/dont-store-data-in-the-application-object/