search

airbnb / MagazineLayout

A collection view layout capable of laying out views in vertically scrolling grids and lists.
Apache License 2.0
3.3k stars 220 forks source link

Feature Request/Discussion - Pinned headers across sections #60

Closed jarrodrobins closed 4 years ago

jarrodrobins commented 4 years ago

I just want to say upfront thanks so much for open sourcing this library. They say naming variables and caching data is the hardest thing in computer science, but I'd argue dealing with collection view layouts on iOS has made me pull out more hair over the years than anything else I can think of.

I have one feature request, and it's something I've been messing with over the last few days but this is your library, and I want to make sure that everyone here is happy with the idea/approach.

Is your feature request related to a problem? Please describe. Section headers can be pinned to the top of the screen like table view headers can. This is fantastic! And more than enough in most circumstances. However, I have a use case where, instead of the section header scrolling off screen when we get to the next section, I want it to stay stuck until I encounter the next pinned section.

So let's say section 0 and section 5 are pinned. I want the header in section 0 to stay on screen while scrolling through sections 0 until 4, only scrolling off once we reach section 5.

Describe the solution you'd like Currently in MagazineLayoutHeaderVisibilityMode there's a boolean pinToVisibleBounds property. I propose changing this to be an enum to be something like -

public enum MagazineLayoutPinningMode {
    case none
    case sectionVisibleBounds
    case visibleBounds
}

As mentioned in the opening, naming things are hard, so I'm not married to any of these. But essentially, none is the same is the current pinToVisibleBounds being set to false, sectionVisibleBounds is the current truebehaviour, and visibleBounds would be this new case I'm talking about.

Describe alternatives you've considered One alternative could be to instead just allow the ability to create a header (similar to table view headers, not section headers) which could have pinning behaviour on it. In some ways this might be preferable as it doesn't muddy the implementation of section headers (which already behave as you'd probably expect based on how they work on table view headers), and doesn't break existing API. But this is also a little less flexible.

Additional context This has come about because I'm working on an app which has a component based API (I'm guessing Airbnb has something similar if they've gone to the trouble of building this library) where all content is driven by the server. Each component is part of its own section, and I want video players to be able to stick around on screen. The option of putting everything in one section and only having one sticky header was investigated but in the end this made things even more tricky to deal with.

bryankeller commented 4 years ago

Hey @jarrodrobins, first of all, thanks for the feedback! It's always comforting to find other people who know the pain of working with collection view layouts 🙂 And also, thanks for taking the time to write up this feature request with all of those details!

My initial reaction is that, while I see how this is useful, I think collection view is the wrong tool for the job. My reasoning for this builds on these two "rules":

  1. A section's elements should never leave the bounds of that section
  2. A section's bounds should never overlap with another section's bounds

Having a sticky header from section 0 stay on screen, overlapping section 1-4, breaks at least one of those rules depending on how you implement it.

These "rules" are made up by me, based on how flow layout and table view work, but I do feel that it's an appropriate boundary to draw.

Here's an idea of how I'd implement this using collection view and a bit of custom "floating video view" logic:

If you have a video view that should start out in a section header (in section 0), you can add some logic in scrollViewDidScroll to on-the-fly pull that video view out of the header and into a floating view. When the header view comes back on screen, you can move the video view back to the header.

Happy to discuss more, or if you agree with my reasoning then feel free to close this out.