Move the library over to MAUI. #138
Conversation
Using MAUI Compatibility I've compiled the library under VS2022 17.2.0 Preview 6.0 for MAUI and included an example app that's modeled after the current. Android works, Windows works but doesn't display lists (?), Mac/Tizen are not implemented, and iOS throws an InvalidCastException in the depths of MAUI code. It's a start.
bakerhillpins
changed the title
…anch. I was experimenting with code ported over from the XF iOS implementation of Label and had always intended on pulling this before I committed it. Seems I forgot, so pull it out now.
|
@bakerhillpins That seems great! I am not up to date with the latest Xamarin developments so it's hard for me to validate anything really. But I will try to learn more as it seems the way forward. Time to buy a mac again maybe |
Migrate to the MAUI custom control implementation. The basic wireframe structure that MS suggests is implemented and I've plumbed up enough to get the HTML text to properly render on both Android and Windows. I'll be trying iOS next. HtmlLabel is only reacting to the TextProperty, no other individual property updates are implemented/working. The namespaces and file structure will receive more organizational work when I've got a better handle on what I think MS is suggesting.
|
@matteobortolazzo If someone wants to run with the Compatibility implementation they can branch off of commit c30cd5d above. |
Not all of it appears to be correct though (like Italics) but it's loading up and running. It's inheriting from the Maui.Controls.Label handler implementation (UILabel) rather than implementing it's own functions with the native UITextView like the Xamarin based one was.
These properties didn't follow the .NET BindableProperty pattern with naming and as such it kept MAUI from properly making the connection when they were updated. Specifically I saw this when editing XAML while running in Debug.
It still calls AddTransient under the hood but this is what's in all the examples.
No functional changes, Simply move files, namespaces, rename variables, etc. so that the project structure more closely resembles the format that MAUI designers suggest. See: https://github.com/jsuarezruiz/xamarin-forms-to-net-maui/tree/main/Library/.NET%20MAUI/Library
|
@matteobortolazzo - I've moved the project to a file/project format that the MAUI team appears to suggest in their examples. In doing so I've changed the Namespaces and other Package name elements. I've moved from the Xam/Plugin/Forms names to Maui and removed the root namespace HtmlLabel because I got annoyed with how it interfered with intellisense when coding. The Root namespace choice Thanks, |
|
@matteobortolazzo Still have plans to work on this. Need to finish moving some other code over to MAUI first. |
|
Sure, thanks for the effort you are putting into it!! I will not merge until you are happy. About the namespace, I need to think about it when I focus on this project |
|
@bakerhillpins How are things going on this heroic endeavor? I don't mind helping to test things out when you're at a good stopping point! |
Honestly, It got bogged down in dealing with the handlers for each property (resulting in lots of situations where formatting code was re-executed) and other work that I haven't touched it in quite some time. TBH, you should probably look into Blazor Hybrid as if I understand correctly you could just inject the HTML directly into a razor page and let it deal with it without the differences between platforms. That's the direction I'm currently leaning but don't have the bandwidth to try just yet. |
|
@bakerhillpins That's an interesting alternative. I've started looking into this as well. One challenge I'm seeing is the ability to have the HTML be dynamic (i.e. a string of HTML consumed/parsed at runtime). All the examples of the Blazor Hybrid solution seem to just be HTML as part of the page already. If you have any ideas, I'm all ears! |
|
@somoreingold I believe you simply need to use binding operations to bind to the html string. |
|
@bakerhillpins just FYI I've tried the hybrid blazor route, and it works but has serious drawbacks:
Long story short, I do think there is a place for a MAUI version of this control, in case this is still on your radar. |
@somoreingold Recollection was this was going to get mighty messy because IIRC the way MAUI setup it's rendering engine (via the handlers) made multiple passes over the data almost inevitable so perf was going to be bad anyway. Baring some fancy trickery or without help from the inner workings. Regardless, I've had no time to push any further on this for a variety of reasons. It's unlikely to make it's way back in the near term as focus at work has changed as well. |
In response to #134 I thought I'd convert this library as a way to learn MAUI and see what work lies ahead for me in other project space.
Using MAUI Compatibility I've compiled the library under VS2022 17.2.0 Preview 6.0 for MAUI and included an example app that's modeled after the current. Android works, Windows works but doesn't display lists (?), Mac/Tizen are not implemented, and iOS throws an InvalidCastException in the depths of MAUI code. It's a start.
I've set the PR to go into DEV, seemed like the proper target.
I've done NO work on the pipelines to support this. I don't even think I'd have access to them anyway.
At some point, possibly soon, I'm going to try to convert the Renders over to the MAUI format of Handlers/Mappers (or whatever they are called) so that I can understand that process. I'll probably just commit that in this PR.