zacsweers / barber Goto Github PK

This reads nicer to me for some reason

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.

error msg : attribute value must be constant

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.

I don't know if AAPT supports plugins like javac does, but this'd be truely awesome!

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'

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();
}

For example:

String textAllCapsSet = attrs.getAttributeValue("http://schemas.android.com/apk/res/android", "textAllCaps");

Not sure how best to approach this. Simple quick and dirty would be to just get the string and use that, but ideally it would be nice to take care of converting it to whatever type the user needs as well.

// In code
@StyledAttr(androidAttr="textAllCaps")
boolean textAllCaps = false;

// Under the hood
String textAllCapsSet = attrs.getAttributeValue("http://schemas.android.com/apk/res/android", "textAllCaps");
target.textAllCaps = Boolean.parseBoolean(textAllCapsSet); 

Few requirements:

• Basic smoke test (make sure it builds)

./gradlew clean build

• Run instrumentation tests

$ ./gradlew clean :sample:installDebug
$ adb shell am instrument -w io.sweers.barber.sample.test/android.test.InstrumentationTestRunner

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);

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.

This is due to the hard requirement in Style that the target class should extend View. This isn't necessary though.

This would be useful for views that require an attribute to be set

Just something standard to consolidate the version across modules and make it easy to update

How to use the attribute of string value(both hard coded and string ref), not able to find any samples on that

hello world

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);