UIControl Not Calling Event Handlers If UITextFields In SuperViews Are Active Responders - ios

Question

UIButton
I have a View Controller in which the user needs to enter in mission level data. The view controller then has a custom UIView (Crew View) in its view hierarchy where there is a button that the user can press to add Persons to the mission. Those persons are custom UIViews as well (Person Views) that get added as children to the Crew View.
The layout looks something like this:
VC
|_ScrollView
|EntryFields
|_ Crew View (UIView subclass)
|UIButton
|_ Person View (UIView subclass)
|EntryFields
|UIButton
|_ Person View
|EntryFields
|UIButton
...
When there is no first responder for the keyboard, all the buttons pressed trigger their respective handlers regardless of where they are in their View Hierarchy.
Now if an entry field in the PersonView is active I'm able to use both the UIButton in the PersonView as well as the UIButton higher up in the Crew View.
But if an entry field in the top level is active, the handler for the buttons are not called.
Note: I know the buttons are receiving the touch events because their UI changes since the .highlighted state gets activated. The button handlers are set to .touchUpInside.
UISwitch
This has also been an issue in another part of my app with a UISwitch. The view hierarchy looks like this:
VC
|_ScrollView
|Entry Fields
|_Some UIView Subclass
|UISwitch
When the keyboard was active in the scenario (from the Entry Fields up the view hierarchy), the UISwitch would not call it's handler (set on .valueChanged).
My Solution: I removed the target handler from the UISwitch and instead set a tap gesture recognizer for the whole view that would manually trigger the switch, this solution worked regardless if there was an active first responder up the view hierarchy.
Has anybody experienced this before? Why are the event target handlers not being called on the UIControls(yet they're still responding in the UI) when there are active first responders in their superview but gesture recognizers work just fine.
Everything is built programmatically, not that it should matter and the View Hierarchy debugger on XCode shows that the UIControls are not being blocked.
More Information
So the EntryFields is actually a custom component (to follow material design with a floating placeholder). The view hierarchy of the EntryField is as follows:
EntryField (UIView subclass)
|_ StackView
|_ UILabel
|_ UITextField
Everything in this project is done programmatically with auto layout constraints. The EntryField interacts with its delegates by forwarding the protocol methods from the UITextField. I don't know if this is messing with the first responder chain in the application.
Here's a sample project (gutted version of the production code) that replicates it perfectly.
https://github.com/barbulescualex/55051678

Answer 1

I've checked your code and found issue in your button declaration. you need to use lazy in order to get the events.
i.e.
lazy var addButton : UIButton = {
let button = UIButton()
button.setTitle("Add Person", for: .normal)
button.setTitleColor(UIColor.purple, for: .normal)
button.setTitleColor(UIColor.green, for: .highlighted)
button.translatesAutoresizingMaskIntoConstraints = false
button.addTarget(self, action: #selector(addPersonField(_:)), for: .touchUpInside)
button.translatesAutoresizingMaskIntoConstraints = true
return button
}()
output
https://drive.google.com/open?id=1_u4a3anvOPuZGlJ3VtM15D6aBdXsclMm
self: The self keyword refers to the current class instance, from
within that class instance.
func addTarget(_ target: Any?,
action: Selector,
for controlEvents: UIControl.Event)
Target: the object whose action method is called.
Why would self in the closure work and refer to my view controller if clicked on normally vs
it not working if there's an active textfield in the superview:
From the docs
The control does not retain the object in the target parameter. It is
your responsibility to maintain a strong reference to the target
object while it is attached to a control.
i.e. It depends upon the current state of instance (Life Cycle) and how the iOS handle it.
When we use let myButton: UIButton = {...}() you're immediately assigning value to myButton variable there are chances that 'self' hasn't been initialized by the OS
.In order to make sure when we addTarget to our button object, 'self' is initialized properly we use lazy keyword
Lazy: Lazy initialization (also sometimes called lazy instantiation, or lazy loading) is a technique for delaying the creation of an object or some other expensive process until it’s needed.
When programming for iOS, this is helpful to make sure you utilize only the memory you need when you need it.
With lazy we are making sure that our control will have a strong reference to current class which is going to handle the action

Answer 2

I am not sure I fully understand the issue you're experiencing, so I did a little demo that should reproduce yours, even though I am not experiencing the same behaviour as you do, at least not for now.
Check it out (video) and let's see if it's on you or not.
Now, I have the following hierarchy in my demo project:
And when I run it it looks like this:
Color legend:
RED: VC's View (self.view)
BLUE: ScrollView
GREEN: Crew View
I have no issues at all as you can see in the video, what's different from yours?
LATER EDIT:
Ok, the issue is more than meets the eye, the good news is that there's no issue, this is just how iOS works and given this opportunity I am going to explain as detailed as possible what really happens.
Firstly, your question was why it works with the bottom textFields but it doesn't work with the top ones.
ANSWER:
You are messing it when you declare the addButton as a let instead of a lazy var, then you add as a target self, which in that scope is the closure itself and after you exit the scope, if you place a breakpoint in func addPersonField you should see that sender.allTargets has no targets. That's ok with the compiler since you can, there was a time when you couldn't do it, but now you can because target is declared as Any?, which means you could even set nil as a target and you'll experience the same behaviour.
Now, you might wonder why it works with self as a closure which gets deallocated after you exit the scope, or why it works just as fine with nil. The doc for addTarget(_:action:for:)
says that:
If you specify nil, UIKit searches the responder chain for an object
that responds to the specified action message and delivers the message
to that object.
Which is your PersonsView, which doesn't get deallocated since is always on screen and has the specified action your func addPersonField. That's why it works before you start using any textfields (I know it works with the bottom ones, I'll get there).
Why it works with the bottom textFields you'll wonder, right? Well, again... you're doing the magic here without knowing, if you tap on a bottom textField that object becomesFirstResponder, now when an event occurs (like your .touchUpInside on the Add Person button) if the firstResponder can't handle it, UIKit sends the event to the text field’s parent UIView object, which in this case is the stackView, if the stackView can't handle it, the event is sent to the stackView's parent UIView which is exactly the PersonsView - which is the golden one, because it responds to the selector you specified addPersonField(_:).
See the personsView below:
On the other hand, when you tap on the TOP textFields (those EntryFields), they are embedded by a horizontal stackView which is embedded by a vertical stackView, which is contained by the ScrollView. Now, if you followed me til here, you got the idea, the Responder Chain goes from EntryField -> Horizontal StackView -> Vertical StackView -> ScrollView -> etc but it doesn't look in the other stackViews that contain your PersonsView, where you defined the selector, that's why it doesn't work here.
See how the stacks are on the same level, embedded in the same VerticalStackView which is embedded in the ScrollView below:
Even though, if you tap on a Top EntryField/TextField, and press return on the keyboard, you call view.textField.resignFirstResponder() which enables the Add Person button again.