Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[iOS / Mac] The uicollectionviewcell is not being resized if the content resized #29

Open
Alex-Dobrynin opened this issue Mar 1, 2024 · 4 comments

Comments

@Alex-Dobrynin
Copy link

I have the expander as item of the list. when user taps on it it expands, but ios collectionview cell not and it cuts off the expander's content. you can reproduce it just for example setting visibility to the content of virtual viewcell

@Alex-Dobrynin Alex-Dobrynin changed the title [iOS / Mac] The uicollectionviewcell si not being resized if the content resized [iOS / Mac] The uicollectionviewcell is not being resized if the content resized Mar 1, 2024
@Redth
Copy link
Owner

Redth commented Apr 19, 2024

I have a branch started here but still playing with getting properly notified when the cell content actually changes size which is a bit illusive at the moment.

@Redth
Copy link
Owner

Redth commented Apr 20, 2024

This one is harder to do on iOS than it seems. I think what's happening is that the UICollectionView is trying to optimize by short circuiting layout changes within the cell's view hierarchy. The way the MAUI interop between virtual and native views works for example is that changing the visibility on an item would cause the handler to set the visibility on the native control, which would then cause a layout invalidation on the native control, and that in turn causes the measure on the virtual view. For this reason, the invalidation isn't happening when you make a change, and there's no simple way to infer when some MAUI view in the tree of the cell needs a layout pass, so we can't easily (automatically) wire up the invalidation of the particular cell that has changed (again because we don't know it has changed).

I have a branch started that adds support on the adapter for invalidating specific item positions, which does provide a way to manually do this. It's not obviously ideal, it would be lovely if it 'just worked' but I haven't found a reasonable way to wire that up yet.

In my branch there's an example where clicking a button is wired up to an event handler on the parent page of the VirtualListView and adds the ItemPosition as the Button.CommandParameter (from the VirtualViewCell's resource dictionary which gets that object assigned when the binding context changes if you nest your cell's view inside it) so you can call the adapter's UpdateItems(..) method passing that item position.

It's a bit clunky, but for now the reality seems to be if you are manipulating the views within a cell that is already displayed, after the binding context has already been set and the initial layout of the cell has happened, you will need to manually invalidate the item after doing so.

@Alex-Dobrynin
Copy link
Author

Alex-Dobrynin commented Apr 20, 2024

The same issue in maui's collectionview. But it worked well in xam forms.

Btw, maybe you saw the virtualizelistview implemented by me without native code using scrollview and absolute layout. So there item size change works as expected. You can find it in maui's github issue about performance of CV

@Redth
Copy link
Owner

Redth commented Apr 22, 2024

The interplay between native views and MAUI views is fairly different than how Xamarin.Forms worked (Forms had a lot of problems to the approach it took), so it's not very surprising that this may have worked in Forms, despite this being a bit of an unfortunate side effect of the approach we took in MAUI.

Yes I saw your implementation with absolute layout and scrollview, Interesting approach for sure. Maybe you should make it into a nuget package and release it or see if the Community Toolkit has any interest in taking it as a contribution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants