Layout and the Windows Phone navigation bar (XAML)

  • Article

[This article is for Windows 8.x and Windows Phone 8.x developers writing Windows Runtime apps. If you’re developing for Windows 10, see the latest documentation]

What is a navigation bar?

The Windows Phone 8.1 chassis specification supports phones that do not have capacitive “steering” buttons (Back, Start and Search). Instead, the phone is capable of rendering a surface with "soft" steering buttons at the lower edge of the screen. This surface is called the navigation bar—or nav bar—and the user of the phone can control whether it is shown (by swiping up) or hidden (by tapping the chevron). For practical purposes, the height of the nav bar can be considered to be about 1/16 the height of the screen, and this topic explains how to adapt the layout of your app to a nav bar. An example of a nav bar is shown below.

Windows Phone Store apps

The way in which your Windows Phone Store app reacts to the nav bar being shown or hidden depends on the desired bounds mode set on the application view currently being shown. You can set the desired bounds mode on an application view by calling SetDesiredBoundsMode with a value of ApplicationViewBoundsMode.

If you set the desired bounds mode to UseVisible then your application view will resize—and layout will occur—whenever the nav bar (or the status bar, or the app bar) is shown or hidden. If instead you set the desired bounds mode to UseCoreWindow then your application view will not resize and it will not lay out. Instead the nav bar (or the status bar, or the app bar)—when shown—will overlay the view and will occlude part of it.

Whether you configure your application view to resize or not, whenever the nav bar (or the status bar, or the app bar) is shown or hidden, the VisibleBoundsChanged event will be raised and the value of VisibleBounds will contain the bounds of the non-occluded portion of the screen in view pixels. You can compare this value to Bounds, which is the full size of the application view in view pixels.

Full-screen apps

An app can set SuppressSystemOverlays to true at any time to declare that it wants the full screen. When it does this, the nav bar will hide (as will other overlays). In this state, if the user subsequently navigates to an app (or an application view in the same app) that has SuppressSystemOverlays set to false, then the nav bar will become visible once again. Or a game, for example, could set SuppressSystemOverlays to true while the game is playing, but when the game is paused, set it to false, and the nav bar will re-appear. And, SuppressSystemOverlays is set to true by default for all games (that is, all apps in the Store's Games category).

Note that SuppressSystemOverlays only has this effect on the nav bar if Settings > Navigation Bar > Auto Hide is set on the phone.

Apps that use Direct3D

The two types of app that won't resize and lay out when a nav bar is shown are Direct3D apps, and Windows Phone Silverlight 8 apps that host Direct3D content via DrawingSurfaceBackgroundGrid. In these cases, the nav bar will simply overlay (occlude) the content. It is important to note that for hybrid applications, the XAML touch targets may change position due to the nav bar, but the Direct3D content will not. Since that can create misaligned touch targets, test for it in your app.

Windows Phone Silverlight 8 and 8.1 apps

Windows Phone Silverlight 8 and 8.1 apps have a 16:9 aspect ratio. While physical resolution varies between phones, Windows Phone Silverlight apps all run in a resolution of 480x853 view pixels (when you set a dimension in markup, the values are in view pixels). For 16:9 screens up to 5", the size and layout of a Windows Phone Silverlight app is affected by the nav bar, since the nav bar needs to claim some screen real-estate. For screens larger than 5", there can be some letterboxing—which is a function of several factors—but this letterboxing is never sufficient for the nav bar to fully hide in the gap.

When the nav bar is visible the height of the screen reduces from 853 to 800 view pixels. The screen's layout is updated and, as a result, ActualHeight changes and SizeChanged is raised. While there is no specific property to query for the state of the nav bar, it typically can be easily inferred from the value of ActualHeight.

In order for screen layout to work properly here are some best practices:

  • Avoid hard-coding the size of large background elements, for example creating a 480x800 Rectangle. Doing this may prohibit the framework from resizing it.
  • Prefer Grid to Canvas. Grid has better characteristics for resizing, such as auto-sized rows and columns.
  • Test that your app works properly when ActualHeight changes. This can be simulated by showing and hiding an app bar, unless you app already uses one.
  • Vertical lists will work better with a nav bar than will large horizontal lists, where the bottom can be occluded. In general, prefer vertical scrolling to horizontal scrolling.

Windows Phone Silverlight 7.x and XNA 7.x apps

Windows Phone Silverlight 7.x apps and XNA 7.x apps are both required to be one specific resolution: WVGA (480x800 physical pixels). This resolution is a 15:9 aspect ratio. A 15:9 aspect ratio app—when displayed on a 16:9 screen—will typically result in letterboxing at the top of screen. But, on a nav bar phone, the letterboxing is moved to the bottom of the screen and the nav bar is shown in the gap. So, a Windows Phone Silverlight 7.x or XNA 7.x app, when running on a nav bar phone with a 16:9 screen, will be unaware of the nav bar (everything will be as if the app were running on a phone with capacitive "steering" buttons). But that same app running on a nav bar phone with a 15:9 screen will be aware of the presence of the nav bar and it will have a similar experience to the apps described in the preceding sections.