Solving Interesting Problems

Not the Bad Kind of Interesting Either

I'm working on my first new feature on a Raizlabs project this sprint, and it's exciting. At a broad scope, it's all about reducing the amount of code that it takes to manage complex view layouts on multiple device sizes. It's a common issue, but because of new features like UITraitCollection and NSLayoutConstraints there isn't an established best practice for it quite yet.

And to add a layer of complexity, it needs to be compatible with views built entirely in code, and I'd prefer to also continue to play nicely with views designed in interface builder.

One of the interesting questions is just where to put the code for managing that flow, one of my goals is to get as much of that code as possible out of the view controller because those are large enough already. I'm taking a configuration value based approach inspired (loosely) by a Swift snippet from Objc.io.

I'm still fiddling with just where to put the configuration layer, it's out of the view controller but I'm considering if I want to embed the logic directly in the view class, build it into a protocol, or add a viewLayoutManager style class, or figure out a clever way to build all of the layout configuration into blocks.

I'm writing the implementation in Objective-C, because I'm not putting Swift into production code quite yet, but when I have the production version finished, I think I'm going to try building a tighter implementation in Swift on a hack day and probably putting that code out in public.