We were evaluating Masonry prior to our new 3rd party lib vetting process (See here for more info: https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Third_Party_Libraries), but still wanted to do a write up for everyone.
Masonry is a library that allows developers to write autolayout code similar to the Visual Format Language, but instead of error prone strings to describe relationships, it provides a compact compiler checked syntax. You can read more here: https://github.com/Masonry/Masonry
Below are answers to our standard questions:
- Is the license permissive?
Yes - MIT
- Is the library ubiquitous?
Yes 4,362+ stars and 475 forks on Github.
- Is it installable via CocoaPods?
Yes
- What is the impact on binary size?
Negligible - no included assets
- How severe, if at all, are inbuilt subdependencies?
No 3rd party dependencies
- Will this make the code more, or less, understandable for volunteers?
More understandable - it provides an expressive "english" syntax for creating autolayout constraints. It introduces no new concepts, just type checking and syntax.
- What are the performance ramifications of using this library?
None, it uses cocoa autolayout under the covers.
- What are the complexity ramifications of using this library?
Masonry allows developers to write layout code in a much more concise and expressive way - this should reduce number of lines while increasing expressiveness.
- Is it actively maintained?
Yes and receives frequent pull requests.
- Is it compatible with current deployment targets?
Yep
- Does it hinder interop (e.g., with Swift)?
Nope
- What is the exit plan if the library becomes unmaintained?
Since Masonry is basically just a syntax veneer of autolayout - it should be possible for us to maintain if needed. There aren't any foreign concepts to understand. If we choose not to maintain - the constraints can be translated to the VFL language (or Interface Builder) easily.
If anyone has questions / comments - please reply here.
+1
On Wed, Feb 18, 2015 at 12:32 PM, Corey Floyd cfloyd@wikimedia.org wrote:
We were evaluating Masonry prior to our new 3rd party lib vetting process (See here for more info: https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Third_Party_Libraries), but still wanted to do a write up for everyone.
Masonry is a library that allows developers to write autolayout code similar to the Visual Format Language, but instead of error prone strings to describe relationships, it provides a compact compiler checked syntax. You can read more here: https://github.com/Masonry/Masonry
Below are answers to our standard questions:
- Is the license permissive?
Yes - MIT
- Is the library ubiquitous?
Yes 4,362+ stars and 475 forks on Github.
- Is it installable via CocoaPods?
Yes
- What is the impact on binary size?
Negligible - no included assets
- How severe, if at all, are inbuilt subdependencies?
No 3rd party dependencies
- Will this make the code more, or less, understandable for
volunteers?
More understandable - it provides an expressive "english" syntax for creating autolayout constraints. It introduces no new concepts, just type checking and syntax.
- What are the performance ramifications of using this library?
None, it uses cocoa autolayout under the covers.
- What are the complexity ramifications of using this library?
Masonry allows developers to write layout code in a much more concise and expressive way - this should reduce number of lines while increasing expressiveness.
- Is it actively maintained?
Yes and receives frequent pull requests.
- Is it compatible with current deployment targets?
Yep
- Does it hinder interop (e.g., with Swift)?
Nope
- What is the exit plan if the library becomes unmaintained?
Since Masonry is basically just a syntax veneer of autolayout - it should be possible for us to maintain if needed. There aren't any foreign concepts to understand. If we choose not to maintain - the constraints can be translated to the VFL language (or Interface Builder) easily.
If anyone has questions / comments - please reply here.
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
I found this Swift version of Masonry: https://github.com/Masonry/Snap
Are we confident in it, or does anyone know if the original Masonry repo maintainers have Swift plans?
If not, assuming one of our long-term goals is to eventually convert as much of the codebase to Swift as is practical, wouldn't adopting Masonry further entrench Obj-C implementations?
i.e. to "Swift-ify" Masonry'ed code we'd have to decompose Masonry syntax back to VFL strings and/or NSLayoutConstraints.
If there's not a solid Swift implementation, I'd be unsure if Masonry use is wise strategically. Thoughts?
Any concern that Masonry's syntax, while concise/elegant, raises the bar for outside contributions in that it deviates from the "standard" approach at all?
On Wed, Feb 18, 2015 at 10:09 AM, Brian Gerstle bgerstle@wikimedia.org wrote:
+1
On Wed, Feb 18, 2015 at 12:32 PM, Corey Floyd cfloyd@wikimedia.org wrote:
We were evaluating Masonry prior to our new 3rd party lib vetting process (See here for more info: https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Third_Party_Libraries), but still wanted to do a write up for everyone.
Masonry is a library that allows developers to write autolayout code similar to the Visual Format Language, but instead of error prone strings to describe relationships, it provides a compact compiler checked syntax. You can read more here: https://github.com/Masonry/Masonry
Below are answers to our standard questions:
- Is the license permissive?
Yes - MIT
- Is the library ubiquitous?
Yes 4,362+ stars and 475 forks on Github.
- Is it installable via CocoaPods?
Yes
- What is the impact on binary size?
Negligible - no included assets
- How severe, if at all, are inbuilt subdependencies?
No 3rd party dependencies
- Will this make the code more, or less, understandable for
volunteers?
More understandable - it provides an expressive "english" syntax for creating autolayout constraints. It introduces no new concepts, just type checking and syntax.
- What are the performance ramifications of using this library?
None, it uses cocoa autolayout under the covers.
- What are the complexity ramifications of using this library?
Masonry allows developers to write layout code in a much more concise and expressive way - this should reduce number of lines while increasing expressiveness.
- Is it actively maintained?
Yes and receives frequent pull requests.
- Is it compatible with current deployment targets?
Yep
- Does it hinder interop (e.g., with Swift)?
Nope
- What is the exit plan if the library becomes unmaintained?
Since Masonry is basically just a syntax veneer of autolayout - it should be possible for us to maintain if needed. There aren't any foreign concepts to understand. If we choose not to maintain - the constraints can be translated to the VFL language (or Interface Builder) easily.
If anyone has questions / comments - please reply here.
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle IRC: bgerstle
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
It looks like it is possible to use the Obj-C version from Swift:
https://github.com/Masonry/Masonry/issues/75#issuecomment-55230720
so one could probably migrate UI classes using it bit by bit.
But the new all-Swift version in Snap apparently has a cleaner syntax that fits with Swift better...
Actually, do they conflict? Could we start with one in Obj-C and transition to the Swift one in Swift classes, while both sit in place? In theory they're creating regular layout constraints so it's just the setup calls that are different...
-- brion
On Wed, Feb 18, 2015 at 2:59 PM, Monte Hurd mhurd@wikimedia.org wrote:
I found this Swift version of Masonry: https://github.com/Masonry/Snap
Are we confident in it, or does anyone know if the original Masonry repo maintainers have Swift plans?
If not, assuming one of our long-term goals is to eventually convert as much of the codebase to Swift as is practical, wouldn't adopting Masonry further entrench Obj-C implementations?
i.e. to "Swift-ify" Masonry'ed code we'd have to decompose Masonry syntax back to VFL strings and/or NSLayoutConstraints.
If there's not a solid Swift implementation, I'd be unsure if Masonry use is wise strategically. Thoughts?
Any concern that Masonry's syntax, while concise/elegant, raises the bar for outside contributions in that it deviates from the "standard" approach at all?
On Wed, Feb 18, 2015 at 10:09 AM, Brian Gerstle bgerstle@wikimedia.org wrote:
+1
On Wed, Feb 18, 2015 at 12:32 PM, Corey Floyd cfloyd@wikimedia.org wrote:
We were evaluating Masonry prior to our new 3rd party lib vetting process (See here for more info: https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Third_Party_Libraries), but still wanted to do a write up for everyone.
Masonry is a library that allows developers to write autolayout code similar to the Visual Format Language, but instead of error prone strings to describe relationships, it provides a compact compiler checked syntax. You can read more here: https://github.com/Masonry/Masonry
Below are answers to our standard questions:
- Is the license permissive?
Yes - MIT
- Is the library ubiquitous?
Yes 4,362+ stars and 475 forks on Github.
- Is it installable via CocoaPods?
Yes
- What is the impact on binary size?
Negligible - no included assets
- How severe, if at all, are inbuilt subdependencies?
No 3rd party dependencies
- Will this make the code more, or less, understandable for
volunteers?
More understandable - it provides an expressive "english" syntax for creating autolayout constraints. It introduces no new concepts, just type checking and syntax.
- What are the performance ramifications of using this library?
None, it uses cocoa autolayout under the covers.
- What are the complexity ramifications of using this library?
Masonry allows developers to write layout code in a much more concise and expressive way - this should reduce number of lines while increasing expressiveness.
- Is it actively maintained?
Yes and receives frequent pull requests.
- Is it compatible with current deployment targets?
Yep
- Does it hinder interop (e.g., with Swift)?
Nope
- What is the exit plan if the library becomes unmaintained?
Since Masonry is basically just a syntax veneer of autolayout - it should be possible for us to maintain if needed. There aren't any foreign concepts to understand. If we choose not to maintain - the constraints can be translated to the VFL language (or Interface Builder) easily.
If anyone has questions / comments - please reply here.
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle IRC: bgerstle
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Oooh interesting! I hadn't considered calling back to the Obj-C version from Swift land...
On Wed, Feb 18, 2015 at 3:13 PM, Brion Vibber bvibber@wikimedia.org wrote:
It looks like it is possible to use the Obj-C version from Swift:
https://github.com/Masonry/Masonry/issues/75#issuecomment-55230720
so one could probably migrate UI classes using it bit by bit.
But the new all-Swift version in Snap apparently has a cleaner syntax that fits with Swift better...
Actually, do they conflict? Could we start with one in Obj-C and transition to the Swift one in Swift classes, while both sit in place? In theory they're creating regular layout constraints so it's just the setup calls that are different...
-- brion
On Wed, Feb 18, 2015 at 2:59 PM, Monte Hurd mhurd@wikimedia.org wrote:
I found this Swift version of Masonry: https://github.com/Masonry/Snap
Are we confident in it, or does anyone know if the original Masonry repo maintainers have Swift plans?
If not, assuming one of our long-term goals is to eventually convert as much of the codebase to Swift as is practical, wouldn't adopting Masonry further entrench Obj-C implementations?
i.e. to "Swift-ify" Masonry'ed code we'd have to decompose Masonry syntax back to VFL strings and/or NSLayoutConstraints.
If there's not a solid Swift implementation, I'd be unsure if Masonry use is wise strategically. Thoughts?
Any concern that Masonry's syntax, while concise/elegant, raises the bar for outside contributions in that it deviates from the "standard" approach at all?
On Wed, Feb 18, 2015 at 10:09 AM, Brian Gerstle bgerstle@wikimedia.org wrote:
+1
On Wed, Feb 18, 2015 at 12:32 PM, Corey Floyd cfloyd@wikimedia.org wrote:
We were evaluating Masonry prior to our new 3rd party lib vetting process (See here for more info: https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Third_Party_Libraries), but still wanted to do a write up for everyone.
Masonry is a library that allows developers to write autolayout code similar to the Visual Format Language, but instead of error prone strings to describe relationships, it provides a compact compiler checked syntax. You can read more here: https://github.com/Masonry/Masonry
Below are answers to our standard questions:
- Is the license permissive?
Yes - MIT
- Is the library ubiquitous?
Yes 4,362+ stars and 475 forks on Github.
- Is it installable via CocoaPods?
Yes
- What is the impact on binary size?
Negligible - no included assets
- How severe, if at all, are inbuilt subdependencies?
No 3rd party dependencies
- Will this make the code more, or less, understandable for
volunteers?
More understandable - it provides an expressive "english" syntax for creating autolayout constraints. It introduces no new concepts, just type checking and syntax.
- What are the performance ramifications of using this library?
None, it uses cocoa autolayout under the covers.
- What are the complexity ramifications of using this library?
Masonry allows developers to write layout code in a much more concise and expressive way - this should reduce number of lines while increasing expressiveness.
- Is it actively maintained?
Yes and receives frequent pull requests.
- Is it compatible with current deployment targets?
Yep
- Does it hinder interop (e.g., with Swift)?
Nope
- What is the exit plan if the library becomes unmaintained?
Since Masonry is basically just a syntax veneer of autolayout - it should be possible for us to maintain if needed. There aren't any foreign concepts to understand. If we choose not to maintain - the constraints can be translated to the VFL language (or Interface Builder) easily.
If anyone has questions / comments - please reply here.
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle IRC: bgerstle
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Yeah we could swap them out when we need to pretty easily
On Wed, Feb 18, 2015 at 6:48 PM, Monte Hurd mhurd@wikimedia.org wrote:
Oooh interesting! I hadn't considered calling back to the Obj-C version from Swift land...
On Wed, Feb 18, 2015 at 3:13 PM, Brion Vibber bvibber@wikimedia.org wrote:
It looks like it is possible to use the Obj-C version from Swift:
https://github.com/Masonry/Masonry/issues/75#issuecomment-55230720
so one could probably migrate UI classes using it bit by bit.
But the new all-Swift version in Snap apparently has a cleaner syntax that fits with Swift better...
Actually, do they conflict? Could we start with one in Obj-C and transition to the Swift one in Swift classes, while both sit in place? In theory they're creating regular layout constraints so it's just the setup calls that are different...
-- brion
On Wed, Feb 18, 2015 at 2:59 PM, Monte Hurd mhurd@wikimedia.org wrote:
I found this Swift version of Masonry: https://github.com/Masonry/Snap
Are we confident in it, or does anyone know if the original Masonry repo maintainers have Swift plans?
If not, assuming one of our long-term goals is to eventually convert as much of the codebase to Swift as is practical, wouldn't adopting Masonry further entrench Obj-C implementations?
i.e. to "Swift-ify" Masonry'ed code we'd have to decompose Masonry syntax back to VFL strings and/or NSLayoutConstraints.
If there's not a solid Swift implementation, I'd be unsure if Masonry use is wise strategically. Thoughts?
Any concern that Masonry's syntax, while concise/elegant, raises the bar for outside contributions in that it deviates from the "standard" approach at all?
On Wed, Feb 18, 2015 at 10:09 AM, Brian Gerstle bgerstle@wikimedia.org wrote:
+1
On Wed, Feb 18, 2015 at 12:32 PM, Corey Floyd cfloyd@wikimedia.org wrote:
We were evaluating Masonry prior to our new 3rd party lib vetting process (See here for more info: https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Third_Party_Libraries), but still wanted to do a write up for everyone.
Masonry is a library that allows developers to write autolayout code similar to the Visual Format Language, but instead of error prone strings to describe relationships, it provides a compact compiler checked syntax. You can read more here: https://github.com/Masonry/Masonry
Below are answers to our standard questions:
- Is the license permissive?
Yes - MIT
- Is the library ubiquitous?
Yes 4,362+ stars and 475 forks on Github.
- Is it installable via CocoaPods?
Yes
- What is the impact on binary size?
Negligible - no included assets
- How severe, if at all, are inbuilt subdependencies?
No 3rd party dependencies
- Will this make the code more, or less, understandable for
volunteers?
More understandable - it provides an expressive "english" syntax for creating autolayout constraints. It introduces no new concepts, just type checking and syntax.
- What are the performance ramifications of using this library?
None, it uses cocoa autolayout under the covers.
- What are the complexity ramifications of using this library?
Masonry allows developers to write layout code in a much more concise and expressive way - this should reduce number of lines while increasing expressiveness.
- Is it actively maintained?
Yes and receives frequent pull requests.
- Is it compatible with current deployment targets?
Yep
- Does it hinder interop (e.g., with Swift)?
Nope
- What is the exit plan if the library becomes unmaintained?
Since Masonry is basically just a syntax veneer of autolayout - it should be possible for us to maintain if needed. There aren't any foreign concepts to understand. If we choose not to maintain - the constraints can be translated to the VFL language (or Interface Builder) easily.
If anyone has questions / comments - please reply here.
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle IRC: bgerstle
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Here's my take on this is:
|_ Establish layout related stuff in XIBs via Interface Builder when possible. |__ If the XIB approach is inadequate, use VFL where it's easy and clear and achieves the desired result. |___ If VFL is insufficient, try the more verbose builtin methods if they don't make it too hard (e.g., 4-8 manual constraints isn't that bad, but when it starts to go over that, things are probably getting messier than needed). |____ When XIBs, VFL, and verbose methods are too cumbersome, use Masonry if it helps achieve the task with greater clarity, easy, and correctness.
I trust we'll all be able to make reasonable case-by-case judgments about when to fall back from XIB+VFL+builtins to Masonry.
-Adam
On Wed, Feb 18, 2015 at 10:07 PM, Corey Floyd cfloyd@wikimedia.org wrote:
Yeah we could swap them out when we need to pretty easily
On Wed, Feb 18, 2015 at 6:48 PM, Monte Hurd mhurd@wikimedia.org wrote:
Oooh interesting! I hadn't considered calling back to the Obj-C version from Swift land...
On Wed, Feb 18, 2015 at 3:13 PM, Brion Vibber bvibber@wikimedia.org wrote:
It looks like it is possible to use the Obj-C version from Swift:
https://github.com/Masonry/Masonry/issues/75#issuecomment-55230720
so one could probably migrate UI classes using it bit by bit.
But the new all-Swift version in Snap apparently has a cleaner syntax that fits with Swift better...
Actually, do they conflict? Could we start with one in Obj-C and transition to the Swift one in Swift classes, while both sit in place? In theory they're creating regular layout constraints so it's just the setup calls that are different...
-- brion
On Wed, Feb 18, 2015 at 2:59 PM, Monte Hurd mhurd@wikimedia.org wrote:
I found this Swift version of Masonry: https://github.com/Masonry/Snap
Are we confident in it, or does anyone know if the original Masonry repo maintainers have Swift plans?
If not, assuming one of our long-term goals is to eventually convert as much of the codebase to Swift as is practical, wouldn't adopting Masonry further entrench Obj-C implementations?
i.e. to "Swift-ify" Masonry'ed code we'd have to decompose Masonry syntax back to VFL strings and/or NSLayoutConstraints.
If there's not a solid Swift implementation, I'd be unsure if Masonry use is wise strategically. Thoughts?
Any concern that Masonry's syntax, while concise/elegant, raises the bar for outside contributions in that it deviates from the "standard" approach at all?
On Wed, Feb 18, 2015 at 10:09 AM, Brian Gerstle <bgerstle@wikimedia.org
wrote:
+1
On Wed, Feb 18, 2015 at 12:32 PM, Corey Floyd cfloyd@wikimedia.org wrote:
We were evaluating Masonry prior to our new 3rd party lib vetting process (See here for more info: https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Third_Party_Libraries), but still wanted to do a write up for everyone.
Masonry is a library that allows developers to write autolayout code similar to the Visual Format Language, but instead of error prone strings to describe relationships, it provides a compact compiler checked syntax. You can read more here: https://github.com/Masonry/Masonry
Below are answers to our standard questions:
- Is the license permissive?
Yes - MIT
- Is the library ubiquitous?
Yes 4,362+ stars and 475 forks on Github.
- Is it installable via CocoaPods?
Yes
- What is the impact on binary size?
Negligible - no included assets
- How severe, if at all, are inbuilt subdependencies?
No 3rd party dependencies
- Will this make the code more, or less, understandable for
volunteers?
More understandable - it provides an expressive "english" syntax for creating autolayout constraints. It introduces no new concepts, just type checking and syntax.
- What are the performance ramifications of using this library?
None, it uses cocoa autolayout under the covers.
- What are the complexity ramifications of using this library?
Masonry allows developers to write layout code in a much more concise and expressive way - this should reduce number of lines while increasing expressiveness.
- Is it actively maintained?
Yes and receives frequent pull requests.
- Is it compatible with current deployment targets?
Yep
- Does it hinder interop (e.g., with Swift)?
Nope
- What is the exit plan if the library becomes unmaintained?
Since Masonry is basically just a syntax veneer of autolayout - it should be possible for us to maintain if needed. There aren't any foreign concepts to understand. If we choose not to maintain - the constraints can be translated to the VFL language (or Interface Builder) easily.
If anyone has questions / comments - please reply here.
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle IRC: bgerstle
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- Corey Floyd Software Engineer Mobile Apps / iOS Wikimedia Foundation
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Adam great point above about Interface Builder - it should absolutely be the first choice for building UI before anything else - Xcode 6's IB autolayout support is fantastic and you can do pretty much anything that doesn't involve dynamically changing a constraint at runtime. Always use the highest level abstraction you can (we currently have a lot of layout written in code that could/should be done in IB).
But for anything that is better done in code, I highly recommend using Masonry before the other methods.
The entire point of Masonry's existence is that building constraints in code is at best verbose (if you construct NSLayoutConstraints objects), and at worst difficult to debug (if you use VFL since there is no compiler time checking of your constraints).
Even setting up 4-8 constraints is pretty unwieldy in code. I think the Masonry readme does a good job of demonstrating this ( https://github.com/Masonry/Masonry), but a real example might be better…
See this existing 40 lines of code from our project. Not only is it long, but I think most people will need to look it over a few times to understand it - I am pretty experienced with autolayout, and it took me a couple minutes to get the intent (get ready to scroll):
NSDictionary *views = @{@"label": label, @"v1": view};
NSDictionary *metrics = @{
@"iconHeight": @(iconHeight),
@"topBarHeight": @(topBarHeight)
};
[view addConstraints:[NSLayoutConstraint constraintsWithVisualFormat: @"V:[v1(topBarHeight)]"
options: 0
metrics: metrics
views: views]];
[view addConstraints:[NSLayoutConstraint constraintsWithVisualFormat: @"V:[label(iconHeight)]"
options: 0
metrics: metrics
views: views]];
[view addConstraints:[NSLayoutConstraint constraintsWithVisualFormat: @"H:[label(iconHeight)]"
options: 0
metrics: metrics
views: views]];
[view addConstraint: [NSLayoutConstraint constraintWithItem: label
attribute : NSLayoutAttributeCenterX
relatedBy : NSLayoutRelationEqual
toItem: view
attribute : NSLayoutAttributeCenterX
multiplier : 1
constant : 0]];
[view addConstraint: [NSLayoutConstraint constraintWithItem: label
attribute : NSLayoutAttributeCenterY
relatedBy : NSLayoutRelationEqual
toItem: view
attribute : NSLayoutAttributeCenterY
multiplier : 1
constant : 0]];
-----
Compare that to the code below:
[view mas_makeConstraints:^(MASConstraintMaker *make) {
make.height.equalTo(@(topBarHeight));
make.center.equalTo(label);
}];
[label mas_makeConstraints:^(MASConstraintMaker *make) {
make.height.equalTo(@(iconHeight));
make.width.equalTo(@(iconHeight));
}];
It took me longer to grok the old code than it did for me to write the 10 lines to replace it. Not to mention, the intent of the Masonry code reads very well (no keys to assign to my views, no dictionaries to hold values). And the best part is that the compiler would instantly tell me if I had written an invalid constraint, unlike the old code where it would have been very easy for someone to forget to type a "(" or a ":"
(note: conflicting/ambiguous constraints are different concern that really only IB can handle which is a good reason why you should always try to use that first)
On Thu, Feb 19, 2015 at 12:34 PM, Adam Baso abaso@wikimedia.org wrote:
Here's my take on this is:
|_ Establish layout related stuff in XIBs via Interface Builder when possible. |__ If the XIB approach is inadequate, use VFL where it's easy and clear and achieves the desired result. |___ If VFL is insufficient, try the more verbose builtin methods if they don't make it too hard (e.g., 4-8 manual constraints isn't that bad, but when it starts to go over that, things are probably getting messier than needed). |____ When XIBs, VFL, and verbose methods are too cumbersome, use Masonry if it helps achieve the task with greater clarity, easy, and correctness.
I trust we'll all be able to make reasonable case-by-case judgments about when to fall back from XIB+VFL+builtins to Masonry.
-Adam
On Wed, Feb 18, 2015 at 10:07 PM, Corey Floyd cfloyd@wikimedia.org wrote:
Yeah we could swap them out when we need to pretty easily
On Wed, Feb 18, 2015 at 6:48 PM, Monte Hurd mhurd@wikimedia.org wrote:
Oooh interesting! I hadn't considered calling back to the Obj-C version from Swift land...
On Wed, Feb 18, 2015 at 3:13 PM, Brion Vibber bvibber@wikimedia.org wrote:
It looks like it is possible to use the Obj-C version from Swift:
https://github.com/Masonry/Masonry/issues/75#issuecomment-55230720
so one could probably migrate UI classes using it bit by bit.
But the new all-Swift version in Snap apparently has a cleaner syntax that fits with Swift better...
Actually, do they conflict? Could we start with one in Obj-C and transition to the Swift one in Swift classes, while both sit in place? In theory they're creating regular layout constraints so it's just the setup calls that are different...
-- brion
On Wed, Feb 18, 2015 at 2:59 PM, Monte Hurd mhurd@wikimedia.org wrote:
I found this Swift version of Masonry: https://github.com/Masonry/Snap
Are we confident in it, or does anyone know if the original Masonry repo maintainers have Swift plans?
If not, assuming one of our long-term goals is to eventually convert as much of the codebase to Swift as is practical, wouldn't adopting Masonry further entrench Obj-C implementations?
i.e. to "Swift-ify" Masonry'ed code we'd have to decompose Masonry syntax back to VFL strings and/or NSLayoutConstraints.
If there's not a solid Swift implementation, I'd be unsure if Masonry use is wise strategically. Thoughts?
Any concern that Masonry's syntax, while concise/elegant, raises the bar for outside contributions in that it deviates from the "standard" approach at all?
On Wed, Feb 18, 2015 at 10:09 AM, Brian Gerstle < bgerstle@wikimedia.org> wrote:
+1
On Wed, Feb 18, 2015 at 12:32 PM, Corey Floyd cfloyd@wikimedia.org wrote:
> We were evaluating Masonry prior to our new 3rd party lib vetting > process (See here for more info: > https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Third_Party_Libraries), > but still wanted to do a write up for everyone. > > Masonry is a library that allows developers to write autolayout code > similar to the Visual Format Language, but instead of error prone strings > to describe relationships, it provides a compact compiler checked syntax. > You can read more here: > https://github.com/Masonry/Masonry > > > Below are answers to our standard questions: > > > - Is the license permissive? > > Yes - MIT > > - Is the library ubiquitous? > > Yes 4,362+ stars and 475 forks on Github. > > - Is it installable via CocoaPods? > > Yes > > - What is the impact on binary size? > > Negligible - no included assets > > - How severe, if at all, are inbuilt subdependencies? > > No 3rd party dependencies > > - Will this make the code more, or less, understandable for > volunteers? > > More understandable - it provides an expressive "english" syntax for > creating autolayout constraints. It introduces no new concepts, just type > checking and syntax. > > - What are the performance ramifications of using this library? > > None, it uses cocoa autolayout under the covers. > > - What are the complexity ramifications of using this library? > > Masonry allows developers to write layout code in a much more > concise and expressive way - this should reduce number of lines while > increasing expressiveness. > > - Is it actively maintained? > > Yes and receives frequent pull requests. > > - Is it compatible with current deployment targets? > > Yep > > - Does it hinder interop (e.g., with Swift)? > > Nope > > - What is the exit plan if the library becomes unmaintained? > > Since Masonry is basically just a syntax veneer of autolayout - it > should be possible for us to maintain if needed. There aren't any foreign > concepts to understand. If we choose not to maintain - the constraints can > be translated to the VFL language (or Interface Builder) easily. > > > > If anyone has questions / comments - please reply here. > > > > _______________________________________________ > Mobile-l mailing list > Mobile-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mobile-l > >
-- EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle IRC: bgerstle
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- Corey Floyd Software Engineer Mobile Apps / iOS Wikimedia Foundation
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
+1 for everything corey said
On Thu, Feb 19, 2015 at 1:38 PM, Corey Floyd cfloyd@wikimedia.org wrote:
Adam great point above about Interface Builder - it should absolutely be the first choice for building UI before anything else - Xcode 6's IB autolayout support is fantastic and you can do pretty much anything that doesn't involve dynamically changing a constraint at runtime. Always use the highest level abstraction you can (we currently have a lot of layout written in code that could/should be done in IB).
But for anything that is better done in code, I highly recommend using Masonry before the other methods.
The entire point of Masonry's existence is that building constraints in code is at best verbose (if you construct NSLayoutConstraints objects), and at worst difficult to debug (if you use VFL since there is no compiler time checking of your constraints).
Even setting up 4-8 constraints is pretty unwieldy in code. I think the Masonry readme does a good job of demonstrating this ( https://github.com/Masonry/Masonry), but a real example might be better…
See this existing 40 lines of code from our project. Not only is it long, but I think most people will need to look it over a few times to understand it - I am pretty experienced with autolayout, and it took me a couple minutes to get the intent (get ready to scroll):
NSDictionary *views = @{@"label": label, @"v1": view}; NSDictionary *metrics = @{ @"iconHeight": @(iconHeight), @"topBarHeight": @(topBarHeight) }; [view addConstraints:[NSLayoutConstraintconstraintsWithVisualFormat: @"V:[v1(topBarHeight)]"
options: 0
metrics: metrics
views: views]]; [view addConstraints:[NSLayoutConstraintconstraintsWithVisualFormat: @"V:[label(iconHeight)]"
options: 0
metrics: metrics
views: views]]; [view addConstraints:[NSLayoutConstraintconstraintsWithVisualFormat: @"H:[label(iconHeight)]"
options: 0
metrics: metrics
views: views]]; [view addConstraint: [NSLayoutConstraintconstraintWithItem: label
attribute: NSLayoutAttributeCenterX
relatedBy: NSLayoutRelationEqual
toItem: view
attribute: NSLayoutAttributeCenterX
multiplier: 1
constant: 0]];
[view addConstraint: [NSLayoutConstraintconstraintWithItem: label
attribute: NSLayoutAttributeCenterY
relatedBy: NSLayoutRelationEqual
toItem: view
attribute: NSLayoutAttributeCenterY
multiplier: 1
constant: 0]];
Compare that to the code below:
[view mas_makeConstraints:^(MASConstraintMaker *make) { make.height.equalTo(@(topBarHeight)); make.center.equalTo(label); }]; [label mas_makeConstraints:^(MASConstraintMaker *make) { make.height.equalTo(@(iconHeight)); make.width.equalTo(@(iconHeight)); }];It took me longer to grok the old code than it did for me to write the 10 lines to replace it. Not to mention, the intent of the Masonry code reads very well (no keys to assign to my views, no dictionaries to hold values). And the best part is that the compiler would instantly tell me if I had written an invalid constraint, unlike the old code where it would have been very easy for someone to forget to type a "(" or a ":"
(note: conflicting/ambiguous constraints are different concern that really only IB can handle which is a good reason why you should always try to use that first)
On Thu, Feb 19, 2015 at 12:34 PM, Adam Baso abaso@wikimedia.org wrote:
Here's my take on this is:
|_ Establish layout related stuff in XIBs via Interface Builder when possible. |__ If the XIB approach is inadequate, use VFL where it's easy and clear and achieves the desired result. |___ If VFL is insufficient, try the more verbose builtin methods if they don't make it too hard (e.g., 4-8 manual constraints isn't that bad, but when it starts to go over that, things are probably getting messier than needed). |____ When XIBs, VFL, and verbose methods are too cumbersome, use Masonry if it helps achieve the task with greater clarity, easy, and correctness.
I trust we'll all be able to make reasonable case-by-case judgments about when to fall back from XIB+VFL+builtins to Masonry.
-Adam
On Wed, Feb 18, 2015 at 10:07 PM, Corey Floyd cfloyd@wikimedia.org wrote:
Yeah we could swap them out when we need to pretty easily
On Wed, Feb 18, 2015 at 6:48 PM, Monte Hurd mhurd@wikimedia.org wrote:
Oooh interesting! I hadn't considered calling back to the Obj-C version from Swift land...
On Wed, Feb 18, 2015 at 3:13 PM, Brion Vibber bvibber@wikimedia.org wrote:
It looks like it is possible to use the Obj-C version from Swift:
https://github.com/Masonry/Masonry/issues/75#issuecomment-55230720
so one could probably migrate UI classes using it bit by bit.
But the new all-Swift version in Snap apparently has a cleaner syntax that fits with Swift better...
Actually, do they conflict? Could we start with one in Obj-C and transition to the Swift one in Swift classes, while both sit in place? In theory they're creating regular layout constraints so it's just the setup calls that are different...
-- brion
On Wed, Feb 18, 2015 at 2:59 PM, Monte Hurd mhurd@wikimedia.org wrote:
I found this Swift version of Masonry: https://github.com/Masonry/Snap
Are we confident in it, or does anyone know if the original Masonry repo maintainers have Swift plans?
If not, assuming one of our long-term goals is to eventually convert as much of the codebase to Swift as is practical, wouldn't adopting Masonry further entrench Obj-C implementations?
i.e. to "Swift-ify" Masonry'ed code we'd have to decompose Masonry syntax back to VFL strings and/or NSLayoutConstraints.
If there's not a solid Swift implementation, I'd be unsure if Masonry use is wise strategically. Thoughts?
Any concern that Masonry's syntax, while concise/elegant, raises the bar for outside contributions in that it deviates from the "standard" approach at all?
On Wed, Feb 18, 2015 at 10:09 AM, Brian Gerstle < bgerstle@wikimedia.org> wrote:
> +1 > > On Wed, Feb 18, 2015 at 12:32 PM, Corey Floyd cfloyd@wikimedia.org > wrote: > >> We were evaluating Masonry prior to our new 3rd party lib vetting >> process (See here for more info: >> https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Third_Party_Libraries), >> but still wanted to do a write up for everyone. >> >> Masonry is a library that allows developers to write autolayout >> code similar to the Visual Format Language, but instead of error prone >> strings to describe relationships, it provides a compact compiler checked >> syntax. You can read more here: >> https://github.com/Masonry/Masonry >> >> >> Below are answers to our standard questions: >> >> >> - Is the license permissive? >> >> Yes - MIT >> >> - Is the library ubiquitous? >> >> Yes 4,362+ stars and 475 forks on Github. >> >> - Is it installable via CocoaPods? >> >> Yes >> >> - What is the impact on binary size? >> >> Negligible - no included assets >> >> - How severe, if at all, are inbuilt subdependencies? >> >> No 3rd party dependencies >> >> - Will this make the code more, or less, understandable for >> volunteers? >> >> More understandable - it provides an expressive "english" syntax >> for creating autolayout constraints. It introduces no new concepts, just >> type checking and syntax. >> >> - What are the performance ramifications of using this library? >> >> None, it uses cocoa autolayout under the covers. >> >> - What are the complexity ramifications of using this library? >> >> Masonry allows developers to write layout code in a much more >> concise and expressive way - this should reduce number of lines while >> increasing expressiveness. >> >> - Is it actively maintained? >> >> Yes and receives frequent pull requests. >> >> - Is it compatible with current deployment targets? >> >> Yep >> >> - Does it hinder interop (e.g., with Swift)? >> >> Nope >> >> - What is the exit plan if the library becomes unmaintained? >> >> Since Masonry is basically just a syntax veneer of autolayout - it >> should be possible for us to maintain if needed. There aren't any foreign >> concepts to understand. If we choose not to maintain - the constraints can >> be translated to the VFL language (or Interface Builder) easily. >> >> >> >> If anyone has questions / comments - please reply here. >> >> >> >> _______________________________________________ >> Mobile-l mailing list >> Mobile-l@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/mobile-l >> >> > > > -- > EN Wikipedia user page: > https://en.wikipedia.org/wiki/User:Brian.gerstle > IRC: bgerstle > > _______________________________________________ > Mobile-l mailing list > Mobile-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mobile-l > >
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- Corey Floyd Software Engineer Mobile Apps / iOS Wikimedia Foundation
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- Corey Floyd Software Engineer Mobile Apps / iOS Wikimedia Foundation
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Agreed. 4-8 might even be a little generous sometimes :)
On Thu, Feb 19, 2015 at 11:16 AM, Brian Gerstle bgerstle@wikimedia.org wrote:
+1 for everything corey said
On Thu, Feb 19, 2015 at 1:38 PM, Corey Floyd cfloyd@wikimedia.org wrote:
Adam great point above about Interface Builder - it should absolutely be the first choice for building UI before anything else - Xcode 6's IB autolayout support is fantastic and you can do pretty much anything that doesn't involve dynamically changing a constraint at runtime. Always use the highest level abstraction you can (we currently have a lot of layout written in code that could/should be done in IB).
But for anything that is better done in code, I highly recommend using Masonry before the other methods.
The entire point of Masonry's existence is that building constraints in code is at best verbose (if you construct NSLayoutConstraints objects), and at worst difficult to debug (if you use VFL since there is no compiler time checking of your constraints).
Even setting up 4-8 constraints is pretty unwieldy in code. I think the Masonry readme does a good job of demonstrating this ( https://github.com/Masonry/Masonry), but a real example might be better…
See this existing 40 lines of code from our project. Not only is it long, but I think most people will need to look it over a few times to understand it - I am pretty experienced with autolayout, and it took me a couple minutes to get the intent (get ready to scroll):
NSDictionary *views = @{@"label": label, @"v1": view}; NSDictionary *metrics = @{ @"iconHeight": @(iconHeight), @"topBarHeight": @(topBarHeight) }; [view addConstraints:[NSLayoutConstraintconstraintsWithVisualFormat: @"V:[v1(topBarHeight)]"
options: 0 metrics: metrics views: views]]; [view addConstraints:[NSLayoutConstraintconstraintsWithVisualFormat: @"V:[label(iconHeight)]"
options: 0 metrics: metrics views: views]]; [view addConstraints:[NSLayoutConstraintconstraintsWithVisualFormat: @"H:[label(iconHeight)]"
options: 0 metrics: metrics views: views]]; [view addConstraint: [NSLayoutConstraintconstraintWithItem: label
attribute: NSLayoutAttributeCenterX
relatedBy: NSLayoutRelationEqual
toItem: view
attribute: NSLayoutAttributeCenterX
multiplier: 1
constant: 0]];
[view addConstraint: [NSLayoutConstraintconstraintWithItem: label
attribute: NSLayoutAttributeCenterY
relatedBy: NSLayoutRelationEqual
toItem: view
attribute: NSLayoutAttributeCenterY
multiplier: 1
constant: 0]];
Compare that to the code below:
[view mas_makeConstraints:^(MASConstraintMaker *make) { make.height.equalTo(@(topBarHeight)); make.center.equalTo(label); }]; [label mas_makeConstraints:^(MASConstraintMaker *make) { make.height.equalTo(@(iconHeight)); make.width.equalTo(@(iconHeight)); }];It took me longer to grok the old code than it did for me to write the 10 lines to replace it. Not to mention, the intent of the Masonry code reads very well (no keys to assign to my views, no dictionaries to hold values). And the best part is that the compiler would instantly tell me if I had written an invalid constraint, unlike the old code where it would have been very easy for someone to forget to type a "(" or a ":"
(note: conflicting/ambiguous constraints are different concern that really only IB can handle which is a good reason why you should always try to use that first)
On Thu, Feb 19, 2015 at 12:34 PM, Adam Baso abaso@wikimedia.org wrote:
Here's my take on this is:
|_ Establish layout related stuff in XIBs via Interface Builder when possible. |__ If the XIB approach is inadequate, use VFL where it's easy and clear and achieves the desired result. |___ If VFL is insufficient, try the more verbose builtin methods if they don't make it too hard (e.g., 4-8 manual constraints isn't that bad, but when it starts to go over that, things are probably getting messier than needed). |____ When XIBs, VFL, and verbose methods are too cumbersome, use Masonry if it helps achieve the task with greater clarity, easy, and correctness.
I trust we'll all be able to make reasonable case-by-case judgments about when to fall back from XIB+VFL+builtins to Masonry.
-Adam
On Wed, Feb 18, 2015 at 10:07 PM, Corey Floyd cfloyd@wikimedia.org wrote:
Yeah we could swap them out when we need to pretty easily
On Wed, Feb 18, 2015 at 6:48 PM, Monte Hurd mhurd@wikimedia.org wrote:
Oooh interesting! I hadn't considered calling back to the Obj-C version from Swift land...
On Wed, Feb 18, 2015 at 3:13 PM, Brion Vibber bvibber@wikimedia.org wrote:
It looks like it is possible to use the Obj-C version from Swift:
https://github.com/Masonry/Masonry/issues/75#issuecomment-55230720
so one could probably migrate UI classes using it bit by bit.
But the new all-Swift version in Snap apparently has a cleaner syntax that fits with Swift better...
Actually, do they conflict? Could we start with one in Obj-C and transition to the Swift one in Swift classes, while both sit in place? In theory they're creating regular layout constraints so it's just the setup calls that are different...
-- brion
On Wed, Feb 18, 2015 at 2:59 PM, Monte Hurd mhurd@wikimedia.org wrote:
> I found this Swift version of Masonry: > https://github.com/Masonry/Snap > > Are we confident in it, or does anyone know if the original Masonry > repo maintainers have Swift plans? > > If not, assuming one of our long-term goals is to eventually convert > as much of the codebase to Swift as is practical, wouldn't adopting Masonry > further entrench Obj-C implementations? > > i.e. to "Swift-ify" Masonry'ed code we'd have to decompose Masonry > syntax back to VFL strings and/or NSLayoutConstraints. > > If there's not a solid Swift implementation, I'd be unsure if > Masonry use is wise strategically. Thoughts? > > Any concern that Masonry's syntax, while concise/elegant, raises the > bar for outside contributions in that it deviates from the "standard" > approach at all? > > > On Wed, Feb 18, 2015 at 10:09 AM, Brian Gerstle < > bgerstle@wikimedia.org> wrote: > >> +1 >> >> On Wed, Feb 18, 2015 at 12:32 PM, Corey Floyd <cfloyd@wikimedia.org >> > wrote: >> >>> We were evaluating Masonry prior to our new 3rd party lib vetting >>> process (See here for more info: >>> https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Third_Party_Libraries), >>> but still wanted to do a write up for everyone. >>> >>> Masonry is a library that allows developers to write autolayout >>> code similar to the Visual Format Language, but instead of error prone >>> strings to describe relationships, it provides a compact compiler checked >>> syntax. You can read more here: >>> https://github.com/Masonry/Masonry >>> >>> >>> Below are answers to our standard questions: >>> >>> >>> - Is the license permissive? >>> >>> Yes - MIT >>> >>> - Is the library ubiquitous? >>> >>> Yes 4,362+ stars and 475 forks on Github. >>> >>> - Is it installable via CocoaPods? >>> >>> Yes >>> >>> - What is the impact on binary size? >>> >>> Negligible - no included assets >>> >>> - How severe, if at all, are inbuilt subdependencies? >>> >>> No 3rd party dependencies >>> >>> - Will this make the code more, or less, understandable for >>> volunteers? >>> >>> More understandable - it provides an expressive "english" syntax >>> for creating autolayout constraints. It introduces no new concepts, just >>> type checking and syntax. >>> >>> - What are the performance ramifications of using this >>> library? >>> >>> None, it uses cocoa autolayout under the covers. >>> >>> - What are the complexity ramifications of using this library? >>> >>> Masonry allows developers to write layout code in a much more >>> concise and expressive way - this should reduce number of lines while >>> increasing expressiveness. >>> >>> - Is it actively maintained? >>> >>> Yes and receives frequent pull requests. >>> >>> - Is it compatible with current deployment targets? >>> >>> Yep >>> >>> - Does it hinder interop (e.g., with Swift)? >>> >>> Nope >>> >>> - What is the exit plan if the library becomes unmaintained? >>> >>> Since Masonry is basically just a syntax veneer of autolayout - it >>> should be possible for us to maintain if needed. There aren't any foreign >>> concepts to understand. If we choose not to maintain - the constraints can >>> be translated to the VFL language (or Interface Builder) easily. >>> >>> >>> >>> If anyone has questions / comments - please reply here. >>> >>> >>> >>> _______________________________________________ >>> Mobile-l mailing list >>> Mobile-l@lists.wikimedia.org >>> https://lists.wikimedia.org/mailman/listinfo/mobile-l >>> >>> >> >> >> -- >> EN Wikipedia user page: >> https://en.wikipedia.org/wiki/User:Brian.gerstle >> IRC: bgerstle >> >> _______________________________________________ >> Mobile-l mailing list >> Mobile-l@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/mobile-l >> >> > > _______________________________________________ > Mobile-l mailing list > Mobile-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mobile-l > >
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- Corey Floyd Software Engineer Mobile Apps / iOS Wikimedia Foundation
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- Corey Floyd Software Engineer Mobile Apps / iOS Wikimedia Foundation
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle IRC: bgerstle
SHIP IT! :)
On Thu, Feb 19, 2015 at 12:51 PM, Adam Baso abaso@wikimedia.org wrote:
Agreed. 4-8 might even be a little generous sometimes :)
On Thu, Feb 19, 2015 at 11:16 AM, Brian Gerstle bgerstle@wikimedia.org wrote:
+1 for everything corey said
On Thu, Feb 19, 2015 at 1:38 PM, Corey Floyd cfloyd@wikimedia.org wrote:
Adam great point above about Interface Builder - it should absolutely be the first choice for building UI before anything else - Xcode 6's IB autolayout support is fantastic and you can do pretty much anything that doesn't involve dynamically changing a constraint at runtime. Always use the highest level abstraction you can (we currently have a lot of layout written in code that could/should be done in IB).
But for anything that is better done in code, I highly recommend using Masonry before the other methods.
The entire point of Masonry's existence is that building constraints in code is at best verbose (if you construct NSLayoutConstraints objects), and at worst difficult to debug (if you use VFL since there is no compiler time checking of your constraints).
Even setting up 4-8 constraints is pretty unwieldy in code. I think the Masonry readme does a good job of demonstrating this ( https://github.com/Masonry/Masonry), but a real example might be better…
See this existing 40 lines of code from our project. Not only is it long, but I think most people will need to look it over a few times to understand it - I am pretty experienced with autolayout, and it took me a couple minutes to get the intent (get ready to scroll):
NSDictionary *views = @{@"label": label, @"v1": view}; NSDictionary *metrics = @{ @"iconHeight": @(iconHeight), @"topBarHeight": @(topBarHeight) }; [view addConstraints:[NSLayoutConstraintconstraintsWithVisualFormat: @"V:[v1(topBarHeight)]"
options: 0 metrics: metrics views: views]]; [view addConstraints:[NSLayoutConstraintconstraintsWithVisualFormat: @"V:[label(iconHeight)]"
options: 0 metrics: metrics views: views]]; [view addConstraints:[NSLayoutConstraintconstraintsWithVisualFormat: @"H:[label(iconHeight)]"
options: 0 metrics: metrics views: views]]; [view addConstraint: [NSLayoutConstraintconstraintWithItem: label
attribute: NSLayoutAttributeCenterX
relatedBy: NSLayoutRelationEqual
toItem: view
attribute: NSLayoutAttributeCenterX
multiplier: 1
constant: 0]];
[view addConstraint: [NSLayoutConstraintconstraintWithItem: label
attribute: NSLayoutAttributeCenterY
relatedBy: NSLayoutRelationEqual
toItem: view
attribute: NSLayoutAttributeCenterY
multiplier: 1
constant: 0]];
Compare that to the code below:
[view mas_makeConstraints:^(MASConstraintMaker *make) { make.height.equalTo(@(topBarHeight)); make.center.equalTo(label); }]; [label mas_makeConstraints:^(MASConstraintMaker *make) { make.height.equalTo(@(iconHeight)); make.width.equalTo(@(iconHeight)); }];It took me longer to grok the old code than it did for me to write the 10 lines to replace it. Not to mention, the intent of the Masonry code reads very well (no keys to assign to my views, no dictionaries to hold values). And the best part is that the compiler would instantly tell me if I had written an invalid constraint, unlike the old code where it would have been very easy for someone to forget to type a "(" or a ":"
(note: conflicting/ambiguous constraints are different concern that really only IB can handle which is a good reason why you should always try to use that first)
On Thu, Feb 19, 2015 at 12:34 PM, Adam Baso abaso@wikimedia.org wrote:
Here's my take on this is:
|_ Establish layout related stuff in XIBs via Interface Builder when possible. |__ If the XIB approach is inadequate, use VFL where it's easy and clear and achieves the desired result. |___ If VFL is insufficient, try the more verbose builtin methods if they don't make it too hard (e.g., 4-8 manual constraints isn't that bad, but when it starts to go over that, things are probably getting messier than needed). |____ When XIBs, VFL, and verbose methods are too cumbersome, use Masonry if it helps achieve the task with greater clarity, easy, and correctness.
I trust we'll all be able to make reasonable case-by-case judgments about when to fall back from XIB+VFL+builtins to Masonry.
-Adam
On Wed, Feb 18, 2015 at 10:07 PM, Corey Floyd cfloyd@wikimedia.org wrote:
Yeah we could swap them out when we need to pretty easily
On Wed, Feb 18, 2015 at 6:48 PM, Monte Hurd mhurd@wikimedia.org wrote:
Oooh interesting! I hadn't considered calling back to the Obj-C version from Swift land...
On Wed, Feb 18, 2015 at 3:13 PM, Brion Vibber bvibber@wikimedia.org wrote:
> It looks like it is possible to use the Obj-C version from Swift: > > https://github.com/Masonry/Masonry/issues/75#issuecomment-55230720 > > so one could probably migrate UI classes using it bit by bit. > > But the new all-Swift version in Snap apparently has a cleaner > syntax that fits with Swift better... > > Actually, do they conflict? Could we start with one in Obj-C and > transition to the Swift one in Swift classes, while both sit in place? In > theory they're creating regular layout constraints so it's just the setup > calls that are different... > > -- brion > > On Wed, Feb 18, 2015 at 2:59 PM, Monte Hurd mhurd@wikimedia.org > wrote: > >> I found this Swift version of Masonry: >> https://github.com/Masonry/Snap >> >> Are we confident in it, or does anyone know if the original Masonry >> repo maintainers have Swift plans? >> >> If not, assuming one of our long-term goals is to eventually >> convert as much of the codebase to Swift as is practical, wouldn't adopting >> Masonry further entrench Obj-C implementations? >> >> i.e. to "Swift-ify" Masonry'ed code we'd have to decompose Masonry >> syntax back to VFL strings and/or NSLayoutConstraints. >> >> If there's not a solid Swift implementation, I'd be unsure if >> Masonry use is wise strategically. Thoughts? >> >> Any concern that Masonry's syntax, while concise/elegant, raises >> the bar for outside contributions in that it deviates from the "standard" >> approach at all? >> >> >> On Wed, Feb 18, 2015 at 10:09 AM, Brian Gerstle < >> bgerstle@wikimedia.org> wrote: >> >>> +1 >>> >>> On Wed, Feb 18, 2015 at 12:32 PM, Corey Floyd < >>> cfloyd@wikimedia.org> wrote: >>> >>>> We were evaluating Masonry prior to our new 3rd party lib vetting >>>> process (See here for more info: >>>> https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Third_Party_Libraries), >>>> but still wanted to do a write up for everyone. >>>> >>>> Masonry is a library that allows developers to write autolayout >>>> code similar to the Visual Format Language, but instead of error prone >>>> strings to describe relationships, it provides a compact compiler checked >>>> syntax. You can read more here: >>>> https://github.com/Masonry/Masonry >>>> >>>> >>>> Below are answers to our standard questions: >>>> >>>> >>>> - Is the license permissive? >>>> >>>> Yes - MIT >>>> >>>> - Is the library ubiquitous? >>>> >>>> Yes 4,362+ stars and 475 forks on Github. >>>> >>>> - Is it installable via CocoaPods? >>>> >>>> Yes >>>> >>>> - What is the impact on binary size? >>>> >>>> Negligible - no included assets >>>> >>>> - How severe, if at all, are inbuilt subdependencies? >>>> >>>> No 3rd party dependencies >>>> >>>> - Will this make the code more, or less, understandable for >>>> volunteers? >>>> >>>> More understandable - it provides an expressive "english" syntax >>>> for creating autolayout constraints. It introduces no new concepts, just >>>> type checking and syntax. >>>> >>>> - What are the performance ramifications of using this >>>> library? >>>> >>>> None, it uses cocoa autolayout under the covers. >>>> >>>> - What are the complexity ramifications of using this >>>> library? >>>> >>>> Masonry allows developers to write layout code in a much more >>>> concise and expressive way - this should reduce number of lines while >>>> increasing expressiveness. >>>> >>>> - Is it actively maintained? >>>> >>>> Yes and receives frequent pull requests. >>>> >>>> - Is it compatible with current deployment targets? >>>> >>>> Yep >>>> >>>> - Does it hinder interop (e.g., with Swift)? >>>> >>>> Nope >>>> >>>> - What is the exit plan if the library becomes unmaintained? >>>> >>>> Since Masonry is basically just a syntax veneer of autolayout - >>>> it should be possible for us to maintain if needed. There aren't any >>>> foreign concepts to understand. If we choose not to maintain - the >>>> constraints can be translated to the VFL language (or Interface Builder) >>>> easily. >>>> >>>> >>>> >>>> If anyone has questions / comments - please reply here. >>>> >>>> >>>> >>>> _______________________________________________ >>>> Mobile-l mailing list >>>> Mobile-l@lists.wikimedia.org >>>> https://lists.wikimedia.org/mailman/listinfo/mobile-l >>>> >>>> >>> >>> >>> -- >>> EN Wikipedia user page: >>> https://en.wikipedia.org/wiki/User:Brian.gerstle >>> IRC: bgerstle >>> >>> _______________________________________________ >>> Mobile-l mailing list >>> Mobile-l@lists.wikimedia.org >>> https://lists.wikimedia.org/mailman/listinfo/mobile-l >>> >>> >> >> _______________________________________________ >> Mobile-l mailing list >> Mobile-l@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/mobile-l >> >> >
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- Corey Floyd Software Engineer Mobile Apps / iOS Wikimedia Foundation
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- Corey Floyd Software Engineer Mobile Apps / iOS Wikimedia Foundation
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle IRC: bgerstle
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l