When I compile and run my tvOS project with the new Xcode13+, the tab bar scrolls with the scrollView, and I can't access the split view controller moving the focus.
The issue doesn't happen with Xcode < 13. However, after updating to Monterey, I don't have a choice.
Pre-condition:
Create an app on tvOS with a tab bar controller;
In one of the tab, put a split view controller;
In the collapsed master view controller, put a table view.
Issue 1:
Observe that moving the focus towards the left to open the collapsed master view controller, doesn't work anymore. The master view controller won't be pulled out. The only way to pull it out is to tap the back button (ex menu button).
Issue 2:
Scrolling down on the tableView in the master view controller would also scroll away the tab bar at the top (this was possible only setting the tabBarObservedScrollView before, but now is deprecated and it happens automatically. Even using [self setContentScrollView:nil forEdge:NSDirectionalRectEdgeAll] doesn't help.
Did anyone get the same problem? Do you know why this happens and if it can be solved?
In the meantime, I reported the problem to Apple.
PS. another odd thing is that the Apple documentation for setContentScrollView:forEdge: is empty (as of today).
Update:
Observe how even setting the property to nil, it is still populated:
After deeper investigation, I found that the problem happens only when compiling with Xcode13+ and running on tvOS15+.
For some reason, the property above is automatically populated for ALL UITableViewController.
Replacing the UITableViewController with a UIViewController with a UITableView inside solves the Apple issue.
This is a bug with Apple SDK:
Observe how even setting the property tabBarObservedScrollView to nil, it is still populated:
This happens for ALL UITableViewController.
Replacing the UITableViewController with a UIViewController with a UITableView inside wor the Apple issue.
--
Regarding the swipe left, it's another Apple bug or decision to not allow the focus to move on the master view controller when on a split view controller.
I have been using this:
UIApplication.sharedApplication().keyWindow?.rootViewController!.view.addSubview(self.customView)
To add a modal view over all the views in the view hierarchy in app.
But this is giving me problem. It adds subview as expected sometimes but sometimes it doesn't' work.
In what case this wont work and what's the best way to add modal view in view hierarchy like UIAlertView.
Depending on what's happening, there can be more than one UIWindow at a time - for example, if a system alert shows up, you will have two separate windows (one for your view controller, one for the alert itself).
A similar example can be made for the system keyboard. If the keyboard has focus, that will be your keyWindow.
A way of making sure you are adding the subview on top of all windows, could be: UIApplication.sharedApplication().windows.last?.addSubview(yourSubView).
I've also seen people using the application delegate, with: UIApplication.sharedApplication().delegate?.window.
When you subclass UITableViewController, you normally get certain behaviors "for free". For example, when a text field in your table view becomes first responder, the view controller automatically scrolls itself to ensure the field is fully visible.
However, when the table view controller is the detail view controller of a UISplitViewController, this auto-scrolling no longer takes into account the presence of the keyboard. The table view controller will still auto-scroll to keep the text field within the bounds of the screen, but it no longer scrolls to keep the field from being covered by the keyboard.
You can test this yourself by creating a new project using Xcode's "Master-Detail Application" template, and replacing the detail view controller with a table view controller that displays cells with text fields in them.
I would like to understand why the auto-scrolling stops accounting for the keyboard in this case, and if possible how to rectify that without having to duplicate the auto-scrolling functionality myself. BTW, this has nothing to do with overriding viewWillAppear (as in some other questions here about table view controller auto-scrolling).
I know its late but this might help others who are having this issue. This happens to me as well when I added textfield in UITableViewCell. What I did was to remove
superViewWilAppear:animated
line in viewWillAppear method.So the method looks like this
-(void)viewWillAppear:(BOOL)animated{
//[superViewWilAppear:animated];
Your rest of code
}
But what this does is it removes the auto scrolling all together and you have to manage the scrolling of UITableView when textField starts editing. Don't know if this solved your problem but it will save you the trouble of considering keyboard height for different devices and its better to manage on your own. Also I am not sure if this is the right way to do it but it worked for me.
The issue I am having is that text in a UITextField disappears every other keyboard tap on iOS. This issue has happened in multiple view controllers, but previously I have been able to resolve the issue by making the textfield taller, giving it more room to draw the text inside.
That solution is not working for this particular situation. I am using a custom font for my app, so I have used a subclass of UITextField for the text fields that automatically sets the custom font. I have tried reverting back to the basic UITextField, but this does not solve the problem.
I have also tried commenting out the delegate methods I've implemented in the problem view controller and this does not solve my issue. I don't really know what else to try, so I'm hoping someone else here can point me in the right direction. Here are the things I've discovered about my problem so far:
The text disappears and reappears with every key tap, though tapping the backspace button does not change the appearance/disappearance of the text (i.e. if tapping backspace when the text is visible, text is deleted normally. If tapping while the text is hidden, characters are deleted from the textfield's text, but the user can't see what's happening)
Text appears at the bottom of the textfield when it is visible and the textfield is the first responder
When a different text field becomes first responder, the text in the problematic text field will be drawn properly, centered vertically in the textfield, and always visible.
Making a textfield first responder when it has text in it already will cause the text to redraw and appear as if it is scrolling up/down within the textfield. The text will alternately be drawn centered in the textfield and "scroll" down out of view, or be drawn out of view and "scroll" up into view, resting at the bottom of the textfield.
The view controller only has problems in one of the two modes it is presented in. It is either presented modally as the root view controller of a UINavigationController, or it is pushed onto a modally-presented UINavigationController's stack as the navigation controller's third view controller. In the first case, where it is the root view controller, the textfields work perfectly fine and exhibit none of the strange behavior described above. The strange behavior occurs consistently in the second case.
A good example of this problem can be seen in the video posted in this similar question: UITextField text disappears on every other keystroke. The answers to the question itself are not useful and do not solve my problems.
EDIT
I've been successful in reproducing the issue that I was having before. It turns out that the issue was caused by adding a subview to the navigation controller's view, then removing it while a UITextField was in focus. If the subview is removed while the UITextField is not being edited, the bug will not occur.
In my case, a loading image was added as a subview to the navigation controller during a net call, and removed after the completion of said call. During this time, a UITextField would be active, which would cause the visual bug I describe above.
I've recreated the bug in a standalone example project I've uploaded here: https://www.dropbox.com/s/s4kc05vg1pwteeo/Funky%20TextField%20Tester.zip. Also note that if you tell the textField to become first responder in the viewDidLoad implementation for the view controller, this bug will occur right at the beginning and persist.
NEW QUESTION
It's easy enough for me to just avoid putting the loading view in the navigation controller's view, but doing so gives me a nice effect of having the loading view 'float' in the same position on the screen, whereas putting it into a view controller's view on a nav stack raises a bunch of visual issues (moving loading view position when view controller is pushed onto stack, loading view is obscured by other view controllers, etc.).
Is there any way to reproduce this kind of look without putting the view into the navigation controller's view, or perhaps a safe way to put it into the navigation controller's view without performing strange workarounds like stopping editing on all UITextFields in the duration of the subview's presentation?
I've got the same issue here, didn't have in a previous version.
thanks to your project I've test, I've found that the issue is coming from presenting a view controller embedded in a navigation controller with a translucent navigation bar.
I set opaque bar in the simulated metrics of the navigation controller I was presenting and no more issue with UITextField.
On my case at least, everything were resolved at the moment I set opaque bar for top bar in simulated metrics in InterfaceBuilder for my UINavigationController which embed a UIViewController I've wanted to present modally
Hope it will be the same for you as well.
I had a similar problem where the UITextField was showing the text fine but when I came back from the background it was not show the text and the textfield seemed to not respond. However, I noticed that it was actually accepting input. It just wasn't visible. Showing the view in xcode's debut mode revealed that the textfield had moved down and was layered under other views and not visible. In my case I disabled AutomaticallyAdjustScrollViewInsets to NO and the problem was cured!
I have this exactly same problem on two search bars and several UITextFields in my app. It seems to come and go inexplicably and happens across multiple device types in the simulator and on multiple real devices. Rebooting the actual phone seems to make the issue go away in an app that's been installed on the phone. I'm guessing this is an Apple bug...but I really have no leads and none of the solutions here seem to fix the issue.
UPDATE
Ok, I may have solved it...I have a login controller that is shown before this text field, and I've found that if I open the keyboard on that login controller (like I don't just pre-fill in the username and password) then this behavior occurs. But if I don't open the keyboard, then it's totally fine.
UPDATE 2 -- SOLVED!!
So it turned out that when the user or password textfield in the login controller were selected, one of them became the first responder. When the user hit Login and the view went away, those fields never resigned from being the first responder, so it put the keyboard in a state of flux for the rest of the app.
Having the text fields resign as the first responder like below in my login method solved the issue:
if (_emailTextField.isFirstResponder) {
[_emailTextField resignFirstResponder];
}
if (_passwordTextField.isFirstResponder) {
[_passwordTextField resignFirstResponder];
}
...do login stuff
I had same problem . I was using becomeFirstResponder method inside viewDidLoad. But then I felt that becomeFirstResponder should be inside ViewDidAppear because didLoad method renders whole view at that time there is no user interaction . actual user interaction starts after viewDidAppear so I moved becomeFirstResponder inside the viewDidAppear method and everything works fine now.
Previous
-(void)viewDidLoad{
[self viewDidLoad];
[self.textField becomeFirstResponder];
......
}
After
-(void)viewDidAppear:(BOOL)animated{
[self.loginTextField becomeFirstResponder];
......
}
It seems to be a quite common bug from Apple and people have solved it in many different ways.
I came across the same problem. After some trials, I found my case is because I hide the navigation bar when certain textField "didBeginEditing". Once this bug occurs, it occurs all around the app, not only in that controller.
I eliminated this bug by not hiding the navigation bar (which is not what I really wanted but had no choice).
Hope this will help someone. In a nutshell, this bug can happen for various reasons. Try to undo some change until the bug disappears then you know where exactly it comes from.
I had the similar problem on some of the UITextFields added on UIView and found that it was a bug created by myself not by apple . I am setting textfield.setContentScaleFactor on textFieldDidBeginEditing delegate.
[textField setContentScaleFactor:10.0];
Removing the above line and it works without doing any other stuff.
My View hierarchy ---> UIScrollview --> UIImageView --> UIView --> UITextField
Hope it helps anyone.
I had a similar issue. Solved it by resigning keyboard for a previous screen.
The previous screen had a textfield which has a keyboard type of Numpad. So before coming to the screen where textfield flickers, i called resignFirstResponder.
The EDIT from the Ziewvater's original question solved my problem. I had several textfields being loaded at runtime and whenever I'd navigated back, those views were disposed/removed and then it'd instantiate new textfields each time. After reloading once, it would be clear text, but after editing did end, the textfield.text property would be set and you could see the text.
var responder = View.FindFirstResponder(); //(i'm in Xamarin)
if(responder != null)
responder.ResignFirstResponder();
Doing this in the viewwilldisappear fixed my problem. THANKS!!!!!!!
I have a UITextField set up in a UITableViewCell, for a control mimicking that in Apple's own Contacts app, when you go to edit a field. This is all mostly working fine, except for a little UI bug.
The UITableView is part of a UIViewController created and loaded from a XIB, but the text field is being created programmatically (and becoming first responder) in tableView:cellForRowAtIndexPath:, so that it can be added to the cell.
This results in a slight keyboard lag, where the view controller is pushed onto the stack, with the keyboard coming soon after.
The Contacts app, however, pushes it all as one.
How can I correct this lag? I've tried moving the text field creation and first responder-ing to viewDidLoad, and this didn't help. I even tried creating a layoutSubviews and calling it from outside the view controller, before it was pushed to the stack.
Unfortunately, it doesn't seem as though the text field actually becomes the first responder until it is part of the cell—well after the view has been pushed.
You have to let the UITextField become the first responder in viewWillAppear.
I have created an example project here:
https://github.com/lukaswuerzburger/pushed-keyboard