@nicksnyder I would like to remove ExampleLayouts from the shared schemes, since it builds when you specify LayoutKit as a Carthage dependency, which is undesirable as it takes additional build time.

If we are to have LayoutKit, which is swift-based, as a dependency, when building on ci without a pre-built artifact, we would like to minimize the build time for swift dependencies.

Swift dependencies can't really be stored as pre-built artifacts AFAIK due to the lack of ABI stability.

I have built a horizontally scrolling control that uses a fixed number of fixed-size cells using LayoutKit. When the user taps a cell, I'd like to reload the previously selected cell and the newly selected cell in order to move the selection indicator. I attempted to do this by using BatchUpdates and setting the reloadItems property, but the performance is very slow.

Once I build BatchUpdates, I call layoutAdapter.reload() with a fixed width and height, passing in the BatchUpdates I just built, and returning a cached array of Layout items to the layoutProvider (with the 2 indexPaths already rebuilt and updated in the cache).

To work around this, I've instead just fetched each cell manually (cellForItemAtIndexPath), built the new layout, and arranged/made in the cell.contentView. This shows much faster performance. What's the intended use of BatchUpdates, and is there a way to get better performance out of it?

Hello, LayoutKit is awesome, but I would like to develop apps with Swift 3, unfortunately LayoutKit has no Swift 3 support yet, so I create a new branch for that reason. It's migrated by Xcode 8 beta, I don't touch any API names but I'm not sure if the migrations affect the API names, and fix some un-migratable errors manualy.

Hi. I am finding ReloadableViewLayoutAdapter quite useful, but most of the methods are not open making it hard to use it for anything but the simplest of cases. Is there any reason for this?

For example, I need to change UITableView batchUpdates animation style. Method public func perform(batchUpdates: BatchUpdates) in extension UITableView: ReloadableView uses .automatic and cannot be overridden.

open func reload<T: Collection, U: Collection> in ReloadableViewLayoutAdapter is open but var currentArrangement is internal(set) because of which it is needed to call super. reload. As such it is not possible custom reload and call custom batchUpdates.

I ended up implementing custom ReloadableViewLayoutAdapter. Any better ideas? Would it be possible to make open some of the methods?

As of https://github.com/linkedin/LayoutKit/pull/132/files#diff-0b83f9dedf40d7356e5ca147a077acb4 the build script that runs on Travis no longer builds or runs tests for the main LayoutKit target.

Before (tests run): https://travis-ci.org/linkedin/LayoutKit/builds/223716700 After (no tests run): https://travis-ci.org/linkedin/LayoutKit/builds/225308216 Current (no tests run): https://travis-ci.org/linkedin/LayoutKit/builds/225442466

The build script used to be a chain of commands linked with && so that any failure would cause the whole script to fail. As it is now, the first command fails, but the next two commands still run and the build script (erroneously) passes.

Please do not merge or commit any more changes to master until this is fixed.

For instance: https://github.com/linkedin/LayoutKit/blob/master/LayoutKit/Layouts/LabelLayout.swift#L129-L137

Sometimes I want to change some property when configuration, it will be override by the initial setup.

Should the config block execute after initial setup will be better?

I'm trying to add a drop shadow to a view spawned from an inset layout. In the config handler, I'm setting:

        view.layer.shadowColor = kShadowColor
        view.layer.shadowRadius = kShadowRadius
        view.layer.shadowOffset = kShadowOffset
        view.layer.masksToBounds = false
        view.clipsToBounds = false

But the shadow is not showing up. If I set the border color, however, that appears to work fine. What's going on here?

Hey there Is there something equivalent to LabelLayout for views such as UIButton (or any other view that define an intrinsicContentSize)?

Right now I am using a SizeLayout but I am forced to define the size of my button

SizeLayout<UIButton>(
  width: 100, height: 50,
  alignment: .centerTrailing,
  flexibility: .flexible,
  config: { button in
    button.backgroundColor = UIColor.blue
    button.setTitle("Button", for: .normal)
    button.setTitleColor(.black, for: .normal)
  }
)

This line is not compatible with today extension. https://github.com/linkedin/LayoutKit/blob/master/LayoutKit/LayoutArrangement.swift#L105

Could this get checked like http://stackoverflow.com/questions/29246656/ios-sharedapplication-is-unavailable-in-today-extension to add support for extensions as well?

This is related to issue #178 regarding adding support for Objective-C consumers. This objc-api branch is now ready for review.

Two of the open questions are:

1. How do we make these long initializers more convenient for use from Objective-C? I have several options in mind.
2. Should we make these new classes unavailable from Swift somehow? My understanding is that there's a way to use pods to exclude some directories at import time?

The builders for (1) can be added as a separate follow-up change. Currently working on figuring out what we can do for (2).

Updates StackLayout.distributionConfig and calculates the axisSpacing taking into account the spaces that were already added during the measurement phase. Actual excessAxisLength for .fillEqualSpacing is increased by numberOfSpaces * spacing so it can be redistrubuted.

See issue https://github.com/linkedin/LayoutKit/issues/159

iOS13+ has different CGSize for some button types: .contactAdd, .infoLight, .infoDark, .detailDisclosure

Tests were failing when testing with simulators iOS13+

In class LabelLayoutDefaults, UILabel.init() is called on static stored property declaration. This leads [UIView init] must be used from main thread only warning on Xcode. Moreover, it breaks on runtime some cases (e.g. XCUITest tests layout built with using LabelLayout)

This PR fixes this problem.

Hi there,

Is there any reason why the initializers, containing the viewClass argument, are marked internal? It would be extremely useful if they were exposed as public.

Reason: Let's say for example you want to define a SizeLayout and you want to determine what UITextField.Type you want to use at runtime, the current public initializers for SizeLayout prevents you from doing so.

func createSizeLayout<T: UITextField>(type: T.Type) -> SizeLayout<T> {
    .... logic for creation here ...
}

let textFieldLayout = createSizeLayout(type: YourCustomTextField.self) // this inferred as SizeLayout<UITextField> 

// if you follow the initialization steps, the used initializer in BaseLayout is:
public init(alignment: Alignment, flexibility: Flexibility, viewReuseId: String? = nil, config: ((V) -> Void)?) {
    self.alignment = alignment
    self.flexibility = flexibility
    self.viewReuseId = viewReuseId
    self.viewClass = V.self
    self.config = config
}

// instead of:
init(alignment: Alignment, flexibility: Flexibility, viewReuseId: String? = nil, viewClass: V.Type, config: ((V) -> Void)?) {
    self.alignment = alignment
    self.flexibility = flexibility
    self.viewReuseId = viewReuseId
    self.viewClass = viewClass
    self.config = config
}

Using the latter will still yield an inferred type of SizeLayout<UITextField> BUT if you set breakpoints in the config closure it will be a YourCustomTextField instance.

This updates support for SwiftPM manifest based dependency managers. Specifically this adds support for installing via Accio but will probably also work with SwiftPM once it's integrated into Xcode.

Please note that this project is part of Accio's official integration tests within the Demo project.