Blueprints - A framework that is meant to make your life easier when working with collection view flow layouts.

Is there a way to use this with multiple sections? When I set the layout, it crashes and I get this error:

Thread 1: Fatal error: Index out of range

It traces back to the VerticalBlueprintLayout.swift's class prepare() method:

        if section == layoutAttributes.count {
          layoutAttributes.append([layoutAttribute])
        } else {
          layoutAttributes[section].append(layoutAttribute)
        }

The objective was to make the 2nd and 3rd sections of the collection view use the VerticalBlueprintLayout while keeping the 1st section customized.

I'm having troubles understanding how the Mosaic Layout works...

I don't understand why the first "block" isn't aligned on the right.

let mosaicLayout = VerticalMosaicBlueprintLayout(
  itemSize: CGSize.init(width: 50, height: 400),
  minimumInteritemSpacing: 15,
  minimumLineSpacing: 15,
  sectionInset: EdgeInsets(top: 15, left: 15, bottom: 15, right: 15),
  patterns: [
    MosaicPattern(alignment: .left, direction: .vertical, amount: 2, multiplier: 0.5),
    MosaicPattern(alignment: .left, direction: .horizontal, amount: 2, multiplier: 0.33),
    MosaicPattern(alignment: .left, direction: .vertical, amount: 1, multiplier: 0.5),
    MosaicPattern(alignment: .right, direction: .vertical, amount: 2, multiplier: 0.5)
])

I know changes haven't been made to the horizontal layout to fully support dynamic heights however I thought it worth mentioning here that both are affected in slightly different ways.

Vertical: If the previous columns last item has a greater height than the last item in the last column, then the scrollview bounds are pinning against the last item. This stops the user from scrolling which in turn cuts off the collection view cell.

Horizontal:

When scrolling around the cells disappear and re-appear, this is only an issue if items per rows is been used alongside items per column. However this may not be the intended use for a Horizontal layout and will probably be addressed in #43

Fixes #47

Required or the wrong item is looked-up from the layoutAttributes when using headers.

@zenangst - Have left the variable for sectionMaxY for the time been as I believe this will be required to resolve the issue with the incorrect position of the footer when multiple columns are used.

I have observed the following behaviour when updating the dataSource and updating the collectionViewLayout. (As different cells are been used and they have a different height between the datasources)

1. CollectionView with segmented control that changes the datasource.
2. The first datasource has items, the second datasource has no items, the third datasource has items.
3. When switching to the empty datasource the cached items will become nil as there are no items in the section.
4. When switching to a datasource with items after this, the cached items correctly updates initially but then somewhere along the chain it invalidates the cached items returning them to the nil state. I am not sure what is causing this at the moment as the blueprint layout correctly sets this and super is always called before the cached items have been set.
5. When layoutAttibutesForItem(at indexPath: IndexPath) is called, as the cached items have been invalidated, an index out of bounds exception is caused.

implementing a safe check for the index resolves the issues, however I am not sure what's causing the cached items to become nil in the first place.

override open func layoutAttributesForItem(at indexPath: IndexPath) -> LayoutAttributes? {
    let compare: (LayoutAttributes) -> Bool
    #if os(macOS)
      compare = { indexPath > $0.indexPath! }
    #else
      compare = { indexPath > $0.indexPath }
    #endif

    guard cachedItems[safe:indexPath.section] != nil else {
        return nil
    }

    let result = binarySearch.findElement(in: cachedItems[indexPath.section],
                                          less: compare,
                                          match: { indexPath == $0.indexPath })
    return result
  }

subscript (safe index: Int) -> Element? {
        return index < count ? self[index] : nil
    }

I will add an example asap and will continue to hunt down what may be causing the cached items to become nil.

Hey just wondering what the recommended approach is to using items per row with dynamic height, do we have to load a dummy cell to calculate the height and return this in the sizeForItemAt?

Likewise to support self sizing headers, at the moment the headerReferenceSize is been used to set the height. As a result the delegate method for referenceSizeForHeaderInSection is not called. Is this a limitation of the layout?

If headers and footers are been used the horizontal layout will crash when been set.

2018-12-14 11:33:41.254874+0000 Example-iOS[2682:570726] *** Assertion failure in -[UICollectionViewData validateLayoutInRect:], /BuildRoot/Library/Caches/com.apple.xbs/Sources/UIKitCore/UIKit-3698.93.8/UICollectionViewData.m:459
2018-12-14 11:33:41.256220+0000 Example-iOS[2682:570726] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'layout attributes for supplementary item at index path (<NSIndexPath: 0x281b59b00> {length = 2, path = 0 - 0}) changed from <UICollectionViewLayoutAttributes: 0x104700dd0> index path: (<NSIndexPath: 0x281b582e0> {length = 2, path = 0 - 0}); element kind: (UICollectionElementKindSectionHeader); frame = (0 0; 375 61);  to <UICollectionViewLayoutAttributes: 0x104704650> index path: (<NSIndexPath: 0x281b59b00> {length = 2, path = 0 - 0}); element kind: (UICollectionElementKindSectionHeader); frame = (0 0; 1835 61);  without invalidating the layout'
*** First throw call stack:
(0x1c05fbea0 0x1bf7cda40 0x1c0511c1c 0x1c0fff140 0x1ecfbb2ac 0x1ecfba814 0x1ecfbce30 0x1ecf8f594 0x1ecf8eaa8 0x1ecf8e668 0x102f03db0 0x102ee9c80 0x1edb528b4 0x1edb52ed0 0x102f03b68 0x102f0d0f4 0x102f0d044 0x102f0d154 0x1ed6ba768 0x1ece8a6ec 0x1ece8a61c 0x1ed6ba768 0x1ed1486d0 0x1ed1489f0 0x1ed1479f0 0x1ed6f418c 0x1ed6f53f0 0x1ed6d46ec 0x1ed7a057c 0x1ed7a2f74 0x1ed79ba64 0x1c058c1cc 0x1c058c14c 0x1c058ba30 0x1c05868fc 0x1c05861cc 0x1c27fd584 0x1ed6b9054 0x102ed8288 0x1c0046bb4)
libc++abi.dylib: terminating with uncaught exception of type NSException

This implements the delegate methods for header/footer reference sizes so they can be provided just like we do for the items.

This will allow users to provide dynamic heights for headers and footers if they wish.

Compile OSX framework is Ok Compile OSX example is ok but problem is link the message error are:

Undefined symbols for architecture x86_64: "___llvm_profile_runtime", referenced from: ___llvm_profile_runtime_user in BlueprintLayoutAnimator.o ___llvm_profile_runtime_user in BlueprintLayoutAnimation.o ___llvm_profile_runtime_user in TypeAlias.o ___llvm_profile_runtime_user in BlueprintLayoutAnimationType.o (maybe you meant: ___llvm_profile_runtime_user) ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation)

compiled with XCode 10.2.1

Fixes #107 - I don't think we should be having to do this, but occasionally prepare is called without the context been invalidated causing additional calls to things like sizeForItemAt.

This would normally go unnoticed, but I have been playing around with resizable child containers that have collection views with the custom layouts.

Occasionally the rogue calls would add more items than needed into the dynamic height cache I had held causing some cells to have the incorrect size.

This PR changes the initializer of the Mosaic layout to only include a pattern height instead of an item size. The width of the item is never used so this change is motivated by removing the confusion that it might be used. The new label is called patternHeight.

Reference: https://github.com/zenangst/Blueprints/issues/43

Hello 👋 , first of all thanks for this project!

I'd like to know if it would be possible to auto-compute the sectionInset based on the layout (and with self cell size calculation) 😄 .

Regards

This should be 0 not 1 as we can't assume a value. It can cause issues if the collection view is using headers and footers, as the collection view attempts to dequeue a header/footer that has yet to be registered. fixes #139

The number of sections should default to 0 to stop subsequent calls been made to other delegate methods when there are no items to be displayed.

https://github.com/zenangst/Blueprints/blob/c3dc5442d3102d933bc439c5c845b277b20034b1/Sources/Shared/Core/BlueprintLayout.swift#L38

This would cause a crash if headers/footers where been dequeued.

When using dynamic heights for headers and footers the height of the collection view is incorrect. The last item will be overlapped by the footer due to the footers dynamic size not been taken into account. This had been fine in the past and may be related to some of the refactoring between #131 and master.