Sunday, July 04, 2021

What should you do with your UWP app?

Screenshot from the community call including the comment: "We have no plans right now to release WinUI 3 for UWP in a stable way."

Originally, the expectation was that WinUI3  would have support for both "Desktop" and "UWP" app models.

The focus was initially on Desktop with the promise that UWP would follow. Now, it's looking more and more likely that UWP might never be fully supported by WinUI3.

I can see this as a realistic scenario. The intention might be that one-day UWP support is added but it looks like it's very low priority and there are a lot of other things in front of it.

So, what if you have a UWP app?

If your app is only used on a desktop/PC then consider converting it to WinUI. Probably wait for WinAppSDK v1.0 and check that everything you need is possible in WinUI3 but that's your future.

If your UWP app is for use on desktop/PC and Xbox then you'll need to stick with UWP while we wait on future announcements.

If you're still hoping for a return of Windows Phone, then I can't help you.


Or, you could just keep it as it is. It should be good for a few more years at least.


Thursday, June 24, 2021

A cynical take on today's Windows announcement

A cynical response is all I can manage today.

Plus, my cynical view of past events has been appreciated by some and found entertaining to others.

Let me give you the highlights and answer some questions...

---


Do you remember how Windows 10 was going to be the last version of Windows?

....

Introducing Windows 11


Eventually. It seems that in an online event about the future of Windows, they're using streaming tech from ten years ago.

Windows logo with buffering icon overlaid
(and also, this)


Do you remember how Windows 8 changed the start menu and how people complained and then, in response, Microsoft put it back where and how it was?

It's moved.

And looks different.


Anyone taking bets on how long before there's an app in the store that mimics the old start menu?


--- 


"Hey Matt, as you're a Windows Development MVP. What can you tell us about developing for Windows 11?"

Only what was in the announcement. I had no advanced knowledge of today's announcements. I only knew it was coming from the "leaks" on Twitter. There is also an official blog post announcement for developers.


"There seems to be a lack of major changes. It looks a lot like an update to Windows 10 but with an extensive UI refresh."

- Yes, it does. Doesn't it. Hopefully, we'll see the bigger differences in time.


"There seems to be a big focus on PC gaming."

- Yes, there does. People use PCs for gaming. A lot!


"Is this why there haven't been any big updates for Windows in the last few years?"

- Probably. Of course, it's complicated, and there can't be big changes every few months, but this could be connected by the fact I can't remember any noteworthy updates for Windows 10 within the last 2 years.


"There was a lot of focus in an updated UI. Will all apps from Microsoft be updated and look like this?"

- You can probably expect most of Office to look like this and many of the apps that come with Windows to be updated, but there will be some that aren't updated and will keep the look they've had for years (forever!)
From a development perspective, I'm curious what happens with the controls in WPF & WinForms apps.


"Will everything go (back?) to having rounded corners?"

- The trend for rounded and square corners alternates. Don't worry if you're not a fan. It'll change again in a few years.


"A lot was made of the 'sheet of glass' look in the video. This looks like what was called 'Acrylic' previously. Is it the same thing?"

- Very similar. There's more about Mica in the docs.
Again, with my developer hat on, I'm aware of issues relating to using and implementing Acrylic for WinUI3. So let's see where, when, and how this is available to developers...


"I'm curious about how the new design is meant to help 'bring a sense to calm.' What about all the slow, buggy apps and poor UX experiences that frustrate me? Are these getting fixed as well? Or is the new design merely a distraction from poor UX?"

- Let's hope that work is being done to help with the poor UX of many apps. I don't think an OS update will magically fix anything in this area, though. BTW. If you're interested in improving the UX of your app, I wrote a book that can help you.


"Some of the new features look like updated versions of things that were already available in PowerToys. What's up with that?"

- One of the goals of Power Toys is to try things out that may eventually end up "in the box." This is an example of the learning from Power Toys making it into the OS. It's not the same, and I don't expect to give up using Fancy Zones even when using Windows 11.


"A lot of the announced productivity features are things that we've been asking for for years or are things that already exist (such as vertical tabs in Edge) are they worth making a big deal about?"

- Time will tell when we've had a chance to use them for a while. Hopefully, lots of little improvements will lead to a big overall improvement.


"If Teams is integrated into Windows, does this mean they've fixed all those annoying inconsistencies, bugs, and issues with switching between tenants?"

- Let's hope so....


"Windows widgets seem a lot like updated versions of live tiles from Windows Phone and Windows 8?"

- That's definitely a reasonable comparison.


"The page for getting more information (https://www.microsoft.com/en-us/windows/windows-11) includes a tool that can be downloaded to check for device compatibility, but it's packaged as an MSI, rather than an MSIX. I thought MSIX was the recommended format for installing apps. Why isn't this being used? Is MSIX supported for Windows 11?"

- Expect MSIX to continue to work on Windows 11. MSI still works. I assume that it wasn't used here to enable support on devices running ancient versions of Windows that don't support MSIX. 


"What can you say about the game pass?"

- Nothing. Games aren't really my thing. (I might be getting old and boring...)


"What's with the new store? This seems to get a refresh every few years, but people don't like using it, and it seems to regularly give unhelpful error messages."
- The store has been rewritten, and hopefully, this will address many of the issues. More here


"Android apps running on Windows!!! What's that about? Wasn't it tried before?"

- Yes, this was tried before. Hopefully, the new "Intel Bridge" will work better than past efforts, as it emulates ARM instructions on Intel processors. Expect there to be limits on what those apps can do when running on Windows, though. Not that there will be things that don't work (there may be a few edge cases) but don't expect them to use all the native features of Windows when they were built for Android.
This is based on the "Windows Subsystem for Android." (Yes, similar to and related to the Windows Subsystem for Linux)


"What else is coming for Windows app developers?"

- A few things:

  1. With the new store, you can use whatever you want to handle commerce, and Microsoft won't take a cut if you use a separate payment solution.
  2. An update to PWABuilder.
  3. A reinforcement of the intention that you should consider WinUI3 as the framework of choice for building native Windows apps.


"Any updates related to WinUI3?"

- Not really. Version 0.8 is now officially released. But most of the work that has been done since the last release (v0.5) has been experimental work in preparation for the 1.0 release.


"What's the 'Windows Apps SDK'?"

- That's the official name for what was previously known as "Project Reunion." 
(Yes, it's a long wait for an uninspiring name. I wonder what else was considered and rejected...)


"Apparently, 'Windows is more Open' now, does that mean Open Source?"

- Nope, I don't expect Windows to ever be fully open source, but some technologies and parts of it are, and more are expected in the future.



All this is very new. I make no guarantees about the above and expect to share more information in the future.


Friday, June 18, 2021

I don't think you should only test manually

In response to my post When it's Ok to break the build some people thought I was trying to argue against using CI/CD tooling to test changes.

This isn't the case.

Only running tests manually and/or on your main development machine can be slow and a waste of resources.

Creating a draft PR to test against a large test suite and only raise to a full PR when everything has been confirmed as being ok is a good way of working.

Pushing local changes to a private branch with a CI/CD process running tests against it can be a good way of working.

Either of the above is also a good way of incorporating the execution of extensive test suites or tests that involve multiple environments or varied configurations that would be impractical to set up or maintain on each developer's machine.


My objections and concerns come when a full (non-draft) PR is raised before tests have been run.



BTW. I'm currently planning a book all about testing. It will focus more on the concepts than the details, but I think I can bring some new ideas to the subject. (Hopefully, I'll do a better job at avoiding confusion than I did in that other post.) If you want to know more, be sure to sign up for my (very occasional) newsletter. 

Thursday, June 17, 2021

When it's Ok to break the build

For some teams, and some developers, breaking the build is a terrible thing that should be avoided at all costs. (Not just because you may have to buy everyone donuts if you do.)

Dunkin'Donuts donut box


I used to be fine with anyone breaking the build (and not just because I like donuts.)

This came with some qualifications:

  • You shouldn't do it deliberately.
  • You should be making small, frequent changes that are less likely to break anything.
  • You should fix the build ASAP if you do. (You don't go home having broken the build as you'll be blocking other people.)
But, all in all, I'd not sweat it if someone broke the build. I'd rather they were doing that because they were shipping code and not sitting on massive changes or holding back because they were worried about breaking it.

For the most part, this approach has worked well for many years.

But recently, I've encountered behavior that's making me reconsider this idea.


The behavior I've seen is developers using the CI process as a way to validate their code.

I've seen attitudes like:

"If it fails, I'll find out when the CI process tries to build it as part of the PR automation."

"I won't bother running the tests myself as the CI process will do it for me."

"If the CI process fails, it will create a new issue, and if I fix that, it looks like I'm closing more issues."


These thoughts scare me:

  • They indicate a lack of professionalism and pride in the work being done.
    (Why wouldn't you check that it works before saying you're finished?)

  • They indicate a lack of respect for the value of testing.
    (Why wouldn't you check that there are no unintended consequences of the changes you've made by running the tests? - Ok, It may take a while, but surely it's better to be safe than sorry. If running them takes a long time, isn't it better to know about problems sooner? And especially to know about them before you get engrossed in whatever the next thing is.)

  • They suggest you can work the system to look more valuable and productive, and presumably, the organization rewards this.
    (This sounds like you've found a way to make your life simpler at a cost to the product, the company, and the team/your peers. That doesn't sound healthy. It sounds like your manipulating the data to appear to be closing more bugs when actually you're the cause of many of them.)


Don't be like that.
Make an effort to ensure that your code works, doesn't break anything else or have unintended side effects, and that you're helping your team to all be as productive as possible.


So, when is it ok to break the build?

If it's an accident that you attempted to avoid, and will fix it quickly.


When is it not Ok to break the build?

There are many reasons, but my current bug-bear is that it's not ok to break the build if you do it because of laziness.


Saturday, June 05, 2021

Is this TDD? (When you can't do: Red-Green-Refactor)

I've been thinking a lot about testing recently.

Specifically, I've been thinking about using TDD and legacy code. (Yes, I've got Michael Feathers's book and will need to reread it. This is probably covered there.)

So, I've just received a bug report that I decide to work on and fix:

  1. I created some tests that recreate the issue. Running them verified that they reproduced the issue (they failed) so my tests were RED.
  2. I then changed the code so the tests passed. Now my tests were all GREEN.
  3. Then I tidied up the code a bit more. (I REFACTORED the code.)
  4. Finally, I ran the tests again to make sure they all still pass. They did.

  5. But then I thought of another edge case that wasn't currently tested but probably should be.
  6. So, I create a test. And, it passes!
Oh, no! It didn't go Red first, so I can't be doing "proper TDD"™.

I'm happy that the code does correctly handle (and document) this test case but how should I test it "properly"?

  • Change the code so the test fails? and then change it back?
  • Change the test so it fails? and then change it back?
  • Just leave it?
  • Something else?

What would you do?



BTW. I'm currently planning a book all about testing. It will focus more on the concepts than the details but I think I can bring some new ideas to the subject. (Despite what you may think by me asking this question.) If you want to know more, be sure to sign up for my (very occasional) newsletter.