I am facing problem in my app because of the new split keyboard option in iOS5.
Is there any way we can hide or disable this option in objective C?.
Thanks in advance.
Seems like the split keyboard does not use the same functions as regular keyboard. see here.
missing kb notifications
Here's the problem: You can iterate through the keyboard subviews and hide the button but you can't control the state of the keyboard when going from one app to the next. It would get really tricky and sneaky to force the private api to call when the application did enter foreground and the keyboard became active.
You could do this but apple may deny you from the store.
Fix your view to account for the keyboard movement. Your users will dock or unsplit the keyboard when there's clear disruption in the UI due to the keyboard placement.
Other solutions could be to move the entire view that requires keyboard placement to be docked or undocked using the notifications. See other posting here: StackOverflow article
Related
In an iOS application, is it possible to make own keyboard suggestions if the user taps a specific UITextField? The suggestion should only appear if the UITextField is empty.
By keyboard recommendations I mean the Predictive Keyboard:
Swift code is preferred.
Thanks!
I don't think you can provide suggestions to the actual keyboard so they get presented, but what you can do is write your own inputAccessoryView to be there instead, and handle the tapping/appending of text yourself, and possibly disable the completion from the keyboard. This is essentially what the messaging apps do to present a bar with buttons to add photos and attachments when writing.
Since you don't mention what you're trying to accomplish I don't know if this would make sense. Let me know if you want me to elaborate on how to do this in code.
I've added an inputAccessoryView to the iOS keyboard for certain UITextFields in my app. This accessory view provides essential functionality to the user (some buttons that are displayed nowhere else in my app). My understanding (which could be completely wrong) is that if a physical (bluetooth) keyboard is available iOS will not clutter the screen with the software keyboard. If that's the case, users of my app with a physical keyboard will be missing some functionality and I'll need to account for that. So the first question is, is that something I have to worry about? Thanks.
The input accessory view should appear at the bottom of the screen if a physical keyboard is used, so they will still be able to access the functionality. If you want to try this in the simulator, check the Simulate Hardware Keyboard option under the Hardware menu.
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...
Is there a way to force up a software keyboard when the user has a iOS bluetooth keyboard device installed?
Or, to that end, is it possible in code to disable a specific bluetooth device?
Thanks!
In most (maybe all?) iOS apps with which I have used Apple's bluetooth keyboard, pressing the eject key (located in the top right corner) will bring up the soft keyboard on the screen. Maybe that little factoid could help you in some way.
Not from within the application's code, if you're planning on getting into the app store. Apple expressly does not provide methods to show or hide keyboard, instead pushing you to use becomeFirstResponder and resignFirstResponder.
You may be able to do this through some non-AppStore-friendly methods, but somehow I don't think that's the answer you're looking for.
(Note - you could make a fake, Apple-looking keyboard when the real one is hidden, and check if the real one is hidden based on whether a view is visible, but if Apple notices you doing this, you'll get denied.)
I want show the iphone keyboard. How can I write the code (programmatically) to show the keyboard.
As Jacob said, you'll have to run becomeFirstResponder on a UITextView to make it the first responder, the object the user's currently working with. If you do this, the iPhone OS automatically shows the keyboard, cause that's what's needed for working with a UITextView from a user perspective.
As others have noted, you send the becomeFirstResponder message to the control that you want the keyboard to edit.
One extra thing you should be aware of is that if you plug an external keyboard into an iPad then the keyboard will not appear on screen. You need to design your view so it doesn't look silly without the on-screen keyboard.