Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

I have a question regarding to the andriod @IntDef Annotation. I know that in its basic usage, it should replace the enum . But what if I have a parameterized enum with multiple hardwired values for example

public enum MyEnum {
  YES(true, 1),
  NO(false, 0);
  private boolean boolState;
  private boolean intState;
  MyEnum(boolean boolState, int intState) {
    this.boolState = boolState;
    this.intState = intState;
  public boolean getBoolState() {
    return boolState;
  public int getIntState() {
    return intState;
How would this be replaced by an Enumerated Annotation in Android?
Is it even suggestive to do something like that in this case? I searched 
everywhere, but I haven't found any answer for that. 
Thank you in advance!
  
IntDef is a way of replacing an integer enum where there's a parameter
  that should only accept explicit int values.
you can read more about it here. Enumerated annotations are for simple types, you could use it for strings also StringDef. Use enum when you need its features. Don't avoid it strictly. For your case I think creating class instead of enum would look like this:
public class MyEnum {
    public static final MyEnum YES = new MyEnum(true, 1);
    public static final MyEnum NO = new MyEnum(false, 0);
    private boolean boolState;
    private int intState;
    MyEnum(boolean boolState, int intState) {
        this.boolState = boolState;
        this.intState = intState;
    public boolean getBoolState() {
        return boolState;
    public int getIntState() {
        return intState;
    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        MyEnum myEnum = (MyEnum) o;
        return boolState == myEnum.boolState && intState == myEnum.intState;
and you could use constants in your code. But if using enums you will have type checking (you'll be able to accept only listed values) and method overloading (every enum constant can have its own implementation of a method). If you want to use less space and that is the only reason why you want to avoid using enum I would suggest you that it's not worth it. 
                Wouldn't this negate the point of avoiding enums? from my understanding, enums have a similar footprint to class instances, and that is where the memory footprint comes from...
– Ben Neill
                Mar 13, 2017 at 6:08
                I think it's okay to use enums when you need its features we shouldn't avoid it strictly. I just mentioned example of class in my answer to demonstrate what you'll need to create if you won't be using enum. But I think it would be better if I make it clearer.
– GROX13
                Mar 13, 2017 at 8:34
                Fair enough, it just feels to me that the quest to avoid enums in Android isn't great and will more often than not, lead to poorer code (intdef/stringdef style enums excepted). It would be interesting to see what the overhead of using a class like this would be vs enum vs a static helper class.
– Ben Neill
                Mar 13, 2017 at 23:04
                This might be good example here is video of android developers channel on YouTube which explains what and how should be done.
– GROX13
                Mar 14, 2017 at 6:45
                Yeah, that is a great channel, however in this instance, some of his numbers are... misleading. See the second link in my answer from Jake Wharton.
– Ben Neill
                Mar 15, 2017 at 2:34
If there is a way around using an enum, I'll certainly consider it where it doesn't undermine the code.
A lot was made from the video Colt Mcanlis posted: https://www.youtube.com/watch?v=Hzs6OBcvNQE&feature=youtu.be
however it had some fairly shaky numbers in it as pointed out by Jake Wharton: https://plus.google.com/+JakeWharton/posts/bTtjuFia5wm
The main drawback of enums is that they use more memory than constants would, but if that enum aids in better code, I say use it rather than micro-optimise. Just don't go overboard using them and be aware of their footprint.
I'm coming late, but anyways, since intdef ins an annotation, you can create an annotation using a custom class and then use it in the same way. given the fact an annotation needs primitives, you'll have to pass an interface as the annotation class type, and use subclasses as the value array.
example:
public interface GenericContainer<T, X> {
    public T getValueOne();
    public X getValueTwo();
then an implementation for true/1
public class TrueContainer implements GenericContainer<Boolean, Integer> {
    @Override
    public Boolean getValueOne() {
        return true;
    @Override
    public Integer getValueTwo() {
        return 1;
and other for false/0
public class FalseContainer implements GenericContainer<Boolean, Integer> {
    @Override
    public Boolean getValueOne() {
        return false;
    @Override
    public Integer getValueTwo() {
        return 0;
finally, use them:
    @Retention(RetentionPolicy.SOURCE)
    @GenericDef({TrueContainer.class, FalseContainer.class})
    public @interface genericTest{}
    boolean test = isTest(new FalseContainer());
        
Thanks for contributing an answer to Stack Overflow!
Please be sure to answer the question. Provide details and share your research!
But avoid …
Asking for help, clarification, or responding to other answers.
Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.