Using the Xbox Music API in Universal Windows Apps

The Xbox Music API can be used by third party developers (i.e. you and me) to search for artists, songs, albums, etc and also get access to actually play songs.

There are two flavours at present: “unauthenticated” and “authenticated”.

Authenticated access allow playing of full songs and working with user playlists. Playlist changes will automatically roam to user’s other devices. The full access to play full songs requires that the user has an Xbox Music Pass.

Unauthenticated access doesn’t allow access to user playlists, and streaming of music is restrict to 30 second previews.

At present anyone can get unauthenticated access via the Xbox Music RESTful API on Azure Marketplace. Authenticated access is currently limited, you need to apply for the pilot program. I’ve applied for this, hopefully I’ll be accepted so I can understand this part better.

Getting Started with Unauthenticated Access

We need an access key to allow our apps to able to use the (unauthenticated) API. To do this follow these instructions to register and create an application in Azure Marketplace. Don’t worry about the code samples at the bottom of the post, there’s a client API we can use instead.

So now you should have an application registered (you might have to enter some web address in the redirect URI – I’m not sure what this is for at this point).

More...

Consuming Server-Side SignalR Events in Universal Windows App Clients

In a previous article I wrote about creating server side SignalR timer events.

As part of my learning of SignalR I wanted to see how easy it would be to create a Universal Windows app consuming these server side events.

So first off I created a new blank Universal app:

creating universal app in Visual Studio screenshot

 

Next installed the SignalR NuGet package into both app projects: install-package Microsoft.AspNet.SignalR.Client

In the Windows 8.1 Store app project XAML I added a simple bound TextBlock that will display the server messages:

<Page
    x:Class="UpTimeUni.MainPage"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:local="using:UpTimeUni"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    mc:Ignorable="d">

    <Grid Background="{ThemeResource ApplicationPageBackgroundThemeBrush}">
        <Viewbox>
            <TextBlock Text="{Binding Uptime}">please wait...</TextBlock>
        </Viewbox>
    </Grid>
</Page>

I also added similar XAML in the Windows Phone 8.1 main page.

More...

Using Server Side Timers and SignalR in ASP.NET MVC Applications

I thought it would be fun to create an “Internet uptime” page that you can see live here on Azure Websites. It shows how long the Internet (since ARPANET) has been around for.

image

Creating a Class that can be Managed by ASP.NET

The HostingEnvironment.RegisterObject method can be used to register an instance of an object that has its lifetime managed by the hosting environment.

To register an object it must implement the IRegisteredObject interface.

This interface defines a Stop method which gets called when ASP.NET needs to shutdown the app domain.

So, in the application start we can create an instance of our class and register it:

protected void Application_Start()
{
    AreaRegistration.RegisterAllAreas();
    RouteConfig.RegisterRoutes(RouteTable.Routes);

    HostingEnvironment.RegisterObject(new BackgroundUptimeServerTimer());
}

Creating a SignalR Hub to Send Messages from the Server to Client

Next we create a SignalR hub and the HTML.

So the hub class is called UptimeHub:

public class UptimeHub : Hub
{
}

We can get the server to call a client JavaScript method called “internetUpTime” in the HTML page and have this client code display the what’s been sent from the server timer.

The following shows the complete HTML for the page. Notice the “hub.client.internetUpTime = function (time) …” this function will get executed every time our server timer event fires.

More...

Vertically Center Div in Browser Window using Viewport-Relative Lengths

I found out about these units this week so I wanted to have a play with them.

The CSS units: vw, vh, vmin, and vmax allow sizes to be specified relative the the browser window size (or the “initial containing block”).

So 1 vw is equal to 1% of the viewport width and 1 vh is equal to 1% of the viewport height.

vmin and vmax return the smaller and larger respectively of vw or vh.

There is good support  for vw and vh in modern browsers with some partial support for vmax, overall about 55% of browsers offer full support, 20% partial support.

So for example to center a div vertically in the browser we could set its height to “50vh”  (50% of the viewport height) and set its top margin to be “25vh” (or a quarter of the viewport height), thus leaving a quarter below the div.

So here’s a screenshot of this in action in a tiny browser window (the white is the div):

image

And after resizing the browser:

More...

On Staying Positive and Subconscious Prejudices

So I was toying with an idea using SignalR on Azure.

In the client code:

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <title>Internet Uptime</title>
</head>
<body>   
    <script src="Scripts/jquery-1.6.4.min.js"></script>
    <script src="Scripts/jquery.signalR-2.1.0.min.js"></script>
    <script src="/signalr/hubs"></script>
        
    <script>
        $(function () {
            var hub = $.connection.uptimeHub;            

            $.connection.hub.start();           

            hub.client.internetUpTime = function (time) {
                $('body').text(time);
                
            };           
        });
    </script>    
</body>
</html>

So when the server sends  an “internetUpTime” message, the <body> is being set to the content of the string sent from the server.

More...

Say Goodbye to Boring INotifyPropertyChanged Implementation in Universal Windows Apps with Fody

We need to implement INotifyPropertyChanged to allow bindings to be updated. For example in a simple viewmodel to add 2 numbers:

namespace UniFodyDemo
{    
    internal class CalculatorViewModel : INotifyPropertyChanged
    {
        private ICommand _addCommand;
        private string _firstNumber;
        private string _secondNumber;

        public CalculatorViewModel()
        {
            FirstNumber = "5";
            SecondNumber = "10";
            Result = "";

            AddCommand = new RelayCommand(Add);
        }


        // Use strings to simplify demo code (so no val converter)
        public string FirstNumber
        {
            get { return _firstNumber; }
            set
            {
                _firstNumber = value;
                OnPropertyChanged();
            }
        }

        public string SecondNumber
        {
            get { return _secondNumber; }
            set
            {
                _secondNumber = value;
                OnPropertyChanged();
            }
        }

        public string Result { get; set; }

        public ICommand AddCommand
        {
            get { return _addCommand; }
            private set
            {
                _addCommand = value;
                OnPropertyChanged();
            }
        }

        public event PropertyChangedEventHandler PropertyChanged;

        private void Add(object obj)
        {
            var a = int.Parse(FirstNumber);
            var b = int.Parse(SecondNumber);

            Result = (a + b).ToString();
        }

        protected virtual void OnPropertyChanged([CallerMemberName] string propertyName = null)
        {
            var handler = PropertyChanged;
            if (handler != null) handler(this, new PropertyChangedEventArgs(propertyName));
        }
    }
}

There’s more code here than we’d need if we didn’t have to implement INotifyPropertyChanged. Really the important things are the 3 properties that we bind to and the add command / method.

The XAML in both the Windows Store app and Windows Phone app looks like:

<Grid Background="{ThemeResource ApplicationPageBackgroundThemeBrush}">
    <StackPanel Width="200">
        <TextBlock Text="{Binding FirstNumber, Mode=TwoWay}"></TextBlock>
        <TextBlock Text="{Binding SecondNumber, Mode=TwoWay}"></TextBlock>
        <Button Command="{Binding AddCommand}">Add</Button>
        <TextBlock Text="{Binding Result, Mode=TwoWay}"></TextBlock>
    </StackPanel>
</Grid>

Without implementing INotifyProperty changed, clicking the Add button won’t be of much use, we wont see the result.

The solution looks like the following, the shared project contains the viewmodel.

image

It would be great not have to write this same INotifyProperty stuff for everything we want to bind to/from. Using a NuGet package called PropertyChanged.Fody we can achieve this.

First this package needs to be installed into both the Windows Store and Windows Phone app projects. This is because the shared code in the viewmodel isn’t compiled in that shared project, rather the source code is compiled individually in both the Store/Phone projects.

Now the viewmodel can be simplified:

namespace UniFodyDemo
{
    [ImplementPropertyChanged]
    class CalculatorViewModel
    {
        public CalculatorViewModel()
        {
            FirstNumber = "5";
            SecondNumber = "10";
            Result = "";

            AddCommand = new RelayCommand(Add);
        }

        private void Add(object obj)
        {
            var a = int.Parse(FirstNumber);
            var b = int.Parse(SecondNumber);

            Result = (a + b).ToString();
        }
        

        // Use strings to simplify demo code (so no val converter)
        public string FirstNumber { get; set; }
        public string SecondNumber { get; set; }
        public string Result { get; set; }

        public ICommand AddCommand { get; private set; }
    }
}

Notice the [ImplementPropertyChanged] attribute which means INotifyPropertyChanged will be automatically implemented for us. Notice that it’s much easier to see what’s essential in the viewmodel without all the noise of INotifyPropertyChanged.

If we decompile the Windows store app we can see the implementation:

namespace UniFodyDemo
{
    internal class CalculatorViewModel : INotifyPropertyChanged
    {
        public ICommand AddCommand
        {
            get
            {
                return this.u003cAddCommandu003ek__BackingField;
            }
            private set
            {
                if (this.u003cAddCommandu003ek__BackingField == value)
                {
                    return;
                }
                this.u003cAddCommandu003ek__BackingField = value;
                this.OnPropertyChanged("AddCommand");
            }
        }

        public string FirstNumber
        {
            get
            {
                return this.u003cFirstNumberu003ek__BackingField;
            }
            set
            {
                if (String.Equals(this.u003cFirstNumberu003ek__BackingField, value, 4))
                {
                    return;
                }
                this.u003cFirstNumberu003ek__BackingField = value;
                this.OnPropertyChanged("FirstNumber");
            }
        }

        public string Result
        {
            get
            {
                return this.u003cResultu003ek__BackingField;
            }
            set
            {
                if (String.Equals(this.u003cResultu003ek__BackingField, value, 4))
                {
                    return;
                }
                this.u003cResultu003ek__BackingField = value;
                this.OnPropertyChanged("Result");
            }
        }

        public string SecondNumber
        {
            get
            {
                return this.u003cSecondNumberu003ek__BackingField;
            }
            set
            {
                if (String.Equals(this.u003cSecondNumberu003ek__BackingField, value, 4))
                {
                    return;
                }
                this.u003cSecondNumberu003ek__BackingField = value;
                this.OnPropertyChanged("SecondNumber");
            }
        }

        public CalculatorViewModel()
        {
            this.FirstNumber = "5";
            this.SecondNumber = "10";
            this.Result = "";
            this.AddCommand = new RelayCommand(new Action<object>(this, CalculatorViewModel.Add));
        }

        private void Add(object obj)
        {
            int num = Int32.Parse(this.FirstNumber);
            int num1 = Int32.Parse(this.SecondNumber);
            this.Result = (num + num1).ToString();
        }

        public virtual void OnPropertyChanged(string propertyName)
        {
            PropertyChangedEventHandler propertyChangedEventHandler = this.PropertyChanged;
            if (propertyChangedEventHandler != null)
            {
                propertyChangedEventHandler(this, new PropertyChangedEventArgs(propertyName));
            }
        }

        public event PropertyChangedEventHandler PropertyChanged;
    }
}

So not only with Universal projects can we share code via the shared code project, adding Fody into the mix is even more awesome.

For a list of available addins or to contribute (or even create your own addin) check out the GitHub project site.

Also to learn more about Fody feel free to check out my Pluralsight course.

FeatureToggle 2.2Released

Release 2.2 of FeatureToggle is now available via NuGet.

This release adds a single new toggle: HttpJsonFeatureToggle.

This toggle gets it's enabled state from a JSON HTTP endpoint.

Configuration should be the url where the JSON configuration lives, e.g:

<add key="FeatureToggle.HttpJsonTrueToggle" value="http://localhost:8084/api/test/getenabled" />

As with all the toggles, if url is not available then an exception will be raised, rather than assuming either enabled or disabled.

The expected JSON that should be returned is in the form:  {"enabled": true} or  {"enabled": false}

Documentation here.

I’m thinking the next major release will be Version 3, planned changes here.

On Showing Up

So I just listened to episode 1000 of .NET Rocks. I’ve been listening to this podcast for many years, through biting snow-covered walks in England to the cosseted comfort of an air-conditioned car in Australia when it’s 43C outside.

1000 episodes is an amazing achievement and it got me thinking.

There’s a lot of popular talk at the minute on advancing your career, becoming an outlier, and building a personal brand. The thing is there’s one underlying trait that successful people seem to possess: showing up.

"if the rope breaks nine times, we must splice it together a tenth time"

Fear is a big motivator, for the longest time (like so many other developers I’ve met) fear was present; fear of not knowing everything, fear of looking stupid, fear of not being able to find another job. For the most part I’ve let this fear fly away and one of the ways I think I’ve done this through persistence, thorough showing up.

I think if you take an approach of continuous personal improvement you will. Don’t be afraid to put yourself out into the world, whether this be blogs, user groups, Twitter, or lunchtime “brown bag” sessions presenting to your colleagues where you work.

There are always going to be people who criticize, but there are also always going to be people who say “thanks”.

There’s a Tibetan saying that “if the rope breaks nine times, we must splice it together a tenth time” – this is showing up, even when you feel you have nothing to contribute, are fearful of criticism, or feel like you can’t get anywhere – there are always choices, and showing up is one of them.

As Jim Carey says: “you can fail at what you don’t want, so you might as well take a chance on doing what you love”.

Custom FeatureToggle Implementations for Non-Continuous-Delivery Usages

My open source fetaure toggling library contains a number of prebuilt toggles for common things such as enabling a feature based on the date, or a configuration value.

It’s also easy to create custom toggles by implementing IFeatureToggle.

Up to now, FeatureToggle has mainly been an aid for continuous delivery; a “half done” feature can simply be configured off so it doesn’t appear in the UI.

I’m wondering if the following approach has merit, namely treating conditionally available features as a first class citizens. So this is not just using them for continuous delivery but to encapsulate actual features of the application.

The example below requires 3 NuGet packages:

  • FeatureToggle.Core
  • FeatureToggle.WPFExtensions
  • MVVMLight

So the feature in the application will restrict the availability of mature rated games to customers who are 18+.

First off the feature toggle:

using FeatureToggle.Core;

namespace CustomFeatureToggle
{
    class MatureTitleSelectionFeature : IFeatureToggle
    {       
        public MatureTitleSelectionFeature(Customer customer)
        {
            FeatureEnabled = customer.Age >= 18;
        }

        public bool FeatureEnabled { get; set; }
    }
}

Here the business logic is encapsulated in the feature toggle and can be tested.

Next the viewmodel:

class MainViewModel : ViewModelBase
{
    private Customer _selectedCustomer;
    private IFeatureToggle _matureTitlesFeature;
    private ObservableCollection<Customer> _customers;

    public MainViewModel()
    {
        Customers = new ObservableCollection<Customer>
                    {
                        new Customer {Name = "Sarah", Age = 32},
                        new Customer {Name = "Robert", Age = 17}
                    };

        SelectedCustomer = Customers[0];

        MatureTitlesFeature = new MatureTitleSelectionFeature(SelectedCustomer);
    }

    public ObservableCollection<Customer> Customers
    {
        get
        {
            return _customers;                 
        }
        set
        {
            _customers = value; 
            Set(() => Customers, ref _customers, value);                 
        }
    }

    public Customer SelectedCustomer
    {
        get
        {
            return _selectedCustomer;
        }
        set
        {
            _selectedCustomer = value;
            
            Set(() => SelectedCustomer, ref _selectedCustomer, value);

            MatureTitlesFeature = new MatureTitleSelectionFeature(SelectedCustomer);
        }
    }

    public IFeatureToggle MatureTitlesFeature
    {
        get
        {
            return _matureTitlesFeature;
        }
        set
        {
            _matureTitlesFeature = value;

            Set(() => MatureTitlesFeature, ref _matureTitlesFeature, value);
        }
    }
}

Here, every time the selected customer changes, a new (immutable) toggle is created based on the customer’s details, i.e. Age.

The visibility in the UI of mature titles is simple data binding, using a visibility convertor from FeatureToggle.WPFExtensions.

<Window x:Class="CustomFeatureToggle.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:toggles="clr-namespace:FeatureToggle.Toggles;assembly=FeatureToggle.WpfExtensions"
        Title="MainWindow" Height="350" Width="525">
    <Window.Resources>
        <toggles:FeatureToggleToVisibilityConverter x:Key="ToggleVisConverter"></toggles:FeatureToggleToVisibilityConverter>
    </Window.Resources>
    <Grid>
        <StackPanel>
            <ComboBox DisplayMemberPath="Name" 
                      ItemsSource="{Binding Customers, Mode=TwoWay}"
                      SelectedItem="{Binding SelectedCustomer}"></ComboBox>
            <TextBlock>All audience titles here</TextBlock>
            <TextBlock Visibility="{Binding MatureTitlesFeature, Converter={StaticResource ToggleVisConverter}, Mode=TwoWay}">Mature titles here</TextBlock>
        </StackPanel>
    </Grid>
</Window>

I’m wondering how this approach would scale out for larger apps.

screenshot showing mature visible

 

screenshot showing mature invisible