zenangst / blueprints Goto Github PK

Opening this issue for the visibility of others as it's something to keep in mind.

When using the horizontal layout with headers and footers, when not set to stick, they will take the full width of the section.

If you have for example the following layout (see below), where the UILabel is constrained to the edges of the view. It's possible for the UILabel to exceed the graphics context buffer. If this occurs the text of the UILabel will not be rendered.

This is most noticeable on the simulator or on lower end devices and may not always occur on physical devices if there is enough memory.

This can be easily worked around but will vary on the use case, for example with the above instead of pining the edges to the view we can simply centre the label horizontally. The original constraints have also been adjusted so that they can not exceed the width of the frame. e.g. label.leading >= Safe Area.leading + 10.

The system occasionally calls prepare without invalidating the context, this can cause additional calls to things like sizeForItemAt which is not good if you're keeping a cache of sizes instead of returning them directly.

I am trying to update the collectionView layout after rotating the device.

I programatically calculate the number of items that are required per row based on the size of the cell and the available width of the view. However this causes the collection view width and height to behave very oddly.

The width becomes too large and the height becomes too small...

Is there a preferred approach to take? Here a sample of when I set the new layout.

override func viewWillTransition(to size: CGSize, with coordinator: UIViewControllerTransitionCoordinator) {
        super.viewWillTransition(to: size, with: coordinator)

        coordinator.animate(alongsideTransition: nil) { [weak self] _ in
            guard let layout = self?.offlineLoginCollectionViewLayout(forWidth: size.width) else {
                Logger.log(message: "Failed to create layout", event: .verbose)
                return
            }
            self?.collectionView?.collectionViewLayout.invalidateLayout()
            self?.collectionView?.setCollectionViewLayout(layout, animated: true)
        }
    }

What I am trying to achieve is the following,

The number of items are calculated based off the size of the item / the size of the available view width adding .1 to hint that other items are available. However on rotation to landscape I would like to recalculate this and show the update so that more items are visible to the user.

hi when i try to build from xcode i have this error

Type 'UICollectionView' has no member 'UICollectionElementKindSectionHeader'

xcode 10
swift 4.2

If the user has the system preferences for show scroll bars set to either 'Always' or 'Automatically based on mouse or trackpad' where the mouse/trackpad doesn't support gestures, the scrollbar style used has a solid background by default.

This means that the cells are partially covered sometimes.

Example - 'Always' or device without gesture support when using 'Automatic':

Example - 'When scrolling only':

It would be nice to ensure that the collection view is not covered by the scrollbar so that content is not hidden.

Following best practices move common code into a shared lib so that it can be reused it will also minimise impact on maintenance.

hi i read this warning in the dabug area

Snapshotting a view that has not been rendered results in an empty snapshot. Ensure your view has been rendered at least once before snapshotting or snapshot after screen updates.

The frames width is used to calculate the threshold when laying out the items, however this is incorrectly returning a smaller value than the available collections view's width.

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! Does this framework have any performance specifications? How many cells we can use/fetch at once? Thanks!

Hey at the moment if I implement the blueprints layout with sticky headers they do not stick to the top of the view.

Here is an example project: Example

Due to the offset used when obtaining the last footer reference it's possible for the requested item to be negative e.g -1. In this scenario we should return the footerReferenceHeight as there will be no footer to be displayed.

I think it would be nice to improve the public API's for the built-in layouts.
The user (developer) should never have to declare variables that are not used, it simply obscures the public having them there. For example, you don't need to assign an itemSize to a mosaic layout because the size is calculated based on the variables. This kind of clean up would be a good improvement to Blueprints.

Hello,

When I try to use SPM, I got this error message.

#44 - Screenshots of this can also be included in the ReadMe

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

Hey! Thank you for the great framework!
I tried demo project and noticed a vertical layout bug.
For instance: CollectionView contains multiple cells and two cells with index 31 and 32 which have the same Y, but the cell with index 31 is located on the right, not on the left.

Please have a look on the screenshots.

The README should get a bit of love with some screenshots showing of what kind of layouts that Blueprints provides out of the box.

prefer add left line,On the right side of the blank

With UICollectionViewFlowLayout I can set the height dynamic which adjust itself according to the underlying content by setting height in estimatedItemSize to 1 and then overriding systemLayoutSizeFitting in cell and setting height again to 1. This makes the height auto-adjusted according to its content. In Blueprints, it seems to be overriding it and I am no longer able to make it dynamic. I am using single row layout with multiple items.

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?

The headers and footers width are not displaying the correct width.

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

The footers are bound to the collection views bounds height, on OSX this can be greater than the enclosing scroll views bounds height.

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.

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

When a vertical layout only has one item in the section the sectionMaxY is not set correctly as it is missing from the calculations.

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.

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

numberOfItemsInSection is called twice, set a breakpoint and look

The layout is no longer needed as the VerticalBlueprintLayout offers the same functionality with added support for section, headers and footers.

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 is an extension of #40 #42, when the layout has been changed I have observed occasionally that the indexPath is invalidated. The previous fix makes assumptions that this will be available and it probably should be but hey ho..

When you don't use footers the section inset bottom is missed out in the calculations for the nextY.

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.

Layout attributes are not added when there are no items for a section, this will cause index out of bounds exceptions.

Is it possible to fix the width to constant value in HorizontalBlueprintLayout. I have tried using estimatedItemSize and width constraint on contentView but its getting override by the library.

With the changes in iOS 13 the demo project does not look as great as it could. It just needs some small tweaks here and there.

Need to implement an example for dynamic height for the macOS Example, at the point of asking for the size in sizeForItemAt*, the collection view has not been loaded into the view so we can not make use of makeItem(withIdentifier*.

We will need to load a dummy cell and set the calculated width like the iOS example does.

When setting a new layout the contentSize doesn't correctly update, this can be seen in the macOS example project when switching between the horizontal layout -> mosaic layout. As the previous content size has a larger width than the updated layout. Resizing the window makes the collection view update correctly but I am not sure at this time what is causing this.

This may also be an issue on iOS but as the collections views content size doesn't change like it does on macOS it's not noticeable.

Is this swift 4.2 compatible?

If section headers/footers have been implemented the cells are not positioned correctly, some overlap others.

@zenangst - Currently the sectionMaxY is been set but is not been referenced from anywhere. Does this need to be implemented.

Can i use this library in Objective C?

It appears that the cells appear under the scrollbar as this is not taken into account when the size of the item is been resolved. @zenangst - As I am no OS X developer is this by design?

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)
])

The built-in layouts should support stick header and footers.