Right... Having just finished up the code to make it a little more cross platform friendly here's what I needed to do to make it work nice:
1) Make the assumption that the keyboard isn't shown when the application starts (which seems to be generally true) 2) Look for size change notifications (filtering out rotations and those caused by my application showing the keyboard) and then make the assumption that the keyboard has been hidden or shown based on before and after sizing Three other issues came up that are related to this - the first is probably a bug though based on what I've read 1) In portrait mode calling showSoftInput results in the system keyboard being shown and my view correctly resized. However in landscape mode this isn't the case and so I get no notifications about size changes in landscape mode that are caused by the keyboard state being changed. This seems to be a bug in 1.5 based on an earlier posting. Hence in landscape mode my app does not work correctly. I've tried the suggestion to set EditorInfo.IME_FLAG_NO_EXTRACT_UI but that had no effect. 2) Full screen mode is still extremely difficult (if not impossible) to support. In full screen mode you get no notifications about size changes caused by the keyboard being shown or hidden and so you can never tell whether the keboard is visible or not. My app should ideally run in fullscreen mode but can't due to there being no way to get keyboard notifications. Another issue related to (2) above is the lack of ability to query the size of the keyboard on screen. An API that would return the bounding rect or region of the keyboard would be helpful since in full screen mode you would at least know which parts of the screen are being obscured by the keyboard which would then help me position my widgets based on the keyboard size (this would be for fullscreen mode). All of this pain in developing my app could have been avoided if there were APIs like: 1) InputMethodManager.showSoftKeyboard (xxx,xxx,onkeyboardStateChangeCallback) --> where the callback is invoked when the hide / show state of the keyboard changes 2) InputMethodManger.isSoftKeyboardVisible() 3) getKeyboardBoundingRect(Rect boundingRect) This would allow my app to definitely know when the keyboard is hidden rather than needing to induce it through size change notifications. My argument is that if I am asking for the system keyboard to be shown then there should be a way of being told when it's later hidden. Thanks Lee On Sep 24, 12:06 pm, Chris Stratton <cs07...@gmail.com> wrote: > Or to put it real simply, how come we can easily toggle the showing of > the keyboard, but not query or set it? > > I do see the benefit in allowing flexibility for localization, etc, > via open-ended keyboard capabilities, but at the same time some > applications that "just barely fit" in the display really need to > optimize its utilization, and will break if the keyboard can take a > variable about of that. These may not end up being automatically > localizeable via the user's configuration, but that's the price of > working at the limit of the display resolution. > > On Sep 23, 8:39 pm, Lee <labor...@gmail.com> wrote: > > > > > 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 <hack...@android.com> wrote: > > > > On Tue, Sep 22, 2009 at 9:20 PM, Chris Stratton <cs07...@gmail.com> 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 > > > hack...@android.com > > > > 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
