Currently I am developing an app that should be able to share or save whatever is on the screen. I came upon this article by Loek van den Ouweland about RenderTargetBitmap and wondered if I could a) make this more generally (re)usable and b) make it play nice with MVVM.
The answer was – you guessed it – a behavior. The fun thing is, you can drag it onto any UI element, and it will create a screenshot of whatever what’s inside that element ( and that’s not necessary the whole screen!) and save it to storage. Two dependency properties, Target and Prefix, determine what message the behavior listens to, and what the file prefix is.
The main code of the functionality – which still looks a lot like Loek’s original sample – is in the behavior itself. To invoke it from the viewmodel, I call in the help of the MVVMLight messenger. So I start with the message that the viewmodel and the behavior use to communicate:
using GalaSoft.MvvmLight.Messaging; namespace WpWinNl.Behaviors { public class ScreenshotMessage : MessageBase { public ScreenshotMessage(object sender = null, object target = null, ScreenshotCallback callback = null) : base(sender, target) { Callback = callback; } public ScreenshotCallback Callback { get; set; } } public delegate void ScreenshotCallback(string fileName); }
This is a standard MVVMLight message, with the added extra that it can carry an optional payload of a callback. The behavior I created saves the file to a KnownFolder, but it can send the name of the file that’s been created back to the calling object by calling said callback.
The basics of the behavior – implemented once again as a SafeBehavior – is actually pretty simple:
using System; using System.Runtime.InteropServices.WindowsRuntime; using System.Threading.Tasks; using Windows.Graphics.Imaging; using Windows.Storage; using Windows.UI.Xaml; using Windows.UI.Xaml.Media.Imaging; using GalaSoft.MvvmLight.Messaging; namespace WpWinNl.Behaviors { public class ScreenshotBehavior : SafeBehavior<FrameworkElement> { protected override void OnSetup() { Messenger.Default.Register<ScreenshotMessage>(this, ProcessMessage ); base.OnSetup(); } protected override void OnCleanup() { Messenger.Default.Unregister(this); base.OnCleanup(); } private async void ProcessMessage(ScreenshotMessage m) { if (m.Target != null && Target != null) { if (m.Target.Equals(Target)) { await DoRender(m.Callback); } } else { await DoRender(m.Callback); } } } }
So it listens to a ScreenshotMessage coming by. When Target (a dependency property in this behavior) is equal to the target specified in the message, the rendering is done. Think of Target as a shared key – this enables a viewmodel to fire a specific behavior using – usually - a string. This I show in the sample solution. If both the behavior’s target and the message’s target are null, it fires as well. You can use this if you only have one behavior and one call. If, however, the behavior is used on multiple places I strongly recommend specifying Target, or else you might get very interesting race conditions.
The actual rendering method is nearly all Loek’s code with some little adaptions:
private async Task DoRender(ScreenshotCallback callback) { var renderTargetBitmap = new RenderTargetBitmap(); await renderTargetBitmap.RenderAsync(AssociatedObject); var pixelBuffer = await renderTargetBitmap.GetPixelsAsync(); var storageFile = await KnownFolders.SavedPictures.CreateFileAsync( string.Concat(Prefix, ".png"), CreationCollisionOption.GenerateUniqueName); using (var stream = await storageFile.OpenAsync(FileAccessMode.ReadWrite)) { var encoder =
await BitmapEncoder.CreateAsync(BitmapEncoder.PngEncoderId, stream); encoder.SetPixelData( BitmapPixelFormat.Bgra8, BitmapAlphaMode.Ignore, (uint) renderTargetBitmap.PixelWidth, (uint) renderTargetBitmap.PixelHeight, 96d, 96d, pixelBuffer.ToArray()); await encoder.FlushAsync(); if (callback != null) { callback(storageFile.Name); } } }
It creates an unique file based on the Prefix dependency property in the “SavedPictures” known folder, renders the screen as a png file, saves it, and if so desired calls a callback transmitting the name back to that callback – most likely a method of the viewmodel, which can then act on it.
The rest of the behavior are the two dependency properties that I leave out for brevity's sake.You don’t need to use them at all – if you don’t set Prefix, it will use “Screenshot”
To use it: as stated earlier, drag it on top of the UI element you want to make screenshots of, then add for instance the following code to your viewmodel:
public ICommand ScreenshotCommand { get { return new RelayCommand(() => { var m = new ScreenshotMessage(this, "screenshot", MyCallback); Messenger.Default.Send((m)); }); } } private void MyCallback(string name) { Debug.WriteLine(name); }In the message I have set the target to "screenshot", so in the XAML it should now says
<Behaviors:ScreenshotBehavior Target="screenshot" Prefix="MyScreenshot"/>
or else the behavior won’t respond to the message. When it’s done, it writes the name of the created file to the console – not very useful in production scenario’s, but it shows it’s working. In this callback you can for instance inform the user the file has been saved, activate a share contract or whatever you feel is neccesary.
The fun thing is, of course, that in this awesome world we live today behaviors can actually be cross-platform and be defined in a PCL and run both on Windows Phone 8.1 as on “big Windows” 8.1 :).
In the demo solution, that contains both a Windows Phone App, a Windows App, and a shared project you will see I have once again dragged the Main.Xaml to the shared project just for the fun of it. Don’t forget to set access to the pictures library in both the app manifests. I always forget that.
For Windows, the pictures end up in my “USERPROFILE%\Picures” folder, in Windows Phone they end up in “Pictures\Saved Pictures”.
Interesting detail – I have set the application’s root grid background to gray. If I don’t set a color, the background of the picture on Windows is not black, but cropped to 1297x1080 in stead of 1920x1080 as is my native resolution. I have not been able to determine yet why this is.
I built this behavior on top of my WpWinNl 2.0.3 package, but you can easily adapt it to get it to work as a normal behavior just using the procedure I described here.
Oh and the picture? It’s just an old picture of my wife’s Mercedes truck back in 2004, when she and a colleague joined a Guinness Book of records attempt to create the longest truck convoy ever. This is a short stop at dyke road shoulder before the actual 9.5 km long convoy was assembled. Interesting detail: all 416 drivers were women. The convoy drove 22 km without any problems, and as my wife so aptly said – it was the first time she joined a traffic jam for fun.
No comments:
Post a Comment