Merge 4.0 into main #713
Merged
Merge 4.0 into main #713
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The new API replaces the PagingItem initializer with a new Page struct that let's you define custom header items per page. Each page can define their own custom SwiftUI view as the menu item, and it can be customized based on the selection and progress. The new API also supports result builders, which makes it easier to create PageViews with a fixed number of pages.
Add new API for PageView implementation in SwiftUI
This ensures that the menu is shown below the navigation bar by default. This could potentially break apps that expect this to be constrained to the top of the view, and they would need to provide their own PagingView subclass that overrides the constraints.
When swiping fast to the next view controller, the scroll view will overshoot and trigger additional isScrollingFrom methods after didFinishScrollingFrom is called. This is expected, but the view controllers that are returned are the previously selected view controller and not the upcoming view controller. This was done to avoid triggered view controller appearance method (like viewWillAppear) for the upcoming view controllers when overshooting, but it seems like this is not happening anymore, so we can just remove this workaround.
Constrain menu to safe area insets by default
Fix PageViewController isScrollingFrom delegate when overshooting
Fix example projects
By increasing the minimum target for the SwiftUI views to iOS 14, we can use UIContentConfiguration to simplify the integration between UIKit and SwiftUI. We can now use the new UIHostingConfiguration on iOS 16 and fall back to UIHostingController using a custom UIContentConfiguration on older versions.
In #668, the logic for menuPosition was removed by accident. This brings it back and fixes some auto layout warnings.
In #668, the logic for menuPosition was removed by accident. This brings it back and fixes some auto layout warnings.
Fix PagingView layout constraints
Drop iOS 13 for SwiftUI views and use UIContentConfiguration
Update to recommended Xcode project settings
Add missing color modifiers to PageView
Fix didSelectItem delegate being called before actual selection
Allow setting PageView closures multiple times
When Parchment selects items outside of the visibleItems range, it needs to know whether that it is before or after the selected item so it can animate in the correct direction. This worked fine when all items where of the same type, but if you mixed multiple types they needed to know about each other. If you used the build-in PagingIndexItem, it would not know about your custom items and the animation would be wrong. This is now fixed by introducing a new PagingIndexable protocol that PagingIndexItem used to compare itself against. This can then be used by custom items, like in the IconItem example.
Add new PagingIndexable protocol to allow comparison between items
Calling layoutIfNeeded when laying out the page view sometimes caused apps to crash when this was done while hidden. It also does not work when rotating the device while another view is pushing.
When rotating the device while pushing another view, the menu would be messed up when navigating back to this view.
When enabled, the items in the menu will be selected while scrolling.
Fix rotation and crash issues with calling layoutIfNeeded
Add support for new wheel menu interaction
Fix missing UIKit import
This allows you to define a custom PagingIndicatorStyle which can contains any type of SwiftUI view that you prefer.
Add custom style for indicator view when using SwiftUI
Add Example target as shared scheme
Conflicts: Parchment.xcodeproj/project.pbxproj Parchment.xcodeproj/xcshareddata/xcschemes/Example.xcscheme Parchment.xcodeproj/xcshareddata/xcschemes/ExampleSwiftUI.xcscheme Parchment.xcodeproj/xcshareddata/xcschemes/Parchment.xcscheme README.md
The current implementation calls reloadData on each update, which re-creates the entire content view and resets any state (like scrolling). To prevent this, we update the existing UIHostingController if the current page is the same. This requires us to have stable identifiers, to know if the current page is the same as before or a new one. For title-based pages, we just use the title as the identifier. For pages with custom SwiftUI headers, we default to using the index of the view as the identifier. This is the same behaviour that we have today, although it will only work when having static pages. In order to support dynamic pages with custom SwiftUI headers, we introduce a new initializer that allows specifying the identifier.
…pdate Propagate .options on View update
Need to apply @mainactor to each individual test case instead: https://forums.swift.org/t/swift-5-10-concurrency-and-xctest/69929
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.