I think that putting the flexibility onto keyboard developers takes actually imposes a burden on the application developers. I would say that the number of people developing applications for Android are going to far outnumber the number of people who are developing keyboards and IMEs. Furthermore because of the number of different devices out there and the fact that each device may implement its own standard keyboard there should be more information provided about the keyboard than there currently is.
I'm going to layout my problems and explain what information I really need to be able to get my application to work properly. 1) Startup state When my application starts I've got no way of seeing whether the software keyboard is currently being shown or not. My application has an activity screen containing an edit text that when touched will show the keyboard. It then can create a second activity by tapping on a ListView which will start the new activity with the keyboard showing (or not if I didn't first tap in the EditView). Based on your feedback above the only way to determine whether the keyboard is showing is to *induce* this based on the size of my View which hardly seems like a safe bet considering that there are other elements to consider including the title bar. A simple API that would allow me to query the soft keyboard state would be welcome. Given that it'd be the system keyboard being shown when the application starts why is this difficult? 2) Keyboard hide notification To determine whether the keyboard has been hidden / shown I need to respond to the onSizeChanged callback and again deduce that something changed on screen which is *probably* the keyboard being hidden but looking for it in the onSizeChanged doesn't feel right. My application shows the keyboard itself so if there's a standard API to show the keyboard why can't you subscribe to a notification for when that keyboard (that my application asked to be shown) is then hidden? A simple callback that would only work for the case where the keyboard is shown based on a call to showSoftInputMethod would make things so much neater. Solving these two problems in an elegant way would make developing this application a lot simpler and I'd feel a lot more sure about whether this application is going to work on devices other than the emulator and a G1. I've already tested my code on the Magic and it doesn't work. Just inducing things is a pretty non-reliable way to get things done - what is so hard about putting an API in that at least works for the standard system keyboard (which is what is going to be used in 99% of the cases). I again want to make the point that enabling keyboard developers while restricting application developers seems like an inverted way of looking at things when it's going to be the application that makes the phone (and the OS) a success not the keyboard. Thanks Lee On Sep 23, 4:19 pm, Dianne Hackborn <[email protected]> wrote: > On Tue, Sep 22, 2009 at 9:20 PM, Chris Stratton <[email protected]> wrote: > > Expecting applications to be arbitrarily resizable strikes me as > > seriously unworkable in the general case, especially as you include > > the ime taking over the full screen in your list of possibilities. > > In full screen mode the IME completely covers the application and the > application underneath does not resize. > > > This really only works for apps where the necessary context can be > > limited to a single text entry field. > > Or the contacts edit screen, MMS compose screen, GMail compose screen, > contacts list, search box with auto-complete text view (which also uses > standard APIs to move the list of completions above and below the IME as the > user interacts with it), the web browser on any web page that takes input, > etc. And of course if need be you can leave your window not resizeable and > keep that behavior, as is done in the launcher, all kinds of dialogs that > take input, etc. > > > If that's really the strategy I suspect developers will often end up > > having to do their own size-appropriate on screen keyboards and try to > > keep the ime inactive... > > Well that's up to them. The only place we do this in any of the UI of any > of the applications, both included with the platform and ones done by > Google, is for dialers. > > I think there is a basic difference in perspective here: if you want to look > at the keyboard as a tightly integrated part of your application, that is > not how Android IME's work. If you want to let the user use whatever IME > they like to provide input to your app, that is how they are intended to > work. We deliberately went the route of having an open, pluggable input > method architecture at the expense of being able to do some kinds of deeper > integration. Personally I find this really exciting, because there has > rarely been opportunity for people who design and implement these kinds of > input systems to have such an open and easy environment to play in and > actually have their designs used (and maybe even make money selling them > directly to end users). > > If that's not for you... well, we have the standard keyboard as a separate > view that you can stick in your application and customize to your hearts' > content. Some users may not be happy that your app is consistent in input > with other apps, but if you think it improves your UI, go for it. I do > realize that there isn't as much support for this as using the normal IME > (you'll need to take care of hooking up with the text editor and stuff), but > you can probably copy a lot of the framework code out of InputMethodService > to use for your own app. > > -- > Dianne Hackborn > Android framework engineer > [email protected] > > Note: please don't send private questions to me, as I don't have time to > provide private support, and so won't reply to such e-mails. All such > questions should be posted on public forums, where I and others can see and > answer them. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
