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:


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