In March, 2022 (1) Microsoft’s Visual Studio coding tools had a notable security update that caused a full reconfiguration, now done, of Jwc’s Windows version, JwContactsUD. (2) Finally a Multilingual Application Toolkit was released for the Visual Studio 2022 Stable versions, so I could directly add new phrases for translation. (Previously, I had to do this in the former 2019 tools, then copy results over to 2022’s.)
This week Microsoft released (after 14 earlier previews and several release candidates) its new MAUI framework running on Visual Studio for Windows to permit writing one code base for many Operating Systems (Windows, Android, iPad, iPhone, tvOS, Tizen, and Mac). Those previews and candidates often broke efforts under earlier ones, resulting in frequent rework. It is a joy to be beyond THAT phase! My new JwContacts2 will support all but tvOS and Tizen once the Visual Studio MAUI Mac Development tooling is also released, supposedly soon.
JwContacts always follows a coding pattern known as MVVM, designed to isolate what the user sees and can do directly from any means of harming the underlying data. Until MAUI, JwContacts’ MVVM framework was Prism, whose author did make a very early 2021 effort to provide a MAUI version, but has not pursued it. The same proved true of another author of similar software. So, I combined the best I could find of what they had written both for MAUI and earlier and derived my own working MAUI support.
Oddly, Microsoft does have a new tool with MVVM in its name, “Community.Toolkit.Mvvm”, but rather than fully implement that pattern it seems to concentrate on simplifying existing code by eliminating much repetitive “boilerplate” with analyzers that automatically write it for you. JwContacts2 now uses the tool extensively, allowing a large reduction in code I have to write. Even better, I now get improved verification that it works even as I am writing the View coding part of the MVVM pattern, reducing bugs.
Most of what a user sees is the result of software “controls”, which are highly specific to the coding framework. Although MAUI is considered the replacement for Xamarin Forms, “XF”, (on which I always wrote everything until early last year) and its provided controls are often adaptations of XF ones, the way they get displayed (“rendered”) uses an entirely different mechanism. This also meant third-party control vendors have had to provide entirely new control suites. In short, JwContacts2 does not utilize any of JwContacts’ or JwContactsUD’s controls, not even the few I wrote myself. All are new and all have to be tested.
The two 3rd-party control vendors I use have also been trying to keep up with the MAUI previews and have had the same need to rework their code, which also meant reworking mine. One vendor this week has a stable, supported release (but I still have an issue with a very necessary control of his); the other remains in preview and (at the moment) one of my favorite controls of his no longer works in Windows. Hopefully both vendors will soon have stable versions for which I can submit support requests. And MAUI itself still has a Windows issue I had reported to Microsoft weeks ago and another I may eventually report. So, a little more “settling down” must occur before I can hope to release JwContacts2.
I had wondered how many of JwContactsUD’s unique features I could replicate in JwContacts2 for all devices. There is hope it could be all of them, using the brand new MAUI/Blazor Hybrid approach. Blazor appeared in 2020 as a way for web developers to write most of their background code in Microsoft’s C# instead of JavaScript. Everything the user sees via Blazor is actually the result of the browser’s running the same universal HTTP code found throughout the Internet. And all modern browsers support the same single JavaScript library Blazor uses to get C# to work to produce that HTTP code. There are now hundreds of Blazor controls available, including matches for JwContactsUD’s unique abilities.
Blazor can be utilized in a web browser without any sustained Internet connection and MAUI’s hybrid goes several steps further: The “web browser” (actually now called a “web viewer”) no longer looks like a browser but just like a normal MAUI control, can work without ever actually again connecting to the Internet once its controls have downloaded any software they may require to start functioning, can work interchangeably with the rest of the MAUI app, and has the same access to the user’s device as the rest of that app.
This week was largely spent in successfully getting Stimulsoft’s Blazor Report Engine to work in JwContacts2, just as their WPF version does in JwContactsUD. Now Stimulsoft reports display, print, and save identically in both. The extra expense was worth it!
Therefore, I hope soon to also have the same Document Editing and PDF Viewing capabilities in JwContacts2 as in JwContactsUD, although none of those are currently available as native MAUI controls. At least for now, Blazor to the rescue! And I may use a Blazor Scheduler control that works identically to the same vendor’s used in JwContactsUD, although another vendor does have a native MAUI version that works differently. Happily, there should be no further expense for any of these things. There are a couple of strange issues that need addressing, the most important being email no longer works in JwContacts2 for Android, even though it is the exact same code that still works in JwContacts for Android. Interestingly, on the other hand, that code now works in JwContacts2 for the first time in simulated iOS devices (it has always worked in real iOS devices). Unfortunately, my code depends on a 3rd-party offering whose paid support is now lapsed – we’ll see what it takes to resolve this.
