Xamarin forms Tabbed page – UWP with images

When developing cross platform apps with Xamarin forms, you’ll notice that your apps will look and feel right at home on each OS. This because the nice people of Xamarin render each Xamarin forms control as a native control with the needed control properties all filled in.
You can still tweak some of these properties when they are leveraged through the Xamarin forms control abstraction or use custom renderers and effects to get down to the native control layer.

Most of the times this is all working great, but when you try to take UWP into account, you’ll notice not everything works straight out of the box.
Hence this blog post, showing you how you can hack the current TabbedPage implementation of Xamarin forms for UWP to enable pivot headers with images!

If you’ll use following XAML in Xamarin forms, you’ll get a nice Pivot control in UWP

But when you run the app, you’ll notice that on UWP nothing is happening with the Icon property of the NavigationPage

While on iOS you’ll get something like this

So what gives? Well, the current Xamarin forms tabbed page implementation will not take into account this Icon property and ignore it during rendering.
Reading the guidelines from Microsoft, it’s recommended to actually do use icons for pivot headers if possible, read on it here https://docs.microsoft.com/en-us/windows/uwp/controls-and-patterns/tabs-pivot.
The result should be something like this

Now let me show you a hack / workaround to get the same result on UWP. I stress hack, because of the current TabbedPage implementation in Xamarin forms there is no direct way to handle this.

Searching for a solution, I needed to open up the source code of Xamarin forms, fortunately it’s open source 🙂
If you go to the TabbedPageRenderer that is used for UWP, you’ll see that a specific XAML style is used for the Pivot control. This style is called TabbedPageStyle!
Setting the style is done here https://github.com/xamarin/Xamarin.Forms/blob/4e83b8ee0fa9274a1183ca41117eb91df825e341/Xamarin.Forms.Platform.UAP/TabbedPageRenderer.cs#L148
And the actual Style can be found here https://github.com/xamarin/Xamarin.Forms/blob/8c5fd096945301a2db0d85baf77ce46812a8d89f/Xamarin.Forms.Platform.UAP/TabbedPageStyle.xaml

To create a working solution, we need to change the HeaderTemplate that is specified inside that TabbedPageStyle. Normally we would just drop in a new Style with the same name inside our UWP App.Xaml file to override the one from Xamarin forms. But due to how Xamarin forms is initialised during startup this won’t work. So a small interception has to be made to get this going.

Add a new Styles.Xaml file in your UWP project and add following Style element to it

This will enable the use of the Icon property that we have set in our Xamarin forms xaml for each tab of the tabbedPage. Only thing left is swapping out the current HeaderTemplate and using ours.
So be sure to tell UWP we have this Style in our ResourceDictionary by adding it in the App.Xaml

After that, open up the App.Xaml.cs file and look for the Xamarin.Forms.Forms.Init(e); line.
Below it add an extra line of code to do the actual Template swapping

Like I said this is a hack… but it works perfectly 🙂 instead of using the default Xamarin forms TabbedPageStyle inside the Pivot header template we’ll now be using our own TabbedPageStyle2.
Only one small detail remains, you’ll notice I added a converter inside the Style. This was needed because the Icon property on the NavigationPage of Xamarin forms maps to a FileImageSource but that is not processable straight away as a source value for the Image control inside UWP.

The converter will get the File property of the FileImageSource and return that as a valid source. With this in place you’ll get the correct image shown!

Now if you have done everything right, you’ll get the following result, a Pivot control for a TabbedPage with images on UWP

As always a complete demo solution can be found on my Github here…

UWP – iconfy your design ( yep no SVG ;) )

So, been seeing a lot of SVG support being introduced into UWP to get vector images. I love this evolution, but somehow I still love how fonts work and mostly I still go that route if I need some icon representation inside an UWP app.
Fonts also easily scale, by setting the font size, what often results in better outlining with text being set on the same size! Adding color is also no problem and depending on what library you are using there is often also a full filled version as an outlined version available for a given icon.

So let me show you this alternative way on how you can use a great open source icon library to good use inside your UWP apps, through their available font.

First up go to this great icon library called Material Design Icons, here select the Download button and in the popup window select the Download the webfont button. This will contain the materialdesignicons-webfont.ttf that we will use in our UWP app.
To use it in your app, place the TTF inside your Assets folder.

Now that you have the font as an asset, you’ll still need to enable its usage in xaml. To do this, we’ll first add a reference to the font in a ResourceDictionary.
Add following entry in your resource dictionary :

Important note : the code reference should have the correct font name, otherwise it will not be visible…

After this, we are able to use it in our app, I tend to predefine some TextBlock style with default values so I can reuse these throughout my code.

Now that the style is available for any TextBlock you want to use, we can add those in our UI.
For example if you want to add an expand symbol to an image to indicate the user can enlarge it, we just select a good icon from the font and place a TextBlock inside a button on the image.
Now the most difficult part is actually getting hold of the actual text representing a given icon.
To get this, you’ll need to install the TTF in windows ( right click on the font and select install ) and use the Windows Character Map tool to copy the value.

Select a given icon and press copy to get hold of the actual value

screen-shot-2017-02-10-at-00-13-52

Only thing left to do is define an button and add a TextBlock to it with the font value.
Note : in the code preview below this will not be shown because the font value can not be rendered. But inside visual studio you will see a ? representation.

If everything is added correctly you’ll be presented with a nice icon button.

screen-shot-2017-02-10-at-00-19-16

As ever this code is available on my GitHub here…
Happy coding and yep SVG is good but not always needed 🙂

UWP – Split view deep dive ( the story of desktop mode or mobile mode )

So by now most people will know that I’m ‘still’ busy creating a Strava app for UWP called Kliva ( yes it is Open Source here… ).
Now the main purpose for using UWP was the fact that we could create 1 app that can be used on desktop/tablet pc’s and mobile phones!
Thanks to the new way of using Visual States in XAML we can tweak our design like we want depending on the size of the screen real estate.

All fine and dandy, but depending on the form factor it could also be that we need to navigate in a different way, Microsoft illustrated this by defining a Stacked Pattern and a Side-by-side pattern.
Read up on all the details here…

Now how can we as devs handle this difference in navigation? Well let me show you how we handled it in Kliva.

First we defined our own ApplicationFrame ( inherits from Frame ).

You’ll notice we do 2 things here, enable a Loading mode if needed and when a page is Navigated we trigger some code in a ViewModel.
Let’s deconstuct this later, I’ll first show you the actual frame setup…

So our frame will always consist of a SplitView control and the actual pages of our app will be rendered inside the SplitView.Content part!
We are using the SplitView control for the Side-by-side pattern reason, we will however need to adjust this in mobile mode, again more on this later 🙂 ( yep going to be a long post )

More importantly, we are now able to sneak in a full app wide loading overlay control. In other words, each time when needed, we will present an overlay with a progress ring, to indicate the app is still processing. By putting it here, inside the boilerplate code of the ApplicationFrame, it is available for all pages in the app!
Remember the code in the KlivaApplicationFrame? There is a method called ShowLoading(bool isLoading), this will put the Loading Grid in the correct VisualState ensuring it is visible or not and will also trigger the progress ring ( inside the LoadingControl ) to start.
The loading control itself is a user control that is nothing more than some text and a progress ring as show below…

But the real magic is in it’s code behind

We added the IsLoading property, so we can access it in our XAML – like we do in the VisualStates of the KlivaApplicationFrame.
But we also added a static method SetLoading(bool isLoading), we need this so that we can trigger the whole process of actually showing the control to the user!
In Kliva we let all our ViewModels inherit from a BaseViewModel and inside this one, we will call upon this static SetLoading method each time we think our app will need some time processing web requests.

So from a developer standpoint, each time you manipulate the IsBusy propety on the base viewmodel, our Loading Control will be shown to the user.
If you don’t like the ‘link’ between the ViewModel and the actual control, you could also work with MVVM messaging instead. No need for a static method that way, but hey we can’t always be 100% MVVM, right? 😉

Back to solving the mobile view, because you’ll remember that our original setup uses a SplitView and on mobile we want to shift this to actually using a BottomAppBar. To achieve this we need 2 things, hide the SplitView.Pane and showing the BottomAppBar.
Showing the bottom app bar is not that hard! We just check for the correct view size in our VisualStates and if needed toggle it’s visibility property depending on how large the screen actually is. From 320 to 720 we show it, everything above 720, we hide it.

Hiding the SplitView.Pane will need some coding… First part of this was already shown in our KlivaApplicationFrame, there when we navigate to a page we call upon the ShowHide method of the SidePaneViewModel.
This ViewModel is linked to the SidePane Control that is used inside the SplitView.Pane. We use several properties of this viewmodel on our SplitView properties, like the DisplayMode and IsPaneOpen ( cfr XAML code of our KlivaApplicationFrame ).
When we don’t need the SidePane of our SplitView, we set the DisplayMode to Inline and IsPaneOpen to false, if we do need the SidePane, we put the DisplayMode into CompactOverlay. That way, if on mobile, we can hide it and on desktop show it again.
We also extended the method a bit, so that we can hide the side pane on a given type of page, if needed ( currently not used )

Last but not least, we still need to find a way to adjust for page navigation or not. In our case, our main page will show a list of activities and when selecting one, present the details of that activity.
In a side-by-side pattern the details of the activity is on the right side of the list, in a stack pattern we need to navigate to the details page.

The side-by-side way is very easy, we put 2 controls in our main page, the first one contains the lists, the second one the detail info. Each of these controls are bound to the same ViewModel. So when an user selects an item from the list we will fill in the SelectedItem property on our ViewModel and our detail control will automatically show this.
But for the stacked pattern we add a bit of extra code, first again thanks to use of the VisualStates we will hide the detail control and secondly in our SelectedItem invocation we will try to start a page navigation if we are on mobile.
Not rocket science, just a little tweaking 🙂

The complete detail code for this can be seen on our github page for Kliva right here…

UWP TitleBar – inactive color

Just a small tip for desktop UWP apps!
I needed to look this up and it took me more time than I thought it would… so blogging it for reference 🙂

If you create an UWP app, you’ll notice that the app title bar will change color depending on the fact it has or has not the focus.

This can be useful, but if you already themed your app and took time to style the titlebar with some color, it just looks weird the color is no longer the same when not in focus.

So what do you need to do to get the app title bar stay the same, here is the code:

You first check if we are running in desktop mode, if so we get a hold of the titlebar and when you have that, just set Inactive*** properties the same as the normal ones!
That’s it…

Happy coding

UWP – Auto resizable flyout

So imaging you have this great looking layout in your UWP app, all set up with the new guidelines.
Meaning a side bar for navigation and a master detail section, that will dynamically change when you don’t have enough space to fit and master and detail.

We are talking about this layout:

Screenshot (37)

But of course like in most other apps, you want to enable some filtering on the content. That way the user can find the items that are more important to him… So for UWP there is a wonderful control that has all the needed qualities for such a feature; the MenuFlyout !
Now if you add this control, as is, it will only render itself in a certain width and height depending on the content that it contains. Meaning that most of the time, it will look tiny and out of place with the rest of the visual elements.
Here is a Phone screenshot example : notice how the flyout hovers above the side pane and it’s width is only calculated to it’s content

Wrong - 03 Mobile

What we would love to have, is a Flyout that takes up the full width size of the parent control it’s contained in… in other words in our example, have an equal width to the column that hosts the item list.
Let me show you how you can accomplish this.

First up, create this nice triple design, by using the new SplitView control, this will give you the side pane. Of course you’ll still need to add 2 columns to host the list and the detail content.
We’ll use the new Visual State Manager settings style to change the layout if we use the app on smaller screens!
Do note we are using a button with an empty button style to render the text for filter selection and a FlyoutMenu is attatched to that button. They are contained in the MasterColumn

Now that we have this all setup up, only thing left to do is calculate the actual width of the MasterColumn and use that to change the size of the flyout. But also take into account the side pane width to shit the flyout in place.
We will recalculate each time the flyout opens, because the app could be resized by the user before the flyout is actually opened.
So you’ll see a handler hooked up called for the Opened event called OnFilterFlyoutOpened with following code

The trick here is to change the MenuFlyoutPresenterStyle, with that style we can apply a minimum width to the actual flyout. That width should be equal to the width of the Master column…
We also apply some margin to compensate for the side pane.
By doing all this we now get following nice result :

Correct - 03 Mobile

As ever this sample can be found on my GitHub right here…

UWP – Close a Flyout MVVM way with UWP XamlBehaviors

Using a Flyout control in an UWP app is super handy to show contextual actions, but somehow they aren’t very MVVM friendly.
It was easier during windows 8.1 days, but with UWP it’s a hassle.

I’ve seen many solutions on how to tackle this problem, but let you give me mine just to show some other angles.
I’m trying to use the new UWP XamlBehaviors that went Open Source a while back, for all the info take a look here https://github.com/Microsoft/XamlBehaviors.

So the setup, we have a page that has a button – that button will open a flyout. On this flyout we have another button that will trigger some long running process in MVVM ( it’s not in this demo 😛 ).
What we want to do is dismiss the flyout from our MVVM if the process is done.

Here is the XAML code

Some things to note… We are using a MVVM command through binding for the button that is shown on the flyout.
The other thing, is the DataTriggerBehavior! It’s one of the behavior types that is available through the XamlBehaviors and what it allows us to do is perform some action when some data element changes to a certain value.
Here we are monitoring the IsFlyoutClosed boolean of our MVVM ViewModel to see when it’s being set to True. If this happens, we’ll perform an action called CloseFlyoutAction.
This action is a custom one and it’s purpose is to close the current given Flyout, as shown in the code below.

And that’s it… only thing left to do is manipulate the boolean on the ViewModel when you want to close the flyout.

As always an example project is available on GitHub here… https://github.com/Depechie/UWPFlyoutCloseMVVM

MvvmCross UWP SplitView

With the new UWP platform to create universal windows app, we now also have a new control called the SplitView.

This control allows us to ‘split’ a page in 2 parts, a left part that is a pane, mostly used for showing a navigation menu. And a right part where we will be loading our content pages.

Microsoft has created a nice demo app on how you could set this up! To be able to load views in only the right part of the SplitView, we need to use a Frame.
Complete demo can be found here https://github.com/Microsoft/Windows-universal-samples/tree/master/Samples/XamlNavigation/cs

All good and well, but what when we want to use this setup in our cross platform environment? In other words what do we need to do in our UWP project when we are building it using Xamarin and MvvmCross? For reference we are talking about using a PCL project ( for cross platform use ) and a UWP native project using that PCL, all wired up with MvvmCross.
The basis of this setup came from this blogpost: http://stephanvs.com/implementing-a-multi-region-presenter-for-windows-10-uwp-and-mvvmcross/

We’ll only be focussing on the UWP part, because setting up MvvmCross should be ok for people who know MvvmCross 🙂
When your project is created, we’ll set up a main page where we implement our SplitView.
I’ve added a FirstView and it inherits from MvxWindowsPage, it contains the SplitView with a Frame in the content part. Import thing to note here is that we are providing a name for the Frame, called FrameContent, this will define our MultiRegion.

Nothing fancy so far. But in the code behind of this View we need to add a property called AppFrame, because that will be used later on to enable the page loading in the defined frame. So just add the following in the code behind:

Now for the actual page loading, we will need to override the View Presenter creation of MvvmCross, this is done in the Setup.cs of the UWP project. Because instead of creating normal MvvmCross views, we need a MultiRegionView.
So add the following override in your Setup.cs file:

Last thing to do is indicate what views need to be loaded inside the frame, you do this by adding a MvvmCross attribute above your View definition. So if I want SecondView to be loaded in the region, I just add the following above the class definition of the view in code behind:

This will tell MvvmCross to load the complete view in a Region called FrameContent and like we said earlier, this is the name of our Frame we definied in our FirstView.
Now each time when you navigate to this view by using the MvvmCross viewmodel navigation, it will be shown inside the frame of your SplitView!

That’s it, not that hard actually 😉
A complete demo app of this can be found on my GitHub here https://github.com/Depechie/MvvmCrossUWPSplitView

UWP – adaptive triggers and custom triggers

**
UPDATE it seems there IS a way to deep link properties!
Thanks to Juan Pablo for providing this tip!

He posted all the goods up on CodeProject here…

In short you can write:

I’ve update the Adaptive trigger example off the GitHub project
**

Well I’m only just getting started with an UWP windows 10 project, so naturally I guessed I would hit some bumps on the road.
But the real first problem I got, was not an easy one to solve. The fix is easy, but I couldn’t wrap my head around it at first…

So hence this blogpost so maybe others could benefit from it.
Thanks to Scott Lovegrove for helping and testing this…

So what did I want to do, I wanted to change the background of the root grid of a XAML View depending on the Size of the page ( or depending on the Device Family that was viewing the page ).
First can be done with the new Adaptive triggers, second one can be done with a Custom trigger : look at Morten Nielsen his lib on Github.

So I tried following code:

But got no result, same thing with the Device Family trigger!
I then contacted Scott to see if he had an angle I didn’t try and together we tried several other Setters.
Like using other uri’s for the Value like: ms-appx:///Assets/White-Wallpaper-Windows-10-HD.jpg and other bindings for the Target like: LayoutRoot.(Grid.Background)

But all without luck, even contacted Morten to see if debugging the custom trigger would help. But nothing seemed to work out.

Until it hit me, maybe we can’t deep link Targets… so I changed the code to following

And look all of a sudden everything works!!
So the only thing I changed was actually giving the ImageBrush a name and using that as a the target for the triggers.

Not sure why this is the case, because writing this in XAML is valid:

That’s why I started with a wrong foot in the beginning.

Scott has a valid point, that the inner workings of the triggers is trying to map it to the real object and that can be very different then what we put in our XAML. So some internal conversion could be missing when using triggers.

Example project up on GitHub here…