SHIP IT! :) On Thu, Feb 19, 2015 at 12:51 PM, Adam Baso <[email protected]> wrote:
> 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 > >
_______________________________________________ Mobile-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/mobile-l
