I've inherited a partially finished app that I need to finish. Unfortunately there seems to be a bug involving the display of the keyboard. The bug does not occur when opening the app on my iPhone, but it does appear in the simulator, and I'm being told it also appears on iPad.
When selecting a text field on the affected , the keyboard background rolls up in the right spot. However, the keyboard buttons appear near the top of the screen, and then rolls up until they can no longer be seen. If another text field is selected, the keyboard buttons appear so that they are visible, but still at the top of the screen, instead of down on the keyboard background. The problem can be seen in this video:
https://vid.me/0bEs
I've searched through the code, and I can't find anything overt that should cause this behaviour. Any ideas would be appreciated.
Have you check in appdelegate or in view controller that is there any observer with selector method. I generally face such issue while working on some other person's code.
Just search in through out project UIKeyboardWillShowNotification, UIKeyboardDidChangeFrameNotification, UIKeyboardDidShowNotification.
Hope you will get something so we can solve this riddle.
Related
On the iPad there is an icon to dismiss the keyboard on the bottom right of the screen. When a user changes their input data, and taps on this icon, the prior results (calculations) are still displayed. I need to change the UITextField results so that they know they must tap on my submit button to update the results. Any thoughts?
If your code is looking for the UIKeyboardWillHideNotification, you'll know when you can update your calculations.
Sample code can be seen here.
p.s. welcome to StackOverflow! For future questions, it might be useful to tag then with the language that you're using (objective-c or swift), as well as ios.
Upvoters: can you let me know if you've seen this problem as well?
The issue I'm seeing occurs roughly every 1 in 15 times when I try to modally launch a view controller from a button on a certain scene.
This is done with iOS 9.2.1 and XCode 7.2, though it is not clear which versions it happens on. It's not easy to change the iOS version down.
The symptoms are as follows:
The destination view controller is not visible on the phone. Instead, the top bar (the one with the carrier) goes black, and sometimes it flickers so the whole screen is completely black. The launching view controller is visible, but not responsive.
When this happens, I go to the XCode screen and do view debugging. Remarkably, this shows the destination screen, almost as it's supposed to look. The only difference is that one of the views has not done its drawRect, and one of the other views looks all speckled. But of course it does not at all correspond to what the phone is showing.
The cancel button on the destination screen seems to still work, because when I press where it's supposed to be, the app continues to function. If I try to relaunch the screen with the button, it again doesn't work though. So once this has happened, the screen has stopped working for that session and the app needs to be killed and restarted.
There are not many hints, but this information may help:
There's 3 scrollviews containing views on the destination screen. All three child views have their own drawRect. It turns out one of the drawRects is not called when the error occurs, resulting in the grey background being shown. The speckled view does run, but I have no clue why it looks like that in view debugging.
No warnings in XCode. Nothing about NSLayout constraints or presentations overlapping.
Two fields are set on the destination view controller on the prepareForSegue function.
The segue is launched from the times button by way of the storyboard. There's no missing or extra outlet, and it is named correctly for the prepare function to catch it.
The issue is sporadic, but will reliably occur if you launch/cancel many times in a row.
Here are the screen grabs. I won't show you the black screen. It's just black with the carrier and the time.
I've solved it. Checking the memory usage turned out to be quite useful.
The grey area was supposed to be filled by a large background with lines drawn. It turns out the naive implementation of drawBackground causes the memory size to balloon to over 200MB. I replaced it with a CSTiledLayer, and now it takes a few MB instead.
Has anyone ever had this issue:
When you slide your finger from the bottom of your iOS screen to the top, it shows the control center - and then you swipe your finger down to get rid of it, but now when you try to use your app - a lot of the dynamic content is completely broken.
After pressing the home button and coming back to the app, everything is back to normal.
It appears the Control Center breaks my dynamic code - which is basically just a UIWebView that I'm assuming is not refreshing properly.
Does this have something to do with the "app entering the background" and "coming back to foreground"... or is there some sort of event where I can track what's going on?
This is a very strange issue.
It seems I was improperly using "applicationWillResignActive" when I really wanted to use "applicationDidEnterBackground".
By making sure to use "applicationDidEnterBackground" instead of the "applicationWillResignActive", my app appears to function perfectly fine again. Viewing the Control Center or Notification Center no longer breaks my app.
Hope this helps someone else who makes a silly mistake.
I'm working on an iOS app that uses dark keyboards. One such keyboard is affiliated with a UITextView. I create the UITextView and play around with it for a bit and every thing works as it should.
The problem occurs when I dismiss the keyboard and then click the home button and dismiss the app into the background. By reopening my app, I return to the screen on which I just was. When I click on the UITextView, it gives it firstResponder status and the UIKeyboard reappears.
If you check the properties of the UIKeyboard, the appearance is still set to dark but for the first second the keyboard is on the screen it shows as light.
Does anyone know how to force a refresh of the keyboard between the app entering the foreground and the keyboard being displayed?
I do not believe there is anything you can do at this time to fix this. I had a simple project I had just done to send in a bug report to Apple, but it didn't fail in the demo project as it does in my code. I was going to toss that project away when I saw your problem.
So I have verified that even in the very latest unreleased Xcode and iOS beta this still happens. But, since I had the project already, I did enter a bug report on it with the demo project so Apple can see it for themselves.
15586497 "Keyboard flashes from white to dark under one specific test"
If you want to enter your own bug you can say its a dup of the number above, then no need for a demo project.
IMHO, these things do get fixed, but not for a while - maybe iOS 8 if you're lucky, so I think you're just going to have to live with it, or switch to using a white keyboard.
During development of a recent feature for my iPad app, I realized that the new iOS5 keyboard docking/splitting behavior was causing huge issues. I use an inputAccessoryView for the keyboard with a text field on it similar to Safari's find on page feature. I display the keyboard over a scrollable UIWebView, so part my troubles come from having a shrunken UIWebview when the keyboard is docked and having a (mostly) fullscreen webview when it is undocked.
The main issues I have run into with the API are that the new UIKeyboardWillChangeFrameNotification and UIKeyboardDidChangeFrameNotification notifications are a step back from the previous API at best, and have garbage data that makes it nearly impossible to understand what the keyboard is really doing in many cases.
Can any of the following keyboard behaviors be recognized without arduously examining the begin/end frames that come back on the notifications?
Keyboard Undocks
Keyboard Docks
Keyboard Splits/Unsplits
Undocked Keyboard Shows
Undocked Keyboard Hides
View rotates while keyboard is undocked
I've come up with some abstractions to recognize frames that are docked or offscreen, but even with that, my code is becoming very unmanageable. If you've found better ways to do this, please answer or comment. I hope I'm missing something here. Thanks.
The thing is not to overthink this. Nothing of any importance has changed. If the keyboard comes into docked position at the bottom of the screen, you will get a "show" notification. If it leaves the docked position at the bottom of the screen, you will get a "hide" notification. That's exactly what happened before iOS 5.
The only difference is that instead of leaving the docked position because it is moving offscreen, it might be leaving the docked position because the user undocked it. You'll still get a "hide", so you can move your interface back into its base position. You don't need to know that the keyboard is now undocked (though you can find out that it is not offscreen from UIKeyboardDidChangeFrameNotification if you really want to). The reason you don't need to know is that when the keyboard is undocked / split, the user can be proactive and move the keyboard if it's in the way of something that needs to be seen.
Thus, all your old code from before iOS 5 continues to work just fine. It's all really quite clever...