The Microsoft Lumia 640 and 640XL were one of the first Windows Phone devices to take advantage of the move to on-screen hardware buttons. Rather than the traditional hardware buttons for Back, Start and Search, these devices have software rendered buttons (note that there were previous devices that had the buttons as part of the same glass as the reset of the screen but this isn’t the same as having them rendered in software). There were some that didn’t like this move (eg http://www.7tutorials.com/reviewing-microsoft-lumia-640-xl-good-smartphone-business-users) but an nice effect of them being software is that they can be dismissed off the screen. This means that the buttons can be swiped away, leaving more screen available for applications.
The unfortunately thing about this is that because this feature shipped as an update to Windows Phone 8.1 there isn’t good support for detecting when the available screen size changes, often leaving applications either with controls rendered under the buttons, or with empty screen space under the content of the application (where the buttons used to reside).
Side note: Rudy Huyn in his post, “How to test my app on phone with navigation bar and why it matters,” covers how to use the Windows Phone emulator to test applications for this behaviour.
I spent a bit of time this afternoon trying to work out a workable solution to this. The result was a bit hit and miss but the following seems to work:
In order to take advantage of the full screen I added the following lines to the end of the OnLaunched method in the App.xaml.cs file:
var applicationView = Windows.UI.ViewManagement.ApplicationView.GetForCurrentView();
applicationView.SetDesiredBoundsMode(Windows.UI.ViewManagement.ApplicationViewBoundsMode.UseCoreWindow);
The UX of the screen is very basic – it has a background color so that you can see where the page is being rendered and a textbox at the bottom of the screen so that you can see whether an element has been hidden. Note also that the VerticalAlignment of the page is set to Top. This might seem weird but if you don’t, as you adjust the Height of the page in accordance with the visible bounds, you’ll see the page rendered in the middle of the screen, which is not what you want.
<Page x_Class=”AppBarTest.MainPage”
“>“
“>“
VerticalAlignment=”Top”>
<Page.BottomAppBar>
<CommandBar>
<AppBarButton Icon=”Accept”
Label=”appbarbutton” />
<AppBarButton Icon=”Cancel”
Label=”appbarbutton” />
</CommandBar>
</Page.BottomAppBar><Grid Background=”LightBlue”>
<TextBox Text=”Testing”
VerticalAlignment=”Bottom”
Margin=”0″ />
</Grid>
</Page>
The code for this page is where all the hacking happens – essentially it looks to determine how tall the page should be based on the space occluded by the status bar and the input pane. The trick is to make sure this is called anytime something adjusts the visible bounds available to the app.
public sealed partial class MainPage
{
public MainPage()
{
InitializeComponent();
var appView = ApplicationView.GetForCurrentView();
appView.VisibleBoundsChanged += VisibleBoundsChanged;
}private void VisibleBoundsChanged(ApplicationView sender, object args)
{
ResizeMe();
}private void ResizeMe()
{
var statusBar = StatusBar.GetForCurrentView();var appView = ApplicationView.GetForCurrentView();
var input = InputPane.GetForCurrentView();
var newHeight = appView.VisibleBounds.Height + (statusBar?.OccludedRect.Height) ??
0 + (input?.OccludedRect.Height) ?? 0;
if ((input?.OccludedRect.Height ?? 0) <= 0 || newHeight < this.Height)
{
this.Height = newHeight;
}
}
Update: You should also attach an event handler to the Got and Lost focus on the TextBox and invoke ResizeMe otherwise there are some scenarios where the TextBox ends up under the virtual buttons