wayfair-archive / brickkit-ios Goto Github PK
View Code? Open in Web Editor NEWDEPRECATED - BrickKit For IOS
License: Apache License 2.0
DEPRECATED - BrickKit For IOS
License: Apache License 2.0
When a section has a brick with a repeat count and has a trailing brick, the identifier of the layout attributes are not correct, so the behaviors will be wrongly informed
Sometimes the width ratio it's not always respected on iPad
Example on iPad landscape:
let section = BrickSection(bricks: [ImageBrick(BrickIdentifiers.repeatLabel, width: .Ratio(ratio: 1/5.0), height: .Ratio(ratio: 1.625), dataSource: self)], inset: 8, edgeInsets: UIEdgeInsets(top: 8, left: 8, bottom: 8, right: 8))
There are certain situations where two sections are next to each other and one of them was initially hidden, some bricks in the other section would be offscreen.
BrickKit.framework/BrickKit compiled with older version of Swift language (2.0) than previous files (3.0) for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
how can i slove this
thank you
As GenericBrick was introduced, LabelBrick should inherit from this
Example app fails to build
brickkit-ios-swift3/Example/Source/Navigation/NavigationDataSource.swift:154:15: 'title' used within its own type
BrickDimension.Orientation doesn't work correctly when the device isFlat
. Then it defaults to landscape
. This should be fixed by checking the current frame's sizes
If multiple bricks are sticky within the same section, the percentage is not correct
lets say we have one brick in a brick section and when we click a button we add 2 to our BrickRepeatCountDataSource and then call invalidate bricks. If we add a print inside the datasource of the brick thats getting repeated we will see this:
Brick 2
Brick 1
Brick 0
Brick 1
Brick 2
if we do this again we will see:
Brick 4
Brick 3
Brick 0
Brick 1
Brick 2
Brick 3
Brick 4
As you can see the newly added bricks are having their datasource called twice. The reason this is an issue is because if we want to make a asynchronous method call that affects how the datasource will load the next time its refreshed, we are stuck making two asynchronous calls because these bricks reload too quickly so the first call doesn't return in time.
Here is the code I used to determine the multiple reloads:
// OrientationExampleViewController.swift
// BrickKit-Example
//
// Created by Anthony Gallo on 11/28/16.
// Copyright © 2016 Wayfair LLC. All rights reserved.
//
import UIKit
import BrickKit
private let NavBarHeight: CGFloat = 64
private let saveButtonHeight: CGFloat = 50
private let PhotoImageBrick = "PhotoImageBrick"
private let SaveButtonBrick = "SaveButtonBrick"
class OrientationExampleViewController: BrickViewController {
override class var title: String {
return "Example"
}
override class var subTitle: String {
return "Example"
}
var titleView: UIView!
var titleLabel: UILabel!
var num = 1
override func viewDidLoad() {
super.viewDidLoad()
self.view.backgroundColor = .brickBackground
registerBricks()
navigationItem.rightBarButtonItem = UIBarButtonItem(image: UIImage(named: "AddFriend"), style: .Plain, target: self, action: #selector(MockTwitterViewController.backAction))
let mainSection = BrickSection(bricks: [setupPhoto(), setupSave()])
self.brickCollectionView.setSection(mainSection)
}
func registerBricks() {
self.brickCollectionView.registerBrickClass(ImageBrick.self)
self.brickCollectionView.registerBrickClass(ButtonBrick.self)
}
private func setupPhoto() -> BrickSection {
//let photoImageBrickModel = ImageBrickModel(image: UIImage(named:"ImageCarouselExample")!, contentMode: .ScaleAspectFill)
let section = BrickSection("test", bricks: [ImageBrick(PhotoImageBrick, height: .Orientation(landscape: .Fixed(size: UIScreen.mainScreen().fixedCoordinateSpace.bounds.width - (NavBarHeight+saveButtonHeight)) , portrait: .Fixed(size: 50)), dataSource: self)])
section.repeatCountDataSource = self
return section
}
private func setupSave() -> ButtonBrick {
let saveButtonBrickModel = ButtonBrickCellModel(title: "save", configureButtonBlock: ({ (cell) in
cell.button.setTitleColor(UIColor.blueColor(), forState: .Normal)
}))
return ButtonBrick(SaveButtonBrick, height: .Fixed(size: saveButtonHeight), backgroundColor: UIColor.whiteColor(), dataSource: saveButtonBrickModel, delegate: self)
}
}
extension OrientationExampleViewController: ImageBrickDataSource {
func imageForImageBrickCell(imageBrickCell: ImageBrickCell) -> UIImage? {
print("test \(imageBrickCell.index)")
return UIImage(named:"ImageCarouselExample")!
}
func contentModeForImageBrickCell(imageBrickCell: ImageBrickCell) -> UIViewContentMode {
return .ScaleAspectFill
}
}
extension OrientationExampleViewController: BrickRepeatCountDataSource {
func repeatCount(for identifier: String, with collectionIndex: Int, collectionIdentifier: String) -> Int {
return num
}
}
extension OrientationExampleViewController: ButtonBrickCellDelegate {
func didTapOnButtonForButtonBrickCell(cell: ButtonBrickCell){
if cell.brick.identifier == SaveButtonBrick {
num+=2
self.brickCollectionView.invalidateRepeatCounts(true)
}
}
}
When scrolling up, sometimes a brick might get an unexpected height and it starts being jarry
Flickr Example Crash app
Regardless the implementation, the image is always added on the main thread. This is not optimal if the ImageDownloader used is already using the main thread
BrickKit should have better logging to debug issues
Currently Bricks does not support accessibility hints, labels or identifiers. Adding accessibilityIdentifier will make UITesting easier.
Right now, the only way to hide a brick is to set a hideBehaviorDataSource
on the layout. It would be handy if the Brick object itself could have a isHidden
property, that the layout would listen to
No install section for Carthage in your readme
It would be very helpful if there was a way to specify that a brick should have a width that is the remaining of the whole width. So if you have a brick that has a fixed width (button, image etc) and you want the next brick just to fill the remainder of the width
A chunk of blank space appears when above the space I use a collection brick to create a carousel. Invalidating the brick collection view will fix the problem and the missing bricks will appear and the height will get calculated properly.
Fixes issue where when the spotlight Layout behavior is used for some bricks but not others in the same brick collection view, the first spotlight brick extends to the top of the collection view behind other bricks.
There are times when bricks don't get displayed when there are a lot of nested BrickSection
-s
We're overriding Swift.print. We should replace that.
Swift currently doesn't support overriding extension functions. Many of the brick class files and their functions are split up into extensions for cleaner code, but this causes subclasses to be unable to override functions. For example, if a developer tries to make a mock subclass of BrickCollectionView
for unit testing, she or he won't be able to override functions declared in extensions, such as indexPathsForBricksWithIdentifier
. A solution to this would be to simply move all public functions declared for a Brick class in Swift extensions to be moved within the declaration of that class.
Setup: BrickFlowLayout with alignRowHeights=true,
It seems that sometimes visually brick rows are not aligned. But scrolling the bricks offscreen and going back seems to fix it again
sizeChangedHandler
doesn't reload the collectionView properly. This sometimes does not show the image brick at refresh
In the demo-app, the Sticky Footer with sections is broken
The calculation for the bricks within the section are wrong
The SpotlightLayoutBehavior doesn't show the bottom bricks when it initially loads
Bricks that are above the current contents view are resized based on actual height as they are scrolled on screen but we do not account for how this offsets the content.
Since ButtonBrick
inherits from GenericBrick<UIButton>
, the didTapOnButtonForButtonBrickCell
is no longer called
When a brick's height changed because of an invalidation (e.g. rotation), the bricks below that brick get a wrong y-origin and the contentsize of the collectionview is calculated wrongly
We use size classes to define standard width and heights to use across multiple devices and orientations. Following is the code that was used to define variable width ratio for iPad and iPhone.
width: BrickDimension.HorizontalSizeClass(regular: .Orientation(landscape: .Ratio(ratio: 1/5), portrait: .Ratio(ratio: 1/4)), compact: .Ratio(ratio: 1/2))
It seems to be working fine except while running on iPad mini device. When app starts, it shows 5 items in row for portrait iPad mode. (As opposed to 4 as defined in the layout). Switch the device to landscape mode and it shows 5 items as expected for that orientation. Now, if the device rotated back to the portrait mode, it correctly shows 4 items. Looks like the switching of orientations is required to show desired number of horizontal items for a mini.
Right now, the alignRowHeights is set on BrickFlowLayout
, which is less powerful than putting it per section
At this time, we can only override content on a brick by brick basis. It would be useful to be able to override content on a brick section as well.
Create the ability to vertically center a brick inside a section.
When loading data for a given brick include functionality to display a different view for the brick cell.
If a collection brick has a non-automatic height estimate, it will try to update its height anyway. This causes bugs with two collection bricks on the same screen, and nested collection bricks which infinitely loop when adjusting height.
When repeating a ton of CollectionBrick's,it seems like the CollectionBrick's are constantly reloading, resulting in flickering CollectionBrick's
The example app does't compile
BrickFlowLayout
aligns all bricks left
It would be interesting if the alignment could be specified (Left, Center, Right, Justified)
A lot of bricks are just wrappers around a custom UIView (UIControl)
This issue is to propose a generic way to wrap a view inside a brick
Constructor would like like this
let labelBrick = GenericBrick<UILabel>(...)
labelBrick.configureCell { label in
label.text = "foo"
}
Nibs/bricks need to be registered to the BrickCollectionView
That way, it's independent what BrickCollectionView a section is build on
Right now, BrickKit will calculate all the attributes needed for the view. This works pretty well for views with 100 bricks or lower. Once there are massive amount of bricks (like 1000+), the calculations become too expensive, especially when bricks need to move down when heights come in.
This issue is to request an enhancement that the layout is only calculating chunks at the time instead of all at once.
It seems like we have to make different iterations of Brick-nibs when there is a chevron or some kind of accessory. It would be nice if this could be handled directly in the brick itself.
Also, when trying to refactor UITableView to BrickView, the other thing that is not supported is extra action buttons when swiping left/right.
As GenericBrick becomes more used, it would be nice if we could define an accessory view that is added to any kind of brick
If the only layout attribute in a CollectionBrick
(with SnapToPointLayputBehavior
added) is the layout for the overall brick, the attribute is not ignored before the collectionView content offset is calculated. This can occur if resetCollectionViewContentInset
is called before the widths of the collection brick's bricks are calculated.
This is similar to the issue we closed last week. (#6) However, it's more weird than previous one. When app is run on iPad pro simulator it shows correct number of horizontal bricks. However, when app is run on the real iPad pro device, the issue is same as mentioned in the link above.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.