-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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] Implement ScrollView Orientation #13657
Conversation
@hartez I have specially doubts also why do we have 2 methods setting the ContentSize of the UIScrollView. |
* Removed BuildTizenDefaultTemplate and just have it call RadioButton's default template since they were identical. (#13996) * Reinstate WebView cookie functionality for Android & iOS (#13736) * Fix iOS cookies * Fix Android Cookies * Update src/Core/src/Platform/iOS/MauiWKWebView.cs Co-authored-by: Manuel de la Pena <mandel@microsoft.com> * Auto-format source code * Update MauiWKWebView.cs * Update src/Core/src/Platform/iOS/MauiWKWebView.cs --------- Co-authored-by: Manuel de la Pena <mandel@microsoft.com> Co-authored-by: GitHub Actions Autoformatter <autoformat@example.com> * Revert 10759. Fix Button sizing using HorizontalOptions. (#14005) * Ensure that Grid is treating star rows/columns as Auto when unconstrained (#13999) * Ensure that Grid is treating star rows/columns as Auto when unconstrained Fixes #13993 * Auto-format source code --------- Co-authored-by: GitHub Actions Autoformatter <autoformat@example.com> * [iOS] Implement ScrollView Orientation (#13657) * [iOS] Remove not used mapper for ContentSize * [iOS] Implement Orientation mapping * [Samples] Add sample page for ScrollView orientation * Try without this * [iOS] Move from extension to helper * Add back removed API * Use SetNeedsLayout to call measure of ContentView * Cleanup * [Android] Fix Frame Renderer to use Wrapper View correctly (#12218) * [Android] Fix Frame to call missing mapper methods * - fix rebase * Auto-format source code * - update tests and wrapper view code * - remove code that's now generalized in ViewHandler * - cleanup frame renderer --------- Co-authored-by: GitHub Actions Autoformatter <autoformat@example.com> * [controls] fix cases a GC causes events to not fire (#13997) As seen in #13973, some of my recent changes had a flaw: * #13550 * #13806 * #13656 Because nothing held onto the `EventHandler` in some of these cases, at some point a GC will prevent future events from firing. So for example, my original attempt to test this behavior: [Fact] public async Task RectangleGeometrySubscribed() { var geometry = new RectangleGeometry(); var visual = new VisualElement { Clip = geometry }; bool fired = false; visual.PropertyChanged += (sender, e) => { if (e.PropertyName == nameof(VisualElement.Clip)) fired = true; }; // Was missing these three lines!!! // await Task.Yield(); // GC.Collect(); // GC.WaitForPendingFinalizers(); geometry.Rect = new Rect(1, 2, 3, 4); Assert.True(fired, "PropertyChanged did not fire!"); } In each case, I added an additional test showing the problem. I played around with some ideas, but the simplest solution is to save the `EventHandler` in a member field of the subscriber. Will keep thinking of smarter ways to handle this. I also fixed several GC-related tests that were ignored, hoping they might help find issues in this area. My `await Task.Yield()` trick was enough to make them pass. * Fix tests in Release mode In `Release` mode, a `GC.KeepAlive()` call is needed for the tests to pass. Co-authored-by: GitHub Actions Autoformatter <autoformat@example.com> * [iOS] Scroll with the keyboard to not block entries and editors (#13499) --------- Co-authored-by: dustin-wojciechowski <dustin.wojciechowski@microsoft.com> Co-authored-by: Gerald Versluis <gerald.versluis@microsoft.com> Co-authored-by: Manuel de la Pena <mandel@microsoft.com> Co-authored-by: GitHub Actions Autoformatter <autoformat@example.com> Co-authored-by: Javier Suárez <javiersuarezruiz@hotmail.com> Co-authored-by: E.Z. Hart <hartez@users.noreply.github.com> Co-authored-by: Rui Marinho <me@ruimarinho.net> Co-authored-by: Shane Neuville <shneuvil@microsoft.com> Co-authored-by: Jonathan Peppers <jonathan.peppers@microsoft.com> Co-authored-by: TJ Lambert <50846373+tj-devel709@users.noreply.github.com>
Thanks for fixing this - what's the easiest way to find out in which MAUI version this will be available? I have the repository downloaded but even with SourceTree it's complicated to get a good overview. (It's not that critical for me that I need to compile my own MAUI, I'm just using the Stable update channel in Visual Studio.) |
it would be in a net8 version, p3 or p4 |
Description of Change
Seems there was no specific implementation for ScrollViewOrientation on iOS. So it was always allowing to scroll in both directions, 13412
The issue is the ContentSize of the UIScrollView is not set on the correct dimension by constraining the size of the scrollview depending on the orientation.
The implementation of
IContentView.CrossPlatformMeasure
on ScrollView.Impl does try to constrain when measuring using the orientation but the finalDesiredSize
is always the expressed WidthRequested/HeightRequested.So one way to fix is to take in account the orientation when setting the UIScrollView ContentSize.
Issues Fixed
Fixes #13412
Fixes #13187