Summary:
## Changes in this pull request
Should map be a map of `IndexPath`s instead of arrays of `IndexPath`s? Also, we might need some unit tests on this part. I don't think it's covered.
### Checklist
- [x] All tests pass. Demo project builds and runs.
- [x] I added tests, an experiment, or detailed why my change isn't tested.
- [x] I added an entry to the `CHANGELOG.md` for any breaking changes, enhancements, or bug fixes.
- [x] I have reviewed the [contributing guide](https://github.com/Instagram/IGListKit/blob/master/.github/CONTRIBUTING.md)
Pull Request resolved: https://github.com/Instagram/IGListKit/pull/1205
Reviewed By: Ziewvater
Differential Revision: D15962803
Pulled By: lorixx
fbshipit-source-id: f207b69ef0ebad08cd72b14ba53101e56d1604fd
Summary:
- See #1262 (cell reordering using a binding section controller caused problems)
## Changes in this pull request
- Added method override in `IGListBindingSectionController` to update the internal `viewModels` array after a cell has been moved
- Subclasses of IGListBindingSectionController require to call super
Issue fixed: #1262
I've added a test for this change. Is this enough? Or should I add more corner cases or something?
### Checklist
Some tests fail, but they do seem unrelated. I don't know if this is normal. I haven't changed anything regarding those failing tests.
- [x] All tests pass. Demo project builds and runs.
- [x] I added tests, an experiment, or detailed why my change isn't tested.
- [x] I added an entry to the `CHANGELOG.md` for any breaking changes, enhancements, or bug fixes.
- [x] I have reviewed the [contributing guide](https://github.com/Instagram/IGListKit/blob/master/.github/CONTRIBUTING.md)
Pull Request resolved: https://github.com/Instagram/IGListKit/pull/1274
Reviewed By: candance
Differential Revision: D15592822
Pulled By: lorixx
fbshipit-source-id: d81c18bec0ad0a6a6613089245352bb182a92f26
Summary:
The collection view layout here should not be accessing the data source directly but instead asking the collection view for the number of sections and number of items. This is because the collection view holds an internal cache and if there is a discrepancy between when the collection view cache and the data source, preparing the layout will crash the app because we will send a layout down to the collection view with a items that might not exist in the collection view's cache but exist in the data source.
This diff adds an experiment to see the impact of fixing this check so that when we prepare layouts we don't ask the data source directly but ask the collection view instead. The collection view will then update it's cache and check the data source so it does not crash when we prepare a layout.
```
NSInternalInconsistencyException at __45-[UICollectionViewData validateLayoutInRect:]_block_invoke:
UICollectionView received layout attributes for a cell with an index path that does not exist:
<NSIndexPath: 0xc198a8c3ea391fbb> {length = 2, path = 4 - 0}
```
Reviewed By: lorixx
Differential Revision: D15830610
fbshipit-source-id: f3dae3e87c55b86c3b686309c1144ccfff1375bf
Summary: The test was actually deallocated last year, and this test is never cleaned up. Now let's clean it up.
Reviewed By: chritto
Differential Revision: D15777898
fbshipit-source-id: c3a704ee1bfdd085c4ceb89af424a10ed07a65b6
Summary:
## Changes in this pull request
Issue fixed: https://github.com/Instagram/IGListKit/issues/1275
This PR is straintforward solution as mentioned in https://github.com/Instagram/IGListKit/issues/1275. When I finished it, I realized that it is not a problem in `IGListCollectionViewLayout Partial Optimization` and `IGListBindingSectionController` deserved it. Maybe `IGListCollectionViewLayout` is rarely used because of great builtin UICollectionViewFlowLayout or cells in section rarely need changing their sizes in practices.
Despite it is not `IGListCollectionViewLayout`'s fault, I think it can be more optimized against `invalidateLayoutWithContext`. I would like to make an another PR to optimize it.
Due to this PR just giving a proposed solution, it lacks of adding tests and changing log. When this solution is accepted, I would like to complete these todos.
### Checklist
- [x] All tests pass. Demo project builds and runs.
- [x] I added tests, an experiment, or detailed why my change isn't tested.
- [x] I added an entry to the `CHANGELOG.md` for any breaking changes, enhancements, or bug fixes.
- [x] I have reviewed the [contributing guide](https://github.com/Instagram/IGListKit/blob/master/.github/CONTRIBUTING.md)
Pull Request resolved: https://github.com/Instagram/IGListKit/pull/1285
Reviewed By: candance
Differential Revision: D15592807
Pulled By: lorixx
fbshipit-source-id: ae06abce896341509de4f3dfb73b3a7bc0a68c51
Summary:
The implementation of
```Objective-C
-[IGListAdapter scrollToObject:supplementaryKinds:scrollDirection:scrollPosition:animated:]
```
has little inconsistencies where the `UICollectionViewScrollPositionLeft` and `UICollectionViewScrollPositionTop` considering the content inset left/top of the collection view was being applied to the final offset. However, the `UICollectionViewScrollPositionRight` and `UICollectionViewScrollPositionBottom` ignoring the content inset right/bottom of the collection view was being applied to the final offset. The different result is that scrolling to the most `Left/Top`, the first section content always be visible by considering its content inset while scrolling to the most `Right/Bottom`, the last section content always be fully displayed but not be fully visible by considering its content inset.
## Changes in this pull request
Issue fixed: #
### Checklist
- [x] All tests pass. Demo project builds and runs.
- [x] I added tests, an experiment, or detailed why my change isn't tested.
- [x] I added an entry to the `CHANGELOG.md` for any breaking changes, enhancements, or bug fixes.
- [x] I have reviewed the [contributing guide](https://github.com/Instagram/IGListKit/blob/master/.github/CONTRIBUTING.md)
Pull Request resolved: https://github.com/Instagram/IGListKit/pull/1284
Reviewed By: lorixx
Differential Revision: D13590416
Pulled By: lorixx
fbshipit-source-id: ae52be9e5ba25b50c7a0ad768a4af728347523e2
Summary:
This is a bigger PR than I'd like but there is a bunch of stuff in here that feels like we should land all at once to fix the Travis setup.
Currently, there is a few things wrong. Briefly:
1. Travis is failing to even build the library (see: [build 2298](https://travis-ci.org/Instagram/IGListKit/jobs/506564900))
2. There are legitimately failing tests
3. Travis seems to be flakey running UI tests
This PR deals with the first two.
The Xcode projects were not building because some recently added files weren't added to the xcodeproj (ie. 46a124ddfe and 4662454c4a).
Also added `Foundation.h` import for `bool` definition for `IGSystemVersion` (also a new file)
The main `Podfile.lock` was already being generated via `1.5.3` (0c0b31ad7c) but the `Gemfile` had the wrong version and none of the example project `Podfile.lock`s were re-generated with it.
Once I got the projects correctly building and tests running, I discovered there were a bunch of tests that were legitimately failing. It's unclear when these started failing and what caused it.
I thought it made sense to disable these tests for now and then create Github issues to fix them as starter tasks instead of making this diff even larger.. I can create those if that sounds good.
Somewhat related, it seems like the UI tests on Travis may be a bit flakey. They pass locally, but breaks on Travis [[example](https://travis-ci.com/bdotdub/IGListKit/jobs/195758250)] with error messages like `Failure requesting automation session for com.instagram.IGListKitExamples:85190`
----
- [X] All tests pass. Demo project builds and runs.
- [X] I added tests, an experiment, or detailed why my change isn't tested.
- [X] I added an entry to the `CHANGELOG.md` for any breaking changes, enhancements, or bug fixes.
- [X] I have reviewed the [contributing guide](https://github.com/Instagram/IGListKit/blob/master/.github/CONTRIBUTING.md)
Pull Request resolved: https://github.com/Instagram/IGListKit/pull/1317
Reviewed By: rnystrom
Differential Revision: D15157375
Pulled By: rnystrom
fbshipit-source-id: b29131f59b74398b6d2b3a73453248cb3325a955
Summary:
* Currently, there's no easy way to measure how long we spend dequeueing cells or handling scroll events across the app. This makes it a bit difficult to catch scroll-perf issues early on.
* Fix: Lets create `IGListAdapterPerformanceDelegate` which gives us that information.
Reviewed By: rnystrom
Differential Revision: D14430449
fbshipit-source-id: 7bc170bdaa37807c8719976e8818f3a578ee17dd
Summary:
We have observed that keeping the coalescing time here would actually decrease the stability here, it makes the app crash more often.
It's probably caused by some race condition during that time and UICV updates become out of sync.
Reviewed By: rnystrom
Differential Revision: D14379265
fbshipit-source-id: 502c1c14fb8bdfc35969f721687e82888b160110
Summary:
This assert was hoping to find if there are any duplicates from the `fromObjects`. However, from the finding, we did not see any assertion or trace that this is the case.
The `objectsWithDuplicateIdentifiersRemoved` is actually doing extra work during updates.
We should remove this for the sake of better scroll perf and faster UI update.
Reviewed By: calimarkus
Differential Revision: D14339124
fbshipit-source-id: ff40fd23a05640058673d46f63a9e4bf516dd3f6
Summary: This change allows arbitrary layouts to be used in tandem with IGListCollectionView and recieve udpated section indices, by conforming to to conform IGListCollectionViewLayoutCompatible.
Reviewed By: maxoll
Differential Revision: D13671204
fbshipit-source-id: e030f413aefff71754731d1259037077ffb73959
Summary:
Issue fixed: #1288
- [x] All tests pass. Demo project builds and runs.
- [x] I added tests, an experiment, or detailed why my change isn't tested.
- [x] I added an entry to the `CHANGELOG.md` for any breaking changes, enhancements, or bug fixes.
- [x] I have reviewed the [contributing guide](https://github.com/Instagram/IGListKit/blob/master/.github/CONTRIBUTING.md)
Pull Request resolved: https://github.com/Instagram/IGListKit/pull/1289
Reviewed By: timonus
Differential Revision: D13590406
Pulled By: rnystrom
fbshipit-source-id: 0814b0c2383a185da747176bad57dfb15c7e883f
Summary: This diff adds a new `IGListExperimentBackgroundDiffingSerial` experiment that behaves similarly to `IGListExperimentBackgroundDiffing` but executes changes in a per-`IGListAdapterUpdater` serial queue instead of a global queue. Global queues are concurrent, and concurrent queues by nature don't ensure the execution order of the blocks that are enqueued into them, so there's a chance that the former `IGListExperimentBackgroundDiffing` experiment would lead to changes being applied out of order.
Reviewed By: calimarkus
Differential Revision: D13567403
fbshipit-source-id: a2aebb20e5e7dc22601fad3c2dfc80112747c81b
Summary:
Some calls to cellForItemAtIndex: on IGListSectionController expect this method to return a reference to an existing, already dequeued cell. It doesn't do this - it dequeues a new cell instance and returns that.
Added a warning note to the docs.
Reviewed By: lorixx
Differential Revision: D13222395
fbshipit-source-id: bb7a80f9f005e2675eef3d01a236a5f9f0008b46
Summary:
This happens when we set collectionView.dataSource to be nil before calling performUpdates:, the crash is easily reproduced by a simple unit test.
To make the infra more robust and we don't crash the app, let's add an early return before applying a collectionView update.
Reviewed By: rnystrom, calimarkus
Differential Revision: D12896196
fbshipit-source-id: ab024d0e7e9282d50c3be297e1e67cfccaff8242
Summary:
Issue fixed: #1235
- [x] All tests pass. Demo project builds and runs.
- [x] I added tests, an experiment, or detailed why my change isn't tested.
- [x] I added an entry to the `CHANGELOG.md` for any breaking changes, enhancements, or bug fixes.
- [x] I have reviewed the [contributing guide](https://github.com/Instagram/IGListKit/blob/master/.github/CONTRIBUTING.md)
Pull Request resolved: https://github.com/Instagram/IGListKit/pull/1236
Reviewed By: lorixx
Differential Revision: D12839081
Pulled By: rnystrom
fbshipit-source-id: 3e9e1192f16912d560d76f3730a377f303708cd7
Summary:
Issue fixed: #1219
No tests were added and no entry was added to `CHANGELOG.md` since this is a trivial change.
- [x] All tests pass. Demo project builds and runs.
- [x] I added tests, an experiment, or detailed why my change isn't tested.
- [x] I added an entry to the `CHANGELOG.md` for any breaking changes, enhancements, or bug fixes.
- [x] I have reviewed the [contributing guide](https://github.com/Instagram/IGListKit/blob/master/.github/CONTRIBUTING.md)
Pull Request resolved: https://github.com/Instagram/IGListKit/pull/1242
Differential Revision: D12840487
Pulled By: rnystrom
fbshipit-source-id: ded4b09765c5666e23a9aa3596328e90df2b3229
Summary:
Issue fixed: #1223
- [x] All tests pass. Demo project builds and runs.
- [x] I added tests, an experiment, or detailed why my change isn't tested.
- [x] I added an entry to the `CHANGELOG.md` for any breaking changes, enhancements, or bug fixes.
- [x] I have reviewed the [contributing guide](https://github.com/Instagram/IGListKit/blob/master/.github/CONTRIBUTING.md)
Pull Request resolved: https://github.com/Instagram/IGListKit/pull/1241
Differential Revision: D12838898
Pulled By: rnystrom
fbshipit-source-id: af47550dd320fb0e813e8ae22bc7051c2460a05d
Summary: This would help us understands what was the diff result from the algorithm and compare it with the `updates` to check what went wrong. Essentially, this would make our debugging easier going forward.
Reviewed By: calimarkus
Differential Revision: D12828892
fbshipit-source-id: 6dc52cdba1adb5a841760b51599e2df4c845c364
Summary:
There are some crashes related to this path when the number of sections are changed when using the `preferItemReloadsForSectionReloads` optimization for item reloads.
For now, this change would just limit the flag only useable when the section count is unchanged. The proper fix would be finding a repro-case for the unsafe trace.
The follow-up here is adding more logging to capture the crash reason and investigate any variable that leads to this crash.
Reviewed By: calimarkus
Differential Revision: D12828061
fbshipit-source-id: 040e66c051c54f889ee9fbc3e4a48ab6bf93e162
Summary: Provide additional context in willPerformBatchUpdates, which can be useful for debugging.
Reviewed By: lorixx
Differential Revision: D10436588
fbshipit-source-id: a59803affc24ca20f7726e36117df6126b984afb
Summary: Verify our assumption that the `fromObjects` should never contain duplicate identifiers.
Reviewed By: calimarkus
Differential Revision: D10410190
fbshipit-source-id: 4952698fee6373224b4c8395778009540c5ae380
Summary:
section moves are extremely unsafe and crashy.
If we still use the `preferItemReloadsForSectionReloads` on, the item reloads won't be correct when we applies the same logic for cases without section moves.
It leads to crash:
```
2018-09-04 23:28:12.184875-0700 xctest[51440:12103918] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Invalid update: invalid number of items in section 0. The number of items contained in an existing section after the update (1) must be equal to the number of items contained in that section before the update (1), plus or minus the number of items inserted or deleted from that section (0 inserted, 1 deleted) and plus or minus the number of items moved into or out of that section (0 moved in, 0 moved out).'
```
even if we change to use -reloadSections: instead, we still get crash like the following:
```
2018-09-04 23:21:14.129961-0700 Direct[45654:12078189] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'attempt to perform a delete and a move from the same section (25)'
```
Thus let's only add the moves.count == 0 check before using the prefer item reloads over section reload optimization.
Reviewed By: calimarkus
Differential Revision: D9661723
fbshipit-source-id: 8c3ddcd5178cb1aa58ccd9ae274cd8e5198f7609
Summary:
This made the items reload safer, as I tested that passing in an out-of-bound section index to -[UICollectionView numberOfItemsInSection:] would crash the app.
UIKit did not handle this gracefully.
Reviewed By: calimarkus
Differential Revision: D9624061
fbshipit-source-id: bcf14a3d4746b648046992adf221faff36a0257c
Summary:
When we added the ability to register the same class with multiple reuse identifiers, forgot to adjust the `registeredClasses` set to reflect that. This resulted in a bug where the collection view could be asked for a cell of a class that had already been registered, but with a different reuse identifier, which would end in a crash.
This diff fixes the crash, I'll follow up with another diff that adds unit tests around this, but want to fix master ASAP.
Differential Revision: D9560338
fbshipit-source-id: e8df6fe5d9929b44842c6abc01d52064ccb4147e
Summary:
We have seen unnecessary flashiness updates for any section reload updates.
Basically we have 1 section for 1 cell, which is recommended by the IGListKit document in https://instagram.github.io/IGListKit/best-practices-and-faq.html, specifically:
> "We highly recommend using single-item sections when possible."
However, the issue is that whenever we update the underlying data model, we would trigger a delete+insert for the section reload.
In order to mitigate that, we can fix this delete+insert changes or we use the `IGListBindingSectionController`, however, the latter one requires more refactoring plus view model wrapper to have `isEqualToDifferable:` to return YES, which seems less than ideal.
I am proposing that we add an option to the `IGListAdapterUpdater`, as `preferItemReloadsForSectionReloads` so that when it's set to YES, we would trigger the proper `-[UICollectionView reloadItemsAtIndexPaths:]` which handles the cell update properly.
This option also handles the case where the number of items in the section is changed before and after the updates, in that case, it will fallback to do the "delete+insert" section operation.
Reviewed By: rnystrom
Differential Revision: D9519519
fbshipit-source-id: 22ecca07679ebdd212cf771c61e40887cb6a9ba8
Summary: Causes more crashes, removing since this isn't a useful feature.
Reviewed By: maxoll
Differential Revision: D8543859
fbshipit-source-id: 681aeaa23143e119405eefa2c2775180c51a5657
Summary: After experimenting with scroll performance gains, default `IGListAdapter` behavior to use the faster means of collecting visible section controllers.
Reviewed By: maxoll
Differential Revision: D8543686
fbshipit-source-id: e33a78c0f1d4f208705ff5d490ab032eb6c36e70
Summary:
Issue fixed: #1174
- [X] All tests pass. Demo project builds and runs.
- [x] I added tests, an experiment, or detailed why my change isn't tested.
- [X] I added an entry to the `CHANGELOG.md` for any breaking changes, enhancements, or bug fixes.
- [X] I have reviewed the [contributing guide](https://github.com/Instagram/IGListKit/blob/master/.github/CONTRIBUTING.md)
Pull Request resolved: https://github.com/Instagram/IGListKit/pull/1213
Differential Revision: D9003398
Pulled By: rnystrom
fbshipit-source-id: 2c68f42e21abaea9191f26309668d866544f80b4
Summary:
Issue fixed: #
- [x] All tests pass. Demo project builds and runs.
- [x] I added tests, an experiment, or detailed why my change isn't tested.
- [x] I added an entry to the `CHANGELOG.md` for any breaking changes, enhancements, or bug fixes.
- [x] I have reviewed the [contributing guide](https://github.com/Instagram/IGListKit/blob/master/.github/CONTRIBUTING.md)
Pull Request resolved: https://github.com/Instagram/IGListKit/pull/1211
Differential Revision: D9003392
Pulled By: rnystrom
fbshipit-source-id: 73ef837300f8fdb6d9a6005e86f8e9e842827979
Summary:
Fixed the order of variables in this assertion.
- [x] All tests pass. Demo project builds and runs.
- [x] I added tests, an experiment, or detailed why my change isn't tested.
- [x] I added an entry to the `CHANGELOG.md` for any breaking changes, enhancements, or bug fixes.
- [x] I have reviewed the [contributing guide](https://github.com/Instagram/IGListKit/blob/master/.github/CONTRIBUTING.md)
Pull Request resolved: https://github.com/Instagram/IGListKit/pull/1203
Differential Revision: D8770959
Pulled By: rnystrom
fbshipit-source-id: 982996cc218d5db32a0fb67d045ac05870741d71
Summary: The `IGFailAssert` for duplicate object identifiers causes unit tests to fail in CI / IGListKit because assertions aren't silenced. Changing this to a log for now.
Reviewed By: rnystrom
Differential Revision: D8773452
fbshipit-source-id: 369415fda4ba3eef8fe8684dc792b0a9905a4759
Summary:
Issue fixed: #1187
- [x] All tests pass. Demo project builds and runs.
- [x] I added tests, an experiment, or detailed why my change isn't tested.
- [x] I added an entry to the `CHANGELOG.md` for any breaking changes, enhancements, or bug fixes.
- [x] I have reviewed the [contributing guide](https://github.com/Instagram/IGListKit/blob/master/.github/CONTRIBUTING.md)
Closes https://github.com/Instagram/IGListKit/pull/1188
Differential Revision: D8204493
Pulled By: rnystrom
fbshipit-source-id: 52bf75e6436d95b127d44302c4eb6f0bfdc1da08
Summary:
Issue fixed: #859
- [x] All tests pass. Demo project builds and runs.
- [x] I added tests, an experiment, or detailed why my change isn't tested.
- [x] I added an entry to the `CHANGELOG.md` for any breaking changes, enhancements, or bug fixes.
- [x] I have reviewed the [contributing guide](https://github.com/Instagram/IGListKit/blob/master/.github/CONTRIBUTING.md)
Closes https://github.com/Instagram/IGListKit/pull/1186
Differential Revision: D8264918
Pulled By: rnystrom
fbshipit-source-id: 9f32c085f305299efd839bb365a5d32109ff4f17
Summary: There is one private method in IGListKit which isn't being called from anywhere. We should just remove it.
Reviewed By: rnystrom
Differential Revision: D8346790
fbshipit-source-id: b74766373ca6b9262e03c728b26b647e164fcb03
Summary:
I was building a new `IGListBindingSectionController` subclass and accidentally used two view models with the same ID. Was seeing strange results and realized we're not removing dups or asserting here.
Adding a call to `objectsWithDuplicateIdentifiersRemoved` when the view models are first requested.
Reviewed By: rnystrom
Differential Revision: D8303601
fbshipit-source-id: 42c62adc401feaec2c7dce2a83cfc6533599752b
Summary:
If an `IGListAdapterUpdater` was unable to retrieve a collection view in `[IGListAdapterUpdater performBatchUpdatesWithCollectionViewBlock:]`, it would return early without cleaning state. This would sometimes cause future updates to crash, as this `IGListAdapterUpdater`'s state would now be out-of-sync.
This change also ensures that the `IGListAdapterUpdater`'s completion blocks run when `[IGListAdapterUpdater performBatchUpdatesWithCollectionViewBlock:]` and `[IGListAdapterUpdater performReloadDataWithCollectionViewBlock:]` return early due to having a nil `UICollectionView`.
Reviewed By: rnystrom
Differential Revision: D8056539
fbshipit-source-id: 1af7b675ec6805c2d8031f32d8a4c8e8929564e6
Summary:
I'd like to be able to access the current collection view scrolling traits inside section controllers. These are expressed as three properties from `UIScrollView`:
`isTracking`, `isDragging`, and `isDecelerating`.
My approach is to add a new struct `IGListCollectionScrollingTraits` with these three values, and expose this to section controllers through `IGListCollectionContext`.
Reviewed By: rnystrom
Differential Revision: D7986814
fbshipit-source-id: 19e9bd3b89545b10238dd060a5af8c5a0f39eb82
Summary:
Adding a fix to the `IGListAdapterUpdater` that requests the `UICollectionView` to perform updates on until just-before we update. This way if the `UICollectionView` is changed between update-queue and execution (b/c updates are async), we guarantee the update is performed on the correct view.
See the accompanying unit test that fails w/out the fix enabled.
Differential Revision: D7889908
fbshipit-source-id: 7178677f34951a1e42986b0289fc4abc708d6946
