Green Rocks from Space
I like auto layout. A ton. It totally makes sense to me to declare layout rather than to code it.
I’m all on board.
I’ve worked with it enough to understand the APIs. I have no trouble visualizing what’s going on, and no trouble translating my intentions to the right declarations.
And yet I do have trouble. Of course I do. Because whenever I use it everything goes wrong. It’s like Kryptonite to me.
I don’t tend to get errors or warnings about my constraints — I just get things like a table header view sitting on top of the cells. Weird things like that that I can’t explain.
This isn’t like Core Data is to me — there are some things about Core Data that don’t fit how I like to do things. Which is fine. Auto layout, on the other hand, fits exactly.
The premise is great: save time and get better results. What is it about me that I can whip up layout code practically in my sleep and yet I can’t get the easier thing to work?
There’s no excuse for giving up. Except for the big, obvious one: I have to ship software, not play endlessly.
That’s okay as long as the giving-up isn’t permanent. I think my best bet is to adopt it really, really slowly, with near-leaf views and simple cases to start. But not till after I finish what’s in front of me right now.
Update 5:40 pm: I just realized that I don’t use the old-fashioned struts-and-springs stuff much either. I write layout code for everything. Struts-and-springs was often frustrating, and things didn’t work as I expected. (I’m not saying there were bugs, just that this gave me gas too. Clearly it’s my problem.)
The thing about auto layout, though, is that when things go wrong they go wildly wrong. I think that’s the issue for me. With old-fashioned layout code, things go wrong by just a little bit — and I can figure out, and fix, the problem pretty quickly.
But with auto layout, when things go wrong, it looks like a bomb went off.