Skip to content

Conversation

@jbarr21
Copy link
Contributor

@jbarr21 jbarr21 commented Jan 20, 2017

Refactors Calligraphy's LayoutInflater and ContextWrapper into a new library and adds Inflate Request/Response notion plus an Interceptor API

}

dependencies {
compile 'com.android.support:appcompat-v7:24.0.0'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We shouldn't make these required dependencies. I would prefer provided and your tests/demo app build it in.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that's a good point. that should help avoid dependency messes

return;
}

final Method setPrivateFactoryMethod = ReflectionUtils.getMethod(LayoutInflater.class, "setPrivateFactory");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A TODO: we need to get this and wrap it if something has already set this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will add a TODO comment to cache the Method. please correct me if i've misunderstood

protected View onCreateView(String name, AttributeSet attrs) throws ClassNotFoundException {
return ViewPump.get().inflate(InflateRequest.builder()
.name(name)
.context(getContext()) // TODO: is this OK? before was fallbackView.getContext()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What was the old code in Calligraphy? I have a feeling it should use it's parent view where possible, otherwise theme styles get lost.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code in Calligraphy was here. At this point, we haven't inflated the view yet, so we can't pass the view's context to the InflateRequest, we only have access to the layout inflater's context. is this ok? if not, what would be an example where something Calligraphy would not be styled properly?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, I looked into this further, and it appears as though previously, when LayoutInflater.createView(name, prefix, attrs) was called, it used the mContext from the LayoutInflater, so by using getContext(), which returns mContext, I am using the same Context [link to source]

View view = null;
for (String prefix : sClassPrefixList) {
try {
view = inflater.createView(name, prefix, attrs);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this should short if view != null See: chrisjenx/Calligraphy#361

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh good call, will fix

<?xml version="1.0" encoding="utf-8"?>
<resources>
<item name="viewpump_tag_id" type="id"/>
</resources> No newline at end of file
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry to be super picky, can you leave EOF whitespace?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

np at all, will add. we can get a basic checkstyle added in a future PR and run it on Travis

buildToolsVersion "24.0.0"

defaultConfig {
minSdkVersion 7
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I mentioned in the other review, that we should probably support 14+ which will simplify the Inflater a little bit.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sounds good to me. will bump to 14 and remove the Honeycomb-specific code

@jbarr21
Copy link
Contributor Author

jbarr21 commented Jan 31, 2017

Addressed all comments

@chrisjenx chrisjenx merged commit a73a738 into jb/initial-setup Feb 5, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants