Find examples of code, tutorials, and walkthroughs! When discussing programming and software engineering topics, examples are critical!
In this article I'll be going over one of my most used design patterns called the facade (or façade), and explaining why I like to use it. As with all things I share information about, it's important to remain pragmatic as software engineers. With that said, this article is not to persuade you to use this pattern exclusively or that there are not alternatives. Instead, I'd like to arm you with another design pattern tool in your figurative coding toolbox. The more tools you have available, the better prepared you are to go build awesome stuff. What We're Trying to Achieve With a Facade When I am developing software, whether it is personally, professionally, or as someone that is influencing the direction of software I am not directly coding myself, I encourage a focus on flexibility in software. I have…
As C# programmers, we've all been burned by asynchronous EventHandlers. And if you still haven't yet, then hopefully this article will arm you for being able to better navigate long debugging sessions where functionality mysteriously stops working in your application. While there are several different solutions for dealing with async event handlers, either by avoiding use of async void or even by embracing async void, in this article we will explore another option which is Task EventHandlers. Disclaimer: this article was originally written with the perspective that this solution feels close to bullet-proof, but there are important limitations. These limitations are addressed later in the article, and I felt it would still be valuable to explore the space (both positives and negatives). A Companion Video! https://www.youtube.com/watch?v=QVGjpRz0JZU What you DIDN'T know about C# Async EventHandlers The Source of the Problem Normal…
When we discuss async EventHandlers, the first thing that comes to mind for many of us is that it's the only exception that we seem to allow for the dreaded async void setup. When I had written about this before, I was excited that I was exploring a solution that involved actually allowing async void to exist (without wanting to pull the rest of my hair out). For me, this was much more about some clever tricks we can use to overcome async EventHandlers than it was to provide solutions for avoiding the problem entirely. With that said though, there was a lot of traction on the article, which I am very thankful for, and some folks expressed opinions that they'd rather solve async EventHandlers a different way. I thought this was a great point, so I wanted to come…
In C# 9.0 we received access to a great quality of life type called the record. You can read more about that from Microsoft here. Record types allowed us as dotnet programmers to skip a lot of boiler plate code, thereby saving us time and making code more readable. Wins all around! Before record types, we might have simple data transfer objects (called DTOs) that would look something like the following: public sealed class MyData { public MyData( string value1, int value2) { Value1 = value1; Value2 = value2; } publc string Value1 { get; } publc int Value2 { get; } } And for a simple class with two properties... I think we can all agree that the verbosity here is just over the top. With the record type that we were given access to, we can now write…
You're an intermediate dotnet programmer and you mostly know your way around using Tasks. You sprinkle async and await through your code, and everything is working just as expected. You've heard time and time again that you always want the return types of your asynchronous methods to be a Task (or Task<T>) and that async void is essentially the root of all evil. No sweat. One day you go to wire up an event handler using the syntax myObject.SomeEvent += SomeEventHandler, and your event handler needs to await some asynchronous code. You take all of the right steps and change your method signature to get that beautiful async Task added in, replacing void. But suddenly you get a compile error about your event handler not being compatible. You feel trapped. You're scared. And then you do the unspeakable... You change…
As a C# developer, understanding the different simple data types in C# and when to use them is crucial for writing efficient and maintainable code. I've been trying to spend more time this year putting together some content aimed at really introductory level programming. There's plenty of resources available online, but I want to do my part to ensure I can help break down some of the barriers for people getting started on their programming journey. In this beginner's guide, we will look at the basics of the most commonly used simple data types in C#, including int, float, double, byte, char, bool, and string. We will also look at how these data types differ from each other and when to use them in your C# programming! Integer Data Types The most commonly used integer data types in C# are…
(This article is intended to be a spiritual successor to this previous entry, and now includes Tasks!) Even if you're new to C#, you've probably come across at least one of Tasks, Threads, or BackgroundWorkers. With a bit of additional time, it's likely you've seen all three in your journey. They're all ways to run concurrent code in C# and each has its own set of pros and cons. In this article, we will explore how each one operates at a high level. It's worth noting that in most modern .NET applications and libraries you'll see things converging to Tasks. The Approach I've gone ahead and created a test application that you can find here. Because this is in source control, it's possible/likely that it will diverge from what we see in this article, so I just wanted to offer…
Python is a powerful and versatile programming language that has become increasingly popular. For many, it's one of the very first programming languages they pick up when getting started. Some of the highest traffic posts on my blog many years after they were written look at using C# and Python together. Today we're going to explore how you can use Python from inside a C# .NET Core application with much more modern approaches than my original articles. Enter Pythonnet! Pythonnet Package & Getting Started We're going to be looking at Python for .NET in order to accomplish this goal. This library allows you to take advantage of Python installed on the running machine from within your .NET Core applications. You must configure it to point at the corresponding Python DLL that you'd like to use, and after a couple of…
I love dependency injection frameworks ever since I started using them. Specifically, I'm obsessed with using Autofac and I have a hard time developing applications unless I can use a solid DI framework like Autofac! I've recently been working with Xamarin and found that I wanted to use dependency injection, but some of the framework doesn't support this well out of the box. I' was adamant to get something going though, so I wanted to show you my way to make this work. Disclaimer: In its current state, this is certainly a bit of a hack. I'll explain why I've taken this approach though! In your Android projects for Xamarin, any class that inherits from Activity is responsible for being created by the framework. This means where we'd usually have the luxury of passing in dependencies via a constructor and…
Background on Timur's Kernel I got fed up with having a pretty crummy head unit in my 2012 Audi TT RS (named Ignantt), and decided that it was time to take matters into my own hands. Part of doing a Nexus 7 head unit install in a vehicle involves powering the tablet up with a USB on-the-go (OTG) cable and being able to not only power the device but also plug in USB devices into the tablet to use. In order to get this working, everyone seems to be relying on this kernel from Timur. As per Timur's site: This feature allows you to connect one or more USB slave devices to your tablet and charge it at the same time. This allows you, say, to operate an external USB DAC without the tablet ever running out of power. To…
