Browser + Razor = Blazor!

In case you missed it, a few days ago Microsoft decided to enter the Single Page Application (SPA) frameworks war. Well not in a fully committed way yet, but nevertheless in a rather interesting way. Blazor will allow developers to write SPA Web applications, using C# and Razor syntax. Yes you will be able to build composable web UIs using C#! This is direct competition with popular frameworks such as Angular and React. I know what you will all say “I just got done learning Angular, React, Aurelia, Meteor, Ember, Polymer, Backbone, Vue, Knockout, Mercury, and was so looking forward to learning the next great JavaScript framework”. Well you still can but maybe, just maybe in the future you might not have to.

This is all made possible by the work the Mono team at Microsoft has been busy with. They have been working on bringing Mono to WebAssembly. WebAssembly has been around for a while now and it allows for the efficient and safe execition of code in web browsers. As a matter of fact WebAssembly is an open standard and with the introduction of iOS 11 it is now pretty much universally available on all major browsers. The Mono team has managed to bring the ability to run C# code within WebAssembly and hence develop applications using C# and Razor that natively run in the browser. WebAssembly is designed as an open standard by a W3C Community Group. You can learn more about it http://webassembly.org/.

All this is currently in the very early stages of development but it is all very exciting. Even though Microsoft says this is not a committed project, it seems to be heading to the right direction. This could help Web Developers to finally have a “go to” framework for SPA development instead of having to learn and pick between the ever changing JavaScript SPA frameworks.

You can see a live demo here https://blazor-demo.github.io/.

This is all part of the long term Microsoft strategy to embrace as many environments and tools as possible. They have been heavily investing in attracting as many developers as possible to their ecosystem. With their efforts in delivering open source frameworks and free cross platform development environments they are aiming to get people using their tools with the hope, of course, that they will choose Azure as their hosting platform. Long gone the days that Microsoft can demand huge sums for IDEs and compilers. Nowadays all an engineer needs is a good text editor and an LLVM compiler and off they go. Microsoft simply decided to provide most of their tools free of charge in order to attract people to their platform. Blazor is another great example of how they are shifting and embracing this brave new open world.

Advertisements

Objectively Patterned – Singleton

In this series of blog articles I will try to cover a number of very important software design patterns, that every developer should have in their toolkit. Design patterns are highly reusable solutions to common software design problems. At their core they are just simple code templates that have been designed to help engineers write clean, reusable and easily understandable code. Most, if not all, design patterns apply across all modern object-oriented programming languages. Despite that, I will be using my favourite one, Objective-C, for this series of articles.

In this article we will cover the Singleton pattern.

The Singleton pattern makes sure that only one instance of a class can ever be initialised. This is extremely useful when you need a single global access point to an instance of a class across your system. There are numerous examples of the Singleton pattern used across Cocoa Frameworks. For instance [UIApplication sharedApplication] is an example of a Singleton object.

Let’s assume we are building a download manager. This class allows you to add items to a queue for downloading from a specified URL. You will want the process of downloading to be accessed in global fashion from any part of your application. That way you can provide feedback on completion and progress as well as access for adding items to the queue.

The code below assumes you are familiar with GCD (Grand Central Dispatch), Apple’s concurrent code execution framework for iOS and OS X. You can read more here https://developer.apple.com/library/mac/documentation/Performance/Reference/GCD_libdispatch_Ref/Reference/reference.html#//apple_ref/doc/uid/TP40008079-CH1-SW1. Also we will be using Blocks. Blocks are similar to C functions but on steroids! You can read more here https://developer.apple.com/library/ios/DOCUMENTATION/Cocoa/Conceptual/Blocks/Articles/00_Introduction.html.

Take a look at the code below:

@interface DownloadManager : NSObject
        + (DownloadManager *)sharedDownloadManager;
        – (
void)addToDownloadQueueWithUrl:(NSURL *)url;
@end

+ (DownloadManager *)sharedDownloadManager
{
        static DownloadManager *sharedDownloadManager = nil;
        
static dispatch_once_t onceToken;
        
dispatch_once(&onceToken, ^{
                
sharedDownloadManager = [[self alloc]init];
        });
        
return sharedDownloadManager;
}

Let’s break up the above code and see what’s going on:

Firstly we declare a static variable that will hold our instance and make it globally available within our class.

        static DownloadManager *sharedDownloadManager = nil;

Then we declare a static dispatch_once_t variable. This predicate will ensure that our initialisation code will execute once and only once for the lifetime of our application.

Finally we use GCD’s dispatch_once function to execute a block of code that will initialise our instance of sharedDownloadManager. GCD ensures this is done is a thread-safe manner. So next time the [[DownloadManager sharedDownloadManager]is executed it will initialise an instance of our class. Subsequent calls will always return a reference to the previously created instance. You can now safely call any instance function of this class, knowing that you are working against one global instance. Of course you can expand the above code to add your own custom initialisation code as well.