Monday, January 30, 2023

MAUI App Accelerator version 1.2 is now available - What's new?

Version 1.2 adds:

  • 1 new Navigation Style: None (No Shell)
  • 4 new pages: Map, NavigationPage, TabbedPage, & FlyoutPage
  • 7 new features: FontAwesome, sqlite-net-pcl, AppCenter, Sentry.io, InAppBilling, StoreReview, & Audio
  • Use of the newest versions of NuGet packages.
  • Support OS-level Text Sizes in the wizard (for improved accessibility.
  • Some bug fixes
  • Improved testing (although you'll never see that)
  • Images of new sponsors - a big thank you to all of them
  • Support for all the sponsor images when the wizard is too small. 

Let me break that down.


New Navigation Style: "None"

Don't want to use Shell? - Now you have that option.

Wizard showing the "None" option for "Navigation Style"

New Pages:

If you're targeting .NET 7.0 you can now create a page with a map on it (and the relevant package referenced and configured in the app Builder.)

This means you can easily create the following on Android & iOS.

But not on Windows--because it doesn't (yet?) have a native map control. :(


If you're not using Shell, you may also want to use one of the page types that aren't supported by Shell. Now you can:

FlyoutPage, NavigationPage, & TabbedPage options in the wizard

New Features:

There are lots of new features that have been added.

The "Add Features" step in teh wizard showing all the newly added options.

Most of these add references/files and do essential configuration. 

Hopefully, this provides an idea of what's possible and hints at where I'd like to go with this in the future.

If it gives you ideas for what you want to see added to this list, please create a suitable issue.


Updated NuGet package references:

I find it very disappointing when you create a new project, and the first thing you need to do is update all the referenced NuGet packages to pick up the latest features, fixes, and security patches.

Well, not here. Everything 


Support for OS-level text sizing:

In the past, if someone had configured Windows to make text larger, like this:

Partial screenshot of the "Make text bigger" option in the "ease of access" or accessibility settings
Then the wizard could end up looking "less than ideal." All the buttons are at least accessible, even if you can't read all the text.

Wizard not coping with resized text

Most of this UI had come from Windows Template Studio and had design and accessibility reviews by the Visual Studio team. I was surprised this was an issue.

But, now it's not:

The updated wizard that adjusts to increased text sizes

This isn't something I've ever considered previously. For the most part, addressing the issues was easy, but some things were harder than I would have hoped. This includes testing the related changes. I guess that part of the reason this hasn't been noticed before is that there are no automated testing tools for verifying this behavior, and to manually test requires changing an OS setting. Hopefully, this will change in the future.


New sponsor images & Improved handling of so many sponsor images:

Having a lot of people sponsor me via GitHub is a lovely thing. In appreciation of this, I tell them how to remove the prompt to become a sponsor that is shown in some extensions. And if their sponsorship isn't private, I add their avatar to the bottom of the wizard.

Like this:

Sponsor avatar images

However, when the wizard is made smaller, some of those images are obscured.


Hey, I'm not complaining. This is a nice problem to have, and I want to respect all my sponsors, not just those displayed on the leftmost edge of the screen.

So, now this happens when the screen gets smaller:

Yes, I have wasted several minutes watching as things overlap when the available space is reduced.


Please download version 1.2, try it, and tell me what you think. (If it's good, leave a review on the marketplace so others can see it too.)

Then, if you have suggestions for other things I can add, head over to the GitHub repo and create, upvote, or comment on a suitable issue.




Did you know that GitHub sponsors can be Private?

When you sponsor someone via GitHub Sponsors, there's an option to make your sponsorship public (so everyone can see it) or private (so only you and the sponsor know about it.)

Partial screenshot of the sponsorship form. Title: Who can see your sponsorhsip? Option 1: Everyone - Others can see that you sponsor mrlacey. Option 2: Private - only mrlacey will be able to see that you are a sponsor

Why might you want to keep your sponsorship private?

Well, you may have many reasons. 

If I had to speculate, one reason I've assumed is that you don't want other people asking you to sponsor them too, or questioning why you are sponsoring a person.

I've had a few well-known people (in the Microsoft/.NET world) sponsor me. This was very surprising and flattering, but I can easily see other people online reacting to this knowledge negatively or demanding that they sponsor them too.

All I can do is thank these secret benefactors.

Whatever your reason, I (or anyone else you chose to sponsor) will always be grateful for your sponsorship.


If you do sponsor me, you will get:

  • My gratitude.
  • The knowledge that you're helping me create tools to help more developers do more. (like this.)
  • Details of how to remove the prompt to become a sponsor that's shown by some of my extensions.
  • Early access to my writings and some tools via a private GitHub repo. (recurring sponsors only--for now, based on how the GitHub sponsors infrastructure makes this possible.)
  • If not a "private" sponsorship, I display your avatar in some of my tools. As below. (Position and duration of inclusion depend upon sponsorship amount and if one-off or recurring.)

partial screenshot of the MAUI App Accelerator windows showing images of all public sponsor avatars


Any amount, one-off or recurring, for as long as you wish. Your sponsorship will be appreciated. :)


And a big thank you once again to all who have, are, or will sponsor my activities.


Sunday, January 29, 2023

All my Visual Studio extensions now work on ARM64 - thanks to GitHub sponsors

Thank you, lovely sponsors!


My MacBook is broken. According to the "Genius" I spoke to, it's not dangerous, but if it gets worse, I shouldn't use it anymore.

My plan had been to replace that and then start thinking about getting an ARM64 device for Windows development and testing.

But then I started to get requests for supporting my Visual Studio extensions on the ARM64 version. In that, those sponsoring me on GitHub are primarily in response to the extensions I've made, it made sense to use the money they've generously provided to be able to enhance those extensions so more people can use them.

So I put the sponsorship money towards a Windows Dev Kit so I can test the extensions in a suitable environment. Technically, it's not needed for development, but I didn't want to release anything that isn't adequately tested.


So, what can you do?

Well, here are the supported extensions:


Warn about TODOs

Visual Studio automatically takes code comments that include TODO and turns them into User Tasks that are displayed on the Task List.

This extension takes those same tasks and also creates warnings for them.

You can also configure which items result in warnings (or Errors) being listed. Like here:

Example of filtered TODO items shown in the Error List

Error Helper

Make it easier to work with items in the Visual Studio Error List by copying or searching (with Ecosia, Bing, Google, or StackOverflow) for just the description of an error.

Additional items shown in the drop down

WaterMark

Display a text watermark over the Visual Studio editor.

Visual Studio Editor window showing (highlighted) as watermark of my Twitter handle

C# Inline Color Visualizer

See samples of the colors you use within your C# code.

Never again be forced to remember what a named color looks like.

Examples of a number of colors specified in different ways in C#

Clearly Editable

A Visual Studio 2022 extension to change the editor's background color to show which documents can't or shouldn't be edited. This could be because that are generated, read-only, or linked files.

Example of the backgrounds set on different editor windows

String Resource Visualizer

Visual Studio extension that shows the text of a string resource (.resx) when used inline in code.

The default language value is displayed as a text string directly above where the resource is used. As shown in the screenshot below.

Use it in your C# files

C# editor screenshot showing resource values

and in .cshtml files with the ASP.NET Localizer

Editor showing resource values as used by the ASP.NET Localizer

Const Visualizer

A Visual Studio extension to show the values of constants where they are used.

screenshot showing const values above their use elsewhere in code


Comment Links

Create links between any files. Useful if your project or solution contains code in multiple languages or if you wish to link to documentation.

Watch an example on YouTube
YouTube link


Don't Copy Always

Automatically checks for files that have 'Copy to output directory' set to 'Copy always'.

Any affected files will be listed in the Output Pane.


Resource Pseudo Localizer

Testing localized string resources can be tricky, especially if you don't speak multiple languages. This extension adds a new context menu to RESX and RESW files in Solution Explorer that will allow you to pseudo Localize your string resources. Viewing the app with pseudo-localized strings makes it easy to spot any text that doesn't come from a resource.

Context menu showing available options

Demo Snippets

Makes using code snippets in demos easy. Do real demos but without having to worry about typing or managing pieces of code to copy in from elsewhere.



Coming soon:

MAUI App Accelerator

Rapid XAML Toolkit


A big thank you to all my lovely sponsors. (You could become one too.)
Who knows what future sponsorship money will enable me to do.....?

Tuesday, January 10, 2023

4 Ways 'MAUI App Accelerator' can save you time (and money)

Step 4 (Add Pages) of the extension wizard

MAUI App Accelerator (marketplace link) is a Visual Studio extension that can help you start making apps with .NET MAUI.

It shows several best practices and examples and is intended to help you start building the app you want to make and do it faster and with less effort.

Here's how:


1. It lets you start with something closer to what you actually want!

The default app generated by the official new app template gives you a single page with content that you'll probably want to delete.

Instead, MAUI App Accelerator lets you choose the coding pattern and navigation style that you want to use. You can then add as many pages as you want/need. These pages can be blank or include some basic content--if that's what you'd like. It also adds any view models, navigation entries, dependency references, and anything else you need based on the options you choose.

It also lets you add references to libraries you want and adds in any basic, associated plumbing code. All with a single click.

It means that once you click "Create" you have something you can add your specific code to. You don't need to then start setting up the project structure and adding more references.


2. It forces you to think before starting your project.

I think this is the most important point. How often have you ended up spending more time overall because you rushed into something (not just code) and need up having to go back and change it? 

If you'd spent more time planning things in advance, you'd have saved more time overall.

I've seen many developers start projects by selecting "File > New Project > {selecting options}> Create" and only then stopping to think about what they're going to need in their project. By wiring up more functionality at the start and adding multiple pages (that you know you're going to need), you're forced to think about what you actually need in the app. 

Yes, you can still add to the generated app, but by being encouraged to do a little planning in advance, you'll save more time overall.


3. It makes it easier to try out new things.

Want to quickly try something that requires an app with two pages? Yes, you could create this yourself, but MAUI App Accelerator will let you do it faster and with less effort.

Want to try a specific control that has a sample page in the options presented in the wizard? Generating an app with that page can be much quicker than adding all the code and wiring up the control functionality yourself.


4. It lets you learn from complete examples. 

Want to try something new? With MAUI App Accelerator, you're not forced to rely on documentation or descriptions.

Maybe you've got no experience with MVVM, and you'd like to learn, but the resources online are confusing (& sometimes contradictory) and working with event-handlers and code-behind has always been sufficient for you. Well, you can now easily build the same app twice, once with code-behind and once with MVVM, and compare to see the differences. 

Or do the same with an app that uses XAML and one that generates the UI with C#. See what the differences are and how things work by comparing apps with identical functionality and content.


To enjoy these benefits yourself, simply install the extension. Then, when creating your next project, select `MAUI App Accelerator` in the new project wizard.

The 'MAUI App Accelerator' option in the new project wizard



Friday, December 30, 2022

Understability of code should be the default priority

All things being equal, so not when performance is an issue, and in addition to any existing coding conventions, the understandability of code is the most important thing.


Typically this means, "can I read the and easily understand 'everything' about it?"


In the past, I've said that "readability" is the most important thing but what I've realized lately is that I mean: can I easily read it AND understand it?


This is more important than "SOLID principles" or "Clean Code."


Delivering value is the end goal when writing code. The code is a means to an end. It's not an end on its own. The primary goal is not to have code that meets a specific standard. Even if there are appreciable benefits from following that standard. The goal is to benefit the people using the code.


Yes, there are many reasons for following established principles, practices, and conventions. I recommend and follow many myself. But they're not the most important thing.


It doesn't matter how great the code is if you don't ship.

It's great that you've structured code to make it easy to maintain, but if you don't release bug fixes or new features, I question the value of the effort put into how the codebase is structured.


I've seen code that is technically "clean" but is slow and hard to understand and modify.


I recently met some developers at a company who highly prioritize "clean code." But, their shipping schedule was so slow that their customers complained about the infrequency of new features and updates. They had a massive backlog of "core" functionality that was expected to take years to be implemented. Their competitors had more features, more customers, and a better reputation. The developers at this company wanted to create a better product but admitted that their focus on "clean code" meant their development process wasn't as fast as it could be. I'm not implying it's the only issue or factor, but the product, their customers, and ultimately their business weren't as competitive as they could be because of an arbitrary set of rules they were enforcing upon themselves.


Obviously, there are multiple factors to consider when deciding what to prioritize. Priorities will also differ for products, domains, and personal preferences, but having a fixed rule that is never changed can hurt as much as it's designed to help.


Test coverage is also an important related factor. If I'm not writing something "test-first" (because sometimes this isn't practical or desirable), my guiding principle is that anything "non-trivial" should have tests. I define "non-trivial" as anything where I can't look at the code and immediately see and understand every code path and likely error case. It's not always perfect, but it's served me well for years.   


I don't have any "hard and fast rules" for when to play specific practices or when to structure code in specific ways, but "is this easy for me to read and understand?" is my guiding principle. And if I'm working with a team, having code reviews can verify that others working on the code can read and understand it too.


If I can understand it, I'm aware of the potential consequences of any changes, regardless of how it's structured.



I'm curious if others have general principles for planning and structuring code. Anything that doesn't include "must" or "always" (or treats "should" like "must") but instead acknowledges the complexities of managing multiple priorities in different circumstances.