This change addresses the 2nd issue reported in #633. The previous attempt
in commit b0fd0d4 was intended to fix this, but it has a regression.
This change resolves the issue without introducing any regressions.
* Added '--verbose' in cocoapods job
* Fixed 'error: No simulator runtime version'. Some of the example apps cannot be built on github actions.
> /Users/runner/work/FloatingPanel/FloatingPanel/Examples/Samples/Sources/Assets.xcassets: error: No simulator runtime version from [<DVTBuildVersion 21A342>, <DVTBuildVersion 21C62>, <DVTBuildVersion 21E213>, <DVTBuildVersion 21F79>, <DVTBuildVersion 22B81>] available to use with iphonesimulator SDK version <DVTBuildVersion 22C146>
* Used macos-15 to fix random build fails
* Stop pinning the scroll offset in moving programmatically
* Add 'optional' string interpolation
* Add comments
* Add CoreTests.test_initial_scroll_offset_reset()
* ci: remove macos-12 jobs for the deprecation
* ci: name circleci jobs
This PR modifies the transitionDuration(using:) method in FloatingPanelController to return 0.0 instead of calling fatalError when the FloatingPanelController instance is not found. This change is crucial for several reasons:
1. Avoiding Crashes in Production: Using fatalError in production can lead to unexpected crashes, which are detrimental to user experience. It's safer to return a default value like 0.0 and handle the scenario gracefully.
2. Improved Stability: By returning 0.0, the application can continue running, allowing for better stability and user satisfaction. This approach also aligns with the principle of fail-safety, where the system continues operating under error conditions.
3. Real-World Case: In our large-scale project, we encountered a crash at this specific point due to the fatalError. Given the size and complexity of our application, it has been challenging to pinpoint the exact cause. Switching to a return value of 0.0 would significantly help us mitigate the issue and maintain app stability while we investigate further.
4. Maintainability: Returning a default value makes the codebase more maintainable and easier to debug, as it avoids abrupt termination and allows for logging or other error handling mechanisms.
Removed the `pre > .zero` condition from `FloatingPanelLayoutAnchor` as it was not appropriate for zero or negative `absoluteInset` values.
Added documentation for `shouldScrollingContentInMoving(from:to:)` to prevent similar mistakes in the future.
This patch fixed the error at SurfaceView#L63 in Xcode 16 (#635):
> 'CALayerCornerCurve' is only available in application extensions for iOS 13.0 or newer.
use a separate `scrollLocked` var instead of abusing the scrollView's properties to store the locked state;
fixes an issue where the scroll indicators were no longer visible because lockScrollView() was executed twice before unlockScrollView() was called (due to the user changing `showsVerticalScrollIndicator` mid-animation);
The state was not changed after moving a panel without attractive
interaction. For example, a panel is moved from half to full and
the scroll content continues to scroll with its deceleration
animation. We can test it on 'Show tracking(TextView)' in Samples app.
dbef6a6 commit causes this issue.
This is because the `state` argument of `Core.isScrollable(state:)` is
not always equal to `FloatingPanelController.state` property. Therefore,
the API should pass the `state` property of `Core.isScrollable(state:)`.
On `DebugTableViewController` in the Samples app, the panel does not move
when a finger move up from the menu area to the grabber area.
`scrollViewFrame` is not necessary due to the same condition is already
checked at Core.swift:L578.
The new `floatingPanel(_:shouldAllowToScroll)` delegate method allows the
library user to determine whether the content scrolls or not in certain
state. `Core.isScrollable(state:)` and `LayoutAdpter.offset(from:)` are
added for this feature.
Shin Yamamoto
Ivan Levin
Will Bishop
Ortwin Gentz, FutureTap