Monday, August 30, 2021

Creating Cross-platform C# Applications with Uno Platform

That sounds like a good name for a book. Doesn't it? ;)

And it is.

Book cover: Creating Cross-platform C# Applications with Uno Platform

I know that when I finished my first book I made a specific point of calling it "my book and not my first book."

Save your judgment.

Like most writers, after finishing my first book, I wasn't in a hurry to ever write anything again.

But things, and times, change.


While I wasn't in a hurry to write another book I was still using writing as a way to communicate and pass on information.

Last year, I realized there were specific things I didn't know about the writing process and set out to understand them better. I wanted to learn so I could be a better writer and communicate more effectively. So, I spent much of the first pandemic lockdown reading books about writing, watching videos about writing, listening to podcasts about writing, and attending online workshops about writing.


Fast forward to earlier this year, and I was approached about writing a book about Uno Platform.

I wasn't in a position to write a whole book but the publisher called my bluff and agreed to me becoming a contributor to one. I figured I could write four chapters of a book and learn more about the process that would help me with my own future self-publishing plans. (More details of these at another time.) It would also be a way to test if I could apply what I'd been learning.

When it suits me, I can be quite assertive and I had strong ideas about what this book should and shouldn't be. I was keen that if I was writing the book, it would be distinctive. There's no point in me doing what just anyone could do. I wanted to make this my own. (Well the chapters I was writing, at least.)

When it comes to technical books there is a convention that over the course of the book the reader will build a basic app and each chapter will add to it as a way to learn about and demonstrate, a new feature or area of functionality. I didn't want to do this and my reasoning is threefold:

  1. I didn't want it to be like every other book. 
  2. I'm not a fan of this convention as it tends to strong-arm features into an app in an unnatural way. I knew trying to do something I'm not a fan of would be frustrating and as writing a book is already a slow, hard, frustrating process this wouldn't be good for my sanity or motivation.
    (I mean no offense to people who write such books. I have great respect for you as you're doing something I can't.)
  3. Most importantly, it didn't fit the subject. 
    Uno Platform enables the creation of an app that can be compiled for multiple platforms but the number of cases where it is appropriate to have the same app run on all those platforms is very small. Instead, I thought it more appropriate to show how Uno Platform can be used to create apps for a number of different scenarios that demonstrated appropriate features running on appropriate devices/platforms.
So, instead of a book that walks you through building one app over the course of many chapters, this book shows how to create multiple apps, one per chapter. The goal is to show how Uno Platform could be used within an organization that needs to build lots of different kinds of apps (both internal and public-facing.) My hope is that when you see the organization we use, and the variety of the apps of apps we create there will be something you can relate to and is comparable with the apps you are considering building.

The book attempts to answer the question "Can I use Uno Platform to build the apps I need to?"
Obviously, there's some theory and an explanation of when and why you would use Uno Platform, but my hope is that by showing how Uno Platform can be used to build some very different apps, that run on different devices (mobile, desktop, and web) you'll see where and how you could be using Uno Platform too.

Is this ambitious for a short, introductory book?
Will I learn that all those other books only build one simple app because it's better for the reader than building many apps?
Will everyone involved have the same vision for the book as me?
Possibly.
You'll have to buy it to find out.



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.