Xcode 12 ships with 5.3 but also drops iOS 8 support. This causes a warning ("The iOS Simulator deployment target 'IPHONEOS_DEPLOYMENT_TARGET' is set to 8.0, but the range of supported deployment target versions is 9.0 to 14.2.99.")
This is a major API change so is in a v2 branch. If we agree on a direction we could start adding PRs in to this branch.
This change would enable multiple changes to be applied at once, e.g. by requiring balanced calls to mappingWillBeginUpdating and mappingDidEndUpdating and only performing the updates when an equal number of mappingDidEndUpdating calls have been made. This could be a small performance improvement but would also improve animations.
By adding the performUpdate closure the changes to the model layer can be applied only when the consumer is expecting them, e.g. for UICollectionView this would be inside performBatchUpdates and would fix the existing crashes that occur when performing a change when there are pending layout changes.
Some tests and types have been commented out since this is more of a starting point for a discussion around the API than it is a solid implementation.
This is the closest I can see the API being (although it's still a breaking change) but maybe a bigger change would be better.
The biggest PITA is that the sections need to keep track of "current" data (e.g. what's being displayed by a collection view) and the "pending" data (e.g. what's about to be applied). I don't think this adds any memory overhead but it does add much more to the knowledge required when implementing a section.
This needs more tests to ensure full coverage, but also to prove that this was previously broken and is now fixed.
The added function is public because I'm using it to extract a subset of the entries in the archive that contains symlinks.
#185, possibly #62.
These were quite hard to track down since the errors that would occur would often be visual and not a crash, although in some scenarios it did seem to trigger a crash.
I think this highlights the need for a much larger test suite.
It also made me question the insert(_:at:) functions because it's not really clear what the index is. Should it insert it at the index in the context of the sections and providers (as it does now), or just sections?
For example, with:
If I insert a section at index 3 should it look like:
or
The tests are currently essentially empty but at a minimum this makes sure things compile on Xcode 11.7 and 12.0.
@shaps80 I think this will need updates to the repo settings to enable GitHub Actions.
Introduced in #9. #12 adds GitHub actions to ensure this doesn't occur again.
Previously there was no way to get the index of a child or even know if a Section or SectionProvider is a child of a ComposedSectionProvider.
On top of these functions new insert(_:after:) and insert(_:before:) have been added for convenience.
The completion block is called when the animation has completed, but at the end of the updates block the data has already been updated (from the perspective of the UICollectionView).
Not calling reset() and setting defersUpdate = false could cause crashes e.g. due to changes being applied multiple times.
The best way to recreate this is to have a series of updates occur very close to each other but with the "Slow Animation" setting enabled in the simulator.
This change might also apply to table views, I have not checked.
The crash would often be along the lines of "Tried to delete section at index 11 but there were only 11 sections" or would occur in elementsProvider(for:) with the error "No UI configuration available for section 11" when performing a non-data change e.g. a reload of a section
Sometimes it's useful to have multiple different cell types within a single section, for example to use sticky headers or to reduce to need for many layers of composition (which can be tricky to get animation right for).
This isn't a breaking change for consumers.
I think some of the naming should be improved if this were to be merged.
Draft because I want feedback on the impact of the feature itself rather than specifically the code.
The package(s) being submitted are:
I have either:
swift ./validate.swift.Or, checked that:
Package.swift file in the root folder.swift package dump-package with the latest Swift toolchain.https and the .git extension.Xcode does not support ed25519 SSH keys so if a user uses ed25519 keys to authenticate with GitHub the connection will fail. HTTPS does not require authentication (for public repos)
Config from https://developer.apple.com/documentation/avfoundation/cameras_and_media_capture/avcam_building_a_camera_app was used to make it easier to people checking out the repo to run the sample code. Only the team needs to be changed with this config.
A copy of Package.swift with swift-tools-version updated to 5.3 and iOS platform updated to iOS 9.
Having this as a separate file prevents breaking backwards compatibility with Swift < 5.3 projects that support iOS 8.
A copy of Package.swift with swift-tools-version updated to 5.3 and iOS platform updated to iOS 9.
Having this as a separate file prevents breaking backwards compatibility with Swift < 5.3 projects that support iOS 8.
Using embedded collection views with each one using a CollectionCoordinator would cause an infinite loop in responds(to:).
Maybe it's better to check in responds(to:)? I don't know if there are other scenarios this could happen in.
It looks like there's been a breaking API change compared to 1.0.1, albeit a small one.
ArraySection.updateDelegate was already weak and looking at the memory graph this is causing circular references
This is a copy/paste from https://github.com/JosephDuffy/Persist/, with a couple of small tweaks:
It will do the following:
v is pushedv0* or v*- (e.g. v1.1.0-rc1) will be marked as pre-releasegh-pages branch as part of releasesNote that the cache is not as useful as it could be right now; Swift likes to rebuild things based on inodes so the cache is largely (maybe entirely) discarded, but will be useful in a future Swift release.
You'll need to create an orphaned gh-pages branch for the docs since I don't have permissions. I don't think it needs an initial commit, although maybe you can't push an empty branch? I've never tried.
Basic Sections were not propagating updates if added via a call to invalidateAll. This is to address #2.
The issue can be recreated by using a SegmentedSectionProvider when switching to a segment that contains a Section (SectionProvider works I think)
This commit alone is likely not enough to fix this issue; updateDelegate should probably be set to nil for removed Sections, and should probably be set in more places.
Improve API for Subscription/Cancellable
Add documentation
Much better handling of optional values, which also allows for non-optional values
Add support for --output flag to select subcommand
Build docs and attach a release binary to releases
Release candidate 1 for 1.0 stable release
Has lots of tests but little documentation. API has changes a lot since initial 0.1.0 but I’m happy with it now. Hopefully it is consistent and (once docs are added) easy to use.
Updated App Store URL generation
Fixed error when loading app store from generated URLs Moved logic for generating App Store URL to the AppMetaData struct Improved documentation around App Store URLs