Platforms > Implementations
I recently read an insightful post about how being a developer is less about coding and more about tooling, and while I do not agree with all of the post, the fact we as developers are tool obsessed rings very true. This obsession with tools becomes a white hot rage when our favourite tool is threated with extinction or causes a world of panic when a competing tool is proposed without enough information on it.
Let’s look at two key examples of that:
- WinForms was very popular and when Microsoft brought us WPF, there was major push back from those who did not want to change and learn a new tool. If you reading this, then you are thinking well time solved that, I disagree. This very week I was asked about WinForms vs. WPF again. Time doesn’t heal all wounds, it just gives some of us time to move on.
- To illustrate the world of panic I can use a more recent issue – Windows 8! Remember all the discussion before //Build about the death of <insert your favourite tool here>? The confusion caused by incomplete discussions around tools we love caused panic.
So what is the solution to this? I think simply a mind set change would be enough. The mind set change needed is to remember that a platform is more important/powerful/useful than a tool. I would like to take credit for this idea, but the first time I heard anyone mention this was a few years back and it was Scott Hanselman talking on MVC almost three years ago to the day. He mentioned that ASP.NET > ASP.NET Web Forms and ASP.NET > ASP.NET MVC. In short he was saying that the core understanding of ASP.NET, the core features and the core uses of the platform are bigger than a single implementation (tool) could be. Sure, you need to learn a new tool, but you aren’t starting at zero if you know the platform.
Why I am bringing this up? It is because of the discussions I have been having about another tool recently: Silverlight. We are approaching the panic stage on this tool due to rumours of it’s demise. However it is VERY important to take a step back and see what the platform is and how knowing the platform means that a tool can move along and we are still able to work/code/make money etc…
The platform Silverlight uses is XAML based UI technologies, a core set of how we can layout UI components using an XML dialect called XAML. This platform also has lots of options for things like binding, the MVVM patterns and so on that are either difficult or impossible to do with other UI technologies (like WinForms for example).
XAML based UI technologies started with a single tool: WPF – an implementation of the platform designed to run on top of the .NET Framework. A second tool, Silverlight, later appeared – this is an implementation of the platform designed to run as a plugin in a browser. A third tool, Silverlight for Windows Phone 7, came next and while very close to Silverlight it had it’s differences as it was an implementation of the platform for the phone. In the last few months we have had the forth implementation of the XAML based UI technologies appear: WinRT. This is the Windows Runtime in Windows 8 and when you develop with C#, VB.NET or C++ your UI technology is just another implementation of the platform.
Every implementation of the platform has been different, some in big ways and some in smaller ways but the core of the XAML based UI technology platform hasn’t changed and there is not a single rumour, plan, or hint that we are even close to seeing the end of XAML based UI technologies. We may see a tool end of life and die (like some rumours say about Silverlight) or other tools just find completeness and not need new work done (like WPF if) but the platform remains and grows and learning a platform is always more important/powerful/useful.
Firefly for Windows Phone 7
I am a brown coat – if you know what that means then you will be excited to see my new application for Windows Phone 7: a Firefly hub app which contains news, images, sounds & ringtones from the show and from the movie, Serenity.
This started as me wanting a sound board for the show, but grew larger
This is the first app I have done since my UX training and I hope a lot of the tools and skills I learnt in that training comes through in the application.
TCP servers with .NET: Scenario 4 & Non-blocking servers with .NET 4.5
This post is part of a series, to see the other posts in the series go to the series index.
Scenario 3 is a great solution to the problem, but the problem with it was the complexity of the code is way higher than in scenario 1 or scenario 2. We are calling to other methods, using recursive like behaviours and all kinds of things that are not obvious or easy to grasp.
Thankfully Microsoft has identified this issue and in .NET 4.5 we will be getting some help with this thanks to the new ASYNC features, in particular the async & await keywords.
In short async provides information to the compiler that this method will spawn off an asynchronous process and will return to the caller at some point while the await points out the line of code that line asynchronously.
So using this allowed me to modify the code back to pretty close to the scenario 1 code (I even have the Boolean continue running server flag). However the two methods are enhanced with the async keyword and in there the await keyword is used with AcceptTcpClientAsync and ReadAsync – these are new methods in the TCP stack which return Task<T>, a fundamental requirement of calls that work with async.
I think this is a fantastic improvement, and I cannot wait for .NET 4.5 to ship
class Program { private const int BufferSize = 4096; private static bool ServerRunning = true; static void Main(string[] args) { var tcpServer = new TcpListener(IPAddress.Any, 9000); try { tcpServer.Start(); ListenForClients(tcpServer); Console.WriteLine("Press enter to shutdown"); Console.ReadLine(); } finally { tcpServer.Stop(); } } private static async void ListenForClients(TcpListener tcpServer) { while (ServerRunning) { var tcpClient = await tcpServer.AcceptTcpClientAsync(); Console.WriteLine("Connected"); ProcessClient(tcpClient); } } private static async void ProcessClient(TcpClient tcpClient) { while (ServerRunning) { var stream = tcpClient.GetStream(); var buffer = new byte[BufferSize]; var amountRead = await stream.ReadAsync(buffer, 0, BufferSize); var message = Encoding.ASCII.GetString(buffer, 0, amountRead); Console.WriteLine("Client sent: {0}", message); } } }
TCP servers with .NET: Scenario 3 & Non-blocking (Async) optimistic servers
This post is part of a series, to see the other posts in the series go to the series index.
The first two posts (post 1, post 2) in this series were really to just set the stage and help explain problems with TCP servers that do blocking. The code and method is not wrong, they are okay for some scenarios, but if you want a really robust model, a model that fixes the issues with them without any extra technical issues being added you need to use a non-blocking server.
We start the server the same way, however instead of using the blocking AcceptTcpClient method we use the non-blocking method BeginAcceptTcpClient which implements the async or begin/end (I’ll call it async from here on) pattern. Mark Pearl has a great post explaining the async pattern.
When a client connects, it runs the code associated when we setup the async and in there we call the EndAcceptTcpClient to end the async process and get the TcpClient implementation.
We repeat this process with reading from the client by switching from Read to BeginRead.
The advantage of this model is the only blocking point is the Readline so shutting the server is very easy, we have no thread management to worry about (it is using threads under the covers, but we do not need to care), and clients can connect now and send data at any time – it doesn’t matter!
This pattern does require a lot more code and it is more complex to setup, but once you understand the async pattern (call begin > pass the info we need in state > call end to get more info we need) it is pretty easy
class Program { private const int BufferSize = 4096; static void Main(string[] args) { var tcpServer = new TcpListener(IPAddress.Any, 9000); try { tcpServer.Start(); tcpServer.BeginAcceptTcpClient(ClientConnection, tcpServer); Console.WriteLine("Press enter to shutdown"); Console.ReadLine(); } finally { tcpServer.Stop(); } } private static void ClientConnection(IAsyncResult asyncResult) { Console.WriteLine("Client connection"); var tcpServer = asyncResult.AsyncState as TcpListener; var tcpClientConnection = tcpServer.EndAcceptTcpClient(asyncResult); tcpServer.BeginAcceptTcpClient(ClientConnection, tcpServer); var stream = tcpClientConnection.GetStream(); var buffer = new byte[BufferSize]; var clientData = new ClientReadData() { Buffer = buffer, Stream = stream }; stream.BeginRead(buffer, 0, BufferSize, ClientRead, clientData); } private class ClientReadData { public byte[] Buffer { get; set; } public NetworkStream Stream { get; set; } } private static void ClientRead(IAsyncResult asyncResult) { var clientReadData = asyncResult.AsyncState as ClientReadData; var amountRead = clientReadData.Stream.EndRead(asyncResult); var buffer = new byte[BufferSize]; var clientData = new ClientReadData() { Buffer = buffer, Stream = clientReadData.Stream }; clientReadData.Stream.BeginRead(buffer, 0, BufferSize, ClientRead, clientData); var message = Encoding.ASCII.GetString(clientReadData.Buffer, 0, amountRead); Console.WriteLine("Client sent: {0}", message); } }
TCP servers with .NET: Scenario 2 - Optimistic Blocking Servers
This post is part of a series, to see the other posts in the series go to the series index.
In the previous post we looked at the simplest of all TCP server scenarios, but what about the third issue highlighted in the post: It assumes your clients will connect, pass data and disconnect. What about for clients the connect optimistically so that they can send data at some point in the future?
This is very common for games, where the client connection process is very slow or where even smallest of overhead should be eliminated.
In this mode rather than read data and disconnect we add a loop on the reading and read until we get a end of message notice and will then end the connection.
The problem with extending the simple model to this, is that we now have a blocking action, i.e. code can not continue until something happens, in both the server thread and in all the client connection threads. So now shutting down the server is not just related to the server, we need clients to disconnect properly first.
What is common here, is to send a message to all clients saying it will shutdown and then having them do that. That assumes we have pretty smart clients and/or control them and in scenarios you do not control the TCP clients it could be a bit problem. We will look at a way to solve this in the next post, but for now the code below shows how this is done, and compared to scenario 1 it contains one small change:
class Program { private const int BufferSize = 4096; private static bool ServerRunning = true; static void Main(string[] args) { new Thread(RunTCPServer).Start(); Console.WriteLine("Press enter to shutdown"); Console.ReadLine(); ServerRunning = false; } private static void RunTCPServer() { var tcpServer = new TcpListener(IPAddress.Any, 9000); try { tcpServer.Start(); while (ServerRunning) { var tcpClientConnection = tcpServer.AcceptTcpClient(); Console.WriteLine("Client connection"); // spawn thread to deal with it new Thread(ClientConnection).Start(tcpClientConnection); } } finally { tcpServer.Stop(); } } private static void ClientConnection(object state) { var tcpClientConnection = state as TcpClient; var stream = tcpClientConnection.GetStream(); var buffer = new byte[BufferSize]; while (ServerRunning) // new in scenario 2 { var amountRead = stream.Read(buffer, 0, BufferSize); var message = Encoding.ASCII.GetString(buffer, 0, amountRead); Console.WriteLine("Client sent: {0}", message); } } }
TCP servers with .NET: Scenario 1 - Simple TCP servers
This post is part of a series, to see the other posts in the series go to the series index.
Writing a TCP server is something that modern business .NET developers do not need to worry about, we have WCF which has abstracted us from understanding TCP servers & clients for business apps – but for some systems we still need to write a TCP server or client.
Microsoft has optimised the .NET framework for common scenarios – for example doing something like SMTP where a server where it is always running and clients connect when they have data, provide the data and disconnect. So what you may do is start a server (in it’s own thread so you can still do other things in the app), and wait for client connections. At this point you are blocking processing until a client connects. When a client connects, you get the data and process it (in a new thread, so you can allow more clients to connect).
The advantage of this is this is a simple model and is fairly easy to setup, but there is a few problems with this:
- You have this blocking point while you wait for clients, so trying to shut it down is difficult. As the view of a server is that it should always be up, this is not an optimised path so there is no way. Basically you will need to deal with task manager to kill the process.
- You have lots of threading and you must handle threads. Threads are hard to understand and easy to fail so we are opening up potential for problems.
- You assume the client will connect and send data at once and will go away. Once again this is the “normal” scenario (think HTTP or SMTP) but there are scenarios where this is not possible.
Below is the sample to do this in a console application.
class Program { private const int BufferSize = 4096; private static bool ServerRunning = true; static void Main(string[] args) { new Thread(RunTCPServer).Start(); Console.WriteLine("Press enter to shutdown"); Console.ReadLine(); ServerRunning = false; } private static void RunTCPServer() { var tcpServer = new TcpListener(IPAddress.Any, 9000); try { tcpServer.Start(); while (ServerRunning) { var tcpClientConnection = tcpServer.AcceptTcpClient(); Console.WriteLine("Client connection"); // spawn thread to deal with it new Thread(ClientConnection).Start(tcpClientConnection); } } finally { tcpServer.Stop(); } } private static void ClientConnection(object state) { var tcpClientConnection = state as TcpClient; var stream = tcpClientConnection.GetStream(); var buffer = new byte[BufferSize]; var amountRead = stream.Read(buffer, 0, BufferSize); var message = Encoding.ASCII.GetString(buffer, 0, amountRead); Console.WriteLine("Client sent: {0}", message); } }
TCP servers with .NET: Series Index
This page provides links to each of the posts in this series. If the post is not linked yet, check back in a few days as they will be all up soon!
Windows Phone 7 Apps: SA ID Number Tools & AA Rates Calculator Updates
I have a few Windows Phone 7 apps, and two of those are the SA ID Number Tools and the AA Rates Calculator ones. You may be familiar with the AA Rates one from my friend, Rudi Grobler, who used it in his TechEd talks to show a UI that did not follow the model correctly
I took this and the Windows Phone UX training I attended to heart and put a lot of work into updating them and making them a lot more in line with the WP7 UI guidelines.
AA Rates Calculator
The first think is this application has dropped the yellow background, which made sense for an AA tool (being their colour is yellow), and now is black or white depending on your theme. All controls have been updated to reflect that too. I have also fixed the alignment things Rudi was so quick to point out.
I use the highlight colour now and larger typography to really make the key information stand out from the rest – this is something I learnt at the UX camp.
In addition I have some other new features:
- About to share your rate via email or social networks (twitter, facebook etc…)
- The yellow branding is used in a position bar to give you an idea of how much is in the app.
- I also added a fuel price page so you can always have the latest fuel price information!
- The information pickers have also had an update and the selection is much larger now, so easier for people with big hands like me.
- Fuel price can be displayed on a live tile too!
SA ID Number Tools
Once again I dropped the background green (which was a photo of my ID book cover) and that also meant being able to move to a pivot control rather than a (heavy) panorama control. The green/gold theme has been mostly lost, with gold being used in selective places in the application. Also a careful use of font sizes and colours in the application to make the information stand out more.
Hopefully these changes make these apps feel faster, easier to use and more part of your phone than before!
Windows Phone 7: Professional Tips - Press and hold
The keyboard on WP7 is an amazing area which you will be often exposed to, so it is not surprising it contains some hidden gems to make the experience better, like double tap.
Today the hidden gem is the ability to press and hold keys to get pop ups with other options, which could save you navigating to the symbols/number section or even give you access to options that you never had anywhere else.
If you have a look at the screen shot you will see the dot key has been pressed and held and the popup has dash, exclamation, colon, question mark and dot in it. Much easier to find than going to the symbols section.
Other keys with this. Letters shown in lower case support this on upper case too:
- e – ê è ë é
- t – þ
- y – ý ÿ
- u – ù ú û ü
- i – ì í î ï
- o – ò ó ô ö ø œ
- a – ä á â à å æ
- s – ß §
- d – ð
- c – ç ©
- n – ñ
- m – ɥ
- 1 – ⅓ ¼ ½
- 2 – ² ⅔
- 3 – ¾ ³
- 0 – °
- £ – $ ¢ € ¥ ¤
- ( – < { [
- ) – > } ]
- - - _ ~ ¬ ·
- ! – ¡
- ' – ´ `
- " – « » “ ”
- ? - ¿
Windows Phone 7: Professional Tips & Dismiss notifications
Windows Phone 7 supports little pop up notifications, which are called toasts (cause they pop up like bread in a toaster). You will see these when you get a text message (SMS) or from games (like Tanks) or in chat programs like WhatsApp.
These can linger around for a little bit, but you can get rid of them quickly – just swipe across them, like you were flicking them away and they will rush off your screen.
I use this a lot with WhatsApp when I get multiple messages quickly so I can clear the first and see the second toast which is under it or when I am playing a game and I want to get that SMS off screen so I can continue to play.
It’s another example of the UX in the phone having great little touches.