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 <[email protected]> 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 <[email protected]> > wrote: > >> Yeah we could swap them out when we need to pretty easily >> >> On Wed, Feb 18, 2015 at 6:48 PM, Monte Hurd <[email protected]> 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 <[email protected]> >>> 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 <[email protected]> >>>> 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 < >>>>> [email protected]> wrote: >>>>> >>>>>> +1 >>>>>> >>>>>> On Wed, Feb 18, 2015 at 12:32 PM, Corey Floyd <[email protected]> >>>>>> 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 >>>>>>> [email protected] >>>>>>> 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 >>>>>> [email protected] >>>>>> https://lists.wikimedia.org/mailman/listinfo/mobile-l >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Mobile-l mailing list >>>>> [email protected] >>>>> https://lists.wikimedia.org/mailman/listinfo/mobile-l >>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> Mobile-l mailing list >>> [email protected] >>> https://lists.wikimedia.org/mailman/listinfo/mobile-l >>> >>> >> >> >> -- >> Corey Floyd >> Software Engineer >> Mobile Apps / iOS >> Wikimedia Foundation >> >> _______________________________________________ >> Mobile-l mailing list >> [email protected] >> https://lists.wikimedia.org/mailman/listinfo/mobile-l >> >> > -- Corey Floyd Software Engineer Mobile Apps / iOS Wikimedia Foundation
_______________________________________________ Mobile-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/mobile-l
