4 ms·
As an ios dev, i know autolayout exists and lets you somehow manage the different resolutions if you manage to change your set of mind ( no more .frame = or .ce
by bsaul 12y ago
As an ios dev, i know autolayout exists and lets you somehow manage the different resolutions if you manage to change your set of mind ( no more .frame = or .center= to change the location of a view dynamically but update constraints instead), and get away with the ugliest thing in the ios api that are constraint string expressions ( which almost made me throw up the first time i saw them).
But let's face it, that's one less thing we can mock Android devs about. Pixel perfect Wysiwyg ui building in interface builder has one foot in the grave.
- Tepix 12y agoIt's not just a matter of layout, it's also a matter of making sure that UI elements are not too small and not too large.
- paulojreis 12y agoThat seems like the only thing that they managed to keep - the assured physical dimensions of UI elements. The 44 point as a minimum guideline for tappable button size is valid for all resolutions (4:3 1x, 4:3 2x, 16:9 2x, 16:9 3x). P.S. At least on the iPhone. The iPad mini (sporting the same resolution as the physically bigger brothers) will produce smaller UI elements.
- lpsz 12y agoFWIW, there are frameworks out there to make writing NSLayoutConstraints much more sensible. For example [1] [1] https://github.com/Masonry/Masonry https://github.com/Masonry/Masonry
- iamraymondc 12y agoHopefully apple has updated the storyboard tools to do all of the layout constraints. I remember back in xcode5, there were some constraints that were only possible via code :(
- dep_b 12y agoIt's really time to dump those code views son. Interface Builder gives you all the tools you need to do it and works reliable, gives a LOT of feedback on your constraints when you build them. You should learn auto layouts using Interface Builders, otherwise it's a nightmare because you're not getting the feedback you need to learn it right in the first place. You need to start using priorities right, specially when you are doing >=, <= constraints you also need to add a low prio == constraint. It's not that hard, but you will be really frustrated if you keep clinging on to your coded views. Try to chop up your Storyboards if you work in teams. They shouldn't be so big that you have trouble following the flow on one monitor.
- duaneb 12y agoYou can't code review storyboards.
- dep_b 12y agoLess code is a good thing! I hope you fire up Xcode to see with your own eyes if the code-only view looks okay as well? Also it's much more documenting to they guy that's going to maintain your screens later on.
- cerberusss 12y agoWhy not? You can simply open a storyboard and review it, no?
- duaneb 12y agoThat requires downloading, checking it out (at the exclusion of your other branches), reviewing it, figuring out how to make comments on it even though there's no review interface for storyboards, rinse repeat. Code review in objective-c is commenting on code in github while code compiles and evaluating screenshots of the current state. If apple came out with a way to review storyboards on something as convenient of github, I might consider it.
- bsaul 12y agoi did, son. but now tell me how you do complex animations on subviews in an autolayout view without adding constraint by code.
- mahyarm 12y agoIf your getting edge cases, why don't you just write your own layoutSubviews method and avoid using constraints except for very basic things? It's relatively simple stuff to write, and is more performant than autolayout, since layoutSubviews is O(1)-ish while autolayout looks like it's O(n^2). If you don't believe me, look at this blog article that measures it: http://floriankugler.com/blog/2013/4/21/auto-layout-performance-on-ios http://floriankugler.com/blog/2013/4/21/auto-layout-performa...