Adds a visualizer to KIF #1179
Adds a visualizer to KIF #1179
Conversation
dostrander
force-pushed
the
dostrander/add-visualizer
branch
from
c882003 to
8c5ec62
Compare
Visualizer/KIFEventVisualizer.h
Outdated
|
|
||
| @interface KIFEventVisualizer : NSObject | ||
|
|
||
| + (instancetype)sharedVisualizer; |
There was a problem hiding this comment.
Do we want to set - (instancetype) init to NS_UNAVAILABLE? Or would anyone else be calling the init method?
There was a problem hiding this comment.
Good callout, since we are creating our own window overlay we probably want only 1 being created.
There was a problem hiding this comment.
Had to make an initPrivate method because since it's marked unavailable using init internally also breaks
dostrander
force-pushed
the
dostrander/add-visualizer
branch
2 times, most recently
from
4c5a35e to
929dd5b
Compare
Visualizer/KIFEventVisualizer.h
Outdated
|
|
||
| - (void)visualizeEvent:(nonnull UIEvent *)event; | ||
|
|
||
| // Unavaiable. |
dostrander
force-pushed
the
dostrander/add-visualizer
branch
from
929dd5b to
31999ee
Compare
|
I don't believe the CocoaPods podspec includes these new files, we had been running KIF at HEAD for a while and had a build failure introduced with this PR. I see that the CI only tests Carthage. Do most people use Carthage these days? |
|
@jgavris I'll fix that this morning, sorry about that. I don't think most use Carthage. Most probably aren't on HEAD though. I'll also fix up the project so we catch this in CI (or earlier). |
|
@dostrander That would be excellent! Thanks. For our internal pods, we just have a really simple example project that imports the pod and checks that it builds. |
|
At the same time, for third-party libraries, we are starting to recommend not building from source, as those iOS build times grow and grow. So Carthage with something like Rome, or Cocoapods with the binary plugin, but that also has to lean on good CI in the external libraries. |
Adds a touch visualizer to see where touches are being sent to. Currently it has a default look and feel. We can have a configuration object that can get set if we feel in the future we want customizability over the visualization of touches.
This is an explicit opt-in feature similar to printing the view hierarchy.