Problem
New minor version of Titanium SDK has a new look of numeric keyboard.
The problem is that it allows input of non-numeric values.
Test case
How to reproduce the issue:
run this example with 1.7.4 version of Titanium SDK, click on text field and type "*" or "#" symbol. You'll see that they are present in text field, while they shouldn't be present.
Compile and run same example with 1.7.3 SDK version and try to do same thing. You'll see that you can't input "*" or "#" symbols (or any other that is not a number).
var win = Ti.UI.createWindow({
modal: true,
backgroundColor: '#000'
});
var textField = Ti.UI.createTextField({
width: 200,
keyboardType: Ti.UI.KEYBOARD_NUMBER_PAD
});
win.add(textField);
win.open();
Also, it would be nice if there was key in this new keyboard that would minimize keyboard (if that is possible).
I forgot to mention, 1.8 has same issue.
PR: https://github.com/appcelerator/titanium_mobile/pull/7429
This PR seems like an odd way of fixing what is clearly a bug. The documentation for KEYBOARD_NUMBER_PAD says: "Use a keyboard with a number pad only". While I like the idea of being able to customize the inputType on Android, shouldn't there be another keyboard type added such as KEYBOARD_CUSTOM where a user can then choose a custom inputType?
[~CollinPrice] So would a better way be:- version 1)
OR version 2) where inputType will override in Android
I think version 2 might be better to allow for iOS to continue using the correct keyboardType. If version 1 were to be implemented, iOS needs to be updated with CUSTOM type which might not be relevant to it. What do you think?
Ultimately Ti.UI.KEYBOARD_NUMBER_PAD should work the same on both platforms without having to add an inputType for Android. I think inputType should be an Android only field and Ti.UI.KEYBOARD_CUSTOM be an Android only type.
Verified the fix. Verified the property input type with Ti.UI.INPUT_TYPE_CLASS_NUMBER & Ti.UI.INPUT_TYPE_CLASS_TEXT. Closing. Environment: Appc Studio : 4.5.0.201601131150 Ti SDK : 5.2.0.v20160114021251 Ti CLI : 5.0.5 Alloy : 1.7.26 MAC Yosemite : 10.10.5 Appc NPM : 4.2.2 Appc CLI : 5.1.0 Node: v0.12.27 One Plus One: Android 5.1.1 GenyMotion Emulator : Android 6.0
[~msamah] Shouldn't this be implemented for TextArea and possibly stuff like SearchBar as well?
[~msamah] Shouldn't the property be
inputTypes
(plural) now you can (must?) assign an array?[~msamah] [~cng] ?? ^
With regards to TextArea and SearchBar, it could possibly be implemented. If required, please create a ticket for that. And for the property to be called
inputTypes
, would it be better?[~msamah] I was asking about TextArea and other user text inputs in the light of parity between different APIs. As for
inputTypes
; since it accepts multiple I'd think plural would make sense yes.Thanks for fixing this after 5 years :P :D But solution is really messy. First of all, the solution should have been implement for all input fields that have "keyboardType" property, TextField was just used as example. Secondly, adding new property is not bug fix, it's new feature. We should have the same behaviour on both platforms! So, if you want to really fix this, implement it on all input fields, set by default Ti.UI.INPUT_TYPE_CLASS_NUMBER when Ti.UI.KEYBOARD_NUMBER_PAD is used and leave "inputType(s)" as new feature in case someone wants to have it. Thanks.