Develop Reference

Numeric keyboard as default, but allow text

I'm currently developing an application targeted at android and desktop devices using apache cordova and HTML5.
In order to get the numeric keyboard to pop up I've used input type="number", which works fine.
However, the input field should also accept strings. The current functionality of type=number is that the ui seems to allow for strings to be entered, but the value property of the element is not changed if the input is invalid (e.g not numberic).
Is there a way of getting the numberic keyboard on mobile devices, while still being able to enter text?
My inital tries consisted of capturing the keydown event and manually setting the this.value property. I've tried this using jQuerys .val() and of course the more 'native' approach element.val += char. None of which work. UI is updated, but the change is not reflected in the model.
EDIT
For the next guy trying to achieve this.
1) The HTML solution.
As #LuudJacobs mentions in the comments below; There's currently no way to decide which keyboard is shown except for defining the type-attribute. Though some devices have a button to go back to alphabet keyboard, its not the case for every device. And can not be used reliably.
2) Writing a phonegap/cordova plugin.
It is possible to write a plugin to show and hide the keyboard at will. But, as far as I could find, there is currently no way of programmatically telling it to default to the symbols keyboard. Thus the functionality achieved is similar to using type=number and type=text in the HTML. Another problem with this approach is the diversity of keyboard for android devices, where even users themselves can install their custom keyboard. The functionality of the keyboard can are therefore unknown. What works on one device, may not work on the next.
3) JS/HTML/Canvas solution
Finally... A feasible solution. I suggest taking a look at this walkthrough as it shows an easy way to creating the keyboard using just html and js. Another option would be to use a canvas, and draw the keyboard yourself, but I would imagine that this is more error prone and harder to do.

As explained in the HTML5 spec you can not have anything but valid floats in a input type="number". So You can not. On a sidenote: how would users enter text when they'd only have a numeric keyboard?

What options are available for handling text input on Android using Adobe AIR?

What options are available for handling text input on Android using Adobe AIR? What are the advantages and drawbacks to each option?

The current options available to AIR developers on Android for handling text input are:
StageText native text (default)
TextInputSkin (spark.skins.mobile)
TextInputSkin (spark.skins.spark)
StageText + TextInputSkin (spark.skins.mobile) hybrid
StageWebView (explained below)
Native view
I'll discuss some of the advantages and drawbacks of each approach below. If I've missed anything (or if you have other ideas that I haven't thought about) please let me know!
StageText
Handles input properly in all cases? Yes
Displays properly in all cases? No
Vertical alignment problems when scrolling.
By default, TextInputs running on mobile devices make use of StageText (native text) for input. StageText offers several advantages, as Adobe outlines in their online documentation, including auto-correct, customization of software keyboards, etc.
The biggest disadvantage to using StageText is described in bugbase ticket 3302441. StageText's positioning becomes broken when a user scrolls. Textfields appear outside of their respective TextInputs or, even worse, inside of other TextInputs. The only work-around for this defect is to design a UI that does not allow scrolling. Obviously this can be very difficult for mobile phones and phablets.
TextInputSkin (spark.skins.mobile)
Handles input properly in all cases? Yes
Displays properly in all cases? No
Inserts random characters on certain Android versions (ex. Nook running Android 2.3).
This component uses StyleableTextField internally. It is optimized for mobile use.
This component inserts additional, arbitrary characters into the TextInput as a user is typing on certain Android versions (ex. Nook running Android 2.3, Kindle HD running Android 4.0). See bugbase ticket 3547601.
If your application is only localized into English (or latin-based languages) and does not need to support older Android versions then this component may work well for you.
TextInputSkin (spark.skins.spark)
Handles input properly in all cases? No
Does not accept certain double-byte characters (ex. Korean).
Does not accept any input on certain devices (ex. Samsung Galaxy 10.1 running Android 4.0).
Displays properly in all cases? Yes
This component uses RichEditableText internally. It is not optimized for mobile use. Beyond that it demonstrates several defects (listed above) that make it unsuitable for use.
This component does not properly handle certain double-byte characters (in languages such as Korean). These characters seem to be inserted into the TextInput (the cursor progresses, visibly) but no text is rendered to the user. (It is possible that this issue could be resolved using an embedded font.) See bugbase ticket 3547591.
While testing the 3rd item mentioned above (input not being accepted on certain devices) an interesting thing was observed. After typing a couple of characters, if a user switches focus to a TextInput that uses the default StageText, at least some of the missing characters will be automatically inserted into the new field.
StageText + TextInputSkin (spark.skins.mobile) hybrid
Handles input properly in all cases? Yes
Displays properly in all cases? No
Sometimes the software keyboard's "show" animation is triggered twice in a row, creating an undesirable visual effect.
Sometimes focus handling is difficult and can result in the StageText-TextInput showing without a software keyboard until the learner touches it again.
This approach combines the benefits of StageText with the scrolling functionality of TextInputSkin (spark.skins.mobile). The general idea is to create 1 TextInput that uses StageText and assign it to a fixed location on the screen. This TextInput should be hidden by default. Other TextInputs (using TextInputSkin) can be created and positioned as needed on the stage. When one of these TextInputs gains focus, the hidden surrogate TextInput should be shown and focus should be shifted to it. As text is entered into the surrogate, a change-handler should copy the text to the user-selected TextInput. When the user tabs or clicks to set focus elsewhere the surrogate TextInput should be hidden again.
I can provide a code example of this if desired. There are a couple of drawbacks to this approach (mentioned above) but it's possible that they are the fault of my implementation.
StageWebView
Handles input properly in all cases?
Yes/No
Depending on the value of <renderMode> and <fullscreen> this component may work properly for you.
Is a little tricky to get working.
Displays properly in all cases? Yes
This approach involves displaying a simple HTML page inside of your AIR application using StageWebView. The HTML page contains <input type="text"> objects which make use of Android's native text and software keyboard. Communicating between the HTML page and the parent AIR app though is a bit tricky, since StageWebView does not support Flash-to-JavaScript communication in the same was as ExternalInterface.
Communicating from JavaScript to Flash
Communicating from JavaScript (or HTML) to ActionScript is difficult because StageWebView does not allow ActionScript to add callbacks. StageWebViewBridge offers this functionality has not been updated in some time and when I tried it, I was unable to get content to display using Flex 4.6 and AIR 3.5.
There are still ways to convey information to ActionScript using LocationChangeEvent. The idea behind this is for the AIR app to listen to location changing events and then parse the incoming event.location for information. For simple links this works easily but things get more complicated when it comes to forms. I tried the following approaches before settling on one:
Add an onclick handler to the form-submit button that sets window.location.href to a string containing URL-encoded key/value pairs. This approach does not work for reasons described in bugbase ticket 3362483.
Add an onclick handler to the form-submit button that dynamically modifies the form-target to contain URL-encoded key/value pairs and then submits the form. This approach does not work because LocationChangeEvents are not dispatched when form.submit() is called.
Add onchange handlers to <input type="text"> tags and modify the href attribute of a "submit" link to contain URL-encoded key/value pairs. When this link is clicked, your ActionScript LocationChangeEvent handler will be invoked and you can parse the incoming data using the URLVariables class.
Communicating from Flash to JavaScript
To communicate with JavaScript (call methods, pass parameters) use the StageWebView's loadURL method like this:
_stageWebView.loadURL( 'javascript:yourMethodName( "A string", true )' );
Unfortunately the loadURL method has a void return type (meaning that you can't retrieve data this way).
Other difficulties
The biggest drawback to this approach is described in bugbase ticket 3535948. If your AIR application uses <renderMode>direct</renderMode> or <fullscreen>true</fullscreen> then text input via StageWebView will be unusable. (Response will be sluggish. Users will be unable to select or delete characters.) If your app does not require either of those flags then this route may work well for you.
One workaround for the fullscreen limitation is to disable fullscreen mode only when your application needs to make use of a StageWebView. This can be done with StageDisplayState like this:
// Turn off fullscreen
stage.displayState = StageDisplayState.NORMAL;
// Turn on fullscreen
stage.displayState = StageDisplayState.FULL_SCREEN_INTERACTIVE;
Native View
Handles input properly in all cases? Yes
Displays properly in all cases? Yes
The last remaining option (that I'm aware of) is to write a native extension that displays text-inputs and returns data to your AIR application. This is probably the safest (although most disappointing) option of the ones discussed in this thread.

We might have a solution that works atleast for our scenarios : http://blog.flexicious.com/post/Scrolling-Issues-With-TextInput-for-Flex-Air-Mobile-Native-StageText.aspx

Create a custom InputType

Is it possible to create a custom InputType for the Android keyboard to use?
I want to make it so the keyboard shows the number pad first and then after a user types in a float or an integer followed by a space I want it to switch to the default alpha keyboard.
I tried using a TextWatcher instance, but this seems buggy on anything above 2.0 (sometimes it would lose a character, this doesn't happen on 1.6 or below).
Any ideas?
Thanks for reading.

Yes, it is possible.
I haven't done it myself, but the evidence is in apps that serve as input types. Look up apps such as Swype and 8pen; they serve as different input types, with Swype building on a keyboard similar to the default and 8pen providing a different input UI altogether.

Global keyboard input listener on Android

I was wondering if it is possible to intercept keyboard input on a global level on Android. For example a user types in text into an edittext (does not matter which application) I would like to access said text to check for certain words. Is this even possible with Android's security model (yes I am aware this kind of feature could be used for various wrong things too).
Thanks,
b3n

Not possible. Thst's a security hole. You're welcome to modify the android firmware though

Custom 'Keyboard' built in an application on Android

I've been looking to create a custom keyboard for my application. At first, I started to look at the SoftKeyboard for the SDK examples, but reading the Android Developer Group led me to this post:
This is really not how the input
method framework is supposed to work.
An IME should be a generic input
facility, not for a particular
application. If you need some
app-specific input, you should build
it into your UI rather than pushing
it out to a generic IME.
How do I build an app-specific input within the UI? I mean, is there a way to extend the Keyboard app or something and use it only in my application?
Features needed for the keyboard:
Shift key to display some other keys
Special keys like square root or PI
etc.
PS: an ugly solution could be to make a table of ImageButton for example, but I wanted to make something clean.

I'm not really sure if there's a straight-forward solution to this (to that extent that it is even possible to understand the real reason behind the original question).
As is quoted in the original question:
If you need some app-specific input, you should build it into your UI
rather than pushing it out to a generic IME.
What is meant by that, is not that you within your app should try to build in such input features by extending or modifying the soft keyboard on the phone. There are so many different soft keyboards (and basically, the soft keyboard is just another app), since most phone manufacturers create their own version, and people download 3rd party keyboards (such as Swype or SwiftKey etc.), and I can't picture there being a way for you to "hack" into those to add a few buttons or whatever it is you want (which could also be a major security hole, another reason why it probably isn't possible).
What instead the above quote suggests, is that you have to create some other form of input besides the keyboard. One such example, and a very good one if I might add, is how the RealCalc Scientific Calculator looks:
Now this isn't open source, so I can only guess how the code looks like (but it shouldn't be too hard a guess either): in its simplest form, this is just a grid with lots of buttons. Each button handles the onClick event, which would mean performing some kind of action (changing the label on some other buttons, showing a menu, displaying some text in the upper label or whatever), and that's probably pretty much what's to it. And of course, the phone's soft keyboard is never displayed (since you don't need a keyboard with all those buttons (and also there aren't any input fields to write anything in)).
It all boils down to the already mentioned quote: If you need some app-specific input, you should build it into your UI. Or in other words: create buttons (and don't display the soft keyboard if you don't need it) and make things happen when you click them.
And just to have mentioned it: if you do want to create your own IME (which I strongly believe is not the case here), you should have a look at the following resources:
Onscreen Input Methods
Creating an Input Method
Soft Keyboard sample

In my humble opinion you should take a look at the beginning of reference about keyboard and keyboard view http://developer.android.com/reference/android/inputmethodservice/Keyboard.html and http://developer.android.com/reference/android/inputmethodservice/KeyboardView.html.
There you can see an example of defining keyboard using XML file. I think that this is what you are looking for.

As mentioned by #sebap123
Keyboard and KeyboardView class are the one you need to use,
Further, for Implementation, here is a quick detailed guide.