3

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?

Ted Hopp
  • 232,168
  • 48
  • 399
  • 521
  • 1
    BTW, I found a very similar question just now: http://stackoverflow.com/questions/1896939/android-app-specific-soft-keyboard . Same answer. – Aleadam May 04 '11 at 22:05
  • Is the answer still the same after 3 years? – Petr Peller May 15 '14 at 12:31
  • @PetrPeller - As far as I know, it still is. I've seen nothing in the release notes or developer blog since then to suggest otherwise. (I may have missed it, of course, in which case I'd be very grateful if someone provided info to the contrary.) – Ted Hopp May 15 '14 at 15:47

1 Answers1

2

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.

Aleadam
  • 40,203
  • 9
  • 86
  • 108
  • There would actually be a lot more to do if I wanted to reproduce all the behavior of an IME. Off the top of my head: panning the app to make room for the keyboard without obscuring the target view; providing for full screen mode; handling configuration changes. – Ted Hopp May 04 '11 at 22:24
  • 1
    @Ted I don't know what is your app doing but if it's a very specific use instead of a multi-purpose keyboard, then you can work around some limitations (i.e., you don't need to scroll the view to keep showing the EditText widget, you can add one to your keyboard and transfer then the whole text). You need to implement only what your app needs. – Aleadam May 05 '11 at 01:19
  • 3
    that sounds reasonable. It's probably what I'll end up doing, including using a KeyboardView like you suggested. It seems rather strange that the Android folks developed this great infrastructure but then made it available only on a global basis. It makes me think of how fonts used to be handled in Java: install them on your machine and then Java can use them. That finally was augmented with an ability to use an application-specific font without having to install it system-wide. I'm (sadly) marking your answer as a solution, even though it was just a nice, "No". – Ted Hopp May 05 '11 at 01:33