- Much improved API - Split in to multiple targets in a single package
This is a counterpart to https://github.com/Quick/Nimble/pull/916, which added support for watchOS to Nimble.
Note that this is a draft until a new version of Nimble is released with watchOS support. Until then this points at
I'm also not sure if the tests will run on CI correctly because the tests require watchOS 7.4 to run and I'm not sure what version of watchOS the simulators are configured with.
I also found that the tests weren't compiling (using Xcode 13.2.1) so I've updated these too.
Support animations when using
Binding provided via
Increase deployment targets to fix archive builds using Xcode 13
Action will no longer push to existing branch when there are no changes
Thread-safety has been improved, including:
Here's a small PR for a bug that I think has just gone unnoticed because we've never used the
sectionInset property of the
UICollectionViewFlowLayout, and we've never used the
contentInset property of
The issues looks to be that the layout's
sectionInset property is applied on a per-section basis, but the collection view's
contentInset was not being honoured.
It was also calculated using
insetBy(dx:dy:), which will modify the width by
-dx * 2, which would double the expected insets.
Hotfix for changes to Google image searches. Clicking links will no longer open the AMP popover and the AMP popover should be removed from the bottom of the screen
bundle exec rspecfrom the root directory to see all new and existing tests pass
bundle exec rubocop -ato ensure the code style is valid
If the simulator is not booted when the status bar is updated it does not do anything and the default status bar is used.
xcrun instruments fails with the error "xcrun: error: Failed to locate 'instruments'." This command will boot the simulator if it's not curerntly booted and then wait for it finish booting before terminating.
snapshot while the
override_status_bar option is
rspec ./fastlane/spec/actions_specs/app_store_connect_api_key_spec.rb:95 # Fastlane Fastlane::FastFile App Store Connect API Key raise error when no key_filepath or key_content rspec ./fastlane/spec/actions_specs/import_from_git_spec.rb:162 # Fastlane Fastlane::FastFile import_from_git with caching works with new tags rspec ./fastlane/spec/actions_specs/import_from_git_spec.rb:200 # Fastlane Fastlane::FastFile import_from_git with caching works with branch rspec ./match/spec/importer_spec.rb:47 # Match Match::Runner imports a .cert, .p12 and .mobileprovision (iOS provision) into the match repo rspec ./match/spec/importer_spec.rb:64 # Match Match::Runner imports a .cert, .p12 and .provisionprofile (osx provision) into the match repo rspec ./match/spec/importer_spec.rb:81 # Match Match::Runner imports a .cert and .p12 without profile into the match repo (backwards compatibility) rspec ./match/spec/importer_spec.rb:98 # Match Match::Runner imports a .cert and .p12 when the type is set to developer_id rspec ./pilot/spec/build_manager_spec.rb:661 # Build Manager #transporter_for_selected_team with one team id rspec ./pilot/spec/build_manager_spec.rb:677 # Build Manager #transporter_for_selected_team with inferred provider id rspec ./pilot/spec/build_manager_spec.rb:633 # Build Manager #transporter_for_selected_team with itc_provider with nil Spaceship::TunesClient rspec ./pilot/spec/build_manager_spec.rb:646 # Build Manager #transporter_for_selected_team with itc_provider with nil Spaceship::TunesClient rspec ./pilot/spec/manager_spec.rb[1:1:2:2:1:1:1] # Pilot Pilot::Manager what happens on 'login' when using web session when username input param is given behaves like performing the spaceship login using username and password by pilot performs the login using username and password rspec ./pilot/spec/manager_spec.rb[1:1:2:2:2:1:1] # Pilot Pilot::Manager what happens on 'login' when using web session when username input param is not given but found apple_id in AppFile behaves like performing the spaceship login using username and password by pilot performs the login using username and password rspec ./sigh/spec/runner_spec.rb:142 # Sigh Sigh::Runner#devices_to_use devices for development rspec ./sigh/spec/runner_spec.rb:152 # Sigh Sigh::Runner#devices_to_use devices for adhoc
In RSS 2 the description may contain the full text and the content can be omitted when there is not a short version available: https://cyber.harvard.edu/rss/rss.html#hrelementsOfLtitemgt
However a JSON feed will not contain a
content_html field when the content is not provided.
This makes it hard to create both a JSON feed and an RSS 2 feed because providing content without a description will create a
content:encoded field but not a
description field in the RSS 2 feed.
My solution to this is to fallback to the
item.content is not provided and generating a JSON feed.
This PR is to add support for running on watchOS. Since Xcode 12.5 watchOS has been supported but Nimble doesn't currently compile for watchOS.
A new target has been added to the project, along with explicit support in the Package.swift.
I don't believe anything here is a breaking change.
I have a fork of Quick that also supports watchOS. I'll create a PR for that if this PR gets approved and merged.
The package(s) being submitted are:
I have either:
Or, checked that:
Package.swiftfile in the root folder.
swift package dump-packagewith the latest Swift toolchain.
https) and the
Partial fix for #31
Added to work around https://bugs.swift.org/browse/SR-14103
Overall this is pretty minor but when dealing with a lot of
SingleElementSections that are infrequently updated is does start to slow down.
I thought a faster approach would be to use generics on
replace(element:) to only check for
nil when the value is
Optional, but generics don't allow for this kind of overload.
Also added some basic tests. The performance tests show a ~9% performance increase.
This PR is being used to diff between the OpenNet fork.
Hopefully other PRs will be merged before this (e.g. https://github.com/composed-swift/Composed/pull/21), which should lead to this PR having no changes and purely to ensure some of the history is not lost.
We've discussed returning
-1 not being great previously, but now we have the
2.0 branch we can make this change :)
Updated to match syntax in README.md.
Maybe these were intentionally left because the package has a minimum tools version of 4.2?
@bill201207 found that
UINib(nibName:bundle:) is a big part of the poor performance when our app launches.
Ultimately batching updates will help with a lot of things like this, but really that'll just be masking some of the performance issues so it's useful to find issues like this now.
This adds the
ComposedUI packages, which will close #16.
The base for this is
2.0-beta, which we can use for testing new changes, which can also break API.
If you go to the repo settings you can (temporarily) set the default branch to
2.0-beta and we can add a note to the README stating this is the beta release and the stable release is available in the
Once merged and these changes are made the READMEs for
ComposedUI repos can be updated to point to this repo and their repos archived.
This is a new type of section that is similar to
ComposedSectionProvider, but rather than flattening each of the children in to a single
SectionProvider it flattens them in to a single
ComposedUI side of this has been updated to support multiple cells per section, with a convenience for
FlatSection that delegates the calls to each of the flattened sections.
This is a breaking change since the protocol requirements have changed. I have set the base of the PR to
merge-all-libraries since that's also a breaking change and this PR relies on those changes.
edit: We've moved to our own fork to allow for more rapid development. The latest changes are in https://github.com/opennetltd/Composed/tree/feature/FlatSection, which will eventually be merged back in to this repo once some of the other PRs/issues have been resolved.
In my open source frameworks I usually use the last major Xcode (currently 11.7), latest (currently 12.3) and latest beta (soon to be 12.4), but this project has only been setup for the latest version of Xcode.
If we feel it's good to run the tests across multiple Xcode versions I have created https://github.com/JosephDuffy/update-xcode-version-action, which we can use to keep the versions in-sync with the versions available as part of GitHub actions.
For now I've removed all use a explicit Xcode versions.
Regression introduce in 1.1.1.
Would occur when a segmented provider was the last child of a composed provider and the selected segment changed.
This could have also been fixed in
SegmentedSectionProvider but changing the
_currentIndex after the delegate has been notified (which is closer to what
ComposedSectionProvider does) but we have nothing in the API contract stating this must be done, so really it's an issue with the caching in
These properties are accessed quite frequently and can be cached with a little extra processing.
This is another finding from screens that have a large number of composed sections.
This and https://github.com/composed-swift/ComposedUI/pull/15 seem to be the main areas of performance issues, although that doesn't mean that once these are working and merged we won't uncover more 😅
Thanks to @bill201207 for their contributions to this change.
The idea of this is that without breaking the API the collection view will batch updates.
Inserting a large number of sections is the main area of performance loss we are currently encountering, because the sections are inserted individually and not batched. This change alone has reduce the initial load time of one our screens (which has 100-150 sections added at once) from 30-45 seconds down to less than a second (at least it is not noticeable).
I had created https://github.com/composed-swift/Composed/pull/17 to try and address this, which has the advantage that it would apply to other view types (e.g.
UITableView), but I believe does not offer the same performance improvements and it is restricted to a single
This is a draft to collect feedback; as you can see there are some TODOs but I think there's enough implemented to provide an overview of the changes that would be required to implement this.
This does not currently work; there are situations that cause the collection
NSInternalInconsistencyException', reason: 'Invalid update error. I have some failing tests that demonstrate what the result should be.
When adding a lot of sections (we have a screen which inserts 100~175 on initial load) the performance is quite poor.
Along with the
improve-composed-section-provider-performance branch (which I want to fully validate before making a PR) performing these changes in batch helps a lot.
Persisted extensions on watchOS
builder(for:)function to aid with building complex type (thanks to @randomeizer)
As mentioned in https://github.com/composed-swift/ComposedUI/issues/13 and https://github.com/composed-swift/ComposedUI/issues/8 there are some scenarios where the collection view’s data is out-of-sync with the data in composed.
As mentioned in https://github.com/composed-swift/ComposedUI/issues/13 calling
layoutIfNeeded can trigger the data to be in sync again. In this I have added it to
mappingWillBeginUpdating(_:) which appears to solve the problem.
It might be needed in
reloadData is called) and/or
mappingDidInvalidate(_:) (for the same reason) but I’m still investigating.
I have validated this fix against https://github.com/composed-swift/ComposedUI/issues/8 and it fixes the crash.
https://github.com/composed-swift/ComposedUI/issues/13 still needs to be investigated and may require
layoutIfNeeded to be called in
mappingDidInvalidate. Marking as a draft until this is checked.
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
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:
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
SectionProvider is a child of a
On top of these functions new
insert(_:before:) have been added for convenience.
Improve API for Subscription/Cancellable
Much better handling of optional values, which also allows for non-optional values
Add support for
--output flag to
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