New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feature: allow WireUpControls to find View members #1217
Conversation
Thanks for the PR @Qonstrukt. It's a 👍 from me. Can one of our @reactiveui/reviewers-android reviewers review as well. Looking to get this in |
@@ -78,7 +78,7 @@ public static T GetControl<T>(this Fragment This, [CallerMemberName]string prope | |||
public static void WireUpControls(this ILayoutViewHost This) | |||
{ | |||
var members = This.GetType().GetRuntimeProperties() | |||
.Where(m => m.PropertyType.IsSubclassOf(typeof(View))); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you please change all these to use IsAssignableFrom
:
.Where(m => typeof(View).IsAssignableFrom(m.PropertyType)))
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, that should be no problem. I choose for this solution because of a post I saw with some good points on SO: http://stackoverflow.com/a/2742288.
But I don't think the false positives are a problem here because we're not using value-type comparisons.
62a94d6
to
991fc02
Compare
lgtm. Thanks @Qonstrukt! 👍 |
What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
This will allow
WireUpControls()
to wire up View properties, and not just subclasses of it.What is the current behavior? (You can also link to an open issue here)
WireUpControls()
doesn't currently wire up View properties, just subclasses.What is the new behavior (if this is a feature change)?
WireUpControls()
now also wires up View properties.Does this PR introduce a breaking change?
It shouldn't, unless you were expecting
null
values on your View properties. If you were working around this with manualFindViewById
calls you're assigning the same view twice to the same property, worst-case. (Considering you weren't using duplicate names for views or controls in the first place.)Please check if the PR fulfills these requirements
Other information: