How to hide the StatusBar in Landscape on UWP

Windows 10 Mobile has lost a lot of the awesome UI/UX from the good ol’ Windows Phone 7 era, but there’s one thing that they kept around: the enormous amount of space the statusbar takes up in landscape view. I still love the look and feel of the old Windows Phone, but this thing has been bugging me since, well, my first smartphone.

The StatusBar on WP7 (screenshots were impossible, back then)

In my apps, I prefer to hide the statusbar when the user goes into landscape mode, but just let it stay where it is when in portrait mode. It includes some useful information, after all, and in portrait the amount of used space is acceptable. Here’s my solution:


tl;dr:

1
2
3
4
5
6
7
8
9
10
11
if (ApiInformation.IsTypePresent("Windows.UI.ViewManagement.StatusBar"))
{
Window.Current.SizeChanged += async (sender, e) =>
{
var statusBar = StatusBar.GetForCurrentView();
if (ApplicationView.GetForCurrentView().Orientation == ApplicationViewOrientation.Landscape)
await statusBar.HideAsync();
else
await statusBar.ShowAsync();
};
}


To get access to the statusbar, we first need to reference the Mobile Extensions, as Mobile’s the only SKU of Windows 10 where the statusbar is available. This can be done using the ‘Add reference’ dialog, which can be found by right-clicking ‘References’ in the Solution Explorer in Visual Studio. After navigating to Universal Windows - Extensions in the left menu, make sure you check the checkbox before the version of the Mobile Extensions you’re targeting:

The 'Add reference' dialog

Now we can get access to the statusbar, how do we do that? The StatusBar class has a static method called GetForCurrentView() to get access to the statusbar, so this is easy:

1
2
using Windows.UI.ViewManagement;
var statusBar = StatusBar.GetForCurrentView();

Now we want to hide the statusbar if we’re in landscape orientation, else we want to show the statusbar. To find out the orientation we can use the ApplicationView class, which is also in the Windows.UI.ViewManagement namespace:

1
2
3
4
if (ApplicationView.GetForCurrentView().Orientation == ApplicationViewOrientation.Landscape)
await statusBar.HideAsync();
else
await statusBar.ShowAsync();

We want to execute this every time the orientation of the device changes, but unfortunately, there is no OrientationChanged event. What we want to use is the Window.Current.SizeChanged event in the Windows.UI.Xaml namespace. We can hook this all up this way:

1
2
3
4
5
6
7
8
Window.Current.SizeChanged += async (sender, e) =>
{
var statusBar = StatusBar.GetForCurrentView();
if (ApplicationView.GetForCurrentView().Orientation == ApplicationViewOrientation.Landscape)
await statusBar.HideAsync();
else
await statusBar.ShowAsync();
};

However, when this code is executed on a non-Mobile Windows 10 device, it will generate a runtime exception. Of course, that’s not what we want; this code should just be ignored if it doesn’t apply. To accomplish this we can check if the StatusBar type is available, before executing the code:

1
2
3
4
5
6
7
8
9
10
11
if (ApiInformation.IsTypePresent("Windows.UI.ViewManagement.StatusBar"))
{
Window.Current.SizeChanged += async (sender, e) =>
{
var statusBar = StatusBar.GetForCurrentView();
if (ApplicationView.GetForCurrentView().Orientation == ApplicationViewOrientation.Landscape)
await statusBar.HideAsync();
else
await statusBar.ShowAsync();
};
}

Finally, where should we place this snippet? I want my entire application to behave this way, so I put the code to set this up in the OnInitializeAsync() method of the Template 10 BootStrapper. You can also choose to enable this functionality later in the runtime of your app. I’d recommend moving the event handler into its own method, so the functionality can easily be disabled by unsubscribing the event:

1
2
Window.Current.SizeChanged += HideStatusBarIfLandscape;
Window.Current.SizeChanged -= HideStatusBarIfLandscape; // Disabling by unsubscribing

In this case, you should also check for availability of the statusbar, before subscribing to the event. If the code inside the handler won’t run anyway, subscribing is just unnecessary overhead.

I think this little snippet of code belongs in almost every app, and I’ll definitely use it in most of mine.

Thanks for reading! Enjoyed this post? Please share it with your friends using the buttons below! Have some questions? Comments can be found below too! And on a final note: grammar corrections are always welcome! English is not my primary language, but that’s not a reason to don’t learn how to use the language correctly.

Share Comments

Hello world!

1
Console.WriteLine("Hello world!");

I’d like to use the opportunity of this first post to tell about the technology behind this blog, as that’s something I’m always interested in myself. This website is build using the Hexo static site generator, hosted on GitLab Pages. The theme is based on Icarus, which can be found here on GitHub (MIT License). All the changes I’ve made are available via the repo for this site.

Using a static site generator isn’t a choice I expected to make. I’ve tried lots of other options before going with Hexo, and with all of them, there was something I just didn’t like. And there’s always the problem of hosting. I was looking for something highly customizable, but simple to use. A really great writing experience was also a big priority, as that’s what I’m hoping to do a lot.

Some of the first systems I tried were full blown CMSs, build in .NET and C#. I like C#, it’s my favorite programming language, and C# can be used to build websites. It made sense to me to use my favorite technologies to build my blog. I tried both Orchard and Umbraco, both of them really great and very powerful systems. A little too powerful for me, and not the neat writing experience for just writing a blog post that I was looking for. I’ve also created a little CMS myself, but it suffers the same problem for every .NET based website: hosting. You’ll want to host the website on a Windows machine. (That’s not completely true anymore, especially with .NET Core, but it was when I tried these things.) Generally, this rule applies: hosting on Windows is more expensive than hosting on Linux, and you’ll have to do a lot more yourself. There are just a couple of .NET hosting providers that are relatively easy to use: Microsoft Azure and AppHarbor. Both of them have a free tier, but as soon as you want to add a custom domain name, pricing rises up like a rocket when compared to simple shared Linux hosting. Sure, the quality of the hosting is a lot better than the average shared Linux hosting, but my personal blog just doesn’t need to have 101% uptime and distributed hosting across datacenters all over the world. That’s where .NET is failing for me.

A CMS that seemed to fix the shortcomings of the CMSs mentioned above is Ghost. It has a beautiful writing experience and it’s very simple to use. It’s also built on Node.js, so it runs completely fine on Linux. It turns out though that on most simple shared hosting you don’t get the control you need to start the Node server. How simple and clean Ghost may be, hosting it is too much of a hassle, i.e. it costs too much money.

The first CMS most people think of is probably Wordpress. Being build on PHP it’s way easier to host than the aforementioned alternatives, as PHP is widely supported on cheap hosting. But it’s Wordpress: big, complicated and built on PHP. No offenses to anyone, but I honestly don’t think PHP should be used for anything serious, or at least I wouldn’t want to. In short: no Wordpress for me.

The biggest problem thus far: hosting. When looking at the blogs of other people I found something interesting: I was seeing a couple of them hosting on GitHub Pages. For free. Without extra fees for adding a custom domain. Pretty awesome, right? So I started looking into it, finding that the most common way to do a blog on a static site host like GitHub Pages is using a static site generator. GitHub Pages works especially well with Jekyll, but that doesn’t (officially) support Windows, which is my OS of choice. Other generators will have to be executed on your own PC, pushing the generated files into Git, which, like publishing your binaries into Git, feels a little dirty. Luckily GitHub isn’t the only repository hosting service with a logo that resembles a cat and an option to host static websites: there’s also something called GitLab, which offers GitLab Pages. The beauty of GitLab’s version of hosting is found in the integrated build system they offer: it can run any static site generator that can run in a Docker container on Linux. You don’t have to publish the generated site into Git, just the source. GitLab will then generate the static site and publish it on the web. This system gives you a lot of flexibility for the price of, well, nothing.

Just one thing left: why Hexo? When scrolling through staticgen.com there are lots of options and there are probably many more out there that aren’t on that list. Why did I pick Hexo? First of all, it’s one of the demos on the GitLab Pages account, so I could just copy their build file, instead of trying to configure something myself. It’s also very easy to install Hexo using npm and, to be honest, the site just gave me a good feeling. Sometimes that’s all it takes.

So there you have it: this is the technology stack supporting this blog. I hope this time everything works out well and I’ll be able to use this blog for a very long time.

Thanks for reading! Enjoyed this post? Please share it with your friends using the buttons below! Have some questions? Comments can be found below too! And on a final note: grammar corrections are always welcome! English is not my primary language, but that’s not a reason to don’t learn how to use the language correctly.

Share Comments