Is there any way in iOS SDK to detect the presence of an active Bluetooth keyboard? As many well know, when a Bluetooth keyboard is active, the on-screen keyboard does not show, so interface placements might have to change...
Right now I am doing this semi-passively by responding to keyboard events, but those notifications are a little slow to post and don't jive perfectly with my animation code. It would be nice to just have a BOOL somewhere to read on...
Related
Is there a way to detect if there is a PHYSICAL keyboard connected in Flutter? I would like to detect if the user is using a physical keyboard, and alter the UI depending on if this is so.
Has this changed? I would also like to detect if a keyboard is connected/available. I'm currently reacting when a physical keyboard is used with a RawKeyboardListener but it would be a smoother experience for the end user if I could see if a keyboard was connected, before it's actually used.
Looks like this is available in Android native: https://developer.android.com/reference/android/content/res/Configuration.html#keyboard
Not sure if it's available on iOS but we have the RawKeyboardListener approach that is OK on iOS. For Android we are supporting Chromebooks with physical keyboards and to provide the best experience we would like to react as early as possible to physical keyboards.
If you want to know if the physical keyboard has been used (but not when it connects), you could listen to keyboard events by listening to RawKeyboard.instance.addListener, and switch modes if you see a key event: RawKeyboard only sends physical keyboard events.
But to answer your question, no, there's no specific notification for when a physical keyboard is connected.
I have to have a bluetooth scanner connected to an app I am developing. The scanner acts as a keyboard input but there are no keys, only a button to scan with. The problem I am running into is there are a few UITextFields that a user needs to interact with on the screen.
When the user taps the textfield to enter in data, no keyboard pops up because the iOS thinks there is a full keyboard attached via bluetooth.
How can I force the screen keyboard to show up when the UITextField "becomes first responder" ?
Thanks in advance!
The problem is that the Bluetooth scanner is pretending to be a Bluetooth keyboard, so iOS thinks that it doesn't need to show the onscreen one.
Unfortunately there's no easy answer for this. Some scanners have a button you can press that will force the onscreen keyboard to come up. Some allow you to pair in "iPhone mode" (or something similar) so that it doesn't act as a Bluetooth keyboard.
This answer to a related question (https://stackoverflow.com/a/3837131/493988) has what seems like a hack based on a UITextField's inputAccessoryView, but I haven't personally verified it so I can't say much about it. Good luck!
Have you tried [myTextField becomeFirstResponder];?
I have received comments from blind users that some of my sound and music related apps only work with VoiceOver off.
With VoiceOver Accessibility enabled on an iOS device, is it possible to enable a music keyboard or drum pad touch area so that music sounds can be played immediately, instead of VoiceOver prompts, when a keyboard key or virtual drum set (etc.) is tapped?
Just setting the UIAccessibilityTraitPlaysSound AccessibilityTrait on a UIView subview doesn't seem to do it. I get VoiceOver clicking instead of piano or drum sounds with VoiceOver enabled.
A blind user can turn VoiceOver completely off, but then all the other buttons (Instrument selection, Configuration, Help, etc.) and/or controls will no longer will have VoiceOver assistance.
I can now answer my own question.
iOS 5 has added a new API exactly for this need:
[ mySubView setAccessibilityTraits: UIAccessibilityTraitAllowsDirectInteraction ];
will disable VoiceOver just for that UIView subview, but leave other subviews (other buttons, etc.) unaffected. This API allows an app to get responsive touch handlers more suitable for keying a musical instrument within the specified subview, even with VoiceOver enabled and providing assistance for other portions of the app's UI outside the specified UIView.
I don't think it's possible for you the developer to turn off VoiceOver, and as you've discovered it's impractical for users to play an instrument with Voiceover intercepting gestures.
I think it's acceptable to leave this in the hands of the user. It's easy to toggle Voiceover off/on by triple-tapping the home button, although this is off by default (users can turn it on via Settings > General > Accessibility > Triple-click Home). With that option engaged, users can explore your interface with Voiceover on, then toggle it off when they're ready to make music, and toggle it back on again when they're finished.
With that in mind you just need to be sure all interactive components (e.g., piano keys, parts of the drum kit) have meaningful labels.
This is a bit curly, and I am not sure there is an answer.
I have a simple application that uses a handheld bluetooth scanner paired to an iPhone to keep lists of parcels coming of the back of trucks.
The scanner acts-as a keyboard sending character strings on scan. In the application the user must pair with the scanner in settings.
Upon scan complete a textfield is populated with the sent string. The last character is a return char, at which time the contents are added to a datasource for a UITableView.
The problem is this; Once the scanner has been used once the system seems to recognize it as the only user input. Any future attempt to bring up the soft keyboard fails. This goes beyond the scanning application ~ quitting the app completely and attempting to use Apples SMS app also fails to bring up the keyboard.
Is there any (apple legal) way of either using both or setting preferred input device? There seems to be a myriad of legal issues around Bluetooth and accessories, I am wondering if I am out of luck. Has anyone heard of anything that might help me out?
It appears I am not alone (as in this post regarding iPad soft keyboard)
I think you've pretty much covered it.
According to HT4111:
You can stop using a Bluetooth accessory by either turning off the accessory, or turning off Bluetooth on iPad.
According to Gizmodo's 10 iPad Essential Tips & Tricks:
When you have a Bluetooth keyboard connected to your iPad, the virtual keyboard will cease to appear. (This is a good thing.) However, what if, for some random reason, you needed that virtual keyboard? Don't unpair your Bluetooth. Just... Hit the eject key on Apple's physical keyboard. It'll bring up the virtual one.
If there's an off button on the scanner, then hit that. If you have an actual bluetooth keyboard, then use that (or hit its eject button if it's an Apple keyboard). If you have control over the design of the scanner hardware, then you can add a "show keyboard" button (I'm not sure which keycode Apple uses for "eject") if turning it off is too tedious.
Socket Mobile just added a new "double tap" feature to their Bluetooth barcode scanner that lets you open the onscreen keboard. There's a video demo on YouTube. http://www.youtube.com/socketmobile
I observe that with the iMac magic mouse, while using the iPhone simulator, if:
a) the active view has an object in the center of the iPhone screen which is capable of generating touch events, and
b) the iMac operator accidentally or otherwise drags their finger(s) across the magic mouse surface in a way which would normally be used for scrolling, that
the object in the center generates (bogus) mouse down and drag events.
If there is no such object in the center of the screen, there is no issue.
Is there a way to programmatically or otherwise disable this feature?
This is actually an issue with all Mac input devices with scroll functionality. If you do a two-fingered scroll up and down on a Macbook touch pad the same thing happens.
I believe this is more or less "intended", though it appears the touch up event is lost - so sometimes the interface gets stuck after a scroll gesture. I don't know of a way to programmatically disable this feature, unfortunately :-/
Gesture-based scrolling the iOS simulator was disabled sometime around iOS 4 or the iPad, I believe. It would have conflicted with the giant, scrolling window of the iOS simulator running on smaller screens.