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 -~----------~----~----~----~------~----~------~--~---
