Fixes BindableLayout BindingContext inheritance

[albyrock87]

Description of Change

Usually the BindingContext is automatically inherited via Element.SetParent using SetChildInheritedBindingContext.
When an element is removed from a Layout, the Element.SetParent takes care of clearing BindingContext automatically.

		void SetParent(Element value) {
			// ..
			object context = value?.BindingContext;
			if (value != null)
			{
				value.SetChildInheritedBindingContext(this, context);
			}
			else
			{
				SetInheritedBindingContext(this, null);
			}

We can see that setting the BindingContext to null is an explicit behavior when the parent (value) is set to null (a.k.a. child removed).

BindableLayout sets the BindingContext manually on each created child, so it is its responsibility to clear the BindingContext once the item is removed.

Not clearing the BindingContext might cause unwanted side-effects and leaks if the child view attached to some of its events (i.e. PropertyChanged).

// inside child view class
private MyViewModel _current;
protected override void OnBindingContextChanged() {
    if (_current != null) { 
        // I see no other way to unsubscribe to that event
        // Even if the event is backed by a WeakEventManager there's a risk
        // that an event is invoke before GC finishes cleaning up resources
        _current.MyEvent -= MyHandler;
        _current = null;
    }


    if (BindingContext != null) {
        // Subscribing to an event is totally legit here
        _current = BindingContext;
        _current.MyEvent += MyHandler;
    }
}

On top of that, the view created by EmptyViewTemplate should not have the BindingContext set manually, because it matches the parent one: we should rely on the automatic inheritance.

Issues Fixed

Issue #10904 does not represent a leak itself, but in a more complex scenario where a child attaches to some events on the BindingContext it would create issues.
Issue #19142

[ghost]

Hey there @albyrock87! Thank you so much for your PR! Someone from the team will get assigned to your PR shortly and we'll get it reviewed.

[jonathanpeppers]

I'm not following how clearing the BindingContext on children solves a memory leak. Usually leaks are MAUI views that live forever -- not model objects. If a model object lives forever, it means there is a MAUI view that lives forever -- that is the actual problem to be solved.

Looking at:

#10904

We should be able to write a test with BindableLayout as mentioned here:

https://github.com/dotnet/maui/wiki/Memory-Leaks#writing-tests

If we can show an issue with GC.Collect() and WeakReference that will prove what is going wrong here.

[albyrock87]

@jonathanpeppers I will add more unit tests to proof what is described in the issue, but besides that, the problem here is also a functional one.

As I've explained, the binding context needs to be cleared the same way it happens with the automatic inheritance.

The unit test I've added show exactly why the current implemention is wrong: because the removed view is still attached to the binding context.

[ghost]

Hi @albyrock87. We have added the "s/pr-needs-author-input" label to this issue, which indicates that we have an open question/action for you before we can take further action. This PRwill be closed automatically in 14 days if we do not hear back from you by then - please feel free to re-open it if you come back to this PR after that time.

[albyrock87]

@jonathanpeppers some updates for you:

• FlexLayout Memory leak #10904 specific report can be closed because the issue's code is not waiting for pending finalizers (I've added a comment there)
• I've updated the unit test regarding the EmptyViewTemplate which is now named EmptyViewTemplateContentInheritsLayoutBindingContext and it proofs that the empty view should inherit the BindingContext of the parent even when it changes
• I've updated the other two unit tests related to leaks with GC execution in order to show that there's no leak (names have been changed too) => you were right, the leak is on the child view and not on the BindingContext.

All the three unit tests are failing on main branch.

Edit: the amend-commit below are just to rename things

[jonathanpeppers]

Can we remove triggeredCount and onTextChangedCallback in these new tests? Nothing asserts against that value.

[albyrock87]

The presence of that variable is what causes the leak, but this doesn't mean that the problem resides in the unit tests.
I guess it all depends on what the MAUI team says.

[jonathanpeppers]

Can we instead create a List<WeakReference> that contains each MyViewModelBoundComponent object, and assert IsAlive is false? Then you wouldn't need a manual InstanceCount.

Example:

maui/src/Controls/tests/DeviceTests/Memory/MemoryTests.cs

Line 79 in aad88d6

Assert.False(viewReference.IsAlive, $"{type} should not be alive!");

[jonathanpeppers]

Is this line the actual cause of the leak? You've created a control and viewmodel where the viewmodel has a strong reference to the control. Then at the top of the test you have a viewmodel that lives the lifetime of the test:

var myViewModel = new MyViewModel();

You would need to enclose myViewModel in a scope, so the GC can collect it?

I'm still not sure there is an actual memory leak here, besides the one created in this test. Clearing the BindingContext just makes the event unsubscribe in this custom control and remove the strong reference. I would consider not designing a custom control this way if the viewmodel is known to live longer than the control.

Maybe someone on the MAUI team can comment what the behavior is supposed to be in regards to BindingContext. Should it always get cleared when children are unparented? @PureWeen @mattleibow @jsuarezruiz?

[albyrock87]

I think the point here is:
What should a View do if it needs to subscribe on a BindingContext property to do some action when something changes there?
How can it unsubscribe properly in the exact moment the view is no more needed?
The view cannot rely on the GC because that might happen at later moment in time, and something can happen in the mean time which would trigger an action on a removed view.
There are things out there on commercial libraries which rely on this behavior of clearing the context, and they work properly only when used outside of BindableLayout.

[jonathanpeppers]

It might be correct to clear the BindingContext (MAUI team can comment), but these tests have simply created a control that leaks unless its BindingContext is cleared. It might be better to use WeakEventManager or other solutions to avoid the problem entirely.

Does that make sense?

[albyrock87]

It might make sense. Is the WeakEventManager instantly reacting to the un-reference of the child view?

Anyway for example, ObservableObject in community toolkit does not use weak event manager.

https://github.com/CommunityToolkit/dotnet/blob/main/src/CommunityToolkit.Mvvm/ComponentModel/ObservableObject.cs#L34

I'm just saying this kind of situations happen in complex applications, and we need a clear way to handle them.
I felt that relaying on the way binding context inheritance works was the way.

[albyrock87]

@jonathanpeppers I see no response from the team, so I've investigated the code myself and it appears to me that clearing the context when the parent is unset is an explicit behavior in Element.cs (see more on PR description).

I've updated the title, description and commit to reflect that this PR is only fixing a wrong behavior.
There are no leaks directly caused by this, unless the developers chooses to subscribe to BindingContext events in child view.

[albyrock87]

This PR is waiting since September 29, it is not stale.

Now that .NET8 GA is done, may I ask for a final review? Thanks
@samhouts @PureWeen

[StephaneDelcroix]

shouldn't you use SetInheritedBindingContext instead of setting the child BindingContext ?

[albyrock87]

@StephaneDelcroix that'd be a nice idea, but it would cause BindingContext changing two times:

1. var view = (View)dataTemplate.CreateContent() => context null
2. layout.Add(view) => context = inherited from parent
3. BindableObject.SetInheritedBindingContext(view, item); => context = item

And the problem is that 3 will happen after the element is already in the visual tree.

I'd like to do 3 right after 1, but layout.Add would override the value I've just set.

[albyrock87]

Any updates on this?

[mattleibow]

@PureWeen I am wondering if this should be using the visual childrent feature you added? I see you opened the OG issue, so not sure if you had thoughts?

[albyrock87]

@PureWeen any chance to include this in the next 8 SR?

[PureWeen]

/rebase

[PureWeen]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[PureWeen]

This behavior now mirrors any other control we have that utilizes an ItemSource. CV and LV both also use this pattern when items are added/removed

[PureWeen]

@StephaneDelcroix that'd be a nice idea, but it would cause BindingContext changing two times:

1. var view = (View)dataTemplate.CreateContent() => context null
2. layout.Add(view) => context = inherited from parent
3. BindableObject.SetInheritedBindingContext(view, item); => context = item

And the problem is that 3 will happen after the element is already in the visual tree.

I'd like to do 3 right after 1, but layout.Add would override the value I've just set.

Chatted with @StephaneDelcroix some about this. We're going to see about adding an API that will achieve this goal. I did some local tests and I really like how this all works if we can set the item as the Inherited Binding Context.

That basically lets us remove all the code that clears out the BC as well because removing the parent will just clear it out.

I feel like this is also an API we can extend out to CV/LV/etc..

[albyrock87]

@PureWeen should I decline the PR then and simply wait for the new API?
I see changes requested but I don't get what I have to do in this situation :)

Changes addressed