RFC: Preprocessing API to do expensive work on background before applying batch updates

[rnystrom]

This is a proposal to add an API that makes it easy to do expensive things (e.g. size text, file i/o) on a background queue from within a section controller before an update is applied.

Current situation

If you have expensive work to do before using your section controller, currently your only options are:

• Create a very specific method/helper to warm up caches or w/e before calling [adapter performUpdatesAnimated:YES completion:nil] 😢
• Do it on main 😭

We use both of these solutions and still hit 60fps, but it is not easy.

API Design

• Create a new protocol IGListPreprocessingDelegate
• Add a new weak property on IGListSectionController similar to the scroll delegate called preprocessingDelegate
  • Let's section controllers assign self
  • nil by default

IGListPreprocessingDelegate

The IGListPreprocessingDelegate will have 2 required methods:

// Called on a background queue. This is where you would do work, sync or async.
- (void)preprocessWithContext:(IGListPreprocessingContext *)context;

// Method called on main once all work is done.
- (void)preprocessingDidFinishWithContext:(IGListPreprocessingContext *)context;

IGListPreprocessingContext

This is object is similar to the UIViewControllerContextTransitioning (should we name it IGListContextPreprocessing?). It's main duties:

• Give the preprocessingDelegate info
  • The object of the section controller
  • Container size
  • The section index?
• Have an id value object to store arbitrary data
  • e.g. calculate the CGSize of some text, wrap it in NSValue, and do context.value = wrappedSize;
• Require calling [context completePreprocessing] to mark finished
  • Allows the method to call async, block-based APIs

Considerations

Main thread affinity

Every public IGListKit API has IGAssertMainQueue() in it and I don't think we should remove any of that so we don't get into threading chaos. That means that when in -preprocessWithContext: you can't do something like [self.collectionContext containerSize]. We should strive to put all necessary background data on each IGListPreprocessingContext object.

Concurrent work

Ideally, preprocessing should all be done concurrently, though we have to wait (non-blocking) until all of the work is finished before continuing. I think we could:

• Create an internal IGListPreprocessor (?) object that inits a private, concurrent queue
• When preprocessing begins, create a new dispatch_group_t
• For each section controller w/ a non-nil preprocessingDelegate:
  • Create a new context object w/ data (container size, dispatch_group_t, object, etc) injected
  • Store context in NSMapTable where context=>sectionController (use when finished)
  • dispatch_group_enter
  • Call [sectionController.preprocessingDelegate preprocessWithContext:context]
  • Context is given dispatch_group_t and calls dispatch_group_leave inside -[IGListPreprocessingContext complete]
• Queue dispatch_group_notify(serviceGroup,dispatch_get_main_queue(),^{...}
  • Block waits for group to be done, then iterate previous NSMapTable calling [sectionController.preprocessingDelegate preprocessingDidFinishWithContext:context]

IGListUpdatingDelegate and IGListAdapter APIs

Adding the concurrent step should coalesce other updates (but NOT execute updates!) until the preprocess work and the batch updates are all finished. Getting this working will be a little surgical:

• The IGListUpdatingDelegate will need a block to execute before actually batch updating
  • Similar to the objectTransitionBlock
• Precisely when to do this is still a little ¯\_(ツ)_/¯...
  • I think that we have to add it here, wait for a delegate or block to be executed when preprocessing is done, then continue w/ batch updating

Thoughts?

Curious to hear comments/questions/concerns on this. Specifically, how do you handle expensive sizing/fetching work with IGListKit (or elsewhere)?

[Adlai-Holler]

I love it!

• Do we want the context to provide information about the change that we're preprocessing for?
• Are we prepared to accept that this will mean the data source and collection view are out-of-sync while preprocessing happens?
• Do we want to provide an API to wait/perform a synchronous update? Maybe later?

[rnystrom]

Do we want the context to provide information about the change that we're preprocessing for?

Hmmm good question. You mean like if this is a new item vs existing? Or like the actual diff result (move, etc). The latter might be really tricky.

Are we prepared to accept that this will mean the data source and collection view are out-of-sync while preprocessing happens?

If built right, hopefully that shouldn't happen. We'll still have a single place where the data source is updated.

The only risk is that section controllers could change a property or something that effects numberOfItems or w/e. There's all sorts of complications there tho, so hopefully we could encourage people to store data on the context object, then store it on main in preprocessingDidFinishWithContext:.

There's probably more complications that I'm missing.

Do we want to provide an API to wait/perform a synchronous update? Maybe later?

Hmm, maybe later. Probably want to avoid any blocking API though, right? Locking up main would be nasty.

[jessesquires]

So where would this processor hook-in relative to the -objectsForListAdapter: data source method?

---

We would basically like to have an "asynchronous" version of -objectsForListAdapter: since this is where we map models --> view models.

[rnystrom]

@jessesquires order of ops would probably have to be:

• -objectsForListAdapter:
• -listAdapter: sectionControllerForObject:
• The current dispatch_async-runloop coalescing happens
• Diff
• Do preprocessing pass (coalescing updates again, executed after this batch update completes)
• Fire off [UICollectionView performBatchUpdates:completion:]
  • -[IGListSectionController didUpdateToObject:] still has to happen in batch update block
  • Might have to do the preprocessingDidFinish stuff before didUpdateToObject, but also w/in this block

So all the fetching-objects, didUpdateToObject:, sectionControllerForObject: still happens on main.

[weyert]

This sounds really nice. I just learned about dispatch_group_t ;)

[jessesquires]

For anyone wanting to work on this, please see the rough draft at #501.