I have a custom view for which I want the user to be able to enter characters from an app-defined set of characters. To do this, as I understand it, I need to write an input method service. The user not only needs to install it, but then needs to enable the IME in the Settings > Language & keyboard, and then select the custom IME for use in the view.
This seems really crazy. I want this IME to be used for just one view in one application. I don't want it to be available system-wide or force the user to make global setting changes.
The only alternative I can see is defining my own in-app custom view and simulate an IME (probably a full-screen one) when the view gains focus. Isn't there anything better?
I do not think the IMEs are conceived for that kind of task. Their concept is to allow user input in a standardized way so it can be used across multiple applications from different vendors.
My strategy would be similar to what you are thinking:
prevent the soft keyboard from appearing,
intercept the menu button key press to show your own instead,
add a custom layout (probably a GridView or a TableView inside a RelativeLayout with bottom gravity)
use an OnItemClickListener
send the required KeyEvents to the root View. If the characters are invented, the KeyCodes do not even need to relate to the ASCII character. You just intercept the code and use at will.
Sorry I can't give you an option as you asked, but this alternative does not seem to be much more work than creating a whole new IME.
Edit: upon reading the related question, it makes sense to use android.inputmethodservice.KeyboardView instead of reinventing the wheel with the GridView.
Related
In my Android app I have a custom layout that is being used as a button - it consists of some TextViews and an ImageView, additionally it has some gradient background.
I'm aligning my app now to conform to the Accessibility rules. In order to do so, I would need to convert this layout into a button, so that TalkBack can correctly indicate the action, that this whole layout is clickable and serves like a button.
I know that on iOS there is a possibility to set the UIAccessibilityTraits to treat such view as a button - this kind of solution would save me a huge amount of work in terms of migration.
Is there any similar solution on Android for that? What approach should I follow in order to make this layout recognized correctly by TalkBack?
No, there's no concept of accessibility traits on Android - but you can still get a good accessibility experience without needing to specifically convert your layout into a Button.
Generally, it's most important that TalkBack (or whatever accessibility service is being used - remember, it's not just TalkBack) is able to detect that the widget is clickable and to be able to read a coherent description of what it does. The additional information that it's a button, specifically, isn't super useful, especially because there are so many different kinds of UI elements that it's often a very ambiguous question whether something even is a button.
You can test this by selecting it in TalkBack and confirming that it reads the content description properly, says something along the lines of "Double tap to activate," and performs the correct action when you double tap.
If it's not correct, make sure the content description, clickable flag, and click action are set correctly on the widget's AccessibilityNodeInfo.
I want to create a custom keyboard which will be available in my application only (It's used jut for a single EditText in one activity), and I was wondering what would be the best way to do so. Here are my specifications for the keyboard:
It should always be displayed in the activity it is used (Regardless whether the EditText is focused or not).
It will have 2 or more keys layouts (Similar to the regular keyboard which has letters layout and a few numbers/symbols layouts).
Some keys may require some special action (Rather than simply adding their android:codes key value to the EditText).
It doesn't offer candidates for completion/correction.
It doesn't offer more than one input type (Like the regular keyboard which has TYPE_CLASS_NUMBER, TYPE_CLASS_DATETIME and so on...).
How should I develop it? Should I create a full input method service for it? Or should I create just a KeyboardView and add it to the activity's layout? (I want to use KeyboardView for the convenience of keys creation and click events handling)
Since it's a one-off thing and not meant as a separate app, You can simply use whatever method is easiest for you (The KeyboardView method).
Try it out and make sure it's responsive and snappy. If it works, then simple and easy method would be my recommendation.
Maybe you could take a look at this. I think the best way is to make a custom layout and inflate it. Theres a tutorial given here too.
I'm writing an app using Titanium. I want to be able to automatically dismiss the keyboard anytime something outside of the text field is clicked. I have yet to find an elegant solution for this issue.
Couple things that I've thought about, but am still looking for a better solution:
Assign event listeners to basically everything else present in the view, and dismiss the keyboard (using textField.blur()). I want to avoid this since it results in a LOT of code just to dismiss the keyboard. Also, if I end up adding anything else to the view, I'll have to add a click listener to that object as well, so it's not very maintainable.
Create a large transparent view, and have it take up the entire screen. Place it directly beneath the text field and add to it one click listener on that which will dismiss the keyboard. This is a better solution than #1, but still isn't great because I've had a lot of trouble getting zIndexes to work properly. It's also inefficient for my purposes because I've got views with a specific width and height that encapsulate text fields. I've used these for the sake of code simplicity and I re-use them throughout my application.
I've tried adding a listener for the "blur" event for the text field but that doesn't seem to get fired appropriately.
That's about it. I'm sort of at a loss. The zIndexing also behaves strangely on the iPhone, and I haven't tried on Android yet. Also, as I mentioned above, many of the text fields I use are encapsulated within small views with set widths/heights-- so I think that will affect the functionality of Z-indexes.
So the root question is: What's the best way to dismiss a keyboard whenever anything outside the text field that's in focus is clicked?
If I'm correct the click event propagates through all views and windows therefore your #1 option could be modified to check for clicks on the bottom most layer (view or window), check for its source then decide what to do.
First of all, I am aware of about 1000 other questions regarding the android keyboard... I am aware I can manually hide keyboard from window or control, and pass in any number of flags that are supposed to control where and when keyboard pops up.
Basically, I aim to have PREDICTABLE keyboard handling in my app... that is that unless explicitly told to focus this control, and popup keyboard, it'll only pop up when a user taps a text edit.
This app is extensive, and manually attempting to hide keyboard from even just the focused control (vs explicitly hiding each and every edit field).
I am also aware I can avoid the popup up keyboard when you dont want it there, by setting focus on a non text editable field, however, that seems like more of a hack than anything else.
So my question is... is there a way to just force app to never auto pop up keyboard on new dialogs, fragments etc... app wide? If I want this text field to et focus on new dialog, I'll manually handle those cases. In addition, any way to automatically handle keyboard dissapear when the previously focused control dissapears?
I just dont get logic there... if I step back and think about this, I'd only want keyboard popping up if I wanted to go type something. As far as keyboard popping up immediately when new dialog opens... seems like the exceptional case (there may be a couple times I'd want to do that).
I dont mind building a manager or something that keeps track of the state of keyboard, however i dont know if I can get at the information I'd need to make it work in a remotely intuitive manner, efficiently.
Any pointers or ideas would be greatly appreciated... because I am at my whits end with this... and I can assure you I've spent a good deal of time researching this and attempting fixes.
Note: Sorry about the title or hostility... I've fought this for quite some time, and been generally infuriated with how bizarre dealing with the keyboard can be.
So my question is... is there a way to just force app to never auto pop up keyboard on new dialogs, fragments etc... app wide?
No.
But you can use:
this.getWindow().setSoftInputMode(WindowManager.LayoutParams.SOFT_INPUT_STATE_ALWAYS_HIDDEN);
On each activity.
Ok, I think I get what you're asking. Have a look at the second answer here:
Stop EditText from gaining focus at Activity startup
You can specify in your AndroidManifest.xml whether or not the softkeyboard should be hidden by adding this android:windowSoftInputMode="stateHidden" to the beginning of your activities tag (<activity>)
I need to bring up a few different keyboards: a 'standard' keyboard with Ctrl and Alt keys; maybe a cursor pad; and so on.
I have found the Keyboard class, which would let me define a keyboard in an XML resource. I have found that the KeyboardView class has a setKeyboard method ... and, so far, I have not found any other class that takes a Keyboard instance.
How am I supposed to use the KeyboardView? I tried adding one to my activity's XML; finding it at runtime with findViewById; and then calling setKeyboard ... but all this did was mess up my layout and not bring up the special keyboard.
This turns out to be very doable, and my initial problems probably had more to do with general Android newbiness (this is my first Android app) and not the KeyboardView. In particular, I'm used to visibility being a simple binary property.
Anyhow:
Declare the KeyboardView in your XML file with android:visibility="gone".
Before you make the view visible, call setKeyboard() to attach a keyboard. This is important, as the KeyboardView gets its size from the keyboard.
To get raw key events, call KeyboardView.setOnKeyboardActionListener(). After refactoring this functionality from a Dialog back to my main View, I put the OnKeyboardActionListener functionality in a stand-alone class, but this is not necessary.
I call keyboardView.setEnabled(true);. This does not seem to be necessary, but I am not sure (yet) under what circumstances it would matter; perhaps only if you call setEnabled(false).
I call keyboardView.setPreviewEnabled(true); - this is especially useful if the user won't be getting visual feedback from an input biox right above the keyboard.
Then, with the keyboard all set, call keyboardView.setVisibility(VISIBLE);.
To hide the keyboard when appropriate, just call keyboardView.setVisibility(GONE);. To change the keyboard (as on a shift key, or a cycle-through-the-symbol-keyboards key, just call setKeyboard again. I use a Map<<Integer, Keyboard> to implement a lazy-create pattern; a weak reference may be desirable, if the program will run for a long time and the keyboard will not be used much.
Keyboard and KeyboardView are for making alternative input method engines (IME). These are then able to be chosen by the user, just as they can install Swype, Graffiti, and other ones from the Android Market.
You, as a developer, can create such an IME, but you cannot force it upon the user.
using the inputType attribute in your editText view will help pick between the different system keyboards (phone, email, etc) Also the APIDemos application that comes with the SDK has an example of how to implement a forced custom keyboard for your app only.