NancyFX authentication for REST API

NancyFX is a great .NET framework well suited for creating REST APIs. There are many ways how to approach authentication, the simplest one is the good old Forms Authentication. The idea of Forms Authentication is that the user logs in with a username and password and gets a cookie, the protected endpoints then check the cookie. NancyFX supports Forms Authentication with the Nancy.Authentication.Forms package. The documentation describes how to use it on a web page, but to use it with a REST API a few changes are needed.

Forms Authentication differences for REST API

There are things you want to do differently in a REST API than on a web page. If a user tries to access a protected endpoint, the Forms Authentication on a normal web page redirects him to the login page. In REST API, you typically want the endpoint just to return HTTP 401, no redirects. Also, when a user successfully logs in, you just typically want to return HTTP 200, no redirects.

[Read More]

Changing the PivotItem header color in Windows Phone 8.1 XAML

Windows Phone 8.1 XAML contains a Pivot control that looks like the one from Windows Phone 78 and also should behave the same way, but does not. You will find the first problem with the new Pivot when you want to change the PivotItem header color.

Windows Phone 78

If you want to change the PivotItem header color in Windows Phone 78, you just define the color in the Header template:

  <TextBlock Text="{Binding}" Foreground="{StaticResource PhoneAccentBrush}"/> 

This works great, changing the color of the active PivotItem Header to the color you want and applying some opacity to the inactive PivotItem Headers.

[Read More]

Dialog helper for Universal Apps the easy way

Today I read Joost van Schaik’s blog post called A behavior to show a MessageDialog from a MVVMLight viewmodel in Universal apps–with callbacks. I am not a MVVMLight guy (I use Caliburn.Micro) and I personally use an approach that uses a little less code, employing a helper class.

Helper class

/// <summary>
/// Helper class for showing message dialogs
/// </summary>
public static class DialogHelper
    /// <summary>
    /// Shows a dialog with given message and ok/cancel buttons. 
    /// </summary>
    /// <param name="message">Message</param>
    /// <param name="title">Title</param>
    /// <param name="okText">OK text (optional)</param>
    /// <param name="cancelText">Cancel text (optional)</param>
    /// <returns>True if ok pressed, false otherwise</returns>
    public static async Task<bool> ShowMessageDialog(string message, string title, string okText, string cancelText)
        bool result = false;
        var dialog = new MessageDialog(message, title);

        if (!string.IsNullOrWhiteSpace(okText))
            dialog.Commands.Add(new UICommand(okText, cmd => result = true));

        if (!string.IsNullOrWhiteSpace(cancelText))
            dialog.Commands.Add(new UICommand(cancelText, cmd => result = false));

        await dialog.ShowAsync();            
        return result;

with a simple usage in ViewModel

[Read More]

Creating a fake splashscreen for your Universal App

Sometimes you may want your app to display the startup splashscreen a bit longer, so you can initialize or fetch some data necessary for the app to run. To achieve this, you can create a fake splaschreen, a View that looks just like the splashscreen, does all the work and redirects to the real main View afterwards.

In theory, it is quite simple:

  • Create a SplashScreenView with just the right background and the splashscreen image
  • Set the app to display SplashScreenView at startup
  • Do all the initializing and data fetching in SplashScreenViewModel and redirect to there real MainView

This works quite well with Windows 8.1, but on Windows Phone 8.1 there is a problem. When you run the Windows Phone 8.1 app, you will see a page transition happen between the real splashscreen and your SplashScreenView. This looks strange, so it is better to get rid of it.

[Read More]

Why Universal Apps as not as universal as you may think

I have been developing Windows Phone apps for a few years now, always sticking to Silverlight and keeping using Silverlight also after Microsoft announced the WinRT flavor of Windows Phone apps and the so called Universal Apps. The Windows Phone 8.0 and 8.1 Silverlight APIs have some limitations, but are now well known do not contain many bugs. They are the safe choice if you want to create a Windows Phone apps. And do not forget that there are still many device running Windows Phone 8 (like Verizon customers in the US) that never got the 8.1 updated promised to everyone during the summer.

Really universal?

Windows Phone 8.1 XAML and Universal Apps included WinRT APIs that have many problems, including some that there is no solution for. I used the WinRT APIs when creating first Windows 8 apps about 2 years ago, so I am not new to the APIs. I have not touched the WinRT APIs again until recently, because there was no demand for Windows 8 or Windows 8.1 apps. Why would it? People use Windows 8 or 8.1 but do not care about Metro apps, they give them no value compared to “normal” Win32 and Windows tablets are practically non-exists (expect for the Surface tablets owned by few programmers and maybe no one else).

[Read More]