If you are writing reusable code, chances are high that you will write quite some code that deals with types, generics, and interfaces. Over the years, the collection of my helper extensions for that have grown. As some of my upcoming posts use them, I share them (also) for future reference.
1. Check if a Type is deriving from another Type
Deriving types is a common practice. To some extent, you can use pattern matching. Sometimes, that isn’t enough, though (especially if you have a multi-level derivation path). This is when I use one of these two extensions:
public static bool IsDerivingFrom(this Type type, Type searchType)
{
if (type == null) throw new NullReferenceException();
return
type.BaseType != null &&
(type.BaseType == searchType ||
type.BaseType.IsDerivingFrom(searchType));
}
public static bool IsDerivingFromGenericType(this Type type, Type searchGenericType)
{
if (type == null) throw new ArgumentNullException(nameof(type));
if (searchGenericType == null) throw new ArgumentNullException(nameof(searchGenericType));
return
type != typeof(object) &&
(type.IsGenericType &&
searchGenericType.GetGenericTypeDefinition() == searchGenericType ||
IsDerivingFromGenericType(type.BaseType, searchGenericType));
}
Update 1: Type.IsSubclassOf will give you the same result as IsDerivingFrom. The main purpose was (is) to use my implementation when having multiple levels of derivation and being able to debug the whole detection process.
2. Get type of T from IEnumerable<T>
Sometimes, one needs to know the item type of an IEnumerable<T>. These two extensions will help you in this case:
[System.Diagnostics.CodeAnalysis.SuppressMessage("Style", "IDE0060:Remove unused parameter", Justification = "Extension method")]
public static Type GetItemType<T>(this IEnumerable<T> enumerable) => typeof(T);
public static Type? GetItemType(this object enumerable)
=> enumerable == null ? null :
(enumerable.GetType().GetInterface(typeof(IEnumerable<>).Name)?.GetGenericArguments()[0]);
3. Check if a type implements a certain interface
Interfaces are supposed to make the life of a developer easier. Like with the type derivation, sometimes we need to know if a type implements a certain interface. This extension answers the question for you:
public static bool ImplementsInterface(this Type? type, Type? @interface)
{
bool result = false;
if (type == null || @interface == null)
return result;
var interfaces = type.GetInterfaces();
if (@interface.IsGenericTypeDefinition)
{
foreach (var item in interfaces)
{
if (item.IsConstructedGenericType && item.GetGenericTypeDefinition() == @interface)
result = true;
}
}
else
{
foreach (var item in interfaces)
{
if (item == @interface)
result = true;
}
}
return result;
}
Update 2: Type.IsAssignableFrom will also tell you if a type implements an interface. As for the IsDerivingFrom method, I wanted to be able to debug the detection, which is – besides from having an explicit implementation – the main reason for this method.
4. Find a Type in an external assembly
If you need a type that lives in an external assembly but you only have it’s Name (or FullName, it’s easy to adapt), this one will resolve the Type for you as long as its assembly is loaded into your AppDomain:
public static Type? FindType(this string name)
{
Type? result = null;
var nonDynamicAssemblies = AppDomain.CurrentDomain.GetAssemblies().Where(a => !a.IsDynamic);
try
{
result = nonDynamicAssemblies.
SelectMany(a => a.GetExportedTypes()).
FirstOrDefault(t => t.Name == name);
}
catch
{
result = nonDynamicAssemblies.
SelectMany(a => a.GetTypes()).
FirstOrDefault(t => t.Name == name);
}
return result;
}
Conclusion
Like I said in the beginning, this post will be used for future reference. These extensions made a lot of controls, MVVM implementations and business logic I wrote in the past (both for work and my private projects) a whole lot easier. Like always, I hope this post will be helpful for some of you.
When it comes to navigation patterns in mobile apps, the tabbed interface is one of the most popular options. While Xamarin.Forms has the TabbedPage (and Shell) to fulfill that need, it lacks one essential feature: scrollable tabs. After studying some of the samples floating around the web and some of the packages that provide such functionality, I tried find an easier solution.
The View
Let’s have a look at the View first. Like you may have guessed from the title, we are using a CollectionView for the tabs and a CarouselView for the Content. This combination makes it quite easy to implement tabs that cover a whole page size or smaller ones within a page.
Let me break that piece down. First, I wrapped everything in a Grid for this sample. The CollectionView of course should be horizontally scrolling but should not show any scroll bar. The tab item template is not a complex one – it is just a Label and a BoxView below it to help with indication of the selection. You are free to make the tab looking whatever you want because of the CollectionView, however.
Below that, we put a CarouselView. For this sample, I just made a simple one with a Lorem Ipsum Label in it on every item.
The ViewModels
Most of you know that I absolutely love the MVVM pattern. And this sample proves me right once again. We need just need two ViewModels to handle scrolling and synchronizing.
The first ViewModel is the TabViewModel:
Snippet
public class TabViewModel : ObservableObject
{
private string _title;
private string _content;
private bool _isSelected;
public TabViewModel(string title)
{
this.Title = title;
this.Content = "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Tempor id eu nisl nunc mi ipsum faucibus vitae aliquet. Turpis egestas integer eget aliquet nibh praesent tristique magna. In fermentum posuere urna nec tincidunt. Vitae congue eu consequat ac felis donec et odio pellentesque. Augue lacus viverra vitae congue. Viverra vitae congue eu consequat. Orci nulla pellentesque dignissim enim sit amet venenatis urna. Et ultrices neque ornare aenean euismod elementum nisi. Id consectetur purus ut faucibus pulvinar. In cursus turpis massa tincidunt. Egestas pretium aenean pharetra magna. Et pharetra pharetra massa massa ultricies mi quis. Nunc sed blandit libero volutpat. Purus viverra accumsan in nisl nisi scelerisque eu ultrices vitae.";
}
public string Title { get => _title; set => Set(ref _title, value); }
public string Content { get => _content; set => Set(ref _content, value); }
public bool IsSelected { get => _isSelected; set =>Set(ref _isSelected, value); }
}
The TabViewModel in this sample just has the bare minimum, namely the Title, the Content and the IsSelectedFlag to control the Visibility of the Indicator-BoxView. Nothing dramatic so far.
The MainViewModel glues everything together, so let’s have a look:
Snippet
public class MainViewModel : ObservableObject
{
private TabViewModel _currentTabVm;
public MainViewModel()
{
this.TabVms = new ObservableCollection<TabViewModel>();
this.TabVms.Add(new TabViewModel("Short Title"));
this.TabVms.Add(new TabViewModel("A Little Longer Title"));
this.TabVms.Add(new TabViewModel("An Even Longer Title Than Before"));
this.TabVms.Add(new TabViewModel("Again Short Title"));
this.TabVms.Add(new TabViewModel("Mini Title"));
this.TabVms.Add(new TabViewModel("Different Title"));
this.CurrentTabVm = this.TabVms.FirstOrDefault();
}
public ObservableCollection<TabViewModel> TabVms { get; set; }
public TabViewModel CurrentTabVm
{
get => _currentTabVm;
set
{
Set(ref _currentTabVm, value);
SetSelection();
}
}
private void SetSelection()
{
this.TabVms.ForEach(vm => vm.IsSelected = false);
this.CurrentTabVm.IsSelected = true;
}
}
Once again, there is nothing complex in it. We are mocking a collection of TabViewModel and handle the tab selection via Binding. After the current item got selected, we are setting the IsSelected property on it to true to show the Indicator in the CollectionView.
For this sample, I didn’t use a fully blown MVVM framework, so I am setting the BindingContext in the MainPage‘s constructor. The Binding engine in Xamarin.Forms already does almost everything to make this work.
The only thing left is to handle the positioning of the tabs if we are swiping the CarouselView. As this is purely View related, I am using the CurrentItemChanged event in code behind to center the CollectionView‘s selected item:
Xamarin.Forms provides a lot of solutions out of the box. Sometimes, however, these are not enough. Luckily, we can combine some of the solutions the framework provides to create fresh solutions within our apps. This post showed one of these. The additional bonus you get with this implementation is the ability to style the tabs in whatever way you want. As always, I hope this post will be helpful for some of you.
Of course, there is also sample for this post on Github.
If you are working with collections in your app, chances are high you are going to want (or need) to scroll to a specific item at some point. CollectionView has the ScrollTo method that allows you to do so. If you are using MVVM in your app however, there is no built-in support to call this method.
My solution
My solution for this challenge consists of following parts:
a BindableProperty in an extended CollectionView class to bind the item we want to scroll to
a configuration class to control the scrolling behavior
a base interface with the configuration and two variants derived from it (one for ungrouped items, one for grouped ones)
Let’s have a look at the ScrollConfiguration class:
public class ScrollToConfiguration
{
public bool Animated { get; set; } = true;
public ScrollToPosition ScrollToPosition { get; set; } = ScrollToPosition.Center;
}
These two properties are used to tell our extended CollectionView how the scrolling to the item will behave. The above default values are my preferred ones, feel free to change them in your implementation.
Then we will define two additional interfaces which we are going to use later in our ViewModel:
public interface IScrollItem : IConfigurableScrollItem
{
}
public interface IGroupScrollItem : IConfigurableScrollItem
{
object GroupValue { get; set; }
}
For a non-grouped CollectionView, we just need to implement IScrollItem. If we have groups, we’ll use IGroupScrollItem to add an object that identifies the group (following the Xamarin.Forms API here).
Extending CollectionView
Let’s connect the dots and implement an extended version of the CollectionView – to do so, create a new class and derive from it. I named mine CollectionViewEx (ingenious, right?).
To wrap things up, we now add a BindableProperty with a PropertyChanged handler to our CollectionViewEx that we can bind against, and which is, most importantly, calling the ScrollTo method of CollectionView.
Here is the full class:
public class CollectionViewEx : CollectionView
{
public static BindableProperty ScrollToItemWithConfigProperty = BindableProperty.Create(nameof(ScrollToItemWithConfig), typeof(IConfigurableScrollItem), typeof(CollectionViewEx), default(IConfigurableScrollItem), BindingMode.Default, propertyChanged: OnScrollToItemWithConfigPropertyChanged);
public IConfigurableScrollItem ScrollToItemWithConfig
{
get => (IConfigurableScrollItem)GetValue(ScrollToItemWithConfigProperty);
set => SetValue(ScrollToItemWithConfigProperty, value);
}
private static void OnScrollToItemWithConfigPropertyChanged(BindableObject bindable, object oldValue, object newValue)
{
if (newValue == null)
return;
if (bindable is CollectionViewEx current)
{
if (newValue is IGroupScrollItem scrollToItemWithGroup)
{
if (scrollToItemWithGroup.Config == null)
scrollToItemWithGroup.Config = new ScrollToConfiguration();
current.ScrollTo(scrollToItemWithGroup, scrollToItemWithGroup.GroupValue, scrollToItemWithGroup.Config.ScrollToPosition, scrollToItemWithGroup.Config.Animated);
}
else if (newValue is IScrollItem scrollToItem)
{
if (scrollToItem.Config == null)
scrollToItem.Config = new ScrollToConfiguration();
current.ScrollTo(scrollToItem, null, scrollToItem.Config.ScrollToPosition, scrollToItem.Config.Animated);
}
}
}
}
Let’s go through the code. The BindableProperty implementation should be common to most of us (if not, read up the docs). The most important part happens in the PropertyChanged handler.
By allowing the value of the BindableProperty to be null, we can reset the item and scroll to the same item again if necessary. Because IScrollItem as well as IGroupScrollItem derive from IConfigurableScrollItem, we can handle them both in one method. To make sure there is a default ScrollToConfiguration, I am checking the Config property for null – in case it is (because I forgot it), there is at least the default. In the end, I am scrolling to the Item in the CollectionView using the ScrollTo method.
The ViewModel(s) and Binding
Here is one of the (simple) ViewModels from the sample application for this post:
public class ItemViewModel : ViewModelBase, IScrollItem
{
public ItemViewModel()
{
this.Config = new ScrollToConfiguration();
}
public string Text { get; set; }
public int Number { get; set; }
public ScrollToConfiguration Config { get; set; }
}
Now in the parent ViewModel, we just add another property that we can use to bind against the CollectionViewEx‘s ScrollToItemWithConfig property. The Binding is straight forward:
The result of this whole exercise looks like this:
Conclusion
Even if the CollectionView control in Xamarin.Forms provides a whole bunch of optimized functionalities over ListView, there are some scenarios that require additional work. Luckily, it isn’t that hard to extend the CollectionView. Scrolling to a precise ViewModel is easy with the code above. Of course, I created also a sample Github repo.
As always, I hope this post will be helpful for some of you.
Sometimes, we want to invoke a method that is available via code for a control. Due to the abstraction of our MVVM application, the ViewModel has no access to all those methods that are available if we would access the control via code. There are several approaches to solve this problem. In one of my recent projects, I needed to invoke a method of a custom control, which should be routed into the platform renderers I wrote for such a custom control. I remembered that I have indeed read quite a few times about command chaining for such cases and tried to implement it. In the beginning, it may sound weird to do this, but the more often I see this technique, the more I like it.
Simple Demo control
For demo purposes, I created this really simple Xamarin.Forms user control:
As you can see, there is just a label without text. We will write the necessary code to fill this label with some text just by invoking a method in the code behind. To be able to do so, we need a BindableProperty (once again) to get our foot into the door of the control:
public static BindableProperty DemoCommandProperty = BindableProperty.Create(nameof(DemoCommand), typeof(ICommand), typeof(CommandChainingDemoControl), null, BindingMode.OneWayToSource);
public ICommand DemoCommand
{
get => (ICommand)GetValue(DemoCommandProperty);
set => SetValue(DemoCommandProperty, value);
}
The implementation is pretty straightforward. We have done this already during this series, so you should be familiar if you were following. One thing, however, is different. For this BindableProperty, we are using BindingMode.OneWayToSource. By doing so, we are basically making it a read-only property, which sends its changes only down to the ViewModel (the source). If we would not do this, the ViewModel could change the property, which we do not want here.
Now we have the BindableProperty in place, we need to create an instance of the Command that will be sent down to the ViewModel. We are doing this as soon as the control is instantiated in the constructor:
public CommandChainingDemoControl()
{
InitializeComponent();
this.DemoCommand = new Command(() =>
{
FillFromBehind();
});
}
private void FillFromBehind()
{
this.LabelFilledFromBehind.Text = "Text was empty, but we used command chaining to show this text inside a control.";
}
That’s all we need to do in the code behind.
ViewModel
For this demo, I created a new page and a corresponding ViewModel in the demo project. Here is the very basic ViewModel code:
using System.Windows.Input;
using GalaSoft.MvvmLight.Command;
namespace XfMvvmLight.ViewModel
{
public class CommandChainingDemoViewModel : XfNavViewModelBase
{
private ICommand _invokeDemoCommand;
private RelayCommand _demo1Command;
public CommandChainingDemoViewModel()
{
}
public ICommand InvokeDemoCommand { get => _invokeDemoCommand; set => Set(ref _invokeDemoCommand, value); }
public RelayCommand Demo1Command => _demo1Command ?? (_demo1Command = new RelayCommand(() =>
{
this.InvokeDemoCommand?.Execute(null);
}));
}
}
As you can see, the ViewModel includes two Commands. One is the pure ICommand implementation that gets its value from the OneWayToSource-Binding. We are not using MVVMLight’s RelayCommand here to avoid casting between types, which always led to an exception when I tested the implementation first. The second command is bound to a button in the CommandChainingDemoPage and will be the trigger to execute the InvokeDemoCommand.
Final steps
The final steps are just a few simple ones. We need to connect the InvokeDemoCommand to the user control we created earlier, while we need to bind the Demo1Commandto the corresponding button in the view. This is the page’s code after doing so:
One thing to point out is that we are also specifying the OneWayToSource binding here once again. It should work with normal binding, but it I recommend to do like I did, which makes the code easier to understand for others (and of course yourself). That’s all – we have now a working command chain that invokes a method inside the user control from our ViewModel.
Conclusion
Command chaining can be a convenient way to invoke actions on controls that are otherwise not possible due to the abstraction of layers in MVVM. Once you got the concept, they are pretty easy to implement. This technique is also usable outside of Xamarin.Forms, so do not hesitate to use it out there. Just remember the needed steps:
create a user control (or a derived one if you need to call a method on framework controls)
add a BindableProperty/DependecyProperty and set its default binding mode to OneWayToSource
instantiate the BindableProperty/DependecyProperty inside the constructor of the user control
pass the method call/code into the Action part of the newly created Command instance
create the commands in the ViewModel
connect the Commands to your final view implementation
Like I wrote earlier, I came across this (again) when I was writing a custom Xamarin.Forms control with renderers, where I had to invoke methods inside the renderer from my ViewModel. Other techniques that I saw to solve this is using Messengers (be it the one from MVVMLight or the Xamarin.Forms Messenger implementation) or the good old Boolean switch implementation (uses also a BindableProperty/DependecyProperty). I decided to use the command chaining approach as it is pretty elegant in my eyes and not that complicated to implement.
The series’ sample project is updated and available here on Github. Like always, I hope this post is useful for some of you.
Why do I need to take control over the back button behavior?
The back button is available on Windows, Android and under certain conditions on iOS. It is one of the key navigation hooks. While the implementations vary between platforms, the functionality is always the same – go back one step in navigation. Sometimes, we need to execute actions before going back, like notifying other parts of our application or even blocking back navigation because we need to perform actions on the local page (think of a WebViewthat has internal navigation capabilities for example). While we do need only a few lines to intercept the hardware back button on Android and UWP, the software back buttons on Android and iOS need some additional code.
Xamarin.Forms – View and ViewModel implementations
Based on the code we have already written in the past posts of this series, we are already able to get events pretty easy into our ViewModel, utilizing the EventToCommandBehavior approach. To get them into our ViewModel, we will throw an own created event. You can do so pretty easy by overriding the OnBackButtonPressed()method every Xamarin.Forms pages come with:
Depending on the boolean you will return here, the back navigation will be executed or not. The next step is to pass the event into our ViewModel, like we have done already with the ViewAppearingand ViewDisappearing events before:
As you can see from the snippet above, the next step is to add the BackButtonPressedCommandto our base ViewModel. There is nothing special on that, so here we go:
private RelayCommand _backButtonPressedCommand;
public RelayCommand BackButtonPressedCommand =>
_backButtonPressedCommand ?? (_backButtonPressedCommand = new RelayCommand(ExecuteBackButtonPressedCommand, CanExecuteBackButtonPressedCommand));
public virtual void ExecuteBackButtonPressedCommand() { }
public virtual bool CanExecuteBackButtonPressedCommand()
{
return true;
}
And that’s it, if you just want to get informed or handle back navigation on your own. However, from some of the projects I have worked on, I know that I may need to prevent back navigation. So let’s extend our code to reach that goal as well.
Blocking back navigation
Back in our base class implementation, let’s add a BindableProperty. This boolean property makes it very easy to block the back navigation (no matter if you’re doing so from a ViewModel or a View):
public static BindableProperty BlockBackNavigationProperty = BindableProperty.Create("BlockBackNavigation", typeof(bool), typeof(XfNavContentPage), default(bool), BindingMode.Default, propertyChanged: OnBlockBackNavigationChanged);
private static void OnBlockBackNavigationChanged(BindableObject bindable, object oldvalue, object newvalue)
{
//not used in this sample
//valid scneario would be some kind of validation or similar tasks
}
public bool BlockBackNavigation
{
get => (bool) GetValue(BlockBackNavigationProperty);
set => SetValue(BlockBackNavigationProperty, value);
}
The next part involves once again the already overridden OnBackButtonPressed() method. If we are blocking the back navigation, we are throwing another event:
Notice that I added an additional step for modal pages. Without that, the hardware button back press code will be executed twice on Android on modal pages. Of course, we are rooting also the BackButtonPressCanceledevent into our ViewModel, so let’s add it to our BindingContextChanged handler:
To complete the code, we need to add a boolean property and the BackButtonPressCanceledCommand to our base ViewModel implementation:
private bool _blockBackNavigation;
private RelayCommand _backButtonPressCanceledCommand;
public virtual bool BlockBackNavigation
{
get => _blockBackNavigation;
set => Set(ref _blockBackNavigation, value);
}
public RelayCommand BackButtonPressCanceledCommand =>
_backButtonPressCanceledCommand ?? (_backButtonPressCanceledCommand = new RelayCommand(ExecuteBackButtonPressCanceledCommand, CanExecuteBackButtonPressCanceledCommand));
public virtual void ExecuteBackButtonPressCanceledCommand() { }
public virtual bool CanExecuteBackButtonPressCanceledCommand()
{
return true;
}
And that’s it. We already implemented everything we need in our Xamarin.Forms project.
Platform implementations
As often, we need to write some platform specific code to make our Xamarin.Forms code work in all scenarios.
Universal Windows Platform
As the Universal Windows Platforms handles the back button globally, no matter if you’re on a PC, tablet or a phone, there’s no need for additional code. Really. It’s already done with the Xamarin.Forms implementation.
Android
For the part of the hardware back button on Android devices, we are already done as well. But Android has also a software back button (eventually), which is in the toolbar (pretty similar to iOS). There are two options we can use for Android. The first one involves just one line of code in our base page implementation’s constructor:
NavigationPage.SetHasBackButton(this, false);
This will hide the software back button on Android (and iOS as well). It would be perfectly fine on Android because all (phone and tablet) devices have a hardware back button. However, often, we do not have the possibility to go down the easy route. So let’s fully handle the toolbar button. It does not involve a lot of code, and it’s all in the MainActivity class:
protected override void OnPostCreate(Bundle savedInstanceState)
{
var toolBar = FindViewById<Android.Support.V7.Widget.Toolbar>(Resource.Id.toolbar);
SetSupportActionBar(toolBar);
base.OnPostCreate(savedInstanceState);
}
public override bool OnOptionsItemSelected(IMenuItem item)
{
//if we are not hitting the internal "home" button, just return without any action
if (item.ItemId != Android.Resource.Id.Home)
return base.OnOptionsItemSelected(item);
//this one triggers the hardware back button press handler - so we are back in XF without even mentioning it
this.OnBackPressed();
// return true to signal we have handled everything fine
return true;
}
The first step is to override the OnPostCreate method. Within the override, we are just setting the toolbar to be the SupportActionBar. If we would not do so, the more important override OnOptionsItemSelected would never get triggered. The back button in the toolbar has the internal resource name ‘Home’ (with a value of 16908332). If this button is hit, I am triggering the hardware back button press handler, which will get code execution routed back into the Xamarin.Formscode. By returning true we are telling Android we have handled this on our own. And that’s all we have to do in the Android project.
iOS
On iOS, a custom renderer for our XfNavContentPage is needed to get the same result. I was trying a few attempts that are floating around the web, but in the end this post was the most helpful to reach my goal also on iOS. Here is my version:
[assembly: ExportRenderer(typeof(XfNavContentPage), typeof(XfNavigationPageRenderer))]
namespace XfMvvmLight.iOS.Renderer
{
public class XfNavigationPageRenderer : PageRenderer
{
public override void ViewWillAppear(bool animated)
{
base.ViewWillAppear(animated);
//making sure to use this only with non-modal pages
if (Element is XfNavContentPage page && this.NavigationController != null)
{
var thisPageIndex = page.Navigation.NavigationStack.IndexOf(page);
if (thisPageIndex >= 1)
{
//disabling back swipe complettely:
this.NavigationController.InteractivePopGestureRecognizer.Enabled = false;
var backarrowImg = UIImage.FromBundle("arrow-back.png")
.ImageWithRenderingMode(UIImageRenderingMode.AlwaysTemplate);
var backButton = new UIButton(UIButtonType.Custom)
{
HorizontalAlignment = UIControlContentHorizontalAlignment.Left,
TitleEdgeInsets = new UIEdgeInsets(11.5f, 0f, 10f, 0f),
//we need to move the image a bit more left to get closer to the OS-look
ImageEdgeInsets = new UIEdgeInsets(1f, -8f, 0f, 0f)
};
//this makes sure we use the same behavior as the OS
//if there is no parent, it must throw an exception because something is wrong
//with the navigation structure
var parent = page.Navigation.NavigationStack[thisPageIndex - 1];
backButton.SetTitle(string.IsNullOrEmpty(parent.Title) ? "Back" : parent.Title,
UIControlState.Normal);
backButton.SetTitleColor(this.View.TintColor, UIControlState.Normal);
backButton.SetImage(backarrowImg, UIControlState.Normal);
backButton.SizeToFit();
backButton.TouchDown += (sender, e) =>
{
if (!page.BlockBackNavigation)
{
this.NavigationController.PopViewController(animated);
}
page.SendBackButtonPressed();
};
backButton.Frame = new CGRect(0, 0, UIScreen.MainScreen.Bounds.Width / 4,
NavigationController.NavigationBar.Frame.Height);
var view = new UIView(new CGRect(0, 0, backButton.Frame.Width, backButton.Frame.Height));
view.AddSubview(backButton);
var backButtonItem = new UIBarButtonItem(string.Empty, UIBarButtonItemStyle.Plain, null)
{
CustomView = backButton
};
NavigationController.TopViewController.NavigationItem
.SetLeftBarButtonItem(backButtonItem, animated);
}
}
}
}
}
Let me explain the snippet. On iOS, we do not have direct access to the back button events in the navigation bar. We are able to override the back button, though. The first thing we have to make sure is that there is a UINavigationControlleraround. This way, we are still able to use our base page class implementation and its features for modal pages. The next step is to create a button with an image (which needs to be bundled).
Of course, we want the button’s text to behave exactly like the OS one does. That’s why we are going to get the parent view. We can easily use the current view’s NavigationStackindex for that – as long as we do not have cross navigation but a continuous one. In this case, the page before the current page is our parent. If the parent’s Titleproperty is empty, we are setting the title to “Back”, pretty much the same like the OS itself does. If you want it to be empty, just add a Title to the page with ” ” as content. This works also if you do not want your MasterPagein a Xamarin.Forms.MasterDetailPage to have a visible title, btw.
The most important thing to note is the button’s TouchDownevent – which is why we are doing this whole thing. First, we manually navigate back in iOS via the PopViewControllermethod (if necessary). After that, we are once again invoking our Xamarin.Formsimplementation via the SendBackButtonPressed method of the Xamarin.Formspage, which will then trigger our EventToCommandBehavior we implemented earlier.
The last step is to create an UIViewcontainer for the button and assign it as a UIBarButtonItemto the UINavigationController via the SetLeftBarButtonItemmethod the UINavigationItem provides. And that’s it, we now also have control over the back button on iOS.
Lust but not least, we need to handle also the swipe-back-gesture. This can be done the hard way by disabling the gesture completelly:
//disabling back swipe complettely:
this.NavigationController.InteractivePopGestureRecognizer.Enabled = false;
I do not have an implementation for handling that in a better way, but I will update the sample with another post in this series later on. At least I have full control over the back navigation, which is (for the moment) all I need.
As always, I hope this post will be helpful for some of you. I also updated the source code of my XfMvvmLight sample on Github to match this blog post. If you have feedback or questions, sound off below in the comments or via my social channels.
In this post, I will show you how to display dialog messages (also known as message box). This time, we will use again native implementations (like in the second post about Dependency Injection) to get the job done. I could have used the Xamarin.Forms Page.DisplayAlertmethod, but that one does not allow a lot of customization, so I went down to implement it my way.
Like always, the interface dictates functionality
Because of the Xamarin Forms code being a portable class library, we need an new interface that can be called from all three platforms. I am covering four scenarios which I use frequently in my apps:
I am tunneling the defined Tasks of the interface via a call to Task.Run() into one single method call that is able to handle all scenarios I want to support. Let’s have a look at the ShowAlert method:
In the first three lines I am setting up a new AlertDialog , taking into account the actual Xamarin.Forms.Context, setting the title and the message content. If no other option is used, this shows just with the standard “OK”-Button to close the message.
Often we want to modify the button text, that’s where the confirmButtonText and cancelButtonTextoverloads are being used. I am also using a callback method that takes a Boolean to show which button on the message was pressed. Showing the Dialog needs to be done on the main UI Thread. Xamarin Forms provides the Device.BeginInvokeOnMainThread method to dispatch the code within the action into the right place.
I am showing the dialog while keeping a reference in the _openDialogs List. This reference is removed once the matching button or cancel action is executed. If the message is allowed to be dismissed via outside touches or other cancel methods, this happens in the CancelEvent Eventhandler delegate I am attaching.
The implementation also has a way to close all open dialogs, but it is a good practice to have only one open at a time, especially as other platforms do support only one open dialog at a time.
UWP
Microsoft recommends to use the ContentDialogclass to show messages and dialogs of all kind. So this is what we will use to show our dialog messages. Like on Android, we need a Task.Run()wrapper to make the implementation async.
Even if UWP allows only one ContentDialog to be open, we are using the list of open dialogs to be able to close “them” for compatibility reasons. The next step to implement is the ShowContentDialog Task all methods above are using:
The setup of the dialog is kind of similar to android. First, we are creating a new dialog setting the title and the message.
The second part is a bit more complex here. Dialogs should hook into the CloseButton properties and events in all cases, at least after OS-Version 1703 (Creators Update). This way, the CloseButtonClickevent is also raised when the user presses the ESC-Button, the system back button, the close button of the dialog as well as the B-Button on the Xbox-Controller.
When we have only one button to show, our confirmButtonText is directed to the CloseButton, otherwise to the PrimaryButton. In the second case, the CloseButtonis connected with the cancelButtonText. We are using the same callback Action as on Android, where the bool parameter indicates which button was pressed.
In the UWP implementation the additional parameters cancelableOnTouchOutsideand cancelableare not used.
iOS
The base implementation on iOS is basically the same like on Android and UWP. In case of iOS, we are using the UIAlertControllerclass, which is mandatory since iOS 8.
Now that we have the Task wrappers in place, we need to implement the ShowAlert method:
internal void ShowAlert(string title, string content, string confirmButtonText = null, string cancelButtonText = null, Action<bool> callback = null, bool cancelableOnTouchOutside = false, bool cancelable = false)
{
//all this code needs to be in here because UIKit demands the main UI Thread
Device.BeginInvokeOnMainThread(() =>
{
var dialogAlert = UIAlertController.Create(title, content, UIAlertControllerStyle.Alert);
var okAction = UIAlertAction.Create(!string.IsNullOrEmpty(confirmButtonText) ? confirmButtonText : "OK", UIAlertActionStyle.Default, _ =>
{
callback?.Invoke(true);
_openDialogs.Remove(dialogAlert);
});
dialogAlert.AddAction(okAction);
if (!string.IsNullOrEmpty(cancelButtonText))
{
var cancelAction = UIAlertAction.Create(cancelButtonText, UIAlertActionStyle.Cancel, _ =>
{
callback?.Invoke(false);
_openDialogs.Remove(dialogAlert);
});
dialogAlert.AddAction(cancelAction);
}
_openDialogs.Add(dialogAlert);
var rootController = UIApplication.SharedApplication.KeyWindow.RootViewController;
rootController.PresentViewController(dialogAlert, true, null);
});
}
What I am doing here is straight forward – I am setting up a new UIAlertController instance via its creation method, telling it to be styled as an alert. Then I need to create two UIAlertAction instances, one for the confirmButtonText and one for the cancelButtonText. Of course, I am hooking up the prior defined callback action, which will inform the Xamarin.Forms class about the result of the dialog.
To display the Alert, we need a reference to the RootViewController of the iOS application. In most Xamarin.Forms applications, the above code will do the job to present the UIAlertController via the PresentViewControllermethod provided by the OS. Like the UWP implementation, also the iOS implementation needs to be executed in the main UI thread, because the UIKit demands it. That’s why also here, the whole code is running inside the Device.BeginInvokeOnMainThread method’s action delegate.
The additional parameters cancelableOnTouchOutsideand cancelableare not used on iOS.
Updating our ViewModelLocator
If you have read my post on Dependency Injection, you might remember that we are able to combine the power of MVVMLight with Xamarin.Forms own DependencyService. This is what we will do once again in our ViewModelLocator in the RegisterServices method:
var dialogService = DependencyService.Get<IDialogService>();
SimpleIoc.Default.Register<IDialogService>(() => dialogService);
And that’s already all we need to do here. Really.
Finally: Showing message dialogs
I added three buttons to the sample’s main page. One shows a simple message, one shows the exception that I manually throw and the last one provides a two choice dialog. Let’s have a quick look at the commands bound to them:
private RelayCommand _showMessageCommand;
public RelayCommand ShowMessageCommand => _showMessageCommand ?? (_showMessageCommand = new RelayCommand(async () =>
{
await SimpleIoc.Default.GetInstance<IDialogService>().ShowMessageAsync("Cool... ?", "You really clicked this button!");
}));
This shows a simple message without using the additional parameters. I use this one primarily for confirmations.
private RelayCommand _showErrorWithExceptionCommand;
public RelayCommand ShowErrorWithExceptionCommand => _showErrorWithExceptionCommand ?? (_showErrorWithExceptionCommand = new RelayCommand(async () =>
{
try
{
throw new NotSupportedException("You tried to fool me, which is not supported!");
}
catch (Exception ex)
{
await SimpleIoc.Default.GetInstance<IDialogService>().ShowErrorAsync("Error", ex, "Sorry",
returnValue =>
{
Debug.WriteLine($"{nameof(ShowErrorWithExceptionCommand)}'s dialog returns: {returnValue}");
}, false, false);
}
}));
This one takes an exception and shows it on the screen. I use them mainly for developing purposes.
private RelayCommand _showSelectionCommand;
public RelayCommand ShowSelectionCommand => _showSelectionCommand ?? (_showSelectionCommand = new RelayCommand(async () =>
{
await SimpleIoc.Default.GetInstance<IDialogService>().ShowMessageAsync("Question:",
"Do you enjoy this blog series about MVVMLight and Xamarin Forms?", "yeah!", "nope", async returnvalue =>
{
if (returnvalue)
{
await SimpleIoc.Default.GetInstance<IDialogService>()
.ShowMessageAsync("Awesome!", "I am glad you like it");
}
else
{
await SimpleIoc.Default.GetInstance<IDialogService>()
.ShowMessageAsync("Oh no...", "Maybe you could send me some feedback on how to improve it?");
}
},
false, false);
}));
This one provides a choice between two options. A good example where I use this is when there is no internet connection and I ask the user to open the WiFi settings or cancel. In the sample, I am also showing another simple message after one of the buttons has been pressed. The content of this simple message depends on which button was clicked.
Action, please!
This slideshow requires JavaScript.
Using Xamarin.Forms’ DependencyServicetogether with the SimpleIoc implementation of MVVMLight, we are once again easily able to connect platform specific code to our Xamarin.Forms project. Every platform implementation follows the dialog recommendations and is executed using the native implementations while keeping some options open to use different kind of message dialogs.
As always, I hope this post is helpful for some of you. Until the next post, happy coding!
I always liked how the MVVMLight Toolkit provided the NavigationService for my Windows & Windows Phone applications. That said, I tried to keep the idea of its NavigationService and ported it over to my Xamarin.Forms structure. I also extended it to fit the needs of my XF apps, for example for pushing modal pages (we’ll see that later). So for the base idea, I have to say thanks to Laurent Bugnion for the Windows platform implementation in MVVMLight and for keeping it simple. The later fact allows one to easily extend and adapt the service.
Also, there are tons of really good and also working samples around the web to show navigation in Xamarin.Forms. However, most of them follow another strategy, so I came to the point where decided to write my own implementation. My way may work for most scenarios without making a difference between navigation and showing modal pages. It provides an easy implementation and usage while following the MVVM pattern as far as it can go with Xamarin.Forms.
Components
My implementation has some key components, which I will describe briefly in this post:
Interfaces for Navigation and view events
Implementation of these interfaces
using the implementations in views
using the implementations in ViewModels
Interfaces for the win!
If we want to follow the MVVM pattern, we need to keep our Views completely separated from our ViewModels. A common practice to achieve this goal is the usage of interfaces, and so do I. If you have read my previous blog post about Dependency Injection, you know already a bit about the things we have to do. First, we will create an interface for the navigation itself:
As you can see, it is a pretty big interface that covers nearly all possible navigation scenarios of a Xamarin.Forms app (at least those that I had to deal with already). We are going to hook into a Xamarin.Forms NavigationPage and configure our page handling cache with the configure method. As all navigation methods in Xamarin Forms are async, all navigational tasks will be implemented async as well. Additionally, we will have some helpful properties that we can use in our application implementation.
In Windows applications, we have some additional events for pages like Loaded or OnNavigatedTo(and so on). Xamarin.Forms pages have something similar: ViewAppearing and ViewDisappearing. These two events correspond to OnNavigatedTo and OnNavigatedFrom in a Windows application. Sometimes, we need to know when those events happen in our ViewModels or other places behind the scenes to get stuff done. That’s why I created an interface for this purpose:
public interface IViewEventBrokerService
{
event EventHandler<ViewEventBrokerEventArgs> ViewAppearing;
event EventHandler<ViewEventBrokerEventArgs> ViewDisAppearing;
void RaiseViewAppearing(string pageKey, Type pageType, bool isModal);
void RaiseViewDisAppearing(string pageKey, Type pageType, bool isModal);
}
I also created my own EventArgs to make it easier to pass all data around (as you can see above). Here is the class:
public class ViewEventBrokerEventArgs : EventArgs
{
public ViewEventBrokerEventArgs(string pageKey, Type pageType, bool isModal)
{
PageKey = pageKey;
PageType = pageType;
IsModal = isModal;
}
public string PageKey { get; private set; }
public Type PageType { get; private set; }
public bool IsModal { get; private set; }
}
Now that we have our interfaces defined, we are going the next step and have a look into their implementations.
So you’re back from reading the documentation? Great, then lets have a look what our XfNavigationServiceimplementation does. It builds on top of the Xamarin.Forms NavigationPage, which implements the INavigationinterface. Other solutions I saw are pulling down this interface and implement it in their implementation. I prefer to keep it simple and just use the already implemented interface in the Xamarin.Forms NavigationPage, which is mandatory for my implementation. We are pulling it into our implementation with the Initialize(NavigationPage navigationPage) method:
public void Initialize(NavigationPage navigationPage)
{
_navigationPage = navigationPage;
}
We could also use a constructor injection here. Most of the time it would work, but I had some problems to get the timing right under certain circumstances. That’s why I prefer to manually initialize it to overcome these timing problems – and it does not really hurt in real life applications to have it a bit more under control.
Before we are going to see the actual implementation, I need to break out of this scope and explain a threading issue.
Locking the current executing thread
Often we are running a lot of code at the same time. This could bring up some issues with ourXfNavigationService. If multiple threads try to change or execute code from our interface implementation, the result may not the one we desired. To prevent this, we would normally use the lock statement to allow only one thread modifying our code. Problem with the lock statement is, that we cannot run asynchronous code within.
As asynchronous code execution removes some of the headache in programming, we need a solution for this. And there is one, utilizing the SemaphoreSlim class of the .NET framework. Basically, the SemaphoreSlim class provides a single application Semaphore implementation. Without going deeper into it, we are replacing the lock statement we would normally use with this. We just need to initialize the SemaphoreSlim class as a private static member:
//using this instead of lock statement
private static SemaphoreSlim _lock = new SemaphoreSlim(1, 1);
This will only allow one thread to access the objects we are passing after it, and before releasing it (which is our responsibility). The code itself is recommended to run in a try..finally block (you’ll see that below). Pretty much the same thing the lock statement would do, but with the possibility to run asynchronous code.
Back to the implementation
The next step is to allow registering pages with a name and their type from the ViewModelLocator. I am doing the same as in the standard MVVMLight implementation here:
//declare private member for the registered pages cache
private readonly Dictionary<string, Type> _pagesByKey = new Dictionary<string, Type>();
public void Configure(string pageKey, Type pageType)
{
//synchronous lock
_lock.Wait();
try
{
if (_pagesByKey.ContainsKey(pageKey))
{
_pagesByKey[pageKey] = pageType;
}
else
{
_pagesByKey.Add(pageKey, pageType);
}
}
finally
{
_lock.Release();
}
}
Once we have our pages configured (we’ll see that later in this post), we are easily able to identify our registered pages for navigation purposes. Sometimes we want to get the current Page, so we need to implement a property for that, as well as for the current page key and the current modal page key:
public Page GetCurrentPage()
{
return _navigationPage?.CurrentPage;
}
public string CurrentPageKey
{
get
{
_lock.Wait();
try
{
if (_navigationPage?.CurrentPage == null)
{
return null;
}
var pageType = _navigationPage.CurrentPage.GetType();
return _pagesByKey.ContainsValue(pageType)
? _pagesByKey.First(p => p.Value == pageType).Key
: null;
}
finally
{
_lock.Release();
}
}
}
public string CurrentModalPageKey
{
get
{
_lock.Wait();
try
{
if (ModalStackCount == 1)
{
return null;
}
//only INavigation holds the ModalStack
var pageType = _navigationPage.Navigation.ModalStack.Last().GetType();
return _pagesByKey.ContainsValue(pageType) ? _pagesByKey.FirstOrDefault(p => p.Value == pageType).Key
: null;
}
finally
{
_lock.Release();
}
}
}
I found myself in situations where I needed to check if I am on a modal page, so lets add a method for that:
public (bool isRegistered, bool isModal) StackContainsNavKey(string pageKey)
{
bool isUsedModal = false;
bool isRegistered = false;
_lock.Wait();
try
{
isRegistered = _pagesByKey.ContainsKey(pageKey);
if (isRegistered)
{
var pageType = _pagesByKey.SingleOrDefault(p => p.Key == pageKey).Value;
var foundInNavStack = _navigationPage.Navigation.NavigationStack.Any(p => p.GetType() == pageType);
var foundInModalStack = _navigationPage.Navigation.ModalStack.Any(p => p.GetType() == pageType);
if (foundInNavStack && !foundInModalStack || !foundInNavStack && !foundInModalStack)
{
isUsedModal = false;
}
else if (foundInModalStack && !foundInNavStack)
{
isUsedModal = true;
}
else
{
throw new NotSupportedException("Pages should be used exclusively Modal or for Navigation");
}
}
else
{
throw new ArgumentException($"No page with key: {pageKey}. Did you forget to call the Configure method?", nameof(pageKey));
}
}
finally
{
_lock.Release();
}
return (isRegistered, isUsedModal);
}
This method checks if a page is registered correctly with its key and if it is presented modal at the moment. It also makes sure that an exception is thrown if a page is used modal AND in a navigation flow, which I think is a good practice to avoid problems when using the service. Finally, let’s add a Task for navigation to another page:
public async Task NavigateToAsync(string pageKey, object parameter, bool animated = true)
{
await _lock.WaitAsync();
try
{
if (_pagesByKey.ContainsKey(pageKey))
{
var type = _pagesByKey[pageKey];
ConstructorInfo constructor = null;
object[] parameters = null;
if (parameter == null)
{
constructor = type.GetTypeInfo()
.DeclaredConstructors
.FirstOrDefault(c => !c.GetParameters().Any());
parameters = new object[]
{
};
}
else
{
constructor = type.GetTypeInfo()
.DeclaredConstructors
.FirstOrDefault(
c =>
{
return c.GetParameters().Count() == 1
&& c.GetParameters()[0].ParameterType == parameter.GetType();
});
parameters = new[] { parameter };
}
if (constructor == null)
{
throw new InvalidOperationException("No constructor found for page " + pageKey);
}
var page = constructor.Invoke(parameters) as Page;
if (_navigationPage != null)
{
Device.BeginInvokeOnMainThread(async () =>
{
await _navigationPage.Navigation.PushAsync(page, animated);
});
}
else
{
throw new NullReferenceException("there is no navigation page present, please check your page architecture and make sure you have called the Initialize Method before.");
}
}
else
{
throw new ArgumentException(
$"No page with key: {pageKey}. Did you forget to call the Configure method?",
nameof(pageKey));
}
}
finally
{
_lock.Release();
}
}
[Update:] Until the latest Xamarin.Forms release, there was no need to use the Device.BeginInvokeOnMainThreadmethod for the navigation itself. I only checked it recently that the Navigation needs now the call to it to dispatch the navigation to the main UI thread. Otherwise, the navigation will end in a dead thread on Android and iOS (but strangely not for UWP). I updated the code above and the source on Github as well.
I try to avoid passing parameters to pages while navigating, that’s why I added another task without the parameter overload as well:
Of course we will run into situations where we want to go back manually, for example in a cancel function. So we have a method for that as well:
public async Task GoBackAsync()
{
await _navigationPage.Navigation.PopAsync(true);
}
That’s a lot of functionality already, but until now, we are only able to navigate to other pages and back. We want to support modal pages as well, so we’ll have some more methods to implement. They are following the same syntax as their navigation counterpart, so no surprise here:
public async Task ShowModalPageAsync(string pageKey, object parameter, bool animated = true)
{
await _lock.WaitAsync();
try
{
if (_pagesByKey.ContainsKey(pageKey))
{
var type = _pagesByKey[pageKey];
ConstructorInfo constructor = null;
object[] parameters = null;
if (parameter == null)
{
constructor = type.GetTypeInfo()
.DeclaredConstructors
.FirstOrDefault(c => !c.GetParameters().Any());
parameters = new object[]
{
};
}
else
{
constructor = type.GetTypeInfo()
.DeclaredConstructors
.FirstOrDefault(
c =>
{
return c.GetParameters().Count() == 1
&& c.GetParameters()[0].ParameterType == parameter.GetType();
});
parameters = new[] { parameter };
}
var page = constructor.Invoke(parameters) as Page;
if (_navigationPage != null)
{
Device.BeginInvokeOnMainThread(async () =>
{
await _navigationPage.Navigation.PushModalAsync(page, animated);
});
}
else
{
throw new NullReferenceException("there is no navigation page present, please check your page architecture and make sure you have called the Initialize Method before.");
}
}
else
{
throw new ArgumentException($"No page found with key: {pageKey}. Did you forget to call the Configure method?", nameof(pageKey));
}
}
finally
{
_lock.Release();
}
}
public async Task GoBackModalAsync()
{
await _navigationPage.Navigation.PopModalAsync(true);
}
The last things that I wanted to note are properties that return the current counts of both the modal and the navigation stack of the navigation page as well as the GoHomeAsync() method to return to the root page. You will see these in the source code on Github.
IViewEventBrokerService implementation
Like I wrote already before, sometimes we need to know when a view is appearing/disappearing. In that case, the IViewEventBrokerService comes in. The implementation is pretty straight forward:
public class ViewEventBrokerService : IViewEventBrokerService
{
public event EventHandler<ViewEventBrokerEventArgs> ViewAppearing;
public event EventHandler<ViewEventBrokerEventArgs> ViewDisAppearing;
public void RaiseViewAppearing(string pageKey, Type pageType, bool isModal)
{
ViewAppearing?.Invoke(this, new ViewEventBrokerEventArgs(pageKey, pageType, isModal));
}
public void RaiseViewDisAppearing(string pageKey, Type pageType, bool isModal)
{
ViewDisAppearing?.Invoke(this, new ViewEventBrokerEventArgs(pageKey, pageType, isModal));
}
}
We have two events that can be raised with their corresponding Raise… methods. That’s all we have to do in here.
Implementing the Interfaces in Views (Pages)
Well, we have written a lot of code until here, now it is time to actually use it. As I want all my pages to be raise their appearing and disappearing automatically, I created a new base class, derived from Xamarin.Forms’ ContentPage:
public class XfNavContentPage : ContentPage
{
private IViewEventBrokerService _viewEventBroker;
private IXfNavigationService _navService;
public XfNavContentPage()
{
_viewEventBroker = SimpleIoc.Default.GetInstance<IViewEventBrokerService>();
_navService = SimpleIoc.Default.GetInstance<IXfNavigationService>();
}
public static BindableProperty RegisteredPageKeyProperty = BindableProperty.Create("RegisteredPageKey", typeof(string), typeof(XfNavContentPage), default(string), BindingMode.Default, propertyChanged: OnRegisteredPageKeyChanged);
private static void OnRegisteredPageKeyChanged(BindableObject bindable, object oldValue, object newValue)
{
//todo, but not needed atm.
}
public string RegisteredPageKey
{
get { return (string)GetValue(RegisteredPageKeyProperty); }
set { SetValue(RegisteredPageKeyProperty, value); }
}
private(bool isRegistered, bool isModal) _stackState { get; private set; }
protected override void OnAppearing()
{
base.OnAppearing();
if (!string.IsNullOrEmpty(RegisteredPageKey))
{
_stackState = _navService.StackContainsNavKey(RegisteredPageKey);
if (_stackState.isRegistered)
{
_viewEventBroker?.RaiseViewAppearing(RegisteredPageKey, GetType(), _stackState.isModal);
}
}
}
protected override void OnDisappearing()
{
base.OnDisappearing();
if (!string.IsNullOrEmpty(RegisteredPageKey))
{
if (_stackState.isRegistered)
{
_viewEventBroker?.RaiseViewDisAppearing(RegisteredPageKey, GetType(), _stackState.isModal);
}
}
}
}
Let me explain what this base class does. It provides a BindableProperty(which is the Xamarin.Forms version of a DependencyProperty) that takes the registered key to provide it as a parameter. You can bind the key from your ViewModel or set it in code behind/XAML directly, all these ways will work. The base page implements our interfaces of the IXfNavigationService and the IViewBrokerServiceinterfaces as members and loads them in its constructor. The _stackStatemember is just an easy way to provide the needed data to the event-raising methods of our IViewEventBrokerservice. If used correctly, every page that derives from this base class will throw the corresponding events, which can be used in other parts of our application then.
Implementing the Interfaces in ViewModels
Like I did for Views, I am also creating a new base class for ViewModels that implement our two interfaces. Here is how it looks like:
public class XfNavViewModelBase : ViewModelBase
{
protected readonly IXfNavigationService _navService;
protected readonly IViewEventBrokerService _viewEventBroker;
public XfNavViewModelBase()
{
_navService = SimpleIoc.Default.GetInstance<IXfNavigationService>();
_viewEventBroker = SimpleIoc.Default.GetInstance<IViewEventBrokerService>();
_viewEventBroker.ViewAppearing += OnCorrespondingViewAppearing;
_viewEventBroker.ViewDisAppearing += OnCorrespondingViewDisappearing;
}
protected virtual void OnCorrespondingViewAppearing(object sender, ViewEventBrokerEventArgs e)
{
}
protected virtual void OnCorrespondingViewDisappearing(object sender, ViewEventBrokerEventArgs e)
{
}
private string _correspondingViewKey;
public string CorrespondingViewKey
{
get => _correspondingViewKey; set => Set(ref _correspondingViewKey, value);
}
public bool IsBoundToModalView()
{
if (!string.IsNullOrEmpty(CorrespondingViewKey))
{
var checkIfIsModal = _navService.StackContainsNavKey(CorrespondingViewKey);
if (checkIfIsModal.isRegistered)
{
return checkIfIsModal.isModal;
}
}
return false;
}
}
The XfNavViewModelBase implements both the IXfNavigationService and the IViewEventBrokerService interfaces. It also registers for the events thrown by IViewEventBrokerService. Making them virtual allows us to override them in derived ViewModels, if we need to. It has a string property to set the name of the View we want to use it in as well as a method that checks automatically if we are on a modal page if it gets called.
Using the created navigation setup
Now our navigation setup is ready it is time to have a look into how to use it. First we are going to create two pages, one for being shown modal, and one for being navigated to.
Then we’ll need to register and configure our services and pages in the ViewModelLocator. Remember the static RegisterServices() method we created in the first post? This is were we will throw the interface registrations in:
private static void RegisterServices()
{
//this one gets the correct service implementation from platform implementation
var osService = DependencyService.Get<IOsVersionService>();
// which can be used to register the service class with MVVMLight's Ioc
SimpleIoc.Default.Register<IOsVersionService>(() => osService);
SimpleIoc.Default.Register<IXfNavigationService>(GetPageInstances);
SimpleIoc.Default.Register<IViewEventBrokerService, ViewEventBrokerService>();
}
The method contains already our IOsVersionService from my last blog post. We are also using DI here for the IXfNavigationService, as we need to Configure our page keys as well. First, we are adding static strings as page keys to the ViewModelLocator:
public static string ModalPageKey => nameof(ModalPage);
public static string NavigatedPageKey => nameof(NavigatedPage);
I am always using the nameof()-operator for this, because it makes life a bit easier. The second step is the missing piece in the service registration, the GetPageInstances() method that returns an instance of the IXfNavigationService interface implentation and registers our two pages via the Configure() method.
public static XfNavigationService GetPageInstances()
{
var nav = new XfNavigationService();
nav.Configure(ModalPageKey, typeof(ModalPage));
nav.Configure(NavigatedPageKey, typeof(NavigatedPage));
return nav;
}
This all will never work if we are not using a NavigationPage. So we are going to load MainPage.xaml as a NavigationPagein App.xaml.cs and pass the navigation page to our IXfNavigationService:
public App()
{
InitializeComponent();
var rootNavigation = new NavigationPage(new View.MainPage());
MainPage = rootNavigation;
SimpleIoc.Default.GetInstance<IXfNavigationService>().Initialize(rootNavigation);
}
Modifying pages
Until now, the pages we created are standard ContentPages, so we need to make them derive from our earlier created base class. First we are adding the namespace of our base class to it:
After that, we are able to use the base class to change ContentPage to baseCtrl:XfNavContentPage. Now open the code behind file for the page and change it to derive from XfNavContentPage as well:
public partial class ModalPage : XfNavContentPage
The sample project has a modal page and a navigated page to demonstrate both ways.
Setting up ViewModels
Normally, we also have a ViewModel for every additional page. That´s why I created a ModalPageViewModel as well as a NavigatedPageViewModel for the sample. They derive from the XfNavViewModelBase, so wie can easyily hook up the view events (if needed):
Remember the page keys we added earlier to the ViewModelLocator? We are just setting it as CorrespondingViewKey in the constructor here, but you could choose to it the way you prefer as well and can easily be bound to the view now:
As the sample pages have a button with back function, we have also a GoBackCommand bound to it. Now that’s already all we need to, and if we set a breakpoint in the event handling overrides, it will be hit as soon as the view is about to appear. See the sample working here in action on Android:
No we have a fully working and MVVM compliant navigation solution in Xamarin.Forms using the MVVMLight Toolkit. I know there are several other toolkits and helpers floating around, but I like it to have less dependencies. Another advantage of going this route: I am mostly familiar with the setup as I am already used to it from my Windows and Windows Phone applications. Creating this setup for navigation does not take a whole lot of time (the initial setup took me around 3 hours including conception). One can also pack the interfaces and the implementations in a (portable) class library to have all this work only once.
If you have feedback for me, feel free to leave a comment below. Like always, I hope this article is helpful for some of you. The updated sample application can be found here on my Github account.
Like some of you may have already registered, I have been doing the next step and went cross platform with my personal projects. I am primarily using Xamarin Forms, because I eventually like XAML a little too much. I took a break from round about 2 years on my Xamarin usage, and I am happy to see that it has improved a lot in the meantime. While Xamarin Forms still has room for improvementes, one can do already real and serious projects with it. As I like the lightweight MVVMLight toolkit as much as I like XAML, it was a no-brainer for me to start also my recent Xamarin projects with it.
There is quite some setup stuff to do if you want get everything working from the Xamarin Forms PCL, and this post will be the first in a series to explain the way I am currently using. Some of the things I do may be against good practice for Xamarin Forms, but sometimes one has to break out of them to write code more efficiently and also maintain it easier.
Installing MVVM Light into a Xamarin Forms PCL project
Of course, we will start with a new Xamarin Forms project. After selecting the type Cross Platform App in the New Project Dialog in Visual Studio, you’ll be presented with this screen, which was introduced in the Cycle 9 Release of Xamarin:
Select Xamarin Forms as UI Technology and PCL as Code Sharing Strategy to start the solution creation. As it creates several projects, this may take some time, so you may be able to refill your coffee cup in the meantime. Once the project is created, you’ll see 4 projects:
Before we are going to write some code, we will update and add the additional packages from within the NuGet Package Manager. If your are not targeting the Android versions 7.x , Xamarin Forms is not able to use the latest Android Support libraries, so you’ll have to stick with version 23.3.0 of them (see release notes of Xamarin Forms). Since it makes sense for a new app to target the newest Android version, we’ll be updating the Android Support packages for our sample app as well.
If the NuGet Package manager demands you to restart, you’ll better follow its advise. To verify everything is ok with the updated NuGet packages, set the Android project as Startup project and let Visual Studio compile it.
If all goes well, let’s make sure we are using the right UWP compiler version for Visual Studio 2015. The .NETCORE package for the UWP needs to be of Version 5.2.x, as 5.3 is only compatible with Visual Studio 2017.
Once the packages are up to date, we’ll finally download and install MVVMLight. As we will host all of our ViewModel Logic in Xamarin Forms, together with their Views, we just need to install it into the Portable library and into the UWP project:
There will be no changes to the project except adding the reference. We need to set up the structure ourselves. First, create two new folders, View and ViewModel:
Move the MainPage into the View Folder and adjust the Namespace accordingly. The next step is to setup a ViewModelLocator class, which takes a central part of our MVVM structure. Here is what you need for the base structure:
public class ViewModelLocator
{
private static ViewModelLocator _instance;
public static ViewModelLocator Instance => _instance ?? (_instance = new ViewModelLocator());
public void Initialize()
{
ServiceLocator.SetLocatorProvider(() => SimpleIoc.Default);
RegisterServices();
}
private static void RegisterServices()
{
//topic of another blog post
}
#region ViewModels
#endregion
#region PageKeys
#endregion
}
You may notice some things. First, I am using the singleton pattern for the ViewModelLocator to make sure I have just one instance. I had some problems with multiple instances on Android, and using a singleton class helped to fix them. The second part of the fix is to move everything that is normally in the constructor into the Initialize() method. Now let’s go ahead, add a MainViewModel to the project and to the ViewModelLocator:
public void Initialize()
{
ServiceLocator.SetLocatorProvider(() => SimpleIoc.Default);
RegisterServices();
if (!SimpleIoc.Default.IsRegistered)
SimpleIoc.Default.Register<MainViewModel>();
}
#region ViewModels
public MainViewModel MainVm => ServiceLocator.Current.GetInstance<MainViewModel>();
#endregion
Let’s give the MainViewModel just one property which is not subject to change (at least for now):
public string HelloWorldString { get; private set; } = "Hello from Xamarin Forms with MVVM Light";
The next step is to get the App.xaml file code right, it should look like this:
[Register("AppDelegate")]
public partial class AppDelegate : global::Xamarin.Forms.Platform.iOS.FormsApplicationDelegate
{
//
// This method is invoked when the application has loaded and is ready to run. In this
// method you should instantiate the window, load the UI into it and then make the window
// visible.
//
// You have 17 seconds to return from this method, or iOS will terminate your application.
//
public override bool FinishedLaunching(UIApplication app, NSDictionary options)
{
global::Xamarin.Forms.Forms.Init();
ViewModelLocator.Instance.Initialize();
LoadApplication(new App());
return base.FinishedLaunching(app, options);
}
}
UWP:
//in App.xaml.cs:
protected override void OnLaunched(LaunchActivatedEventArgs e)
{
#if DEBUG
if (System.Diagnostics.Debugger.IsAttached)
{
this.DebugSettings.EnableFrameRateCounter = true;
}
#endif
Frame rootFrame = Window.Current.Content as Frame;
// Do not repeat app initialization when the Window already has content,
// just ensure that the window is active
if (rootFrame == null)
{
// Create a Frame to act as the navigation context and navigate to the first page
rootFrame = new Frame();
rootFrame.NavigationFailed += OnNavigationFailed;
Xamarin.Forms.Forms.Init(e);
ViewModelLocator.Instance.Initialize();
if (e.PreviousExecutionState == ApplicationExecutionState.Terminated)
{
//TODO: Load state from previously suspended application
}
// Place the frame in the current Window
Window.Current.Content = rootFrame;
}
if (rootFrame.Content == null)
{
// When the navigation stack isn't restored navigate to the first page,
// configuring the new page by passing required information as a navigation
// parameter
rootFrame.Navigate(typeof(MainPage), e.Arguments);
}
// Ensure the current window is active
Window.Current.Activate();
}
Let’s test our app on all platforms by building and deploying them:
Android
iOS Screenshot – post will be updated
UWP
If you get the same screens, you are all set up to use Xamarin Forms with MVVMLight.
Conclusion
I know there are several specialized MVVM frameworks/toolkits floating around, which are commonly used for Xamarin Forms. As I am quite used to the MVVMLight toolkit, I prefer it over them. It is a lightweight solution, and I have more control over the code that is running than with the other options. I know I have to handle a lot of things in this case on my own (Navigation for example), but these will get their own blog posts. Starting with one of the future posts in this series, I will provide a sample app on my Github account.
If you have feedback or questions, feel free to get in contact with me via comments or on my social accounts. Otherwise, I hope this post and the following ones are helpful for some of you.
2015 was once again a year where a lot happened. My year began with the start of a new job – I am now employed as a full time developer at the Swiss Shareholder register ShareCommService AG. The first days in Switzerland where full of trouble, as I needed to start from scratch in a new country. I found a room in a shared appartment, which was quite ok for me alone. Internet, phone, insurance, pass port – these were the things I had to do in the first weeks besides learning all the new things that you usually do when entering a new company.
As part of my new job, it was also heavily demanded that I finally get deeply into MVVM. I always read a lot about that, but avoided it because I wanted to get things done in my private projects. My MVVM learning project was a WPF timer app that supports resuming, multiple timers and more. I learned it in the only right way: without any frameworks/toolkits, which helps a lot to understand what is going on. Needless to say that I am happy to be past this point, as we are using MVVM Light a lot in our LOB applications. LOB (Line-of-Business) applications are different from what I have done before. They are used only internally and directly affect our daily business. I also learned more about SQL and databases, and also SignalR took a big part of my learning curve.
I have the luck to learn from Roman Müller, who has a gigantic amount of experience in programming and also has always some funny programming story to tell from his past. Together with Reto, the second programmer in our team, he teached me a lot – not only programming things, but also better ways to analyze and think about situations where you can end in programming. I am really thankful to be part of this team. Our system administrator Stefan, which I like to refer as a ‘BOFH with the heart on the right place’, makes the team complete.
During the year, I participated also in several Annual General Meetings (AGM) of our customers. This was very helpful for me to understand my new job, as we are responsible for all things regarding the votings on their agenda.
My first private project this year was to rewrite Voices Admin as a universal (Windows 8.1) app. Of course I did it as plain MVVM app, and it helped me a lot to get even deeper into it, and also boosted my learning curve in my daily job. I updated my UserVoice library as well to be fully portable in the meantime. Currently, I am working on the UWP version of UniShare.
My family stayed in Germany for several private reasons in the first month of the year. Beginning in August, we moved completely to Switzerland. I am happy that we passed this point as my family is very important to me and is giving me a lot of power. I have to thank my wife and also both of my kids for their understanding, as being a programmer is often very time consuming.
I also discovered a completely new area: the Internet of Things. With the Rasperry Pi2 supporting the Windows 10 IoT Core, I played around with it, learned a few new things about building hardware – and build a prototype for internal testings.
You see, I had a year full of action, and I tried to make this post as short as possible. I am looking forward to 2016, where my developer story will continue. I did also blog only a few things this year, and I am trying to keep things up and post more frequently next year.
For now, I whish everyone all the best for the end of this year and also for 2016!
If your app performs actions, you most probably want to add also some confirmation if an action has finished. There are some ways to do this, like using local toast notifications or MessageDialogs. While I was working on Voices Admin v2, which is a universal app, I came along with a helper to simplify using local toast notifications. However, there came the point, where I got annoyed by the sound of these, and I looked into possible ways to replace them. My solution is a simple notification system, that uses the MVVM Light Messenger.
The first thing I did was adding a new property that broadcasts its PropertyChangedMessage to my ExtendedViewModelBase (which inherits from the MVVM Light ViewModelBase). This simplifies setting the notification text across multiple ViewModels as I don’t need to create a property in every ViewModel of my app:
public class ExtendedViewModelBase : ViewModelBase
{
public ExtendedViewModelBase()
{
}
/// <summary>
/// The <see cref="NotificationText" /> property's name.
/// </summary>
public const string NotificationTextPropertyName = "NotificationText";
private string _notificationText = string.Empty;
/// <summary>
/// Sets and gets the NotificationText property.
/// Changes to that property's value raise the PropertyChanged event.
/// This property's value is broadcasted by the MessengerInstance when it changes.
/// </summary>
public string NotificationText
{
get
{
return _notificationText = string.Empty;
}
set
{
Set(() => NotificationText, ref _notificationText, value, true);
}
}
}
The second step is to create the possibility to bind this into my view. I am using a custom PageBase class to simplify this. For those binding purposes it is common to add a DependencyProperty, and this is exactly what I did:
/// <summary>
/// global property to bind the notification text against
/// </summary>
public static readonly DependencyProperty AppNotificationTextProperty = DependencyProperty.Register(
"AppNotificationText", typeof (string), typeof (PageBase), new PropertyMetadata(string.Empty, (s, e) =>
{
var current = s as PageBase;
if (current == null)
{
return;
}
current.CheckifNotificationMessageIsNeeded(s);
}));
/// <summary>
/// gets or sets the AppNotificationText
/// </summary>
public string AppNotificationText
{
get { return (string)GetValue(AppNotificationTextProperty); }
set { SetValue(AppNotificationTextProperty, value); }}
You may have noticed that I hooked up into the PropertyChangedCallback of the DependecyProperty, which passes the execution to an separate method. Before we’ll have a look on that method, we need to add two private members to my PageBase: one for a StackPanel (mainly to set the Background color) and another one for Textblock. This is needed because this is the visible part of the notification. In the constructor of my PageBase class, I am filling them with live and connect them together:
//instantiate and create StackPanel and TextBlock
//you can put anything you want in the panel
_panel = new StackPanel()
{
Background = new SolidColorBrush(Colors.Blue),
Visibility = Visibility.Collapsed,
};
_textBlock = new TextBlock()
{
FontSize = 20,
Margin = new Thickness(39, 10, 10, 10),
TextAlignment = TextAlignment.Center
};
_panel.Children.Add(_textBlock);
The next thing we need to do is the FindChildren<T> helper method, which I took from the MSDN docs:
/// <summary>
/// Gets a list of DependencyObjects from the Visual Tree
/// </summary>
/// <typeparam name="T">the type of the desired object</typeparam>
/// <param name="results">List of children</param>
/// <param name="startNode">the DependencyObject to start the search with</param>
public static void FindChildren<T>(List<T> results, DependencyObject startNode) where T : DependencyObject
{
int count = VisualTreeHelper.GetChildrenCount(startNode);
for (int i = 0; i < count; i++)
{
var current = VisualTreeHelper.GetChild(startNode, i);
if ((current.GetType()) == typeof(T) || (current.GetType().GetTypeInfo().IsSubclassOf(typeof(T))))
{
T asType = (T)current;
results.Add(asType);
}
FindChildren<T>(results, current);
}
}
This helper enables us to find the top level grid, where we will add the StackPanel and control its visibilty and the TextBlock’s text. Which we are doing with the CheckifNotificationMessageIsNeeded() method:
/// <summary>
/// handles the visibility of the notification
/// </summary>
/// <param name="currentDependencyObject">the primary depenedency object to start with</param>
private void CheckifNotificationMessageIsNeeded(DependencyObject currentDependencyObject)
{
if (currentDependencyObject == null) return;
var children = new List<DependencyObject>();
FindChildren(children, currentDependencyObject);
if (children.Count == 0) return;
var rootGrid = (Grid)children.FirstOrDefault(i => i.GetType() == typeof(Grid));
if (rootGrid != null)
if (!string.IsNullOrEmpty(AppNotificationText))
{
if (!rootGrid.Children.Contains(_panel))
{
rootGrid.RowDefinitions.Add(new RowDefinition() {Height = new GridLength(_panel.ActualHeight, GridUnitType.Auto)});
_panel.SetValue(Grid.RowProperty, rootGrid.RowDefinitions.Count);
rootGrid.Children.Add(_panel);
}
_textBlock.Text = AppNotificationText;
_panel.Visibility = Visibility.Visible;
}
else if (string.IsNullOrEmpty(AppNotificationText))
{
_textBlock.Text = string.Empty;
_panel.Visibility = Visibility.Collapsed;
}
}
Once we have the rootGrid on our Page, we are adding a new Row, set the StackPanel’s Grid.Row property to that and finally add the StackPanel to the Grid’s Children – but only if it does not exist already. No everytime the AppNotificationText property changes, the visibility of the StackPanel changes accordingly. Same counts for the TextBlock’s text. That’s all we need to do in the PageBase class.
The final bits of code we have to add are in the MainViewModel. I am using the MainViewModel as a kind of root ViewModel, which controls values and actions that are needed across multiple ViewModels. If you do not use it in the same way, you might need to write that code in all of your ViewModels where you want to use the notifications. The biggest advantage of my way is that the notification system (and other things) also works across pages.
The first thing we need is of course a property for the notification Text, which we will use to bind against on all pages where we want to use the notification system:
/// <summary>
/// The <see cref="GlobalNotificationText" /> property's name.
/// </summary>
public const string GlobalNotificationTextPropertyName = "GlobalNotificationText";
private string _globalNotificationText = string.Empty;
/// <summary>
/// Sets and gets the GlobalNotificationText property.
/// Changes to that property's value raise the PropertyChanged event.
/// </summary>
public string GlobalNotificationText
{
get
{
return _globalNotificationText;
}
set
{
Set(() => GlobalNotificationText, ref _globalNotificationText, value);
}
}
Now we have this, we are hooking into the MVVM Messenger to catch the broadcasted NotificationText’s PropertyChangedMessage:
If we would stop here, you would need to find a good point to set the NotificationText (and/or the GlobalNotificationText) property back to an empty string. This can be like the search a needle in the hay, believe me. That’s why I am giving every notification 5 seconds to be displayed, and the I am resetting the GlobalNotificationText property in my MainViewModel automatically. To achieve this goal, I am using a simple DispatcherTimer with an Interval of 1 second:
_notificationTimer = new DispatcherTimer() { Interval = new TimeSpan(0, 0, 1) };
DispatcherTimer has a Tick event, which fires every time a Tick happened. In our case, it fires every second. Hooking up into this event is essential, so add this line of code and let Visual Studio create the handler for you:
Inside the Tick event handler, I am counting the ticks (using a private member in my MainViewModel). Once the timer passed 5 seconds, I am stopping the DispatcherTimer, reset the counter and finally set the GlobalNotificationText property back to empty, which causes the notification to disappear:
Of course we also need to start the DispatcherTimer. The perfect time for this is within the handler of the received PropertyChangedMessage we added earlier:
//register for the global NotificationText PropertyChangedMessage from all VMs that derive from ExtendenViewModelBase
Messenger.Default.Register<PropertyChangedMessage<string>>(this, message =>
{
if (message.PropertyName == ExtendedViewModelBase.NotificationTextPropertyName)
{
if (!_notificationTimer.IsEnabled)
{
_notificationTimer.Start();
}
else
{
_notificationTimerElapsedSeconds = 0;
}
GlobalNotificationText = message.NewValue;
}
});
I am just checking if the DispatcherTimer is not yet enabled (= running) and start the timer in this case. If it is already running, I am just resetting my counter property to make sure that the notification is visible for 5 seconds again.
That’s it. Your MVVM (Light) app has now a simple and not so annoying notification system. It also provides the same experience across both platforms. There are sure ways to improve this here and there, that’s why I put up a sample to play around and contribute to on my Github account.
As always, I hope this post is helpful for some of you.
![[Updated] Xamarin Forms, the MVVMLight Toolkit and I: navigation and modal pages](https://msicc.net/wp-content/uploads/2017/06/showing-modal-page-xf-mvvmlight.png)
