Drawing / Inking API in WinRT (C#) – IV

Updated Code Sample: Windows 8.1 Input: Ink sample in C#/Xaml
Original Code Sample: Windows 8 Input: Ink sample in C#/Xaml

In the previous posts (Drawing Api I, Drawing Api II and Drawing Api III), we talked about the fundamentals of Windows Ink Api. The methods revised were related to the rendering of the ink strokes, saving/loading, selecting the ink strokes on the canvas and also dealing with the clipboard.

In this post, we will be mainly talking about the multi-touch implementation of the canvas and dealing with multiple pointers (i.e. fingers or toes if you want/can 🙂 ) firing multiple events.

Introduction to Multiple Pointers

As you might have noticed, each pointer event includes the PointerPoint which we were using to retrieve the location of the pointer gesture. When it comes to multiple touch enabled devices, another property of this class becomes important – PointerId. Essentially what happens is, every time a “pointer” comes in contact with the control that is firing the events, the pointer gets a new id assigned. So for instance, if I was trying to draw with two fingers on different coordinates on a canvas, each of the press, move, release events would be fired independently associated with a different pointer instance with a separate id.

As an example, we can use the simulator and select the Pinch/Zoom Touch mode. In this case we have two pointers. If we were to add the following line to the pointer pressed event handler, we can easily see how the touch points are handled.

CurrentPointerDevice = args.Pointer.PointerDeviceType;

// Get information about the pointer location. 
PointerPoint pt = args.GetCurrentPoint(m_Canvas);

System.Diagnostics.Debug.WriteLine("Pointer Pressed\r\nType:{0}\r\nPointerId:{1}\r\nPosition:{2}\r\n", 
    CurrentPointerDevice.ToString(), args.Pointer.PointerId, pt.Position.ToString());

The simulator screen combined with the debug output looks similar to the screenshot below.

Multi-Touch Example on Simulator

Revising the Canvas Manager

Considering the repercussions of Canvas Manager trying to micromanage each pointer event from different pointers itself, we should let it delegate a little. (yes, unresolved issues from work 🙂 )

For this purpose, we can create a handler class that will deal with the pointer events until the pointer is released. (e.g. draw the temporary lines until the canvas manager takes over, or move the selected ink strokes with the selection zone until the user releases the pointer)

public abstract class PointerHandler : IDisposable
{
    protected readonly CanvasManager m_Parent;

    /// <summary>
    /// Abstract PointerHandler class, if implemented, deals with pointer move events
    /// </summary>
    /// <param name="parent">CanvasManager that created and owns this pointer handler</param>
    public PointerHandler(CanvasManager parent)
    {
        m_Parent = parent;
    }

    /// <summary>
    /// Pointer Id defines the specific pointer used used for this touch
    /// <remarks>
    /// In multi touch enabled devices each pointer gets a unique id.
    /// </remarks>
    /// </summary>
    public uint PointerId { get; set; }

    /// <summary>
    /// Handle the new point
    /// </summary>
    /// <param name="pt"></param>
    public abstract void HandlePointerMove(PointerPoint pt);

    /// <summary>
    /// Dispose is supposed to be used when the pointer handler is not needed anymore
    /// <example>When the ink pointer handler is disposed, it is suppose to clear all its lines drawn</example>
    /// </summary>
    public abstract void Dispose();
}

So if we were to implement a pointer handler for the drawing mode (e.g. InkPointerHandler), it would be responsible for creating a number of line geometries drawn the same pointer until the pointer is released and temporary lines cleaned up so we can use the Bezier segments from the ink manager. In this pattern, the canvas manager would be only responsible for creating the handler (i.e. on pointer pressed event) and passing on the pointer move events.

private void OnCanvasPointerPressed(object sender, PointerRoutedEventArgs args)
{
    CurrentPointerDevice = args.Pointer.PointerDeviceType;

    // Get information about the pointer location. 
    PointerPoint pt = args.GetCurrentPoint(m_Canvas);

    System.Diagnostics.Debug.WriteLine("Pointer Pressed\r\nType:{0}\r\nPointerId:{1}\r\nPosition:{2}\r\n", 
        CurrentPointerDevice.ToString(), args.Pointer.PointerId, pt.Position.ToString());

    switch (m_Settings.CurrentMode)
    {
        case CanvasMode.Select:
            // TODO:
            break;
        case CanvasMode.Erase:
            // TODO:
            break;
        default:
            // We create the appropriate pointer handler and add it to the hash table keyed with the pointer id
            m_Handers.Add(pt.PointerId, new InkPointerHandler(pt, this));
            // We still need to pass the pointer down event to the inkmanager so it can create the bezier approximation.
            CurrentManager.ProcessPointerDown(pt);
            break;
    }

    args.Handled = true;
}

The pointer moved event handler would be responsible for passing on the pointer moved event to the InkManager and the ink handler.

private void OnCanvasPointerMoved(object sender, PointerRoutedEventArgs args)
{
    PointerPoint pt = args.GetCurrentPoint(m_Canvas);

    if (m_Settings.CurrentMode == CanvasMode.Select)
    {
        #region Select
        // TODO:
        #endregion
    }
    else if (m_Handers.ContainsKey(args.Pointer.PointerId))
    {
        m_Handers[pt.PointerId].HandlePointerMove(pt);
        CurrentManager.ProcessPointerUpdate(pt);
    }
    else if (m_Settings.CurrentMode == CanvasMode.Erase ||
        (pt.Properties.IsEraser && args.Pointer.PointerDeviceType == PointerDeviceType.Pen))
    {
        #region Erase
        // TODO:
        #endregion
    }
 }

Implementing the Ink PointerHandler

InkPointerHandler would be a quick implementation of the PointerHandler. We already have the basic code in CanvasManager that deals with drawing the temporary lines until the ink manager takes over. We can move this code to the derived class and expose the Canvas member of the CanvasManager to the child handlers.

public override void HandlePointerMove(PointerPoint pt)
{
    m_CurrentContactPt = pt.Position;

    var color = m_Parent.Settings.CurrentMode == CanvasMode.Ink ? m_Parent.Settings.CurrentDrawingColor : m_Parent.Settings.CurrentHighlightColor;
    var size = m_Parent.Settings.CurrentMode == CanvasMode.Ink ? m_Parent.Settings.CurrentDrawingSize : m_Parent.Settings.CurrentHighlightSize;

    if (CheckPointerDrawingDelta(m_CurrentContactPt))
    {
        var line = new Line
        {
            X1 = m_PreviousContactPt.X,
            Y1 = m_PreviousContactPt.Y,
            X2 = m_CurrentContactPt.X,
            Y2 = m_CurrentContactPt.Y,
            StrokeThickness = size.Size,
            Stroke = new SolidColorBrush(color.Color)
        };


        if (m_Parent.Settings.CurrentMode == CanvasMode.Highlight) line.Opacity = 0.4;

        m_PreviousContactPt = m_CurrentContactPt;

        // Draw the line on the canvas by adding the Line object as 
        // a child of the Canvas object. 
        m_Parent.Canvas.Children.Add(line);

        // Adding the lines to a local container so canvas manager can reuse these
        // i.e. one pointer is released but the other one is still drawing, remove the lines for
        // the released handler and add the lines from the current one.
        m_Lines.Add(line);
    }
}

As you might have noticed, the handler code is almost completely copied from the previous CanvasManager implementation.

And the whole class structure looks like:

public class InkPointerHandler : PointerHandler
{
    private Point m_PreviousContactPt;

    private Point m_CurrentContactPt;

    private List<Line> m_Lines = new List<Line>();

    private double m_DrawingDelta = 3.0;

    /// <summary>
    /// Checks if the new point from the pointer move event meets the drawing threshold
    /// </summary>
    /// <param name="point">The new point reference received from pointer event</param>
    /// <returns><code>true</code> if the it meets the threshold</returns>
    private bool CheckPointerDrawingDelta(Point point)
    {
        // Calculating the distance between the previous contact and the new point
        double distance = Math.Sqrt(
            Math.Pow((point.X - m_PreviousContactPt.X), 2) + 
            Math.Pow((point.Y - m_PreviousContactPt.Y), 2));

        return (distance > m_DrawingDelta);
    }

    /// <summary>
    /// Temporary Lines drawn with simple geometry (i.e. line segments)
    /// </summary>
    internal List<Line> Lines
    {
        get { return m_Lines; }
    } 

    public InkPointerHandler(PointerPoint initialContact, CanvasManager parent) : base(parent)
    {
        m_PreviousContactPt = initialContact.Position;
        PointerId = initialContact.PointerId;
    }

    public override void HandlePointerMove(PointerPoint pt)
    {
        //... See Previous Snippet
    }

    public override void Dispose()
    {
        throw new NotImplementedException();
    }
}

Wrapping Up

Finally when the pointer is released the canvas manager is responsible for clearing the canvas and redrawing the geometries using the ink manager Bezier segments. While doing this, we have to keep in mind that some of the pointer handlers might still be drawing their temporary lines.

private void OnCanvasPointerReleased(object sender, PointerRoutedEventArgs args)
{
    if (m_Settings.CurrentMode == CanvasMode.Select && m_Handers.Values.OfType<SelectionPointerHandler>().Count() == 1)
    {
        #region Selecting
        // TODO:
        #endregion
    }
    else if (m_Handers.ContainsKey(args.Pointer.PointerId) && m_Handers[args.Pointer.PointerId] is InkPointerHandler)
    {
        PointerPoint pt = args.GetCurrentPoint(m_Canvas);

        // Pass the pointer information to the InkManager. 
        CurrentManager.ProcessPointerUp(pt);

        m_Handers.Remove(pt.PointerId);
    }

    // Call an application-defined function to render the ink strokes. 
    RefreshCanvas();

    args.Handled = true;
}

And the refresh canvas method implementation looks like:

/// <summary>
/// Renders the canvas with the strokes and any other additional elements (selection box)
/// </summary>
/// <remarks>If we are in the selection mode, we check for any strokes that intersect with the Selection Rectangle</remarks>
private void RefreshCanvas()
{
    System.Diagnostics.Debug.WriteLine("Refresh Canvas");

    m_Canvas.Children.Clear();

    // Renders the ink strokes from the ink managers (i.e. ink and highlight)
    RenderStrokes();

    //
    // Getting all the temporary lines from currently active ink handlers
    foreach (var line in (m_Handers.Values.OfType<InkPointerHandler>().SelectMany(handler => handler.Lines)))
    {
        m_Canvas.Children.Add(line);
    }

    if (m_Settings.CurrentMode == CanvasMode.Select)
    {
        m_Handers.Values.OfType<SelectionPointerHandler>().First().DrawSelectionBounds();
    }
}

That’s about it for now. With these changes the current implementation can handle multi-touch enabled devices.

In the next post, I will try upload the universal app sample I have been working on and describe the implementation approach I took to compensate for the missing Windows.UI.Input.Inking namespace on windows phone runtime applications.

Happy coding everyone…

Advertisements

Async Development in WinRT – II

In my first post, we talked about the basic functions of the asynchronous task framework, we did a little bit of digging on the correlation between the event/observer pattern and the awaitables.

The main purpose of these posts, as I explained, was to create a more responsive and fluid UI. So in this post, I want to start by analyzing the UI progress elements for a Windows Store App, and move on to the backend implementation. I will be using the design guidelines for progress described at Guidelines for Progress Controls.

Indeterminate Tasks

Indeterminate tasks, as the name suggests, are the operations of which we cannot let the user know about the estimated completion time (i.e. Not that we don’t want to, we just simply cannot). These operations can be part of a whole process flow (e.g. if the application first needs to connect to a server, then download certain items, then…etc.), or it can be related to a specific element on the UI, or it can relate to the whole application.

Following the fast/fluid ideology, we should refrain from using implementations that would block the whole UI unless the task being processed is crucial for the usage of the application (e.g. we are loading data to show on a grid that the user is going to use to make a decision.)

For indeterminate tasks, we have two basic progress indicators at our disposal: Indeterminate Progress Ring and Indeterminate Progress Bar.

Progress Ring with Status

Progress Bar

You can make use of these items either on a specific UI element or applying it to the whole screen either in the middle of the window (i.e. progress ring) or on top of the whole application (i.e. progress bar).

In our decision tree, first thing we need to decide on is if we want to have a blocking call (i.e. the process is an integral part of the application execution). In a blocking call, the only thing we can give to the user is “hey there is an operation going on, please wait to continue whatever you are trying to do”. It is not very nice of us, but it is what it is. We are doing our best to inform the user about the current execution state and giving the latest updates (i.e. in case of the multi-step workflow).

Blocking Calls

When the call is not blocking, meaning, the user can continue interacting with the UI while the process continues, developers have a little more options. In this scenario, we would just give subtle indications about the part of or the whole application that are involved in the process.

Non-Blocking Calls

This is almost like starting a good old BackgroudWorker or a Thread and changing the view of the progress indicator when the operation is completed. The implementation in windows store apps would involve a simple async method implementation.

        
private async void MyAsynchronousTask(object sender, RoutedEventArgs e)
{
    Dispatcher.RunAsync(CoreDispatcherPriority.Low, () =>
    {
        ProgressRing.IsActive = true;
    });

    // Here we are doing something with an awaitable task (in this case we are just
    // waiting for 10 secs, but this can be an actual implementation)
    await Task.Delay(new TimeSpan(0, 0, 10));

    Dispatcher.RunAsync(CoreDispatcherPriority.Low, () =>
    {
        ProgressRing.IsActive = false;
    });
}

If, in fact, we assign this function as an event handler to a button on the UI, it would make the progress ring (i.e. a progress ring element with the name x:Name=”ProgressRing”) active for 20 secs and then deactivate it.

NOTE: It is important to notice the use of the Dispatcher (i.e. current windows dispatcher) to execute the UI related functions. It is just like using the infamous InvokeRequired/Invoke group from good old days to marshal the UI thread.

Determinate Tasks

Determinate tasks are the ones that we have a clear idea about the current state of progress and we have an estimate for the user as for how much more left to do. We can think about it as a background worker (sorry for all the background worker analogies but it is the closest to the asynchronous implementation in Windows Store apps), which is constantly firing the ProgressChanged event, giving the chance to the developer to reflect this progress on the UI.

Determinate Progress

So as the diagram suggests, for the determinate processes, we can actually use a determinate progress bar. We can easily update the progress bar value on progress changed events. Using the example from the previous section.

Let’s create a determinate progress bar first:

<ProgressBar x:Name="ProgressBar" IsIndeterminate="False" Value="0"></ProgressBar>

Then we can go ahead and implement a quick demonstration function to update the progress bar.

private async void MyAsynchronousTaskWithProgress(object sender, RoutedEventArgs e)
{
    Dispatcher.RunAsync(CoreDispatcherPriority.Low, () =>
    {
        ProgressBar.Value = 10;
    });

    await Task.Delay(new TimeSpan(0, 0, 4));

    Dispatcher.RunAsync(CoreDispatcherPriority.Low, () =>
    {
        ProgressBar.Value = 40;
    });

    await Task.Delay(new TimeSpan(0, 0, 4));

    Dispatcher.RunAsync(CoreDispatcherPriority.Low, () =>
    {
        ProgressBar.Value = 70;
    });

    await Task.Delay(new TimeSpan(0, 0, 4));

    Dispatcher.RunAsync(CoreDispatcherPriority.Low, () =>
    {
        ProgressBar.Value = 100;
    });
}

Using IProgress<T>

In the previous example we are using arbitrary values to update the progress, we can also have a look at a real life scenario. Let’s assume we want to download a file from web. For this example, we can make use of this handy module in windows store apps: BackgroundDownloader.

private async Task DownloadAsync(Uri source, StorageFile destinationFile)
{
    BackgroundDownloader downloader = new BackgroundDownloader();
    DownloadOperation download = downloader.CreateDownload(source, destinationFile); 

    Progress<DownloadOperation> progressCallback = new Progress<DownloadOperation>(DownloadProgress);

    await download.StartAsync().AsTask(progressCallback);
}

NOTE: You notice we are using the AsTask extension method here to convert the Windows Runtime Async operation to a Task. This is just for clarity. We could have easily used the IAsyncOperationWithProgress interface to achieve the same.

In our download operation, we are creating a progress handler that is accepting the parameter DownloadOperation. Now if we use the previous progress bar sample to update the UI with the download progress, we have a determinate progress sample in our hand.

private void DownloadProgress(DownloadOperation download)
{
    double percent = 100;

    if (download.Progress.TotalBytesToReceive > 0)
    {
        percent = download.Progress.BytesReceived * 100 / download.Progress.TotalBytesToReceive;
    }

    Dispatcher.RunAsync(CoreDispatcherPriority.Low, () =>;
    {
        ProgressBar.Value = percent;
    });
}

However, this still does not apply to a scenario where we want to execute a more complicated operation. Let’s assume I want to calculate, a bit of a cliché but still, n-th number of the Fibonacci sequence.

private IAsyncOperationWithProgress<int, int> CalculateFibonnaci(int index)
{
    var previous = -1;
    var next = 1;

    return AsyncInfo.Run<int, int>((token, progress) =>
        Task.Run(() =>
        {
            for (int i = 0; i < index; i++)
            {
                int sum = next + previous;
                previous = next;
                next = sum;

                progress.Report(i/index);
            }

            return next;
        }));
}

In this implementation, I am using the AsyncInfo factory to create the IAsyncOperationWithProgress. The reason for the Task.Run is actually only to create an asynchronous task to execute the for-loop for the calculation. Here, the progress reporting happen in each cycle; giving a percentage to the user about the current calculation process.
You can also have a look at my previous post Download/Send Request AsyncWithProgress with HttpClient for a progress implementation.

Using CancellationToken

In the workflow diagram, you can see that it is suggested to provide a way to cancel the operation if it is taking longer than 10 seconds. If this was a BackgroundWorker, one would simply use the Cancel method to start a cancellation and check for pending cancellations in the worker thread.

The use case here is pretty similar. In asynchronous operations, you have something called a CancellationTokenSource and a token that reflects any cancellation source events to the processing task (kind of a flare gun and the signaling flare).

So, we have to first modify the Fibonacci method to accept a CancellationToken. In the Fibonacci loop, then, we have to check if the cancellation is requested and decide to continue or abort the operation.

private IAsyncOperationWithProgress<int, int> CalculateFibonnaci(int index, CancellationToken cancelToken)
{
    var previous = -1;
    var next = 1;

    return AsyncInfo.Run<int, int>((token, progress) =>
        Task.Run(() =>
        {
            if (cancelToken != CancellationToken.None) token = cancelToken;

            for (int i = 0; i < index; i++)
            {
                if (token.IsCancellationRequested)
                {
                    token.ThrowIfCancellationRequested();
                }

                int sum = next + previous;
                previous = next;
                next = sum;

                progress.Report((i/index)*100);
            }

            return next;
        }, token));
}

So in each loop, we are checking in a cancellation is signaled, and if so, we are throwing an OperationCancelledException exception.
And using this async operation with progress and cancellation token would look like:

private async Task UseFibonacciMethod()
{
    try
    {
        Action reportProgress = (progress) => Dispatcher.RunAsync(CoreDispatcherPriority.Normal, () =>
        {
            ProgressBar.Value = progress;
        });


        m_CancellationSource = new CancellationTokenSource();

        var token = m_CancellationSource.Token;

        var operationWithProgress = CalculateFibonnaci(800, token);

        operationWithProgress.Progress = (result, progress) => reportProgress(progress);

        // You can cancel it after a certain amount of time, which would trigger an OperationCancelledException
        // m_CancellationSource.CancelAfter(2000);

        return await operationWithProgress;
    }
    catch (OperationCanceledException ex)
    {
        // When the operation is cancelled by the cancellation source
    }
    catch (Exception ex)
    {
        // If anything goes wrong with fibonnaci (e.g. sum > int.Max)
    }

    return -1;
}

Hope you enjoyed the post. Happy coding everyone.

P.S> You can find the complete progress workflow diagram here.

Async Development in WinRT – I

When you are dealing with an application that directly interacts with a network, or works on network resources, your app is bound to make some long running calls. If we were dealing with a good old Windows Forms application, the most important point was to avoid your application from blocking the UI. We would use some background threads or a background worker, while displaying a (relatively annoying) loading sign. We could extend this pattern by using some completed or error event handlers to notify the UI about the worker thread. The basic goal here is to let the user know that the application is doing some work in the background without blocking the UI thread, hence avoiding the “MyApp is not responding” status.

In Windows Store Apps, our job is a little harder. We have to deal with the whole “Fast and Fluid” ideology of windows runtime. In other words, our application should stay responsive at all times. We can still use some subtle indicators that the application is doing something in the background but we should avoid keeping the user waiting while we are finishing up a task. In this quest of ours to make our application responsive, our biggest helper is the new asynchronous API. With this new “framework”, you can implement/use progress callbacks, task abortion, awaiter’s and so on; by means of which you can throw some of the basic plumbing on windows runtime’s back.

In this post, we will be implementing and using some of the features of this asynchronous API. For this purpose lets create a new class that works on a simple eventing pattern. We will have a long running task, a Completed handler and an error event.

Preparing Our Demo Class

So let us start by defining our class with a long running task.

NOTE: In these examples, I will be using a custom diagnostic event listener for logging. You can the ETW logging implementation for WinRT sample from the MSDN Code Gallery.

public class EventingClass
{
    private int DoTask1(int input)
    {
        int result;

        // Emulating the long running task
        Task.Delay(2000).Wait();

        if (input < 0)
        {
            throw new ArgumentOutOfRangeException("input", "Input parameter cannot be smaller than 0");
        }

        result = input + 1;

        return result;
    }
}

So our operation just waits for 2000 milliseconds and if the input value is less than 0 throws an exception. Otherwise, it will return a result value. (NOTE: Task.Delay is very similar to Thread.Sleep function from the Threading namespace).

As we described above we need two events for success and error. So we first implement the event arguments:

public class MyTaskCompletedEventArgs : EventArgs
{
    public int Result
    {
        get;
        private set;
    }
    
    public MyTaskCompletedEventArgs(int result)
    {
        Result = result;
    }
}

public class MyTaskFailedEventArgs : EventArgs
{
    public string Message
    {
        get;
        private set;
    }
 
    public MyTaskFailedEventArgs(string message)
    {
        Message = message;
    }
}

And finally we can implement the eventing pattern in our class:

public class EventingClass
{
    public event EventHandler<MyTaskFailedEventArgs> OnTaskFailed;

    public event EventHandler<MyTaskCompletedEventArgs> OnTask1Completed;

    private void RaiseOnTask1Completed(int result)
    {
        var eventHandler = OnTask1Completed;

        if (eventHandler != null)
        {
            eventHandler(this, new MyTaskCompletedEventArgs(result));
        }
    }

    private void RaiseOnTaskFailed(string message)
    {
        var eventHandler = OnTaskFailed;

        if (eventHandler != null)
        {
            eventHandler(this, new MyTaskFailedEventArgs(message));
        }
    }

    public void DoTask1AsyncWithEvent(int input)
    {
        Task.Run(() =>
        {
            try
            {
                var result = DoTask1(input);
                RaiseOnTask1Completed(result);
            }
            catch (ArgumentOutOfRangeException ex)
            {
                RaiseOnTaskFailed(ex.Message);
            }
        });
    }
}

The reason we are using the Task.Run function is the fact that this is the easiest way to execute our function on a separate ThreadPool on windows runtime. We are just emulating the background operation with an async thread.

So now our usage for this class and its functions would be something like:

var newEventingClass = new EventingClass();
newEventingClass.OnTask1Completed += (se, args) => CustomEventSource.Log.Debug("Task1 Completed Event");
newEventingClass.OnTaskFailed += (se, args) => CustomEventSource.Log.Debug("Task1 Failed Event");

CustomEventSource.Log.Debug("Task1 Starting");
newEventingClass.DoTask1AsyncWithEvent(0);
Task.Delay(1000).Wait();
CustomEventSource.Log.Debug("Task1 Starting");
newEventingClass.DoTask1AsyncWithEvent(-1);

As a result of this execution we will have a log composed of:

2013-05-20 13:26:35:6462 Type: Verbose Id: 1 Message: ‘Here is the verbose message’
2013-05-20 13:26:35:6662 Type: Verbose Id: 1 Message: ‘Task1 Starting’
2013-05-20 13:26:36:6717 Type: Verbose Id: 1 Message: ‘Task1 Starting’
2013-05-20 13:26:37:6907 Type: Verbose Id: 1 Message: ‘Task1 Completed Event’
A first chance exception of type ‘System.ArgumentOutOfRangeException’ occurred in LocalStorage.exe
2013-05-20 13:26:39:2922 Type: Verbose Id: 1 Message: ‘Task1 Failed Event’

Great, we have an asynchronous pattern implemented using events. We can now move forward using some of the asynchronous API features.

Converting Events to Awaitables (TaskCompletionSource<T>)

One of the most useful features from the async framework is the TaskCompletionSource. Using the task awaiter developers can easily convert legacy async event implementations to awaitables. So in our example, we can actually write an additional method in our wrapper class to convert the execution for Task 1 to an awaitable.

 private Task<int> ExecuteTask1(int input)
{
    var newEventingClass = new EventingClass();

    var myTaskSource = new TaskCompletionSource<int>();

    // Subscribe to TaskCompleted: When the Task1Completed event is fired, set result.
    newEventingClass.OnTask1Completed += (sender, args) => myTaskSource.SetResult(args.Result);

    // Subscribe to TaskFailed: If there is an error in the execution, set error.
    newEventingClass.OnTaskFailed += (sender, args) => myTaskSource.SetException(new Exception(args.Message));

    // Finally execute the task and return the associated Task promise.
    newEventingClass.DoTask1AsyncWithEvent(input);

    return myTaskSource.Task;
}

As you notice from the comments, you have two main actions with the task completion source. On a successful call we set the result, on a failed call, we set the error / exception. And to actually call our method now, we can use all the features in an async awaitable call:

CustomEventSource.Log.Debug("Task1 Starting");
var taskResult = await ExecuteTask1(0);
CustomEventSource.Log.Debug("Task1 Completed");

Task.Delay(1000).Wait();

try
{
    CustomEventSource.Log.Debug("Task1 Starting");
    var errorTaskResult = await ExecuteTask1(-1);
}
catch (Exception ex)
{
    CustomEventSource.Log.Debug("Task1 Failed");
}

And as before, if we look at the log entries:

2013-05-20 13:43:47:8964 Type: Verbose Id: 1 Message: ‘Task1 Starting’
2013-05-20 13:43:49:9376 Type: Verbose Id: 1 Message: ‘Task1 Completed’
2013-05-20 13:43:50:9489 Type: Verbose Id: 1 Message: ‘Task1 Starting’
A first chance exception of type ‘System.ArgumentOutOfRangeException’ occurred in LocalStorage.exe
A first chance exception of type ‘System.Exception’ occurred in mscorlib.dll
2013-05-20 13:43:53:6639 Type: Verbose Id: 1 Message: ‘Task1 Failed’

Voilà! We converted the event based async implementation to an awaitable method.

Converting Event Pattern to Async Pattern (Task<T>>)

In the previous example, we refrained from changing the EventingClass. This class was maybe a legacy implementation, or there was quite a big amount of business logic implemented and it would be troublesome to implement awaitables.

However, what if you have access to EventingClass and the energy to rewrite the public access methods. In this case, let us get rid of all event related implementations and just deal with our async implementation.

public class EventingClass
{
    public Task<int> DoTask1AsyncWithTask(int input)
    {
        return Task.Run(() => DoTask1(input));
    }

    private int DoTask1(int input)
    {
        int result;

        // Emulating the long running task
        Task.Delay(2000).Wait();

        if (input < 0)
        {
            throw new ArgumentOutOfRangeException("input", "Input parameter cannot be smaller than 0");
        }

        result = input + 1;

        return result;
    }
}

Our long running DoTask1 method is now executed as an awaitable. And just like in the previous example, you can call it with a simple try catch block.

Chaining / Batching Tasks (ContinueWith / WhenAll / WhenAny)

Let us now assume, we have three tasks (i.e. Task1, Task2, Task3), all receiving an input parameter of integer type and returning integer. Moreover, let’s assume we have to write a function that executes all of these methods in an awaitable fashion.

For this scenario, we set the following synchronous methods to be executed.

private int DoTask1(int input)
{
    CustomEventSource.Log.Debug("Task1 Starting");

    int result;

    // Emulating the long running task
    Task.Delay(2000).Wait();

    result = input + 1;

    CustomEventSource.Log.Debug("Task1 Completed");

    return result;
}

private int DoTask2(int input)
{
    CustomEventSource.Log.Debug("Task2 Starting");

    int result;
    Task.Delay(3000).Wait();
    result = input + 2;

    CustomEventSource.Log.Debug("Task2 Completed");
    return result;
}

private int DoTask3(int input)
{
    CustomEventSource.Log.Debug("Task3 Starting");

    int result;
    Task.Delay(4000).Wait();
    result = input + 3;

    CustomEventSource.Log.Debug("Task3 Completed");

    return result;
}

If we were using the old eventing implementation we would have to chain the callbacks in the Completed events for each of these methods and handle the error. However with the ContinueWith<T> callback implementation we can easily chain these methods and have an awaitable parent function:

public Task<int> DoTasksAll(int input)
{
    var task1 = Task.Run(() => DoTask1(input));

    var task2 = task1.ContinueWith(task => DoTask2(task.Result));
            
    var task3 = task2.ContinueWith(task => DoTask3(task.Result));

    return task3;
}

And when we call this method from our UI thread with an “await”, our log would show a result similar to (i.e. let’s say the initial input was 0):

2013-05-20 14:43:06:7226 Type: Verbose Id: 1 Message: ‘Here is the verbose message’
2013-05-20 14:43:06:7246 Type: Verbose Id: 1 Message: ‘TaskAll Starting’
2013-05-20 14:43:06:7336 Type: Verbose Id: 1 Message: ‘Task1 Starting’
2013-05-20 14:43:08:7439 Type: Verbose Id: 1 Message: ‘Task1 Completed’
2013-05-20 14:43:08:7459 Type: Verbose Id: 1 Message: ‘Task2 Starting’
2013-05-20 14:43:11:7609 Type: Verbose Id: 1 Message: ‘Task2 Completed’
2013-05-20 14:43:11:7649 Type: Verbose Id: 1 Message: ‘Task3 Starting’
2013-05-20 14:43:15:7660 Type: Verbose Id: 1 Message: ‘Task3 Completed’
2013-05-20 14:43:15:7680 Type: Verbose Id: 1 Message: ‘TaskAll Completed with result: 6’

In addition to ContinueWith, you are also equipped with functions like WhenAll and WhenAny. These functions are pretty self-explanatory. And the usage pattern would look something similar to the function declaration below if these tasks we have were mutually exclusive.

public Task<int[]> DoTasksAllBatch(int input)
{
    return Task.WhenAll(
        Task.Run(() => DoTask1(input)), 
        Task.Run(() => DoTask2(input)), 
        Task.Run(() => DoTask3(input)));
}

Notice the return values is an array of results we would get from the parallel execution of these tasks. So the log we would see from calling this method would be:

2013-05-20 14:54:00:2678 Type: Verbose Id: 1 Message: ‘TaskAllBatch Starting’
2013-05-20 14:54:00:2798 Type: Verbose Id: 1 Message: ‘Task1 Starting’
2013-05-20 14:54:00:2838 Type: Verbose Id: 1 Message: ‘Task2 Starting’
2013-05-20 14:54:00:2848 Type: Verbose Id: 1 Message: ‘Task3 Starting’
2013-05-20 14:54:02:2899 Type: Verbose Id: 1 Message: ‘Task1 Completed’
2013-05-20 14:54:03:3211 Type: Verbose Id: 1 Message: ‘Task2 Completed’
2013-05-20 14:54:04:3178 Type: Verbose Id: 1 Message: ‘Task3 Completed’
2013-05-20 14:54:04:3198 Type: Verbose Id: 1 Message: ‘TaskAllBatch Completed with result: 1,2,3’

If you look at the time codes, each task started at the same time and the final completion is fired when each of them completed.

I guess this is more than enough for today. In the next post we will be talking about Progress, Cancellation and the other async features of windows runtime.

Happy coding everyone….

Image UserControl with FadeIn & FadeOut Animation for WinRT

One of the main design principles of Metro and Windows Store Apps is to make the UI as responsive as possible while maintaining the smooth transition effects in response to working threads.

For finished control implementation, please scroll to the bottom, unless you want to read a little more about the transitions and animations used for the control.

Following these two basic statements, we will try to solve a very common problem about using web resources in windows runtime. For this scenario, let’s assume we are working on an application that is supposed to visualize a certain dataset that is downloaded from a network source. In this dataset, let us again assume we have certain URIs that we want to use as a source to content images. The best solution for displaying a smooth layout while loading the images from this network source would be to set them to invisible until the image is loaded fully and then fade them in using a transition. (e.g. You can see a concrete example in the Bing app while it is opening the search results and loading the images)

This is not an uncommon problem and if we were dealing with WPF, we could easily deal with this using triggers.

<Style x:Key="StyleImageFadeIn" TargetType="{x:Type Image}">
    <Setter Property="Opacity" Value="0" />
    <Style.Triggers>
        <!--Sets visibility to Collapsed if Source is null - this will cause IsVisible to be false-->
        <Trigger Property="Source" Value="{x:Null}">
            <Setter Property="Visibility" Value="Collapsed" />
        </Trigger>
        <!--Fades-in the image when it becomes visible-->
        <Trigger Property="IsVisible" Value="True">
            <Trigger.EnterActions>
                <BeginStoryboard>
                    <BeginStoryboard.Storyboard>
                        <Storyboard>
                            <DoubleAnimation Storyboard.TargetProperty="Opacity" To="1" Duration="0:0:1"/>
                        </Storyboard>
                    </BeginStoryboard.Storyboard>
                </BeginStoryboard>
            </Trigger.EnterActions>
        </Trigger>
    </Style.Triggers>
</Style>

Beautiful, so the image is collapsed when the Source is set to null. When it becomes visible, meaning when the source is set, we nicely fade it in.

BUT… Where are the triggers in WinRT and Windows Store Apps. The answer is: “They are gone”. However, we have the new, let’s say, “packaged” version of some commonly used animations such as “EntranceThemeTransition”, “RepositionThemeTransition” etc. These “packaged” transitions can be easily included in the transitions property of the framework elements. However, these are render transitions and it would not help us in our quest to load the image from the network source and fade it in, because in most cases the render transition would actually be played before the network resource is actually loaded.

We can go ahead and use the Image controls ImageOpened property and deal with the animation on the page’s implementation but we want a more compact solution that can easily be reused in our other projects.
So let’s try to implement a user control. First thing we do is to create a grid and add an image control in it. We also need to declare the fade-in animation and possibly fade-out animations for the image.

<UserControl
    x:Class="Samples.ImagePreview"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    mc:Ignorable="d" x:Name="ControlRoot" d:DesignHeight="300" d:DesignWidth="400">
    <Grid>
        <Image x:Name="Image" Source=" " Height="{Binding ElementName=ControlRoot, Path=ActualHeight}" Width="{Binding ElementName=ControlRoot, Path=ActualWidth}" />
        <Grid.Resources>
            <Storyboard x:Name="ImageFadeOut">
                <FadeOutThemeAnimation Storyboard.TargetName="Image" />
            </Storyboard>
            <Storyboard x:Name="ImageFadeIn">
                <FadeInThemeAnimation Storyboard.TargetName="Image" />
            </Storyboard>
        </Grid.Resources>
    </Grid>
</UserControl>

Notice that instead of using a standard DoubleAnimation on opacity we are using the FadeInThemeAnimation and the FadeOutThemeAnimation.

Next let’s declare a dependency property for the image source and another one for a placeholder (just in case).

public static readonly DependencyProperty SourceProperty =
    DependencyProperty.Register("Source", typeof(ImageSource), typeof(ImagePreview),
        new PropertyMetadata(default(ImageSource), SourceChanged));

public static readonly DependencyProperty PlaceHolderProperty =
    DependencyProperty.Register("PlaceHolder", typeof(ImageSource), typeof(ImagePreview),
    new PropertyMetadata(default(ImageSource)));

public ImageSource Source
{
    get { return (ImageSource)GetValue(SourceProperty); }
    set { SetValue(SourceProperty, value); }
}

public ImageSource PlaceHolder
{
    get { return (ImageSource)GetValue(PlaceHolderProperty); }
    set { SetValue(PlaceHolderProperty, value); }
}

So at first the PlaceHolder will be set as the source for the image control, and once the actual source is bound and loaded we can fadeout the placeholder and fade the actual image in. This process of fading out the placeholder and setting the source to the loaded image would look something like:

private void LoadImage(ImageSource source)
{
    ImageFadeOut.Completed += (s, e) =>
    {
        Image.Source = source;
        ImageFadeIn.Begin();
    };
    ImageFadeOut.Begin();
}

Once the Image control that is showing the placeholder, or another source as for that matter, is faded out, we can change the source and fade the control back in.

So only thing left to implement is a method to download the image from the network source when the bound Source is actually changed. (i.e. Notice in the dependency property declaration we already declared a callback for SourceChanged.)

private static void SourceChanged(DependencyObject dependencyObject, DependencyPropertyChangedEventArgs dependencyPropertyChangedEventArgs)
{
    var control = (ImagePreview)dependencyObject;
    var newSource = (ImageSource) dependencyPropertyChangedEventArgs.NewValue;

    System.Diagnostics.Debug.WriteLine("Image source changed: {0}", ((BitmapImage)newSource).UriSource.AbsolutePath);

    if(newSource != null)
    {
        var image = (BitmapImage) newSource;

        // If the image is not a local resource or it was not cached
        if (image.UriSource.Scheme != "ms-appx" && image.UriSource.Scheme != "ms-resource" && (image.PixelHeight * image.PixelWidth == 0))
        {
            // TODO:
            control.DownloadImageAsync(newSource);
        }
        else
        {
            control.LoadImage(newSource);
        }
    }
}

This implemented method is doing the usual checks, if it is a local resource it is just loading the image directly with a fade-in, if it is a remote resource, it is calling the method DownloadImageAsync (which we haven’t implemented and will not have to), which, in short, “downloads” the image as a Random Access Stream, loads it into a BitmapImage and assigns it to the image control with LoadImage method.
However, if we go down this road, you will notice that every time we open the same page with our control on it, the images will be fading in and out. Normally, when an image is opened with an image control, (unless instructed otherwise) windows runtime creates a cached version for this image data. Under normal circumstances, we would want to make use of this image caching.

The easiest option would be to create a secondary image control in the UserControl grid which will be used to load the image for the first time, and then once it is loaded assign it to the actual element. Using this “staging” element we can make use of the image caching and have a reusable control.

Below is the completed sample.

Happy coding everyone…

Finished Control

XAML:

<Grid>
    <Image x:Name="Staging" Visibility="Collapsed"/>
    <Image x:Name="Image" Source="{Binding ElementName=ControlRoot, Path=PlaceHolder}" Height="{Binding ElementName=ControlRoot, Path=ActualHeight}" Width="{Binding ElementName=ControlRoot, Path=ActualWidth}" />
    <Grid.Resources>
        <Storyboard x:Name="ImageFadeOut">
            <FadeOutThemeAnimation Storyboard.TargetName="Image" />
        </Storyboard>
        <Storyboard x:Name="ImageFadeIn">
            <FadeInThemeAnimation Storyboard.TargetName="Image" />
        </Storyboard>
    </Grid.Resources>
</Grid>

And the C# implementation:

public sealed partial class ImagePreview : UserControl
{
    public static readonly DependencyProperty SourceProperty =
        DependencyProperty.Register("Source", typeof(ImageSource), typeof(ImagePreview),
            new PropertyMetadata(default(ImageSource), SourceChanged));

    public static readonly DependencyProperty PlaceHolderProperty =
        DependencyProperty.Register("PlaceHolder", typeof(ImageSource), typeof(ImagePreview),
        new PropertyMetadata(default(ImageSource)));

    public ImageSource Source
    {
        get { return (ImageSource)GetValue(SourceProperty); }
        set { SetValue(SourceProperty, value); }
    }

    public ImageSource PlaceHolder
    {
        get { return (ImageSource)GetValue(PlaceHolderProperty); }
        set { SetValue(PlaceHolderProperty, value); }
    }

    public ImagePreview()
    {
        this.InitializeComponent();
    }

    private static void SourceChanged(DependencyObject dependencyObject, DependencyPropertyChangedEventArgs dependencyPropertyChangedEventArgs)
    {
        var control = (ImagePreview)dependencyObject;
        var newSource = (ImageSource) dependencyPropertyChangedEventArgs.NewValue;

        System.Diagnostics.Debug.WriteLine("Image source changed: {0}", ((BitmapImage)newSource).UriSource.AbsolutePath);
            

        if(newSource != null)
        {
            var image = (BitmapImage) newSource;

            // If the image is not a local resource or it was not cached
            if (image.UriSource.Scheme != "ms-appx" && image.UriSource.Scheme != "ms-resource" && (image.PixelHeight * image.PixelWidth == 0))
            {
                image.ImageOpened += (sender, args) => control.LoadImage(image);
                control.Staging.Source = image;
            }
            else
            {
                control.LoadImage(newSource);
            }
        }
    }

    private void LoadImage(ImageSource source)
    {
        ImageFadeOut.Completed += (s, e) =>
        {
            Image.Source = source;
            ImageFadeIn.Begin();
        };
        ImageFadeOut.Begin();
    }
}

Dynamic Tile Background Provider

Code Sample: Dynamic Tile Update Example with IIS Handler

To create lively-er tiles, the developers generally choose to use different web content images to send with the notification updates. Otherwise, if you want to use images from the package, they should be static content included among the package resources. This would be first of all limiting and secondly it would have an adverse effect of the package size (you might even hit the package limit if you really want to have diverse images).

When you send a tile update to windows store app client (either using the TileUpdateManager from the client itself, or using the Windows Notification Services), the tile notification content (i.e. xml content) is processed by the windows runtime and the best tile template is chosen according to the current tile used by the application. (i.e. Wide or Square).

<tile>
  <visual version="1">
    <binding template="TileWideImageAndText01">
      <image id="1" src="http://localhost:49183/Assets/TileLightWide.png" />
      <text id="1">This tile notification uses web images.</text>
    </binding>
    <binding template="TileSquareImage">
      <image id="1" src="http://localhost:49183/Assets/TileLight.png" />
    </binding>
  </visual>
</tile>

So you would have to send at least two images in a visual element to get the content right. (Notice the src attribute of the image nodes)

Left – Wide Tile Template, Right – Square Tile Template

The content (i.e. the image) would normally be scaled to fit the live tile but windows runtime cannot possibly handle different aspect ratios and the rescaling of the image in most cases would give bad results. (e.g. images from news articles can be quite large, and the resulting tile would not be pleasing)

To solve this problem, you can easily implement a server side component that could pre-process the image that is to be send to the windows store app client. The meaning of “Pre-process”  can vary from selecting a static content to feed to constructing the image on the fly. The http handler would use the the parameters that are passed on by the tile update content.

In this example we will be dealing with two parameters:

1) Size: determines if the image return should be for square tile or wide tile

2) Type: determines if the background should be black or white.

So we start by creating an ASP.NET handler that will take two query parameters:

public class TileImageHandler : IHttpHandler
{
    ///
    /// You will need to configure this handler in the Web.config file of your
    /// web and register it with IIS before being able to use it. For more information
    /// see the following link: http://go.microsoft.com/?linkid=8101007

    #region IHttpHandler Members

    public bool IsReusable
    {
        // Return false in case your Managed Handler cannot be reused for another request.
        // Usually this would be false in case you have some state information preserved per request.
        get { return true; }
    }

    public void ProcessRequest(HttpContext context)
    {
        var imageType = context.Request.QueryString["type"];

        // You can essentially extend the parameters that you are using to customize the image more
        var imageSize = context.Request.QueryString["size"];

        //... Further processing
    }

    #endregion
}

These query parameters will determine what the server is going to return to client as content. In this example, we will be just reading the existing static content and pushing it to the response stream setting the content according to the parameters.

//... Image Processing

var imageSizeSuffix = imageSize == "Wide" ? imageSize : string.Empty;

var imagePath = string.Empty;

// We are using actual images to write to the stream but you can develop an image generator
// and generate the images on the fly.
switch (imageType)
{
    case "Dark":
        imagePath = context.Server.MapPath(String.Format("~/Assets/TileDark{0}.png", imageSizeSuffix));
        break;
    case"Light":
        imagePath = context.Server.MapPath(String.Format("~/Assets/TileLight{0}.png", imageSizeSuffix));
        break;
}

context.Response.ContentType = "image/png";
context.Response.StatusCode = 200;

context.Response.WriteFile(imagePath);

//...

The next step is to prepare the web.config file so the calls for a specific piece of content will be handled by our handler.

<configuration>
    <system.web>
        <compilation debug="true" targetFramework="4.5" />
        <httpRuntime targetFramework="4.5" />
    
        <!-- For classic application pool -->
        <!--<httpHandlers>
            <add verb="*" path="SquareTile.png" 
                type="TileProvider.TileImageHandler, TileProvider "/>
        </httpHandlers>-->
    </system.web>
    <system.webServer>
        <handlers>
            <add name="TileHandler" verb="*" path="SquareTile.png" 
                type="TileProvider.TileImageHandler, TileProvider "/>
        </handlers>
    </system.webServer>
</configuration>

And finally we implement the tile update manager function that prepares the visual with the desired parameters.

private void SendTileUpdate(string type)
{
    // Note: This sample contains an additional project, NotificationsExtensions.
    // NotificationsExtensions exposes an object model for creating notifications, but you can also
    // modify the strings directly. See UpdateTileWithWebImageWithStringManipulation_Click for an example

    // Create notification content based on a visual template.
    ITileWideImageAndText01 tileContent = TileContentFactory.CreateTileWideImageAndText01();

    tileContent.TextCaptionWrap.Text = "This tile notification uses web images.";

    // !Important!
    // The Internet (Client) capability must be checked in the manifest in the Capabilities tab
    // to display web images in tiles (either the http:// or https:// protocols)

    tileContent.Image.Src = string.Format("http://localhost:49183/SquareTile.png?type={0}&size=Wide", type);
    tileContent.AddImageQuery = false;

    // Users can resize tiles to square or wide.
    // Apps can choose to include only square assets (meaning the app's tile can never be wide), or
    // include both wide and square assets (the user can resize the tile to square or wide).
    // Apps cannot include only wide assets.

    // Apps that support being wide should include square tile notifications since users
    // determine the size of the tile.

    // Create square notification content based on a visual template.
    ITileSquareImage squareContent = TileContentFactory.CreateTileSquareImage();

    squareContent.Image.Src = string.Format("http://localhost:49183/SquareTile.png?type={0}", type);
    squareContent.AddImageQuery = false;

    // include the square template.
    tileContent.SquareContent = squareContent;

    // send the notification to the app's application tile
    TileUpdateManager.CreateTileUpdaterForApplication().Update(tileContent.CreateNotification());

    OutputTextBlock.Text = CleanPrint(tileContent.GetContent());
}

And this is it, we have an asp.net handler that provides tile backgrounds for the metro app using different parameters.

Happy coding everyone…

Simple AES (Symmetric Key) Encryption in WinRT

Symmetric key encryption, also called secret key encryption, requires that the key used for encryption also be used for decryption. You can use a SymmetricKeyAlgorithmProvider object to specify a symmetric algorithm and create or import a key. You can use static methods on the CryptographicEngine class to encrypt and decrypt data by using the algorithm and key.

Under normal circumstances on top of the encryption key used, you would need to send vector values which is used as the initialization vector. However, for a simple scenario (e.g. you want to send a password value from the client to the server or vice-versa, and you don’t want to do a post with clear-text). You wouldn’t go through the trouble of carrying the IV buffer to the client side as well.

So here is a simple implementation that uses the AES encryption with ECB cipher mode and PKCS7 padding (PKCS #7 algorithms automatically pads the message to an appropriate length, so you don’t need to pad the cipher to a multiple of the block-size of the encryption algorithm you are using)

First step is to implement an MD5 hash generator which will be use to compute a hash from the encryption key that is being used.

private static IBuffer GetMD5Hash(string key)
{
    // Convert the message string to binary data.
    IBuffer buffUtf8Msg = CryptographicBuffer.ConvertStringToBinary(key, BinaryStringEncoding.Utf8);

    // Create a HashAlgorithmProvider object.
    HashAlgorithmProvider objAlgProv = HashAlgorithmProvider.OpenAlgorithm(HashAlgorithmNames.Md5);

    // Hash the message.
    IBuffer buffHash = objAlgProv.HashData(buffUtf8Msg);

    // Verify that the hash length equals the length specified for the algorithm.
    if (buffHash.Length != objAlgProv.HashLength)
    {
        throw new Exception("There was an error creating the hash");
    }

    return buffHash;
}

Once the key material is ready to be used to generate the symmetric key, we can go on with the encryption.

/// <summary>
/// Encrypt a string using dual encryption method. Returns an encrypted text.
/// </summary>
/// <param name="toEncrypt">String to be encrypted</param>
/// <param name="key">Unique key for encryption/decryption</param>m>
/// <returns>Returns encrypted string.</returns>
public static string Encrypt(string toEncrypt, string key)
{
    try
    {
        // Get the MD5 key hash (you can as well use the binary of the key string)
        var keyHash = GetMD5Hash(key);

        // Create a buffer that contains the encoded message to be encrypted.
        var toDecryptBuffer = CryptographicBuffer.ConvertStringToBinary(toEncrypt, BinaryStringEncoding.Utf8);

        // Open a symmetric algorithm provider for the specified algorithm.
        var aes = SymmetricKeyAlgorithmProvider.OpenAlgorithm(SymmetricAlgorithmNames.AesEcbPkcs7);

        // Create a symmetric key.
        var symetricKey = aes.CreateSymmetricKey(keyHash);

        // The input key must be securely shared between the sender of the cryptic message
        // and the recipient. The initialization vector must also be shared but does not
        // need to be shared in a secure manner. If the sender encodes a message string
        // to a buffer, the binary encoding method must also be shared with the recipient.
        var buffEncrypted = CryptographicEngine.Encrypt(symetricKey, toDecryptBuffer, null);

        // Convert the encrypted buffer to a string (for display).
        // We are using Base64 to convert bytes to string since you might get unmatched characters
        // in the encrypted buffer that we cannot convert to string with UTF8.
        var strEncrypted = CryptographicBuffer.EncodeToBase64String(buffEncrypted);

        return strEncrypted;
    }
    catch (Exception ex)
    {
        // MetroEventSource.Log.Error(ex.Message);
        return "";
    }
}

The decryption function is not any different in this case except for the fact that you would need to use Base64 conversion to convert the encrypted cipher to a buffer.

/// <summary>
/// Decrypt a string using dual encryption method. Return a Decrypted clear string
/// </summary>
/// <param name="cipherString">Encrypted string</param>
/// <param name="key">Unique key for encryption/decryption</param>
/// <returns>Returns decrypted text.</returns>
public static string Decrypt(string cipherString, string key)
{
    try
    {
        // Get the MD5 key hash (you can as well use the binary of the key string)
        var keyHash = GetMD5Hash(key);

        // Create a buffer that contains the encoded message to be decrypted.
        IBuffer toDecryptBuffer = CryptographicBuffer.DecodeFromBase64String(cipherString);

        // Open a symmetric algorithm provider for the specified algorithm.
        SymmetricKeyAlgorithmProvider aes = SymmetricKeyAlgorithmProvider.OpenAlgorithm(SymmetricAlgorithmNames.AesEcbPkcs7);

        // Create a symmetric key.
        var symetricKey = aes.CreateSymmetricKey(keyHash);

        var buffDecrypted = CryptographicEngine.Decrypt(symetricKey, toDecryptBuffer, null);

        string strDecrypted = CryptographicBuffer.ConvertBinaryToString(BinaryStringEncoding.Utf8, buffDecrypted);

        return strDecrypted;
    }
    catch (Exception ex)
    {
        // MetroEventSource.Log.Error(ex.Message);
        //throw;
        return "";
    }
}

And there it goes, a simple symmetric key encryption ready to be used in Windows Store Apps (aka Metro).

Happy coding everyone…

Drawing / Inking API in WinRT (C#) – II

Code Sample: Windows 8 Input: Ink sample in C#/Xaml

In the previous part of this series, we talked about how to use efficiently the inking namespace in WinRT. As you may recall the main component in this drawing adventure was InkManager. In this part of the series, we will be talking about how we can save the strokes to an image file and later on load and render these stokes.

Saving the Ink Stokes

In WinRT API, the only function that InkManager exponses for saving strokes is the SaveAsync method. This might be quite disappointing for most since in good old silverlight, one could easily load an InkPresenter to WriteableBitmap and manupulate it as he/she wants.

try
{
    Windows.Storage.Pickers.FileSavePicker save = new Windows.Storage.Pickers.FileSavePicker();
    save.SuggestedStartLocation = Windows.Storage.Pickers.PickerLocationId.Desktop;
    save.DefaultFileExtension = “.png”;
    save.FileTypeChoices.Add(“PNG”, new string[] { “.png” });
    StorageFile filesave = await save.PickSaveFileAsync();

    using (IOutputStream fileStream = await filesave.OpenAsync(FileAccessMode.ReadWrite))
    {
        if (fileStream != null)
        {
            await m_InkManager.SaveAsync(fileStream);
        }
    }
}
catch (Exception ex)
{
    var dialog = new MessageDialog(ex.Message);
    dialog.ShowAsync();
}

In this implementation we are using a FileSavePicker to create a file, but we could as well use an InMemoryRandomAccessStream. Using the memory stream also help you to display the image in an Image control right away. (e.g. You might want to preview the image that is drawn in a smaller size.)

Loading the Ink Strokes

When the ink strokes are serialized into an image file, you as well load these strokes back to an InkManager and also use them to render the image for further editing perhaps..

using (IRandomAccessStream stream = await storageFile.OpenAsync(Windows.Storage.FileAccessMode.Read))
{
    await m_InkManager.LoadAsync(stream);

    if (m_InkManager.GetStrokes().Count > 0)
    {
        // RenderStrokes();
    }
}

You could possibly use the same render function that was outlined on the previous article.

Further Implementation

The saving of the ink strokes creates a rectangle that is only a small cutout from the whole canvas. (e.g. Canvas.ActualWidth = InkManager.BoundingRectangle.Left + InkManager.BoundingRectangle.Width + InkManager.BoundingRectangle.Right) Still trying to figure out how to include the whole canvas area in the image that is saved.

The main reason for this cropped version of the canvas is the fact that even though we are saving the stokes to a “PNG” file (and the microsoft version uses “GIF”), the file is actually in ISF format (*.isf). You can as well rename the extension to .isf and open the image file with paint and save it as “*.png”. You will notice that the magic number change on the file binary and the file size change.

UPDATE: Next post in the series about updating the solution and using the Select/Copy/Paste features.

Good luck everyone, happy coding.