Agreed. 4-8 might even be a little generous sometimes :) On Thu, Feb 19, 2015 at 11:16 AM, Brian Gerstle <[email protected]> wrote:
> +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
