On Windows Mobile 5 (and I assume the same is true of 6 and 7), the small bar at the bottom which shows the current meaning of the two smart buttons is not a separate chunk of real estate taken away from the rest of the application; instead it is a floating HWND object. It is up to your application to know if that HWND object is present, and to make sure you don’t obscure the HWND.

On the iPhone with the v2.2 and v3.0 OS, the slide-up keyboard is essentially a floating window which overlays your UI. It is your responsibility to know if the keyboard is present, and if so, resize the contents of your view accordingly. That means if you have a table view with an edit text field that is graphically in the area where the keyboard will appear, you have to figure out a way to move the table contents up and down as the keyboard appears and disappears.

I contend that the region of the screen devoted to the keyboard or custom keypad or the like should not be handled as pop-up windows overlaying your user interface. Instead they should be handled as events that resize the main “window” of your user interface. And instead of hooking a half-dozen different events that could change the form factor of the screen, all of these events should be handled exactly the same way they’re handled on a desktop application: with a resize event sent to the “window”, which then percolates down the view chain.

Unfortunately it appears no-one agrees with me. And so we’re stuck doing all sorts of complicated stuff–including Android, which tears down and rebuilds the “Activity” (the thing which manages the views in a UI) rather than simply send a resize event.