+1 for everything corey said On Thu, Feb 19, 2015 at 1:38 PM, Corey Floyd <[email protected]> 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:[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 > > -- 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
