Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-5817] Android: keyboard type set as number pad permits input of non-numeric values

GitHub Issuen/a
TypeBug
PriorityHigh
StatusClosed
ResolutionFixed
Resolution Date2015-11-24T21:22:04.000+0000
Affected Version/sRelease 1.7.4, Release 1.8.0, Release 5.0.2
Fix Version/sRelease 5.2.0
ComponentsAndroid
Labelsmodule_textfield, qe-manualtest, qe-testadded
ReporterIvan Skugor
AssigneeAshraf Abu
Created2011-10-20T01:18:34.000+0000
Updated2016-05-13T12:52:40.000+0000

Description

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).

Comments

  1. Ivan Skugor 2011-10-20

    I forgot to mention, 1.8 has same issue.
  2. Ashraf Abu 2015-11-12

    PR: https://github.com/appcelerator/titanium_mobile/pull/7429
  3. Collin Price 2015-11-12

    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?
  4. Ashraf Abu 2015-11-13

    [~CollinPrice] So would a better way be:- version 1)
       keyboardType: Ti.UI.KEYBOARD_CUSTOM,
       inputType: [Ti.UI.INPUT_TYPE_CLASS_NUMBER, Ti.UI.INPUT_TYPE_CLASS_TEXT]
       
    OR version 2) where inputType will override in Android
       keyboardType: Ti.UI.KEYBOARD_NUMBER_PAD,
       inputType: [Ti.UI.INPUT_TYPE_CLASS_NUMBER, Ti.UI.INPUT_TYPE_CLASS_TEXT]
       
    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?
  5. Collin Price 2015-11-13

    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.
  6. Lokesh Choudhary 2016-01-19

    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
  7. Fokke Zandbergen 2016-02-21

    [~msamah] Shouldn't this be implemented for TextArea and possibly stuff like SearchBar as well?
  8. Fokke Zandbergen 2016-02-21

    [~msamah] Shouldn't the property be inputTypes (plural) now you can (must?) assign an array?
  9. Fokke Zandbergen 2016-04-11

    [~msamah] [~cng] ?? ^
  10. Ashraf Abu 2016-04-12

    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?
  11. Fokke Zandbergen 2016-04-12

    [~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.
  12. Ivan Skugor 2016-05-13

    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.

JSON Source