XIBRuntimeAttributeMismatch should check instance variables
This error message doesn't take in account that the property can be defined on a superclass.
Step to replicate: 1. Create a class "ParentClass" subclass of "UIView" and add a property "someProperty". 2. Create a subclass of "ParentClass" called "ChildClass" 3. On a xib file or storyboard add a view and specify the class type "ChildClass" 4. Define a runtime attribute with name "someProperty" 5. Run Faux Pas.
Comments (6)
-
repo owner -
reporter Hi @ali_rantakari In this case I think we found a small bug :) This is the result And this is the sample project: https://www.dropbox.com/s/crlt6tp8ilslgb4/SampleProject.zip?dl=0
-
repo owner Thanks for the sample project.
It does however look like the diagnostic is correct in this case —
ParentClass
has a property calledkeyProperty
whileMain.storyboard
sets the stringFOOBAR
with the key pathkeyPath
.If you run the sample project with the debugger attached, you'll see this in the Xcode console:
2015-08-18 20:13:09.652 SampleProject[15647:463754] Failed to set (keyPath) user defined inspected property on (ChildClass): [<ChildClass 0x7fc0c3725e20> setValue:forUndefinedKey:]: this class is not key value coding-compliant for the key keyPath.
-
reporter I'm sorry, there was one error on that project. The error was the name of the runtime attribute, it should be
keyProperty
as defined on theParentClass
,keyPath
doesn't exist at all!Fixing the project I found also a more specific case that cause the "bug". In particularly FauxPas checks for properties that are defined on the class or on the superclass, but -probably- not for the ivars.
Now the
ParentClass
has an ivarkeyProperty
, a subclass calledChildClass
is used on storyboard and akeyProperty
is configured as a runtime attribute. In this case FauxPax generate the warningXIBRuntimeAttributeMismatch
Here the link with the second version of the project. https://dl.dropboxusercontent.com/u/792862/SampleProject%20v2.zip
-
repo owner - changed title to XIBRuntimeAttributeMismatch should check instance variables
-
assigned issue to
Thanks for the clarification — this rule indeed doesn't check for instance variables. I have updated the title of this issue accordingly.
-
repo owner - changed status to closed
Fixed in v1.6
- Log in to comment
Thanks for reporting this.
This rule should indeed be checking properties in superclasses in the manner described, but it's possible that a bug is preventing this feature from working correctly.
I have been unable to reproduce this issue — can you please provide a small Xcode project that demonstrates the false positive?