Remove workingRangeSize from initializer

[rnystrom]

Talked w/ @ocrickard, probably default disabled and allow setting the size (which would internally create and update the WR state) after initing the IGListAdapter.

Incredibly useful feature, but:

• Other apps have their own implementation
• We should investigate how well the UICollectionView prefetch API works
• Since this is a more advanced feature, most implementations don't need to think about it at init time

Options:

• 2 initializers (initWithUpdater:viewController: and initWithUpdater:viewController:workingRangeSize:
  • Makes transition easier
  • Maybe add __attribute__ ((deprecated)) to the old init?
• @property NSUInteger workingRangeSize
  • Have to worry about setting after feed created and used. Means we have to find what the range is and what's in it so once scrolling starts we're g2g.

[BasThomas]

Which of the two options would you prefer and why? Reading this, I'd think the first option would be best.

[rnystrom]

@BasThomas let's do the first! I agree, easier for everyone.

[jessesquires]

@BasThomas if you want to / have time to do this within the next week or so, we can include in the 3.0 release 😄

[BasThomas]

So I was looking at this - do we want to deprecate and remove the option to provide a working range size completely? Or should we still provide the init for advanced usage (or the property to set after init)?

[rnystrom]

@BasThomas let's leave the current init as the designated initializer still, but provide an initializer that internally does workingRangeSize: 0.

Also would you mind double-checking what work IGListWorkingRangeHandler does when the size is 0? I think it basically no-ops, but we might want to wrap initializing the handler with something like:

if (workingRangeSize > 0) {
  _workingRangeHandler = // ...
}

Might want to sync w/ @ocrickard really quick too to see if that's the best course of action.

[BasThomas]

When we do a no-op (not initializing the workingRangeHandler), test_whenDisplayingItemAtPath_withWorkingRangeSizeZero_thatItemEntersWorkingRange and test_whenDisplayingItemAtPath_withWorkingRangeSizeZero_thenHidingThatItem_thatItemLeavesWorkingRange fail, as they seem to rely on a rangeHandler to be present - hence their names 😉

[rnystrom]

Hmmm. We can followup w/ another issue on that. We might want to consider removing those tests and not using the working range when size = 0.