I'm worked on a custom keyboard and Apple review team rejected it because the keyboard does not support 'Numbers and Decimals' types.
So, I found that the problem is that when a text field requires those specific type of keyboard (for example to inset age, measures, or other numeric values), my keyboard 'misses to respond'.
I understood, reading from Apple documentation, that you must respond to the UIKeyboardTpye property per text object's.
I searched for specific delegate of the UIInputViewController but I wasn't able to find something close to that.
In this forum I found that one good place to examine the current keyboard type required is the textDidChange: delegate, but, it is not called.
I suppose this responder is called when your keyboard, somehow, 'declares' to iOS that it can handle Numbers or Decimal types. In fact I created a simple app with a simple UITextView that requires the Decimal keyboard type:
textView.keyboardType = UIKeyboardTypeDecimalPad;
And I put a NSLog() in the keyboard extension Input View Controller textDidChange: delegate.
As I tap on the text view my delegate is not called, instead the standard Decimal keypad is shown and in the Xcode console I see the following message:
Can't find keyplane that supports type 8 for keyboard iPhone-Portrait-DecimalPad; using 405786210_Portrait_iPhone-Simple-Pad_Default
I noticed also that this message comes when the UITextView requires the not-allowed keyboard types, i.e. the phonepad. All other keyboard types do not issue that message and the custom keyboard is shown and the textDidChange: delegate is correctly called.
The Numbers and Decimal types are surely allowed and are a MUST for the review team guys. Why the behave as a forbidden-types?
I think we need to 'declare', for example in the info.plist that our extension supports various keyboard types, but... well or more simply... I do not get the point... so... I'm asking... How can I add multiple keyboard types to my keyboard extension??
Thank you very much for help!
After the second rejection of my keyboard extension they sent me a screenshot. I noticed that they, generally, test apps on iPad. This made me think.
After some test it came out that the Numbers and Decimal types do not respond the same way on iPhone and iPad.
On iPhone a text view requiring Numbers or Decimal type keyboard always shows the iOS keypad, i.e. the custom extension is not called.
On the other side, on the iPad a text view requiring Numbers or Decimal type keyboard activates the custom extension.
Finally, after provided a standard numeric keypad (even if my keyboard uses hand-written techniquies) it was approved.
Related
I know that unlike the operator name and the country code, it's not possible to get the user's phone number in iOS programmatically (at least not with publicly available APIs).
But I have just tried the app Lyft and it is autosuggesting my current phone number. I want to know how this app is doing that.
The phone number suggestion appearing above the keyboard is a built-in iOS feature and it works if a Text Content Type is set for a UITextField.
Since iOS 10, you can provide a content type for your inputs. iOS then will recommend autofill options for the given content type.
You can set up a content type...
in Interface Builder by navigating to the Text Input Traits section of the Attributes inspector (the fourth icon from the right in the top sidebar):
...or programmatically with:
textField.textContentType = .telephoneNumber
On iOS, the numeric keyboard has a return key on iPad but not on iPhone.
I am taking the standard approach of adding a toolbar as inputAccessoryView of the target text field, with a "Done" button in it.
However, on iPad the keyboard already has a return key (labelled "Done", "Next", etc. according to one of the constants enumerated in UIReturnKeyType); I would like to display the accessory view only when necessary.
Is there a way to detect the presence of such key, other than the (inelegant) method of querying the user interface idiom?
I ask this because, the fact that the iPad keyboard has a return key and the iPhone one does not seems like an implementation detail, in principle unrelated to whether the device is a phone or a tablet. As such, it feels like it might change in the future, breaking my (unrobust) solution.
There's a bucketload of previous questions/answers about this already.
"Can't find keyplane that supports type 4 for keyboard
iPhone-Portrait-NumberPad; using
563160167_Portrait_iPhone-Simple-Pad_Default"
However all the answers involve changing a setting on the simulator, but I'm not using the simulator, I'm getting this message in the console when running on a phone.
There's also a few more answers when the issue arose trying to change the return key on the keyboard, but I'm not doing that either.
All I have is two UITextFields, one sets the keyboard entry type to UIKeyboardTypeNumberPad and the other uses the default keyboard type. That's it.
Then the message appears in the console when the text field set to UIKeyboardTypeNumberPad becomes the first responder.
If I change it to UIKeyboardTypePhonePad, then the message becomes
Can't find keyplane that supports type 5 for keyboard.
A numeric keypad will appear in both instances however it takes a very long time to do so, quite a few seconds.
If instead of specifying a numeric keypad the UITextField just uses the default keypad then it dose not have this long delay time before it appears.
[XCode 7.3, iPhone 6, iOS 9.2.1]
I want to add a search field inside my custom keyboard that allows the user to search for content which can then be input into the main text document for which the keyboard is being displayed.
However, calling -becomeFirstResponder on the UITextField object causes a 3-4 second lag during which no input is accepted. The same thing happens if I call -resignFirstResponder. I can set the text property of the text field just fine, but that means that there is no caret, and the text is truncated to fit.
On calling (become|resign)FirstResponder, I get the following messages in the log:
2014-10-28 13:39:50.920 Giffy KB[2073:514844] Received 0 images
2014-10-28 13:39:57.942 Giffy KB[2073:514745] <_UIRemoteInputViewController: 0x14762a030> timed out waiting for fence barrier from com.theappical.giffage.giffagekb
2014-10-28 13:39:58.446 Giffy KB[2073:514745] View service did not balance fencing 'begin' messages with 'end' messages within a second; timing out.```
Other third party keyboards seem not to use textfields (they use custom views instead). Does that mean this is a bug at Apple's end, or is there something I can do to resolve it?
Filed a bug report with Apple for the same, ended up faking a text field using a UILabel. As of now (iOS 8.1 latest), this issue has yet to be resolved.
I have a requirement wherein I have to change the text of the return key of the iPad to Sign-in. Obviously it is not one of the options available in the sdk. I have searched it over the net and it seems doing that possible.
The only question remaining is whether the app would be accepted by Apple if I modify the default system keyboard? The HIG is not clear on this , it states that "A custom input view can replace the system-provided onscreen keyboard in apps" and "You can also provide a custom input accessory view, which is a separate view that appears above the keyboard (or your custom input view)". Nothing about whether we are allowed to add an extra button on a system keyboard.
Any experiences??
#Vin you can change the name of return key of the keyboard to your requirement. I have an app that has the changed to return key name to Done and Search. And apple did not reject it.
To "Sign-In" you can use the return key UIReturnKeyJoin
textField.returnKeyType = UIReturnKeyJoin;
EDIT
Nope. You get the return key and
keyboard types defined in the OS.
Unless you want to try to hack the
keyboard's view hierarchy to change
that button, which would be a really
bad plan. (Standard recommendation
here is to file a bug report with
Apple to let them know you'd like
more/different options.)
see Custom iPhone return key text
Since I didn't get any satisfactory answer, I convinced the client that it would be inappropriate to modify the default system keyboard for a sake of one button(even if it is allowed by Apple). We are now going for the "Go" option available for return key.