-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Crash when update occurs as side effect of view configuration #34
Comments
This doesn't really make sense. The whole point of calling performBatchUpdates for every single update is to ensure it enqueues those correctly. So it shouldn't be possible to NOT have The most common cause of issues here is usually the data being out of sick. Are you updating the model inside the |
Moving to the closure-based design is aimed to ensure that the models are updated inside One way this crash seems to happen is when the configuration of a header (possibly cells, I've not tested this yet) triggers an update. This is probably impossible to support without capturing the The workaround I've found (after a few separate debugging sessions) is to invalidate all if this scenario is detected:
After the updates have been applied the collection will layout, dequeuing views as necessary. If any of these views then trigger an update it will enter I've added a long At first I thought this might work because collection view apparently supports nested batch updates: But I would guess their logic is along the lines of:
Because the crash is essentially:
|
A crash can happen when an update occurs as a side effect of a view being configured, e.g. the following will trigger a crash:
0, 0
0, 0
deletes item0, 0
during configurationA somewhat more reasonable example would be something in a header (e.g. a series of tabs) triggering the update as a setup of initial state.
This is because the
updates
closure ofperformBatchUpdates
is still being called so the delete is processed in the context prior to the insert. This is generally a misuse ofUICollectionView
and is hard to create a correct fix.Consumers should be discouraged from performing updates during configuration, but it would be nice if this could be detected and the crash prevented.
Original message
I'm trying to debug batch updates and seeing some strange behaviour, maybe you can provide some insight @shaps80?The updates are applied in https://github.com/opennetltd/Composed/blob/batch-collection-view-updates-closure/Sources/ComposedUI/CollectionView/CollectionCoordinator.swift#L254, which can be simplified as:
I have then seen logs like:
Note how
Starting batch updates
is printed twice before the`performBatchUpdates` has been called
. How can this be possible?This made me look at this a little more, and only raised more questions. The updates closure has to be sync because it's not escaping (although I don't see this in the actual header and it is optional, but somehow Swift thinks it's not escaping) and
Batch updates have been applied
is always printed before another update.It looks like collection view is blocking the return from
performBatchUpdates
and multiple calls are possible, but this is all being done on the main thread. This makes me think my method of testing is wrong but I can't see what it could be.Note that the crash occurs when updates are applied as:
Since the completion hasn't been called yet I think it hasn't committed the insert yet and it crashes with a message stating that it can't delete element 0,0 because it doesn't exist yet.
One solution is to wait for completion to be called before applying more updates but this would then make all updates within Composed potentially async and introduce delay (due to waiting for layout) that isn't required the majority of the time.
The text was updated successfully, but these errors were encountered: