[Enhancement] Support Microsoft MAUI platform

[orwo1]

Summary

It would be helpful if the library was ported to support Microsoft's MAUI platform.

API Changes

Interface with new implementation of resources handling in MAUI
Update controls to support new native handlers instead of Xamarin.Forms renderers.

Intended Use Case

We would like to keep the images we currently have, and use the same nuget with its controls, behaviors and services.

[orwo1]

?

[baskren]

@orwo1 : I would agree - but I'm not the guy to do it. Having spent a lot of time with both MAUI and UNO, I can't see the value proposition (for me) to port Forms9Patch to MAUI. UNO is just more feature complete, covers a LOT more platforms, and (because the Uno team Dogfoods their framework) it MUCH MORE RELIABLE.

I have migrated some parts of Forms9Patch to UNO, in the form of the following packages:

• https://github.com/baskren/P42.Uno.Controls
• https://github.com/baskren/P42.Uno.HtmlExtensions
• https://github.com/baskren/P42.Uno.Xamarin.Essentials
• https://github.com/baskren/P42.Uno.Markup
• https://github.com/baskren/P42.Uno.HardwareKeys

... only because most of what necessitated me making Forms9Patch in the first place is already built-in to UNO. And, over time, they've made more and more of Forms9Patch redundant. Based upon what I've seen they've already made a good bit of the above libraries redundant (which is great for me)!

You may not have the luxury of looking at an alternative framework (it took me 9 months to convince one of my clients to switch to Uno) but I'm pretty sure you won't regret it.

[baskren]

@orwo1 : One more thing. There are some MAJOR differences under the covers between how MAUI is architected and how UNO is architected. Since uno doesn't use bait-and-switch nor uses renders:

1. Things don't break as easily during linking - and its AOT code is faster.
2. It's much, much easier to make custom stuff at the native level.

[smalgin]

@baskren thanks for the explanation. I was not really optimistic about MAUI migration, but your packages will give me a bit of a boost with UNO, that helps. On the other hand, I use MS AppCenter builds. AppCenter + UNO = Unknown (at least to me at this point in time).

[baskren]

@smalgin : good question. I use AppCenter for Analytics and Crash reporting - but not builds. I do use GitHub Actions for my beta and production UNO.WASM builds for the sake of deploying to a Azure Static WebApp.

[baskren]

@smalgin : I should have said "I use AppCenter, with UNO, for Analytics and Crash Reporting..."

[smalgin]

@baskren Thanks. Now that I actually began looking - there's MAUI (uses platform UI toolkits), UNO (open source alternative, uses platform UI toolkits, and Skia for Linux), and Avalonia (uses Skia for identical cross-platform rendering woo hoo) https://github.com/AvaloniaUI

There are also various posts on how to configure AppCenter to build for UNO, looks pretty straightforward. All of the above use C# and XAML, so that's a bonus for a migration route.

I am still stuck behind because my Mac is old, and I can't switch my iOS solution to use VS 2020 :) But one can dream, yes...

[smalgin]

For the record, Uno Platform beats Avalonia so far in terms of general polishing :)
The PLAYGROUND is pure gold https://playground.platform.uno/#wasm-start

[orwo1]

Avalonia has been in the background for so long without any real world push it is no longer an option for enterprise application in production.
Uno is an option but we'll have to learn more about it first.
Regarding not porting to MAUI because its not Uno, I don't know.
I don't get why it even stops you from porting, supposedly should be easy as they're pretty close to one another.
Like Uno, MAUI has their own solution to multi resolution images but they rely on using SVG files.
We would like to reuse existing resources, and of course the same libraries, when porting to MAUI.
MAUI is at present our preferred path only because Xamarin.Forms won't support future Android and iOS release
beyond May 2024, and the fact that they are fairly similar.
Won't porting to MAUI be attractive as more people and orgs move to it by default, like us?

[smalgin]

@orwo1 - following @baskren 's logic - MAUI also has the services that will render f9p partially obsolete. Did you check what parts of f9p you need vs what MAUI already has? I would say, the proper path forward would be to doing something @baskren did, freeze f9p along with the Xamarin - and, for example, fork p42 utilities above for MAUI, filling the blanks -if-needed-.
Let's do some planning first? I might be able to lend a hand, since I am on the fence between MAUI and Uno.

[baskren]

Some comments:

I sized porting Forms9Patch to MAUI - it was just going to take too much time and MAUI just wasn't mature enough to justify the effort. Forms9Patch has a LOT of platform specific code that won't migrate with the automated migration tools (I tried). Fortunately, there are a number of parts of Forms9Patch now implemented in MAUI ... and more implemented in UNO. Still not everything (hence why I wrote the libraries I referenced, above). It does seem that, every six months, Uno continues to flush out the WinUI API - and thus making those libraries redundant. For example, I spent a lot of time building PDF and printing functionality into P42.Uno.HtmlExtensions --- The Uno.Toolkit library recently added printing (although I haven't played with it yet). Too bad my pockets were deep enough that I could have influence over their roadmap.

FormsGestures was the real "nail in the coffin" for my decision to not port Forms9Patch to MAUI. Everytime I think I should obsolete it, there would be a use case where Xamarin.Forms's gestures didn't work and I needed to use FormsGestures. When I tried to see if those same gesture issues existed in MAUI, I was dissapointed to learn that some of them were. I was crushed because writing and testing FormsGestures was just too much work.

@orwo1 : I've heard that Uno 5 (coming out in January) will have a major streamlining of how it handles images and fonts. I expect it will be on par to what happened with images when Xamarin.Forms became MAUI - but (I'm guessing) an attempt to be consistent in handling those resources in the "WinUI" way?

@smalgin : Good question about forking P42.Utils - it should be framework agnostic. P42.Utils does have a companion library for Uno - P42.Utils.Uno - that adds more Uno specific functionality. That being said, I haven't touched the platform (iOS, Android, UWP) specific permutations of P42.Utils in a very long time (Uno pretty much made that no longer necessary). At the current time, I've been maintaining separate Xamarin.Forms and Uno branches of P42.Utils - a very stupid and lazy thing on my part. It might be worth cleaning that up and returning back to one branch for all platforms and frameworks.

[orwo1]

@baskren Yes that's the main thing.
To be consistent means we can maintain the app in the long run.
If every 2-3 years we have to rewrite everything to support another platform just to keep up with mobile OS releases,
its both unproductive and unmaintainable.

[baskren]

@smalgin : one thing I forgot to ask, in response to your comment about having an older mac. Do you use a newer Windows machine? I ask this because (unfortunately) Microsoft's support of VSMAC 2022 is terrible - productivity there has (for me) crashed since the November update. As a result, painfully, I've had to switch all my development work to VS Windows 2022 and use the PC to Mac pairing for iOS specific development. Actually, my whole paradigm has changed (not because I wanted to). Before, I used to develop Android first because that's where all the problems would be. iOS just worked. Now, I develop WinUI first, because it's the fastest to build/run/debug. I do WASM next because that's where the problems might be. Next Android (because it's still not perfect) and last, iOS (because it still, almost always, "just works"). That workflow keeps me away from MacOS - I'm sure to the pleasure of some Microsoft executive somewhere. Of course, for everything else, I return back to Macos.

So, for you, the question isn't "VSMAC 2022", but does Pair-to-mac work between VSWIN 2022 and VSMAC 2019? If it does, then you might be able to get up and running.

[UnreachableCode]

Great Framework, Baskren, and I appreciate that you don't have infinite time to work on this.

I'm working with a Xamarin app that has a webview with HTML that we turn into a PDF. It works great for now. If we upgrade to MAUI, I'm guessing the package will just stop working? So would it be simple to just harness the ToPDFAsync method, and it's platform specific parts, and port that to MAUI? Has anyone done something similar?

[baskren]

@UnreachableCode

Charlie - I'm not aware if anyone has started porting this to Maui. FWIW, I've ported this to UNO as a series of more or less stand alone packages. You might find porting them to MAUI much easier than porting Forms9Patch:

For WebView or HTML printing or conversion to PDF:

• https://github.com/baskren/P42.Uno.HtmlExtensions

And other things that Forms9Patch does:

• https://github.com/baskren/P42.Uno.Xamarin.Essentials
• https://github.com/baskren/P42.Uno.HardwareKeys
• https://github.com/baskren/P42.Uno.Controls

[UnreachableCode]

Thank you! I will try this approach.

[smalgin]

Hi. I don't have any flavor of VSMAC, I pair VS 2019 with the older XCode. (VS 2022 won't pair and XCode can't be upgraded further on that laptop). I currently focus on Android + IPhone apps, no WinUI/WASM planned yet.

[xoogit]

@baskren - Do you have any write-ups on how to migrate your Forms9Patch to UNO? Thanks.