Add UITextContentType values to text fields provided by the SDK. #870
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
For STPFormTextField, this was a lot harder than expected, due to *always* returning NO from `textField:shouldChangeCharactersInRange:replacementString:`. There's a workaround for the way UIKit behaves, which is only applicable for the Phone Number field right now. Also using `UIKeyboardTypeASCIICapableNumberPad` in `STPPaymentCardTextField` if available Per [WWDC 2016](http://asciiwwdc.com/2016/sessions/201), this was specifically added to support things like credit card entry: > We’ve also localized the keyboard number pads this year. [...] > Now in some cases, you might want to specify ASCII capable number pad instead when you’re sure that the input that you have needs to be restricted to ASCII digits. > Some examples of this are credit card numbers and IP addresses. I think this is redundant for the Credit Card Number field (just setting the `textContentType` is sufficient to use this keyboard), but it'll help w/the expiration and CVC. These text fields fall back to using .PhonePad, apparently to avoid localized & third party keyboards (#358), and as far as I can tell `.ASCIICapableNumberPad` continues to avoid them.
|
Unfortunately, in English on my 11.2 test device, this puts a space after the inserted content. This breaks our validation for email & zip codes (as well as having unwanted spaces in the other fields). I plan to submit a follow up PR that relaxes validation to allow those trailing spaces, and trims spaces from these fields. |
|
This PR currently relies on the changes from #867, and has that branch as a base. |
bg-stripe
approved these changes
Dec 19, 2017
| @@ -156,6 +175,9 @@ - (void)updateTextFieldsAndCaptions { | |||
| break; | |||
| case STPAddressFieldTypeCountry: | |||
| self.textField.keyboardType = UIKeyboardTypeDefault; | |||
| if (@available(iOS 10.0, *)) { | |||
| self.textField.textContentType = UITextContentTypeCountryName; | |||
There was a problem hiding this comment.
does this autofill the full name of the country? if so, i'm not sure if autofill will correctly update contents (which should be a country code).
There was a problem hiding this comment.
Hmm. It does not provide quicktype suggestions (when tested on 11.2 and 11.0.1), and I think that's due to our use of the UIPickerView (which handles updating contents, etc).
This does seem potentially dangerous, because that could change in the future. I don't think this is adding anything, so I'm leaning toward removing it.
There was a problem hiding this comment.
Ah yeah, +1 for removing it then.
Stripe/STPPaymentCardTextField.m
Outdated
| if (@available(iOS 10, *)) { | ||
| textField.keyboardType = UIKeyboardTypeASCIICapableNumberPad; | ||
| } else { | ||
| textField.keyboardType = UIKeyboardTypeNumberPad; |
There was a problem hiding this comment.
should this be PhonePad?
There was a problem hiding this comment.
Yes, it should be, thanks for catching that!
|
|
||
| 1. UITextContentType suggestions are only available when textField is empty | ||
| 2. When user taps a QuickType suggestion for the `textContentType`, UIKit *first* | ||
| calls this method with `range:{0, 0} replacementString:@" "` |
There was a problem hiding this comment.
interesting, nice comment!
danj-stripe
changed the base branch from
danj/bugfix/separate-payment-and-address-text-fields
to
master
…d/NumberPad regression
danj-stripe
added a commit
that referenced
this pull request
Dec 20, 2017
…ng the property. Fixes a user-interaction issue (knowingly) introduced by #870. When selecting email or zip code autocompletion suggestions, they fail validation. US zip codes would fail immediately, while email addresses waited until the field lost focus. This was an unpleasant UX experience. This is both a very concise fix, but also one I like. It keeps the contents of the text field unchanged, and does not interfere with editing in any way. Leading & trailing spaces are simply ignored while validating, and they are likewise ignored when considering what the logical contents of the cell/text field are. This results in the trimmed string being persisted to the server, and the trimmed string being passed around the payment context (like copying to the other address type)
danj-stripe
added a commit
that referenced
this pull request
Dec 20, 2017
…ng the property. (#872) Fixes a user-interaction issue (knowingly) introduced by #870. When selecting email or zip code autocompletion suggestions, they fail validation. US zip codes would fail immediately, while email addresses waited until the field lost focus. This was an unpleasant UX experience. This is both a very concise fix, but also one I like. It keeps the contents of the text field unchanged, and does not interfere with editing in any way. Leading & trailing spaces are simply ignored while validating, and they are likewise ignored when considering what the logical contents of the cell/text field are. This results in the trimmed string being persisted to the server, and the trimmed string being passed around the payment context (like copying to the other address type)
jaimepark-stripe
added a commit
that referenced
this pull request
Mar 16, 2022
Release version 21.13.0
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
This turns on QuickType suggestions for the name, email, and address fields. Also, using
a better keyboard for Payment Card fields.
For STPFormTextField, this was a lot harder than expected, due to always returning NO
from
textField:shouldChangeCharactersInRange:replacementString:. There's a workaroundfor the way UIKit behaves, which is only applicable for the Phone Number field right now.
Also using
UIKeyboardTypeASCIICapableNumberPadinSTPPaymentCardTextFieldif availablePer WWDC 2016, this was specifically added to
support things like credit card entry:
I think this is redundant for the Credit Card Number field (just setting the
textContentTypeis sufficient to use this keyboard), but it'll help w/the expirationand CVC.
These text fields fall back to using .PhonePad, apparently to avoid localized & third
party keyboards (#358), and as far as I can tell
.ASCIICapableNumberPadcontinues toavoid them.
Motivation
#836
Testing
Tested in the Standard Integration example app. Best tested on a device that knows an
address (simulator doesn't provide valid completions).
Both Shipping & Billing addresses are affected, and this also touches the Payment Card
text field.
Verified that enabling/using non-ASCII keyboards doesn't allow non-ASCII digits into
payment card fields.
Verified that 3rd party keyboards cannot be used for the credit card number entry.