Thursday, May 25, 2023

MAUI App Accelerator version 1.3 is now available!

TLDR: Go here and download it. In addition to bug fixes, it adds a new page and 6 new features you can add to the generated app. 

Screenshot of the the Features step showing 15 options in 5 groups
Yes, this list is getting very big!

I'll be honest; this release has taken longer than I expected and isn't as planned. If you're following the activity on GitHub, you'll have noticed that most of what was originally planned for the 1.3 release is now scheduled for v1.4.

That's probably not what you're here for though. Here's what's included in this release.

A new page: MediaElement

MediaElement option in the wizard
A simple page that includes the MediaElement control. This is for you if you want to play videos in your app.

New Features:


BenchmarkDotNet option in the wizard
Add an additional project to the generated solution that is set up to run performance benchmarks on your code with BenchmarkDotNet.


EFCore.Sqlite option in the wizard
Add a reference to the Entity Framework SQLite library so you can work with SQLite databases with Entity Framework.


Akka.Hosting.Maui option in the wizard
Use Akka.NET actors in your .NET MAUI app.


AlohaKit option in the wizard
Add a reference to the AlohaKit control library to use their controls in your app.


SimpleToolkit option in the wizard

Add a reference to the SimpleToolkit control library to use their controls in your app.

Uranium UI

Uranium UI option in the wizard

Add a reference to the Uranium UI library to use their controls in your app.

If you've made it this far and haven't already, install the extension or update it if you already have it installed.

Suggestions for what else to add is appreciated, as are reviews, and sponsorship.

Wednesday, May 10, 2023

Three years with GitHub Sponsors

I'm trying to be a bit more intentional about my career, money, and where I spend my time/effort. As part of this, I thought it might be interesting to look at my sponsorships via GitHub Sponsors.

I know many people publish full income reports. I don't feel confident enough to do that, but I hope that some of this analysis will still interest others without monetary sums.

Here's the key graph. It's the total amounts received each month.

Line graph showing many peaks and troughs but generally heading up and to the right

While not a smooth graph, it's definitely trending up!

Public vs private sponsorships

There are two broad ways of grouping sponsors. Those that are public or private; and those that are one-off or recurring.

Let's look at the public vs private distinction first.

It's easy to see who the public ones are. Their avatars are shown on my sponsor page.

Avatar images of present and past public sponsors

To save you from having to count, that's 35 public and 12 private.

The only difference to me is that I don't publicly thank the private ones by name.

But are there any differences between the different types of sponsors?

Different amounts from different types of sponsor

The figures in blue (on the left) of each group are the averages from all sponsors. However, as the very spikey graph above might suggest, there have been a few sponsors choosing larger amounts which skew things slightly.
The orange bar excludes the largest and smallest value from each group when calculating the mean.

Recurring sponsors typically pay less each month than a one-off sponsor. This isn't surprising and is almost encouraged.
I found it pleasantly surprising that amongst one-off sponsors, private sponsors pay about 17% more. I'm unsure why or how to use this information, but it intrigues me.

I didn't separate the public and private recurring sponsors, as only one is private.

But averages don't tell the whole story.

Total amounts from recurring vs one-time sponsorships

Unsurprisingly, while I have many fewer recurring sponsors, and the monthly average from each one is less than a one-off sponsor, the total amount from them is nearly three times the amount from one-off sponsorships.

Pie chart - 1/4 representing one-off sponsors and 3/4 for recurring sponsors

I'm not sure this graph needs a legend, but the blue wedge is the total from one-off sponsors, and the green section is from recurring sponsors.

Who I sponsor

I currently only sponsor 1 person through GitHub Sponsors, but I sponsor 6 people through Patreon. Again, without using actual figures, it's only in the last couple of months that the amount I receive through sponsorships is more than the amount I give via Patreon. It's the circle of creative people supporting each other.

Other "interesting" things I noticed during the analysis

One person has made multiple one-off sponsorships.

One person started out by making a one-off sponsorship and, a few months later, came back as a recurring sponsor.

Recurring sponsor durations vary greatly. From 2 months to 3 years (and going). I see no discernable pattern to this.

In summary

While I'm not giving actual figures, I will say that the total for the whole period is about half of what I'd earn in a typical month of paid work. However, over the last three years, this has still been really helpful. As in the last 3.5 years, I've only had paid work for 8 months. (Yay, COVID!)

The most crucial point was when sponsorships helped pay the balance of an unexpected tax bill when I hadn't worked in nearly 2 years!

Now I'm nearly debt free again, and this makes me think about how I can (and should?) give more back to other creators who I want to support.

I also need to think about how, if at all, I can use the above analysis to help encourage more people (or organizations) to become sponsors. (Either of myself or others.)

Tuesday, May 09, 2023

Do you really need MVVM?

MVVM is a popular design pattern, but I think it is often misunderstood, and I frequently encounter people with strong opinions about how/when/where it should be used.

Is MVVM Appropriate?

It's a powerful and useful pattern, but I meet people who use it that have never questioned if they should. It's just "what everyone does" and has become a default for many people.

It being a default isn't necessarily a bad thing, but never questioning decisions can be.

The MVVM pattern allows for separation between the UI/presentation layer and application or business logic.
It is commonly understood to provide 3 potential benefits:

  1. Increased testability (for business/application logic).
  2. Reuse of business/application logic in different projects/solutions/apps.
  3. More easily allow different people to work on the UI and other layers simultaneously.

And yet, I see people who are the sole developers on a project, don't write any tests, and don't need to (re)use any of the code elsewhere being dogmatic about using a pattern for which they get none of the intended benefits.

I admit that there can still be other benefits to using the pattern, but it's always worth questioning whether you should use something if you're not getting (or don't need) the benefits it was designed to provide.

Are you strictly sticking to "rules" of "how things are supposed to be done" when you're not getting or using any of the benefits the pattern was designed to enable and encourage?