0 Comments

Black Metal Padlock

So lately I was playing around with one of Azure DevOps many features. Namely pushing freshly created NuGet packages to your private feed. Bringing up the question how can I access the feed and authenticate during a NuGet restore process via dotnet restore?

While this blog post shows steps to be taken for Azure DevOps - the same actions are required in the NuGet.config for other sources.

While I knew how to click my way around Visual Studio to do this. Under my Ubuntu Shell, this was not an option. Luckily adding a NuGet feed is quite common knowledge, while the paths differ under Windows and Unix systems you will find it in your home directory under:

~/.nuget/NuGet/NuGet.config

Or for Windows that would be:

%appdata%\NuGet\

You can add the feed to your NuGet.config file:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <packageSources>
        <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
        <add key="NameOfYourFeed" value="path to your nuget/index.json" />
    </packageSources>
</configuration>

Now for accessing a private NuGet feed, you will have to provide a username and password. You can add them to the config file:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <!-- packageSources -->
    <packageSourceCredentials>
        <NameOfYourFeed>
            <add key="Username" value="gnabber"/>
            <add key="ClearTextPassword" value="YourPassword"/>
        </NameOfYourFeed>
    </packageSourceCredentials>
</configuration>

The only issue being you probably do not want to store your Azure DevOps password in plain text on a computer. And you shouldn't do that either. So let's head back over to Azure DevOps, click on your profile picture and select "Security". Now generate a new token. Be sure to select "Show all scopes" then under Packaging choose the "Read" permissions.

Image showing the dialog to generate a token for readonly access to your package feed

Copy the generated token and store it in the NuGet.config within the PlainTextPassword field. You can now dotnet restore your packages from the private Package feed.

HTH

0 Comments

pexels-photo-292426

Whether writing a mobile app with Xamarin Forms or native Xamarin.iOS/Xamarin.Android sometimes the requirements demand that your app updates as quickly as possible when something changes on the server. This might be a chat application, stock ticker or any monitoring app showing live data to a user of a process currently running in the backend.

Let's say we wanted to create a simple chat app. If we would go down the path of a traditional Create Read Update Delete (CRUD) app over HTTP, we might choose to poll the server every few seconds or so to read the latest value. While this approach delivers the results, it comes with some drawbacks. To name a few: making requests even though nothing has changed, climbing the leader board on the battery usage category plus your server gets hammered with requests only to tell them: "Sorry no news yet..." - so if not poll lets push. And this is where WebSockets come in.

The only problem with WebSockets is that the implementation in .Net is close to the metal. This results in an additional implementation effort having to be done by the developers. Luckily for .Net developers, there is SignalR which comes with all the boilerplate code you want around WebSockets. A web developer will also tell you about fall back options backed into SingalR. As a Xamarin developer, you will most probably never use those features. But the chances are good that you will be delighted by the ease of handling connections, channels or writing to specific connected clients.

SignalR is around for quite a while; it has been ported over to .Net Core and is .Net Standard compatible. This is excellent news since we can add the SignalR client directly into our Xamarin Forms app - no platform-specific/wrapper code required. But before we can start implementing our client, we will first have to create a SignalR enabled backend.

If you are new to SignalR, be aware that there is quite a big difference between SignalR and SignalR Core. If you are writing a new app today using ASP.NET Core or Azure Functions. You will want to use SignalR Core or else you will go on a nasty error hunt ending with your palm slapping against your forehead ‍🤦‍♂️

The Server

When implementing the backend, we can choose between two options. Either we implement SignalR using ASP.NET Core, or we decide to go with Azures SignalR Core Service. The later can be integrated into ASP.NET Core or an Azure Function app. The Azure option also comes with scaling capabilities - in other words, you get up to 1 Million simultaneous connections using SignalR out of the box.

For more detail on how to set up the Azure Functions and SignalR combo, you will find instructions in the official documentation.

For our simple chat application, we will want a way for our clients to send and receive messages. To achieve this, we will have to create a SignalR Hub that provides a method for sending messages:

[FunctionName("SendMessage")]
public static Task SendMessage(
    [HttpTrigger(AuthorizationLevel.Anonymous, "post")]string message,
    [SignalR(HubName = "SignalRDemo")]IAsyncCollector<SignalRMessage> signalRMessages)
{
    return signalRMessages.AddAsync(
        new SignalRMessage
        {
            Target = "NewMessage",
            Arguments = new[] { message }
        });
}

On invocation, the method will send the message to all connected clients. Which brings us to our next point. Every chat participant will first have to connect to the hub so that messages can be received. So let's implement that registration method:

[FunctionName("Negotiate")]
public static SignalRConnectionInfo Negotiate(
[HttpTrigger(AuthorizationLevel.Anonymous)]HttpRequest req,
[SignalRConnectionInfo(HubName = "SignalRDemo")] SignalRConnectionInfo connectionInfo)
{
    // connectionInfo contains an access key token with a name identifier claim set to the authenticated user
    return connectionInfo;
}

The naming of the method is a convention from SignalR. In other words, you must name the method Negotiate, or your code will not work. No, I do not want to elaborate on how I found this one out the hard way 😉

With the function and SignalR Service in place, we can now turn our focus to the client.

The mobile client

On the mobile client, we want to be able to receive messages and type responses to the group. Our simple app will have to live with the limitation of only receiving messages while being connected. At least for the moment. But here is the chat running in all of its glory.

SignalRChat

Now let's have a look at the ChatService which connects us to the backend and receives messages:

public async Task Connect()
{
    if (_connection.State == HubConnectionState.Connected) return;

    _connection.On<string>("NewMessage", (messageString) =>
    {
        var message = JsonConvert.DeserializeObject<Message>(messageString);
        _newMessage.OnNext(message);
        Debug.WriteLine(messageString);
    });

    await _connection.StartAsync();
}

Note that we register the receiver method before we connect to the backend. This way, we start receiving updates as soon as being connected to the SignalR Service. Now when implementing a receiver method, you must ensure that the type signature matches the method we defined earlier on the server. If the types or the name do not match, you will never receive any messages.

Since reading is only half the fun, let's implement the send message:

public async Task Send(Message message)
{
    var serializedPayload = JsonConvert.SerializeObject(message);

    var response = await _httpClient.PostAsync("https://gnabbersignalr.azurewebsites.net/api/SendMessage", new StringContent(serializedPayload));
    Debug.WriteLine(await response.Content.ReadAsStringAsync());
}

And if you ever had enough from the stream of messages but want to give your eyes the joy of staring at a bare app here is the disconnect method:

public async Task Disconnect()
{
    await _connection.DisposeAsync();

    _connection = new HubConnectionBuilder()
        .WithUrl(backendUrl)
        .Build();
}

I hope you could see that using SignalR it is a breeze to implement a bidirectional communication layer to your server. Which will allow your (mobile) clients to send and receive data in near real-time. Another side effect of using SignalR is that you could easily extend the app with a web client. Since your favourite JavaScript framework will allow you to use the SignalR client. If you are ready to get started with SignalR, be sure to check out the docs.

You can find the entire sample, including all the UI code on GitHub.

This blog is part of the October Xamarin Challenge. So be sure to check out the other posts for more best practices when writing Xamarin apps.

HTH

1 Comments
  •   Posted in: 
  • F#

A picture containing colour crayons

I recently was faced with the task to render RAL Colours on an app that I was developing. RAL Colours are used mainly in industrial colour appliances - i.e. powder coating. So while well known in the powder coating industry it was quite an exciting read on Wikipedia to find out how RAL colours came to life. The good thing is that there is a finite set of classic RAL colours. Even better there is a table on Wikipedia which contains a good enough approximation for the classic RAL colours.

So instead of copy & pasting the table into an editor and slashing away at the data. I was wondering if there would be a better way to extract the information from the website. And store the data in a more handy form such as a JSON file.

In the last couple of months, I have been dabbling with F# in my free time. Data providers are a powerful tool which is available in the F# language. In short, you can point a data provider at a data source, and during compilation, the types used in that source get generated for you. So for your typical JSON response from a website. You can use the JSON type provider to create a type based on that stream which you then can use throughout your F# program. Now, this is a more than your "create a C# POCO from JSON" Visual Studio feature. You also get methods to slice and dice through your data. In other words, it is an excellent tool for exploring new data sources or just parsing new data sources and processing that data.

As with LINQ extensions it is is possible to write your type providers. But for most general use cases the type provider already exists and can be added to your project as a NuGet package. The NuGet package we will be using is the FSharp.Data which provides type providers for JSON, XML, CSV and HTML (plus the World Bank ‍🤷‍♂️).

Using an F# script, we will first have to reference the type provider:

#I "./packages"
#r "FSharp.Data/lib/netstandard2.0/FSharp.Data.dll"

open FSharp.Data


Side note: I am using paket for my dependency management because it installs the package right into the project folder. You do not need to use paket, but you will have to make sure that the #r ... line points to the dll.

Now type providers create a type based on a data source. In our case I can point it at the Wikipedia website listing all the RAL colours:

type wikipedia = HtmlProvider<"https://en.wikipedia.org/wiki/List_of_RAL_colors">

We could have also provided a local file:

type wikipedia = HtmlProvider<"list_of_ral_colors.html">

The local file is excellent if you do not always want to hit the remote site. But you run the risk of having an older version locally than on the server which can lead to ugly problems. As far as we are concerned for the script. I will point it at Wikipedia and be sure to make my again annual donation at the end of year

In the JSON file, we will want to store the RAL, RGB and colour name. So let's create a record type for that quickly:

type ralColor = { ral: string; hex: string; name: string}

Now that we have our types, we are all set to extract that data. By looking at the website, we can see in which section the table is located:

Picture showing part of the Wikipedia RalColor List

Knowing this location, we can scan the site and hone in on the data we are looking for:

let ralColorSection = wikipedia.Load("https://en.wikipedia.org/wiki/List_of_RAL_colors")
                                .Tables
                                .``All RAL Colours in a single listing``

If you have never used type providers, you will be probably reading the lines above and go: "Okay... I guess..." - so let's just quickly look at what happened underneath those lines of code. As the name suggests, type providers provide a type based on a data source. This is where we nod. So what do we get with the lines above? We get a type which represents the table of RAL colours. We can access all of the rows via ralColorSection.Rows. When iterating over each row we can read the value in a column by using its name. So we could print out all colour names as follows:

ralColorSection.Rows |> Seq.iter (fun r -> printfn "%s" r.``Colour name``)

I know this is freaking cool right! So if we wanted to extract the RAL, RGB and name from the table we could use our previously defined type and the values as follows:

let ralColors = ralColorSection.Rows
                    |> Seq.map((fun r -> 
                        {ral = r.``RAL Number``; 
                            hex = r.``HEX Triplet``; 
                            name = r.``Colour name``}))

Note the two ticks are how F# variables with spaces in them can be accessed. Now we have all the data we wanted. So now all that is left to do is the boring bit of storing it into a JSON file:

#I "./packages"
#r "Newtonsoft.Json/lib/netstandard2.0/Newtonsoft.Json.dll"

// ...

open Newtonsoft.Json

// ...

let writeToJsonFile ralColors =
    let filePath = Path.Combine(__SOURCE_DIRECTORY__, "ral_colour_map.json")
    let jsonString = JsonConvert.SerializeObject(ralColors)
    File.WriteAllText(filePath, jsonString, Encoding.UTF8) |> ignore

And that wraps up this blog post. I hope you have seen that F# 's type providers can be a great way to scan through data sources and extract the information you need. One thing to be aware of when using type providers: You can't directly share the generated type with other .Net languages such as C#. You would have to wrap the data in a record type - by the way: the type we created to hold the subset of data is a record type. So while there might be some additional effort up ahead when writing fully-fledged enterprise applications, they are a no brainer for scripting. And will provide you with a significant productivity boost when exploring new datasets.

Be sure to check out the official documentation on the HTML provider used in this post. As always you can find the entire code on GitHub.

HTH

0 Comments

Ever since I have received my Azure IoT Devkit, I wanted to create a small app with it. The app would let me play around with streaming data from the device and view it on my phone. Also sending data to the device and many other exciting aspects of creating an IoT application. So what better way than to create a system that would stream the sensor data from my devkit to my mobile phone. Once that is implemented, how about creating an alerting system. Should a value increase over a certain threshold, the system will notify me. Many exciting ideas and paired with the capabilities of Azure all in my grasp. So before implementing, let me show you my high-level system design:

System Overview showing the IoT Kit, the different Azure services and the Xamarin mobile app.

However, first we will need to create an app on the device or emulate a device that sends up a stream of data to the Azure cloud over the IoT Hub. Then we will probably want to stream the data to the mobile client using SignalR. And finally visualise all of the data using some nice Xamarin Forms code - perhaps even a fancy charting library.

Once the data is getting streamed to the client let's have a look at alarming scenarios. What if the value e.g. the humidity rises quickly over a short timeframe. We should be able to detect such an event using Stream Analytics and then send a push notification to a client.

SignalR vs IoT Hub

Before diving into the implementation I showed this overview to a friend of mine - to make sure I am not overdoing it with the Azure-candy store. And promptly I got the question: "Hey Mark, so what you are basically doing is a Publish and Subscribe system - why do you need SignalR and IoT Hub. Wouldn't IoT Hub or SignalR offer all you need to send messages at scale to clients?". What a great question - and simplification of the problem. While it is right that what we are doing is nothing else then publishing data and subscribing to it. They are two worlds we are combining here. On the one side we have the IoT world. Here we the creator/company/enterprise produce the software and often also distribute the hardware. So we own the device and software. On the other hand when we release an app we often do not own the device on which the app is running on. So while we generally tend to trust our IoT devices because we create them, harden them and equip them with certificates for communication with our backend - in our case Azure IoT Hub. We generally do not have the same trust in mobile apps. Mobile apps are often deployed to the mobile store and therefore have no guarantee that the app does not end up on a rooted Android or Jailbreaked iOS phone. Once on such a device is often just a cat and mouse game to make it as difficult as possible for an attacker to access the secrets that got installed with the app. In short IoT apps and mobile apps come from a different starting position and therefore we tend to use different approaches for implementing security. And that is why we use two pub/sub systems, because both of them were designed with the two different aspects in mind.

In the next blog post we will get started with writing the IoT client and also see how we can write an IoT client without requiring a devkit.

0 Comments

A view of Big Ben at night with traffic lights going by.

Reactive Extensions (Rx.Net) was released in 2009 and therefore is celebrating it's 10th anniversary this year. Reactive Extensions is well known as a solution approach for event-based systems. However, it also features many other helpful features, such as timers! I guess the title of the blog might have given this one away - nonetheless let me show you why Rx.Net provides you with a great alternative to the standard .Net timer(s).

Usually, timers serve for two scenarios. Delaying the execution of a certain piece of logic until a specified later time or to periodically execute some logic. For example, in network stacks, it is common to send a heartbeat / keep-alive message every n-seconds to let the counterpart know that the communication partner is still alive, and the connection should be kept open. We could implement such a general timer as such:

public class LiveBit : IDisposable
{
    private readonly INetworkInterface _networkInterface;
    private readonly Timer _timer;

    public LiveBit(INetworkInterface networkInterface)
    {
        _networkInterface = networkInterface;
        _timer = new Timer(1000);
        _timer.Elapsed += SendLiveBit;
        _timer.AutoReset = true;
        _timer.Enabled = true;
    }

    public void Dispose()
    {
        _timer.Dispose();
    }

    private void SendLiveBit(object sender, ElapsedEventArgs e)
    {
        Console.WriteLine("Send Live Bit");
        var liveBit = new byte[]{0xAA}; // Some imaginative payload
        _networkInterface.Send(liveBit);
    }
}

The code is implemented using only the .Net library and does not use Rx.Net. So why should we even bother to replace this piece of code? Well, how would one go and test this code? We could write a Test looking something like this:

[Fact]
public async Task LiveBit_WhenCreated_TheSendMethodWillBeInvokedAfter1Second()
{
    // Arrange: Given a mock interface ...
    int counter = 0;
    // Using Moq https://www.nuget.org/packages/Moq/
    var networkInterfaceMock = new Mock<INetworkInterface>();
    // Write a function that counts the number of invocations
    networkInterfaceMock
        .Setup(n => n.Send(It.IsAny<IEnumerable<Byte>>()))
        .Callback(() => counter++);
    // Act: ... start the livebit service and wait for a good second ...
    var liveBit = new LiveBit(networkInterfaceMock.Object);
    await Task.Delay(TimeSpan.FromMilliseconds(1100));
    // Assert: ... the mocked send method has been invoked once.
    Assert.Equal(1, counter);
}

To be honest whenever I see an await Task.Delay(someNumber) it never feels right. Usually, this is always some hack. I am not saying you should never do this, but in 95% of all cases, they are an indication of bad programming. However, what else can we do? "Shift time by one second!" - Sure, but how would you do that? Well, let me show you. First, let's rewrite the timer function to use the Rx.Net approach:

public class ReactiveLiveBit : IDisposable
{
    private readonly INetworkInterface _networkInterface;
    private readonly IDisposable _timer;

    public ReactiveLiveBit(INetworkInterface networkInterface)
    {
        _networkInterface = networkInterface;
        _timer = Observable
            .Interval(TimeSpan.FromSeconds(1))
            .Subscribe(x => SendLiveBit());
    }

    public void Dispose()
    {
        _timer.Dispose();
    }

    private void SendLiveBit()
    {
        Console.WriteLine("Send Live Bit");
        var liveBit = new byte[]{0xAA}; // Some imaginative payload
        _networkInterface.Send(liveBit);
    }
}

We can rerun our test, and it is still passing. However, the delay is still present in our test code. Looking at the definition of Rx.Net Scheduler, we see that it takes an IScheduler as an argument. This means that we can inject the time (ticker) into our scheduler - in other words, we can play timelords. So if we rewrite our constructor a bit:

public ReactiveLiveBit(INetworkInterface networkInterface, IScheduler scheduler = null)
{
    var timerScheduler = scheduler ?? Scheduler.Default;
    _networkInterface = networkInterface;
    _timer = Observable
        .Interval(TimeSpan.FromSeconds(1), timerScheduler)
        .Subscribe(x => SendLiveBit());
}

We now pass in an optional parameter of IScheduler which is set to null by default. Moreover, if the parameter is not set, we use the Scheduler.Default. So if we do not inject a scheduler, the method uses the system clock and a second is a second. To test this, we can rerun our test at this point to find it still snoozing in the green.

When testing with Rx.Net, there is a dedicated NuGet package Microsoft.Reactive.Testing that provides some excellent helpers such as the TestScheduler.

Using the TestScheduler we can rewrite our test code like this:

[Fact]
public void ReactiveLiveBit_WhenCreatedWithATestScheduler_TheSendMethodWillBeInvoked1TestSecond()
{
    // Arrange: Given a mock interface ...
    int counter = 0;
    // Using Moq https://www.nuget.org/packages/Moq/
    var networkInterfaceMock = new Mock<INetworkInterface>();
    // Write a function that counts the number of invocations
    networkInterfaceMock
        .Setup(n => n.Send(It.IsAny<IEnumerable<Byte>>()))
        .Callback(() => counter++);
    var testScheduler = new TestScheduler();
    // Act: ... start the livebit service and wait for a good second ...
    var liveBit = new ReactiveLiveBit(networkInterfaceMock.Object, testScheduler);
    testScheduler.AdvanceBy(TimeSpan.FromSeconds(1).Ticks);
    // Assert: ... the mocked send method has been invoked once.
    Assert.Equal(1, counter);
}

Utilising the TestScheduler allows us to move forward in time with the AdvanceBy method. Forwarding the time will execute the timer code and reduce our test execution time to mere milliseconds.

Conclusion

So do you need Rx.Net to write timers? No, you do not - then again do you need C# to write applications instead of using assembler? Again no, you don't, but it helps to ship stable and maintainable code. Be sure to check out the official Rx.Net website to find more resources on Rx.Net.

You can find all the code to this small sample on GitHub.

HTH