Of course you are now all writing MVVM based apps, after all I have been advocating that for years, and you are listening this here old venerable MVP, right? ;). Anyway, some UI interactions between UI and viewmodel can seem to be a bit complicated, but these kinds of problems are usually pretty simple to solve with a combination of a behavior, the MVVMLight messenger, and a message containing a callback. And as I hate to write things more than once, I made this into a reusable behavior. It ain’t rocket science, but it’s nice and clean.
I start with a class holding the actual message, and in this class file I have defined a callback delegate as well:
using System.Threading.Tasks;
using GalaSoft.MvvmLight.Messaging;
namespace WpWinNl.Behaviors
{
public class MessageDialogMessage : MessageBase
{
public MessageDialogMessage(string message, string title,
string okText, string cancelText,
MessageDialogCallBack okCallback = null,
MessageDialogCallBack cancelCallback = null,
object sender = null, object target = null)
: base(sender, target)
{
Message = message;
Title = title;
OkText = okText;
CancelText = cancelText;
OkCallback = okCallback;
CancelCallback = cancelCallback;
}
public MessageDialogCallBack OkCallback { get; private set; }
public MessageDialogCallBack CancelCallback { get; private set; }
public string Title { get; private set; }
public string Message { get; private set; }
public string OkText { get; private set; }
public string CancelText { get; private set; }
}
public delegate Task MessageDialogCallBack();
}
It’s a basic MVVMLight BaseMessage child class, with properties for various texts, and two optional callbacks for OK and cancel actions.
The behavior itself is, as behaviors go, pretty simple:
using System;
using System.Diagnostics;
using Windows.UI.Popups;
using Windows.UI.Xaml;
using GalaSoft.MvvmLight.Messaging;
namespace WpWinNl.Behaviors
{
public class MessageDialogBehavior : SafeBehavior<FrameworkElement>
{
protected override void OnSetup()
{
Messenger.Default.Register<MessageDialogMessage>(this, ProcessMessage);
base.OnSetup();
}
private async void ProcessMessage(MessageDialogMessage m)
{
bool result = false;
var dialog = new MessageDialog(m.Message, m.Title);
if (!string.IsNullOrWhiteSpace(m.OkText))
{
dialog.Commands.Add(new UICommand(m.OkText, cmd => result = true));
}
if (!string.IsNullOrWhiteSpace(m.CancelText))
{
dialog.Commands.Add(new UICommand(m.CancelText, cmd => result = false));
}
try
{
await dialog.ShowAsync();
if (result && m.OkCallback != null)
{
await m.OkCallback();
}
if (!result && m.CancelCallback != null)
{
await m.CancelCallback();
}
}
catch (Exception ex)
{
Debug.WriteLine("double call - ain't going to work");
}
}
}
}
This being once again a SafeBehavior, it simply starts to listen to MessageDialogMessage messages. When one is received, a MessageDialog is constructed with the message and title to display, as well as an optional Ok and Cancelbutton – and callback. If you send a message, you can provide optionally provide simple method from your viewmodel to be called by the behavior when Ok or Cancel is called, thus providing a two-way communication channel. Mind, though, all this is async, which has a curious side effect: if you send another message before the user has clicked Ok or Cancel, this will raise an exception.This will be displayed in the Visual Studio output window while you debug, but it won’t show up in release, and your message won’t be displayed either – so you need to carefully control sending messages, and not throw them out like there’s no tomorrow.
I have made a little sample app – a Universal app of course, because there have been some pretty clear hints by Microsoft this is the way to go forward. You will notice everything worthwhile is the shared project, up to the MainPage.xaml. People who were present at the latest Lowlands WpDev day last October will remember my fellow MVP Nico Vermeir saying in his talk “don’t do that, there’s pain in there”, and while this is true, it’s an ideal thing for lazy demo writers.
I started out with a blank Universal app, and moved the MainPage.Xaml and it’s companion MainPage.Xaml.cs to the shared project. Then I brought in my WpWinNl project that, amongst other things, drags in MVVMLight and everything else you need. Then I created this whopping complex viewmodel:
using System.Threading.Tasks;
using System.Windows.Input;
using GalaSoft.MvvmLight;
using GalaSoft.MvvmLight.Command;
using GalaSoft.MvvmLight.Messaging;
using WpWinNl.Behaviors;
namespace SampleMessagePopup
{
public class MainViewModel : ViewModelBase
{
public ICommand MessageCommand
{
get
{
return new RelayCommand(
() =>
Messenger.Default.Send(new MessageDialogMessage(
"Do you really want to do this?", "My Title",
"Hell yeah!", "No way",
HellYeah, Nope)));
}
}
private async Task HellYeah()
{
Result = "Hell yeah!";
}
private async Task Nope()
{
Result = "NOOOO!";
}
private string result = "what?";
public string Result
{
get { return result; }
set { Set(() => Result, ref result, value); }
}
}
}
- Both methods are async, although they don’t implement anything asynchronous. That’s because I wanted to be able do awaitable things in the callback and a contract is a contract – were not making JavaScript here. Only tools like ReSharper (highly recommended) will make you notice it, but you can ignore it for now.
- You might notice the callback methods are private but still the behavior is apparently able to call these methods. This, my dear friends who grew up in the nice era of managed OO languages that shield you from the things that move below you in the dark dungeons of your processor, is because you basically give a pointer to a method – and that’s accessible anywhere. Your compiler may tell you it’s a private method, but that’s more like it has a secret telephone number – if you got that, you can access it anywhere ;-). Us oldies who grew up with C or Assembler can tell you all about the times when boats were made of wood and men were made of steel and the great ways you can shoot yourself in the foot with this kind of things. If you want to make you app testable it makes more sense to make the methods public, by the way, but I could not let the opportunity to show this great example of the law of leaky abstractions pass.
But I digress, I know, that is also a sign of age ;)
The Xaml is of course also pretty simple – as this app does not do much:
<Page
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:Interactivity="using:Microsoft.Xaml.Interactivity"
xmlns:Behaviors="using:WpWinNl.Behaviors"
x:Class="SampleMessagePopup.MainPage"
DataContext="{StaticResource MainViewModel}">
<Interactivity:Interaction.Behaviors>
<Behaviors:MessageDialogBehavior/>
</Interactivity:Interaction.Behaviors>
<Page.BottomAppBar>
<CommandBar>
<AppBarButton Icon="Accept" Label="go ask!"
Command="{Binding MessageCommand}"/>
</CommandBar>
</Page.BottomAppBar>
<Grid Background="{ThemeResource ApplicationPageBackgroundThemeBrush}" >
<TextBlock Text="{Binding Result}" HorizontalAlignment="Center"
VerticalAlignment="Center" FontSize="56"/>
</Grid>
</Page>
Notice the behavior sitting on the page itself. For obvious reasons, it’s the logical place to put. You can also put it on the top grid. But whatever you do, use only one per page. They all listen to the same message, and if you put more of them on one page you will get an interesting situation where multiple behaviors will try to show the same MessageDialog. I have not tried this, but I assume it won’t be very useful.
To make this work, by the way, you need of course to declare your viewmodel in App.Xaml. You have no other choice here, as the App Bar sits at the top level of the page, the button calls the command and thus the resource must be one level higher, i.e. the app itself.
<Application
x:Class="SampleMessagePopup.App"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:local="using:SampleMessagePopup"
xmlns:system="using:System">
<Application.Resources>
<local:MainViewModel x:Key="MainViewModel" />
</Application.Resources>
</Application>
Again, if you use something like ReSharper a simple click on the declaration in MainPage.Xaml will make this happen.
So, that’s all there is to it. You won’t find the code for this behavior in the solution, as it is already in WpWinNl. Just like the previous one ;). As usual, a sample solution is provided, but in inspired by my fellow MVP Diederik Krols I’ve have decided that going forward I will publish those on GitHub.
