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 <cfl...@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 <mh...@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 <bvib...@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 <mh...@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 <bgers...@wikimedia.org >>>> > wrote: >>>> >>>>> +1 >>>>> >>>>> On Wed, Feb 18, 2015 at 12:32 PM, Corey Floyd <cfl...@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: >>>>>> 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 >>>>>> 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 > >
_______________________________________________ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
