dotnet / maui

.NET MAUI is the .NET Multi-platform App UI, a framework for building native device applications spanning mobile, tablet, and desktop.
https://dot.net/maui
MIT License
22.26k stars 1.76k forks source link

BindingContext Not Propagated Correctly to ContentView When ControlTemplate Changes at Runtime #25934

Open s-beltz opened 2 days ago

s-beltz commented 2 days ago

Description

We are using AdaptiveTrigger to dynamically adjust the ControlTemplate of a ContentView based on screen size, ensuring an optimal layout for various devices.

Following the workaround detailed in this issue, we were able to implement this approach successfully up to .NET 9 RC2. However, after upgrading to the final release of .NET 9, this solution no longer works.

The issue occurs when the ControlTemplate is changed at runtime (e.g., via AdaptiveTrigger or OnSizeChanged). While the initial ControlTemplate is applied correctly with the expected BindingContext, any subsequent changes to the template cause the BindingContext to be lost. Once lost, the BindingContext does not reapply, resulting in broken bindings.

Unfortunately, we have not identified any workaround for this issue, which blocks us from shipping our product.

Is there any guidance or known workaround to resolve this? Any help would be greatly appreciated! 😊

Steps to Reproduce

We have created a repro project to demonstrate the issue: controltemplate-repro.zip

On Windows, resizing the window triggers a ControlTemplate change and reproduces the problem. On Android and iOS, the issue can be observed on phone-sized simulators where the smaller screen size causes the ControlTemplate to change. However, tablet-sized simulators (which do not trigger a template change) work as expected.

Link to public reproduction project repository

No response

Version with bug

9.0.10 SR1

Is this a regression from previous behavior?

Yes, this used to work in .NET MAUI

Last version that worked well

9.0.0-rc.2.24503.2

Affected platforms

iOS, Android, Windows

Affected platform versions

No response

Did you find any workaround?

Unfortunately not... ;-(

Relevant log output

similar-issues-ai[bot] commented 2 days ago

We've found some similar issues:

If any of the above are duplicates, please consider closing this issue out and adding additional context in the original issue.

Note: You can give me feedback by 👍 or 👎 this comment.

s-beltz commented 2 days ago

We've found some similar issues:

If any of the above are duplicates, please consider closing this issue out and adding additional context in the original issue.

Note: You can give me feedback by 👍 or 👎 this comment.

We are uncertain if the similarities are relevant, as we cannot determine if the root cause is the same. However, we have been using the workaround documented here to achieve the desired functionality, as demonstrated in our repro project. This workaround worked flawlessly up until .NET 9 RC2 but stopped functioning with the final release of .NET 9.

Currently, any runtime change to a ControlTemplate breaks the app's functionality.

We have tested several alternative approaches, but unfortunately, none have resolved the issue. This leaves us with a significant regression that is blocking our progress.

We would be open to implementing a different workaround if it enables us to swap out the ControlTemplate at runtime effectively. This ability is crucial for our implementation, not just for adaptability but for a wide range of scenarios where dynamic changes are required. Any guidance or suggestions would be greatly appreciated.

kevinxufei commented 12 hours ago

I can repro this issue at Windows platform on the latest 17.13.0 Preview 1.0(9.0.0-rc.2.24503.2 & 9.0.10). In addition, I was going to verify this on 8.0.3, but there were some errors.