Who cares about the view anyway?

While working on an issue, I discovered a cool way in which to draw using SkiaSharp – without caring about view sizes at all.

In many cases, drawing code does not really care about the actual view sizes or canvas sizes. For example, if you are drawing a button, the drawing code is going to fill the entire view. If you are working on some image, you typically want the image to fill the view.

This is because in most cases, the UI framework will do all the view sizing based on your constraints, available space and any parameters. Then, you want to draw the best image on the size that the UI framework gave you.

Let’s take a practical example: we want to make a badge with a number on it.

Badge

If we assumed that the badge will always be 15×15, then we would think this would be easy. All our sizes would be around that number. But since we are drawing a circle from the center, we actually have a center of 7.5 and a radius of 7.5. This is not a problem in any way for SkiaSharp, but it is a bit for us as we now have more things to do.

If we were to draw this without checking screen density or actual view size, we might get something like this:

Tiny badge

This is because we have used numbers like 15 and 7.5. These numbers are actually tiny when compared to the thousands of pixels on modern devices.

If we used bigger numbers, this help, but not fix all the issues. For example, this might happen:

Too big Too small

This is a result of the way SkiaSharp and UI frameworks work. The way SkiaSharp does pixels is a bit different to typical UI frameworks. When designing a UI, the framework knows about screen densities so this typically means that UI frameworks will scale UI elements automatically.

For example, if there is a view with a size of 15×15, in most cases you would expect this view to be the same size across all screens and devices. So, if you were on an iPhone, this might translate to a 30×30 view. On some Android devices, they use a density of 3.5, so this translates to a 52.5. As a result of the screen density, placing the devices side by side results in very similar view sizes to our eyes.

However, SkiaSharp does not care about screen densities (maybe incorrectly, but that is for an open issue). Regardless of the device or platform, it asks the OS for the exact bounds of the view – in raw pixels. So, if we take our previous examples of iOS and Android, we will end up with different canvas sizes: 30×30 and a 52×52 (because there is no such thing as a .5 raster pixel).

Drawing Correctly

If we know that SkiaSharp does not scale automatically, we can use simple arithmetic to work out that we can just scale before we draw.

In all our drawing code examples, we are going to draw a 15×15 circle in the center of the view so that it touches the edges:

  // assume a perfect 15x15 canvas and view
  canvas.DrawCircle(7.5f, 7.5f, 7.5f, paint);
  

Screen Desnsity

To handle screen density, we could use something like Xamarin.Essentials. There is a nice DeviceDisplay API that will give us the main screen’s density:

// get the density
var density = (float)DeviceDisplay.MainDisplayInfo.Density;

// scale to the density
canvas.Scale(density);

// draw
canvas.DrawCircle(7.5f, 7.5f, 7.5f, paint);

This would work.

In that one case.

If we need to support devices where density may change or has multiple displays, then we can use a trick of just dividing the canvas size by the view size:

  var density = e.Info.Width / (float)this.Width;
  

View Size

What happens if you decide that a 15×15 badge is too small and want to use 16×16 or even a big 20×20? Or, in a case where 15×15 is too big? You would think to just make the view bigger and all would be well.

Unfortunately, it won’t.

Because you may have used sizes like radius = 7.5f or a textSize = 8f.

Using exact sizes is often just fine, if you are very sure that the view size will never change. But, as developers, we can not assume that.

A smart developer might think to use the view size instead of hard coordinates. Then using arithmetic, scale things relative to that:

// get the density
var density = e.Info.Width / (float)this.Width;

// scale to the density
canvas.Scale(density);

// draw
var halfWidth = (float)this.Width / 2f;
canvas.DrawCircle(halfWidth, halfWidth, halfWidth, paint);

That would work.

In many cases.

If you have a lot of drawing to do, there may be many, many division and multiplication operations. Modern CPUs are very fast, but why even do that? Also, with every draw, you might end up with many other operations to calculate the size and position.

An example would be if padding was needed. If you were going for a 2px padding, then this would also have to be calculated:

var halfWidth = (float)this.Width / 2f;
var padding = 2f;
canvas.DrawCircle(halfWidth, halfWidth, halfWidth - (padding * 2), paint);

And this gets worse if you want the padding to be based on the circle size, maybe with a 10% padding:

var halfWidth = (float)this.Width / 2f;
var padding = (float)this.Width / 10f;
canvas.DrawCircle(halfWidth, halfWidth, halfWidth - (padding * 2), paint);

This involves lots of arithmetic – who really wants to deal with that when trying to draw a basic circle?

Not me.

Arbitrary Size

What if we could draw things using any base size, and then let the graphics engine do all the work? Like it was designed to do.

Now this is probably not something that I invented or discovered. I may have thought of it now, but I am not always the brightest person so that basically means everyone already knows. But, let’s assume that there was one other person that didn’t know.

So, what if we could take our 15×15 circle and convert that thought into a 100×100 circle and let the engine do the work to make our numbers appear as if it was 15×15?

We can do that with SkiaSharp.

It is called scaling. Pretty obvious, I know, but it only took a few years.

Instead of doing “advanced” arithmetic to calculate sizes, offsets and percentages, we can use any base size that makes things easier. In our example, we have a full-view circle with a number in the center.

So why not use 100 as the base size and have the circle have a radius of 50? Well, we can.

// pick a cool number for us
const float baseSize = 100f;

var canvas = e.Surface.Canvas;

// scale to our base unit
canvas.Scale(e.Info.Width / baseSize);

var circleFillPaint = new SKPaint {
    IsAntialias = true,
    Style = SKPaintStyle.Fill,
    Color = 0xFFFF5722,
};

// center of 50x50 and a radius of 50
canvas.DrawCircle(50f, 50f, 50f, circleFillPaint);

// we can even use nice numbers for font sizes
var textPaint = new SKPaint {
    IsAntialias = true,
    TextSize = 70f,
    Color = SKColors.White,
};

// measure the text width
var textBounds = SKRect.Empty;
var advance = textPaint.MeasureText(BadgeValue, ref textBounds);

// draw the text at the center (x = 50 - half the width; y = 100 - half text height)
canvas.DrawText(BadgeValue, 50f - (advance / 2f), 100f - (textBounds.Height / 2f), textPaint);

Now, we can use this exact code to render a perfect badge, regardless of the view size, the screen density or any other view-related property. The reason for this is that the first thing we do is convert from drawing units into our perfect unit:

canvas.Scale(e.Info.Width / 100f);

As long as our numbers are based on 100, then we can never go wrong.

Beware of C# 8 Using Statements

Let’s be honest here, C# 8 is crazy cool. It has such a big set of new features to make developers more productive and write even better code. There are some awesome things, like nullable reference types and asynchronous streams (async enumerables). There are also some weird things, like private members on interfaces. But there are many features that just make life better. Using statements is one of them.

If you want to see a list of all the new things, check out the Microsoft docs. It has all the goodness.

But, let’s get back to the using statements. What are they? Where are they used? Well, using statements are just normal using blocks with some syntactic sugar to make the code more readable. Here is an example of a normal, traditional using block:

using (var stream = File.Create("test.txt"))
using (var writer = new StreamWriter(stream))
{
    writer.Write("Hello World!");
}

This is a very simple example. There are two objects that need to be disposed, and we have them in the using blocks. This code creates a file, creates a writer and then writes to the file. At the end, the writer closes the stream and the file is closed. We have all seen this before.

So, what does C# 8 bring to the table? Well, lets convert the using block into a using statement:

using var stream = File.Create("test.txt");
using var writer = new StreamWriter(stream);

writer.Write("Hello World!");

It is very similar, but there are no braces and parenthesis. There are no indents.

The Good

That was a simple example, but just imagine the case where there are loops, conditions and other statements. It could, and does, get a bit messy. Take a look at this example:

var array = new[] { "first", "second", "third" };
foreach (var item in array)
{
    using (var stream = File.Create($"{item}.txt"))
    {
        stream.WriteByte(1);
        if (item != null)
        {
            using (var writer = new StreamWriter(stream))
            {
                writer.Write("Hello World!");
            }
        }
    }
}

Lots of nesting, lots of indents, lots of braces. With using statements we can remove 4 lines and 2 levels of indents. Much better on the eyes:

var array = new[] { "first", "second", "third" };
foreach (var item in array)
{
    using var stream = File.Create($"{item}.txt");
    stream.WriteByte(1);
    if (item != null)
    {
        using var writer = new StreamWriter(stream);
        writer.Write("Hello World!");
    }
}

The Bad

We saw a nice saving of everything, so what is this “beware” in the title? Well, it has to do with scopes. The using statements are nice as they dispose/close things when they go out of scope.

If we look at the example above, we can see the stream variable goes out of scope at the end of each iteration of the foreach loop. This means that after the code in the foreach block runs, it is auto disposed. That is nice. But, this is also the cause of the “beware”. Take a look at this example:

using (var stream = File.Create("test.txt"))
using (var writer = new StreamWriter(stream))
{
    writer.Write("Hello World!");
}

return File.ReadAllText("test.txt");

Here, we create a file, write to it, dispose it and then return the results. We probably wouldn’t write this exact code in real life, but hey, examples! If we were to convert this into using statements, as one would be tempted, we end up with this code:

using var stream = File.Create("test.txt");
using var writer = new StreamWriter(stream);

writer.Write("Hello World!");

return File.ReadAllText("test.txt");

That looks nice, but has a “hidden” bug. If you think back to the using statements and their scope… Where does the stream go out of scope? At the end of the method, after the return. So what does this mean? Well, it is that the stream is still open and the file handle is being held. That means we will get an exception:

Unhandled exception. System.IO.IOException:
The process cannot access the file ‘test.txt’ because it is being used by another process.

Not so nice.

We can have a look at what the compiler writes to help us understand what just happened:

using (var stream = File.Create("test.txt"))
using (var writer = new StreamWriter(stream))
{
    writer.Write("Hello World!");

    return File.ReadAllText("test.txt");
}

As you can see, the return is inside the using block.

Not what we wanted.

The Ugly

Just when we thought we had the bad news, there is more. An exception is not nice, but at least we know something went wrong. We can fix that. So what is worse than an unhandled exception? No exception!

If our operating system was cool with opening a file that was already opened. We cannot be sure that the contents had actually been flushed! Some streams only flush when the stream is either explicitly flushed or when it is closed.

So, if we are running on this system, we would not get an exception, but we would return an empty string. Even though we just wrote to the file! This is most certainly an unexpected result!

Now, streams are one thing and we can handle that. But it gets tricky when we have other disposable objects.

Maybe they are very large. If we have 1GB of RAM and we open a 1GB file, we are good. But if we try an open another 1GB file, we will run out of memory. If we were using blocks, then we could control the fact that it had to first close the first file before opening the second.

Maybe they are critical. We could potentially lock some resource for longer than necessary if we aren’t careful. This is very dangerous. We could potentially cause other systems of functions to crash because things took too long to respond.

At the end of the day. Use the new using statements. Your code will be better. But… Use them were they should be used. Don’t just auto-convert all blocks to statements with ReSharper.

JavaScript Ajax & ASP.NET WebAPI

Recently I was working on a HTML/JavaScript web application and I was having one of those moments where everything was working fine except for one small thing: the server always seemed to receive NULL.

I tried the usual check-for-null-before-sending, but this was not the problem. Maybe it was breaking in the jQuery Ajax call? Is that even possible? 🙂 Everything was perfect, including when checking the request data with Internet Explorer’s Network Traffic Capturing Developer Tool. It was sending the data across. The JSON was valid and everything.

I decided it was the server. It was a basic ASP.NET WebAPI. All the GETs were working so why was the POST failing? I checked the ApiController’s http context request content. That was correct. The only thing that was wrong was the method’s object parameter value being NULL.

So what was it? The client was sending the right data and the server was receiving it, but the object was NULL.

Here is the JavaScript code:

$.ajax({
    url: '/api/ingredient',
    type: 'POST',
    data: JSON.stringify(ingredient),
    contentType: 'json',
    success: function() { ... },
    error: function() { ... }
});

That was perfect. Now on the server:

public class IngredientController : ApiController
{
    public void Post(IngredientDto ingredient)
    {
        // it failed here as "ingredient" was NULL
    }
}

After searching for some time and trying all sorts of things, I finally found where I went wrong. Now, we all know Microsoft for not being very standards compliant, I mean look at Internet Explorer before version 9, it was pretty glum times. But the problem lay with Microsoft being too standards compliant. The problem lay in the small string, “json”: it is not the right string. Of course if this was a strongly typed language, an enum based action, this would have never have happened. (Look out for my upcoming post on Type Safety)

The informal standard according to Internet Assigned Numbers Authority‘s (IANA) media types and The Internet Engineering Task Force‘s (IETF) RFC4627:

The official MIME type for JSON text is “application/json”.

Wow. What a waste of time. And of course, as soon as I changed the Ajax type from “json” to “application/json” everything JustWorked™.
So the new code is:

$.ajax({
    url: '/api/ingredient',
    type: 'POST',
    data: JSON.stringify(ingredient),
    contentType: 'application/json',
    success: function() { ... },
    error: function() { ... }
});

I hope this helps someone to avoid what I was doing: wasting time. But I did learn a few other things along the way, all was not lost.