This should address #4. I was thinking I could get around this by using parameterized classes, and to my good fortune it turned out Butterknife had a pretty decent solution for this. @emilsjolander would you mind taking a look and see what you think? @denley you as well if you're interested, since you opened the issue.

• Adopt Butterknife's approach to making all generates classes implement a IBarbershopInterface, and do class lookups of this interface rather than method lookups. This makes this next part possible.
• Fix inheritance by determining if a generated class has a parent and then extending from the parent instead of implementing the IBarbershopInterface. This way, style() can just call super.style() to ensure that the entire hierarchy of style() methods run.

~~This functionally works, but I'm slightly concerned about one thing that I'm going to mull over tomorrow. Right now, it traverses the entire hierarchy. So if you have a parent with a child and grandchild, you conceivably could have the parent getting styled three times (that is, once for the parent's constructor, once for the child's, and one more for the grandchild). I'm not sure how to get around this yet though, if at all.~~ I should write better tests.

Now, if you have a TestView and ChildTestView that extends it, Barber will generate code that looks like this:

public class TestView$$Barbershop<T extends io.sweers.barber.sample.TestView> implements Barber.IBarbershop<T> {
  @Override
  public void style(final T target, final AttributeSet set, final int[] attrs, final int defStyleAttr, final int defStyleRes) {
    if (set == null) {
      return;
    }
    TypedArray a = target.getContext().obtainStyledAttributes(set, attrs, defStyleAttr, defStyleRes);
    if (a.hasValue(0)) {
      target.testBoolean = a.getBoolean(0, false);
    }
    a.recycle();
  }
}

public class ChildTestView$$Barbershop<T extends io.sweers.barber.sample.ChildTestView> extends TestView$$Barbershop<T> {
  @Override
  public void style(final T target, final AttributeSet set, final int[] attrs, final int defStyleAttr, final int defStyleRes) {
    super.style(target, set, attrs, defStyleAttr, defStyleRes);
    if (set == null) {
      return;
    }
    TypedArray a = target.getContext().obtainStyledAttributes(set, attrs, defStyleAttr, defStyleRes);
    if (a.hasValue(0)) {
      target.coolNumber = a.getInt(0, -1);
    }
    a.recycle();
  }
}

Hi -

Tracking this, so I wanted to put in an issue. When adding Barber to a project that already uses Dagger (and dagger-compiler) for injection, dagger code generation fails to run.

My setup is as such;

apt 'io.sweers.barber:barber-compiler:1.0.1'
compile 'io.sweers.barber:barber-api:1.0.1'
compile 'com.squareup.dagger:dagger:1.2.2'
provided 'com.squareup.dagger:dagger-compiler:1.2.2'

I thought this might be a good feature to have while using the library. Android support annotations provide similar functionality to the kind annotation parameter so instead of duplicating the info, this change-set enables looking at the support annotation (which people should be using anyways) and setting kind to resource type if the support annotation used is one of the @Res types. The one additional special case is the @ColorInt annotation. Which this also checks for and sets kind to COLOR if it's used. What are your thoughts?

• Remove unnecessary configuration and convention
• Move most configuration to extension
• Provide support to get android dependencies from any 'provided' like plugin
• When depending on project dependencies in apt configuration, also need to add a dependency on the acp configuration. This is not required once the compiler jar is packaged

Currently, we can only annotate/style a class that is directly instantiated. It would useful to be able to maintain the extendability of custom View types.

The problem is that a class' generated Barbershop is not invoked by subclasses. When the parent class calls Barber.style it will find the subclass' Barbershop instead of its own, because target.getClass does not refer to its own class.

I don't see any clean fix for this, unfortunately. So perhaps it's something to discuss for now rather than fix immediately. It would probably require some change to the API, such as passing the Class as a parameter in the Barber.style method. We can't simply have a Barbershop look for its parent class' Barbershop because it won't know the correct styleable resource to pass.

Resolves #16

This allows for the use of a new defaultValue option in StyledAttr annotations, where you can set a resource ID to use as a default.

The generated code will still check Required if the annotation is there. It will not resolve the default value unless there is no resource at that index (that is, it won't unnecessarily resolve it just to pass it into the second param of many of the typedarray getters).

AndroidAttr doesn't support defaults, because it doesn't really make sense to. It would really have to force the user to only use it on setters to be practical.

Just an idea, but I think this could work. It's not the prettiest solution, but it would at least give users and avenue to handle dynamic defaults.

public class MyView extends View {

  @StyledAttr(R.styleable.MyView_my_attr)
  int myAttr;

  public MyView(Context context, AttributeSet set) {
      Barber.style(this, R.style.MyView, set);
  }

  // Annotate a method that resolves the default value
  @AttrDefault(R.styleable.MyView_myattr)
  public int getMyAttrDefault() {
      return 4;
  }

  // Alternatively could have a "catchAll = true" value that tells Barber 
  // that this method will handle ALL default value resolution. Need to be 
  // careful here though, as things could get sticky really fast.
  @AttrDefault(catchAll = true)
  public Object resolveDefault(int styleable) {
    switch (styleable) {
      case R.styleable.MyView_my_attr:
        return 4;
    }
  }

  // Generated code would look like this
  target.myAttr = a.getInt(0, target.getMyAttrDefault();
}

Would need another overload for Style, and remove the hard requirement for attributeset not to be null in the generated Barbershop#style(...) method.

private static final int[] ATTRS = new int[]{
        android.R.attr.listDivider
};

// Want to do this boilerplate
final TypedArray a = context.obtainStyledAttributes(ATTRS);
mDivider = a.getDrawable(0);
a.recycle();

// Probable method signature
style(Object target, int[] attrs);

Pretty straightforward, Bintray makes it easy to sync. Issue is the bintray-release plugin currently doesn't generate some required portions of the pom.xml (tracked in this issue. Once that's resolved, should be quick to make them available on both.

Right now the minSdkVersion is 14, but it could possibly support lower. I don't know for sure if I want to support lower versions, but something to look in to.

Both the api and the compiler module now depend on the annotations module. This removes the need for the android-23.jar dependency, as well as the dual sourceSets configuration in compiler’s build.gradle.

I was playing around with adding Butterknife as a dependency to test something and ran into a bunch of issues due to the previous setup. This seems like a saner way of doing things, in line with what other popular repos are doing (like Butterknife, for example.)

The tests are all still successful & the sample runs and works properly.

Not high on my priority list right now, but will consider adding if people express an interest.

TypedValue outValue = new TypedValue();
context.getTheme().resolveAttribute(android.R.attr.textColorPrimary, outValue, true);
int primaryTextColor = outValue.data;

Have access to TypedValue means this could support a full range of checks to figure out its type. Doing so automatically might come at the expense of flexibility (e.g. user might want to force a particular type).

@ResolvedAttr(android.R.attr.textColorPrimary)
int primaryTextColor;

The default could be to resolve the attribute based on TypedValue's type, with an optional specifier.

Alternative approach.

Simpler for code generation, but more work for the user as they would have to figure out how to mix their desired attrs with these. Would need another overload for Style, and remove the hard requirement for attributeset not to be null in the generated Barbershop#style(...) method.

private static final int[] ATTRS = new int[]{
        android.R.attr.listDivider
};

// Want to do this boilerplate
final TypedArray a = context.obtainStyledAttributes(ATTRS);
mDivider = a.getDrawable(0);
a.recycle();

// Probable method signature
style(Object target, int[] attrs);