-
Notifications
You must be signed in to change notification settings - Fork 21
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
DrivingScrollView not selected after startup #32
Comments
Hey @Lumentus, thank you for the detailed issue! It is hard to tell without a sample code... it sounds like the area is not propagated correctly.
|
@gaetanzanella Unfortunately that does not fix the problem. Did you try my branch with a simulator of your own? |
I can reproduce this issue. Whenever the overlay gets hidden ( A quick workaround is to disable the scrollView in the initial position. However, this doesn't resolve the underlying issue in the SDK. ScrollView {
content
}
. scrollDisablediOS15(self.notch == .min)
struct DisableScrollingModifier: ViewModifier {
var isDisabled: Bool
func body(content: Content) -> some View {
if #available(iOS 16.0, *) {
content
.scrollDisabled(isDisabled)
} else {
if isDisabled {
content
.simultaneousGesture(DragGesture(minimumDistance: 0))
} else {
content
}
}
}
}
public extension View {
func scrollDisablediOS15(_ isDisabled: Bool) -> some View {
modifier(DisableScrollingModifier(isDisabled: isDisabled))
}
} |
The problem
In our productive app we have a problem with the new way to determine the driving scroll view. Namely the modified ScrollView is not actually driving after the overlay is first shown. After moving the sheet to a different notch the ScrollView is actually driving and everything is working as expected.
Unfortunately I have not been able to create a simple example for this, since this seems to be some kind of race condition. This file here basically shows what we do in my companies app: https://github.com/Lumentus/DynamicOverlay/blob/driving-scroll-view-test/DynamicOverlay_Example/DynamicOverlay_Example/View/DrivingScrollViewTest.swift
This code alone will unfortunately not fail (on my simulators), but with a change to the
ActivatedOverlayArea
struct, that I added mainly to get better insight into what is going on, this will produce the problems that we have in our app too. The changed file can be seen here: https://github.com/Lumentus/DynamicOverlay/blob/driving-scroll-view-test/Source/Internal/Handle/ActivatedOverlayArea.swiftMy diagnosis
I have tried to figure out what exactly is going wrong here and with two debug outputs I think I have been able to get to the bottom of the problem, though I have no idea how to fix this.
I added two outputs that print the
ActivatedOverlayArea
that is present at that location. One toDynamicOverlayScrollViewProxy.findScrollView
and one to the onPreferenceChange closure inOnDrivingScrollViewChangeViewModifier.body
.This produces something like the following output when the scroll view is correctly found:
And something like the following when the ScrollView is not driving after startup:
What is pretty obvious is that in the erroneous case the last call to findScrollView is called with an
ActivatedOverlayArea
that has no spots set, while in the successful case there is a spot defined. Judging by the timestamps that I added to theActivatedOverlayArea
for debug purposes (and causes the error to surface on my simulator), theActivatedOverlayArea
used for the last findScrollView is the first one that was received in the preferenceChange event.The text was updated successfully, but these errors were encountered: