ustwo / autolayout-helper-swift Goto Github PK

The fillSuperview method should use the bottom and right constant margins and apply them as negative constants to the addBottomConstraint and addHeightConstraint methods.

The original version of this extension did that so I think there's been a regression or a typo since we cleaned up the file for OSS.

The fix would be to update fillSuperview to apply right and bottom constants as negative values.

Note. the same thing happened on the Obj-C port ustwo/autolayout-helper-ios@d9fc906 :)

cc @danieladias @jamaine-ustwo

• Create a Podfile for the project
• Test that it works

Ideally after #3 so we know if there's any cross over there

Update framework to use the new programatic auto layout approach.

Hey @madhikarma over the past couple weeks @aamctustwo has added some cool helper methods to 'UIView+Layout' , may be some stuff you find useful or interesting to you!

Aaron added some methods to search and retrieve constraint objects via an string identifier so you can change individual layout constraints having called 'fillSuperview'

Jam

• Updated project to build on Travis CI
• Update README to a link to the latest status using Travis CI

Tasks

• Add target to create a dynamic framework (library) for the helper class so its easier to integrate for others
• Add FatFramework target to merge device and simulator libraries together into a fat dynamic framework
• Updated project structure to remove / move demo project sample

See
http://code.hootsuite.com/an-introduction-to-creating-and-distributing-embedded-frameworks-in-ios/
https://gist.github.com/madhikarma/09e553c508f870639570

Description

• Add a clear description of how to contribute to the project

how can I set constraints for the devices like iPhone X as they have different safe area at the bottom and top(notch)

The sources folder appears to be in the Root and duplicated within the project which causes a problem making changes within Xcode and Pods not picking it up.

Should we prefix methods and the extension (category) itself?

This is common practice to avoid name space clashes in Obj-C when adding methods via a category of a Cocoa Framework class

Whilst the class is prefixed by the Swift module itself in Swift, when looking around a lot of Swift frameworks prefix both the class and methods still so maybe we should do the same

Thoughts please?

So that they can be accessible outside their module I.e. CocoaPods

Note. Use open instead for allowing subclassing / overriding if applicable otherwise public

Migrate the library and sample code to Swift 3 via Xcode 8 GM

Summary

Add a pod lib lint test to the CI script to ensure that the pod stays valid on all targets in the podspec.

Details

This could either be done after the Xcodebuild test script using the command above or, if you want to also migrate to Fastlane, you could use the pod_lib_lint command in the Fastfile (see https://github.com/ustwo/formvalidator-swift/blob/master/fastlane/Fastfile as an example).

In either case, a Gemfile with CocoaPods in it should also be added to ensure a pinned version of CocoaPods is used for the linting.

Notes

For more detail on linting a Pod see: https://guides.cocoapods.org/terminal/commands.html#pod_lib_lint

As soon as a constraint is added to a view autoresizing masks should be translated automatically. Removes boilerplate. The respectable auto layout framework Masonry did the same thing which I liked.

Description

I recently changed to non optionals for certain methods to be non-optional (see 5c09f94) but I'm rethinking and wondering if its better that Cocoa crashes inside UIKit if you send in a nil superview instead of it being a no-op (does nothing)

Solutions

• We could / should change back to optionals also so its easier to integrate and consistent across all methods. Note if you use a method that needs a toView then it will crash when the constraint is created
• Or we could go one step further and make some use default params to reduce method chaining
• Other??

What do you think? @danieladias @chris59david @jamaine-ustwo

Note. should merge PR #1 first

Currently we are using Version 1.3 of the Contributor Covenant's Code of Conduct. We should update to Version 1.4, which is the latest version.

There are some attributes not support by the helper as Leading, Trailing etc

I'm not 100% sure but this may be an issue if the new right to left language support is for those layout attributes specifically

https://developer.apple.com/library/ios/documentation/MacOSX/Conceptual/BPInternational/SupportingRight-To-LeftLanguages/SupportingRight-To-LeftLanguages.html

To resolve we could add new methods such as addLeadingConstraint or addTrailingConstraint
and advise to use those for labels instead of addLeftConstraint or addRightConstraint

We should also see how the new support works

cc @danieladias @jamaine-ustwo @chris59david