I am having real difficult time using auto layout as when I sometimes change the views, it becomes a real mess with the already assigned constraints. So should I really give more time to myself learning auto layout or should I just go with multiple storyboards as it takes a bit of time but ultimately makes it easier for us to change the design easily in future.
From my learning,
I felt the same because its hard to learn and understand AutoLayout for first time. Here is the lot of advantages using
AutoLayout Advantages
Future iOS Versions going to support auto layout
It will save you lot of your time when ever new version of OS get released
Using Multiple StoryBoard
You need to maintain for each screen which is clearly hassle if you want to change anything in your View.
It will eat lot of your time to fixing
and much more
Spend little time in AutoLayout. Its not that hard to learn.
Auto Layout
Size Class Explanation
I am sure above link will help for all beginners.
The practice we are using is always splitting the Storyboards into smaller chunks, because they get ridiculously big and hard to work on. But we are not splitting them for different devices, but feature-wise. For example the Onboarding process has a separate Storyboard.
But we are always using auto-layout and iOS 8 size classes to support different devices. In some cases we even code constraints in code.
So learn Auto-layout sooner rather than later, it will save you time on multiple occasions.
In new Xcode you can find Size Classes in Storyboard which helps to manage various screen sizes. On beginning it seems to be hard but after little time it will save you lots of work.
I suggest to start here: https://developer.apple.com/library/ios/recipes/xcode_help-IB_adaptive_sizes/_index.html
It is important to create proper constraint. Set on view size class: Any x Any and then you can create constraints automatically, clicking Editor -> Resolve Autolayout Issues -> Reset To suggested Constraints or use shortcut: Command + Option + Shift + "=" while object in storyboard is selected. Honestly, it doesn't work properly in each case, sometimes you just have to set it manually.
Summarizing it's worth lo learn AutoLayout and make all screen sizes in one Storyboard.
Related
I am designing my first iOS app at the moment. Every view of the app needs to be available in portrait aswell landscape. Also all iPhone versions need to be supporrted.
As someone always working with windows and never owning any apple product it was a pain in the ass getting started but slowly things seem to work out. But before the whole design approach takes a wrong direction I rather ask here:
What I want to do is have constraints based on multipliers as much
as possible.
I will try to avoid constant values as much as possible since from
my understanding they arent scaling. I read that you can change them
programmatically but if possible I want to stay in the designer for
frontend related stuff.
Since the multiplier cant be changed based on the current size class
I plan to have a set of constraints for all kind of portrait size
classes and another one for landscape (using installed feature of
xcode)
To up and downscale labels and textviews I want to have a height
constraint to the superview with a very tiny multiplier (will
probably be complicated to keep all textviews the same height when
there are different parents across them?)
In theory this should produce views which up and downscale well and look the same on all kind of iPhone screens. Now I am curious what more experienced iOS designers think about my "plan":
Do you have different approaches?
Is there any book/tutorial/page you can suggest?
Thanks in advance! :)
I'm working on an iOS app in Swift. The other app I created was one I did in Objective C and release around this time in 2014. Storyboards seem to have made UI stuff both easier and more complicated at the same time, so I'm trying to figure out current best practice in terms of view development.
Size classes and constraints seem like almost a necessary timesaver at this point for multiple screen sizes. Back in 2014, this was less the case, and programmatically keeping track of UI layouts as CGRect code made programmatically mucking with UI layout much simpler and better for code reuse vs creating a whole new view controller for just adding new UI elements to much the same view. Doing the same thing with constraint code seems less appealing, but also necessary if I want more code reuse there.
So I'm wondering what the current practice is here as I'm just thinking in terms of code reuse. Programmatic constraints just seem less elegant than storyboard defined ones, but I'm not sure they're the end all be all for UI code since they seem problematic for programmatically updating the UI on the fly.
Is the best strategy at this point to enclose everything in layout preserving superviews and keep most of this storyboard centric or would it still make sense to do swift programmatic code for these layouts since I'd have to for iPad and iPhone specific changes anyway? On that subject would it still make sense to split drastically different UIs into multiple storyboards (e.g. 2 different iPad and iPhone storyboards as that was a default at one point)?
Thanks in advance for answers to this. Device specific stuff just seems to not always be code reuse, but I just want reuse to be relatively simple I guess. Otherwise I'm just creating more swift classes than I strictly need.
This is inherently opinion based. Everything from no Interface Builder to only StoryBoards is likely being used in production applications, and you can make just about anything work.
My personal tendency is to use Storyboards for everything other than TableView/CollectionView cells. I find it removes almost all interface boilerplate code from my classes and makes it so I only need to handle the interface between my ViewControllers. Here are the guidelines I generally try and follow: (again...opinion)
Use multiple storyboards organized in a useful way:
Large storyboard become hard to maintain and performance while editing suffers noticeably. We have the option to use StoryboardReferences, so might as well use them.
The more Scenes and ViewControllers, the better. (within reason)
This makes things more maintainable and re-usable. E.g. a header that could be used in multiple Scenes. It can be a bit annoying to have to use containerVCs and deal with segues everywhere, but I rarely regret separating something into it's own ViewController.
Don't use separate interface files for different sizes.
It's more code to maintain and will force you to swap ViewControllers in-out if you want to support resizing on iPad (or any future devices). Not to mention going forward it's clear Apple is assuming you're using size classes rather than swapping ViewControllers and is clearly where the future is headed in Apple platforms development
When you need animations, try and narrow it down to changing a single constraint.constant
This greatly simplifies your code and usually avoids having to deal with size-classes anywhere other than the storyboards. It's not always possible for complicated animations, but you can do a surprising amount if you're willing to mess around. It makes it possible to narrow down a toggling action to 2 lines of code, which is quite nice. Using StackViews can also help with this a lot.
The other thing to focus on is avoiding as much of the stringly-typed nature of IB as possible. This is much easier in Swift and there are some decent solutions using string-backed enums and extensions, but specifics are probably out of the scope of this question.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
So I'm new to iOS development and I found it easier to write the views all programmatically. So my views have UIViews, ScrollViews, UIButton, UILabel all created and positioned programmatically. (So I never used AutoLayouts).
I've now pretty much finished my app and want to make the iPad views, and realized maybe it was a bad idea to do it like this.
Is this bad practice or should I really be using auto layouts as much as I can?
If it's ok to do it how I'm doing it right now, what is the correct way to add different views for iOS and iPad? I've seen this answer below on how to find the device, is a simple if else statement sufficient? - iOS: How to determine the current iPhone/device model in Swift?
I am using programatic views in a live app and its awesome. A bunch of people I know us this as well.
Here is a little algorithm I use to choose between the two methods:
Are you building a fast app for a client or a hobby? Use storyboard with autolayout.
Are you building an open source project that will be used by many people? Use programatic UI
Are you building an app for the long run? (1+ year) Use programatic UI
Its also harder to make an app thats supposed to be rotated without autolayout. Because doing that with code takes much more work than autolayout. Most good apps dont use this feature anyways so I don't see much problem.
A good tip is never to use constants while writing programatic UI.
If you are going to make a button thats 100px in width, do not type in 100px anywhere in the code. Instead figure out the screen sizes and place the main views according to screen sizes. Then place the subviews or secondary views according to the position of the main views. If you do this correctly you will have more powerful multidevice layout support than autolayout.
Here is a little library I wrote, please inspect and play with the code on how I place the view: https://github.com/goktugyil/CozyLoadingActivity/blob/master/CozyLoadingActivity.swift
Also here is a good article I like about this:
http://www.toptal.com/ios/ios-user-interfaces-storyboards-vs-nibs-vs-custom-code
This is only fine, If you have enough time, patience, good skill on calculations and relationship configurations between different UI elements.
However, using Auto Layout is pretty useful and low time consuming than manual calculations.
We can easily create a dynamic and versatile interface that responds appropriately to changes in screen size, device orientation, and localization with minimal effort.
Read Adopting Auto Layout,to implement the Auto Layout in your existing application
TL;DR
It depends
Longer version
Clearly one size does not fit all. AutoLayout is pretty powerful both in Interface Builder and code (be it visual language format, or simple constraint setting), but sometimes it just seems like you're "rubbing your right ear with your left hand" - that's when adding views programmatically comes in. But beware of not having it different in each view controller - you don't want to introduce too much complexity in your project, right?
I personally like using AutoLayout as much as I can and whenever I can't use it anymore, or the StoryBoard View would get too messed up with millions of constraints, I try to separate views into containers - have the container be resized by AutoLayout and have the subviews handled by code.
Example would be a custom Media Player - maybe I want to have two stripes below and above the video - I could have the video and two UIView extended stripes handled by the AutoLayout. But the subviews (controls) in the stripes themselves would be added by code. It gives me the control over my code but still it doesn't introduce too much complexity.
First of all - if you want to develop for iOS you have to learn Autolayout. There are already a lot of different devices with different resolutions and maybe will be even more in future.
Secondary - if you want to work effectively with IB you have to read guide / watch tutorial videos and have some practice. It could be difficult to start but then you will realize that IB is powerful, fast and often the best way to develop GUI. Often, but not always!
Code advantages:
Easy to copy-paste and reuse GUI. It could be critical if you have
several similar views or want to reuse some old code.
Easy to resolve merge conflicts and check commits.
Easier to make styles - like the same font for all labels depending on the country.
More powerful (there are things that could not be done with IB) so you have to use it sometimes.
IB advantages:
You can see your GUI during development for different resolutions/localizations so you do not have to compile and run a project on different devices/simulators to check is GUI ok or not. Also IB will show you warnings if you forget some Autolayout constraints or there are conflicts. Saves a lot of time if you have a complex GUI with non-trivial Autolayout constraints.
It is much easier to understand someones else code if it is developed in IB. Especially important for complex GUI - not so easy to find a required label or button in a few hundreds lines of code.
Small bonus - if you want to use a custom control developed via code you can make it IBInspectable and use it without problems in IB
Just to summarize - if you do not need IB benefits (for example GUI is quite simple and does not use Autolayout) developing GUI via code could be easier and faster. But in case you have to support different resolutions and/or you have hundreds lines of GUI code in each view controller I strongly recommend to try IB.
We have a utility app that has like 10 major animations for manipulating the UI. A new developer suggested that we convert from managing position in code to using AutoLayout. We have tried this once before and it just really didn't work (and all constraints in code) and the constraints would break. Are we being Luddites by not adopting AutoLayout or are major projects not using it?
Has anything significant changed where this would be easier from 18 months ago? My feeling is that if we don't absolutely need it, we're better off staying just manipulating frames in code.
Using autolayout is necessary because the screen sizes vary so much. Trying to modify layout constraints manually to mimic what you currently have can be a HUGE head ache.
A solution is to move the animation code into storyboards (well as much as possible anyway). The code you have to maintain will most likely shrink dramatically from pre-autolayout to using autolayout (depending on the animation type). Here's a tutorial
I have a feeling about iOS development on which I would like to get feedback.
Storyboard / Interface Builder are, at first glance, awesome tools. The truth is that aside quick prototypes and really simple user interface I always feel blocked using them. This question offers probably a good example: how can I use one storyboard for 4" and 3.5" iphone screens with autolayout (ios6 + ios7)?
I am considering to code all my views. Mostly because it will let me implement some logic, like equal spacing of elements. Something that is, AFAIK, impossible to do in a cross device fashion through the GUI tools.
My questions are: Does Storyboard / IB support advanced view layout? How do you usually code your view if you do so: extending UIView / tweaking the controller?
EDIT: the accepted answer link is nice. Interested readers could also look at Apple's Auto Layout Guide relevant example: https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/AutolayoutPG/AutoLayoutbyExample/AutoLayoutbyExample.html#//apple_ref/doc/uid/TP40010853-CH5-SW7
http://www.raywenderlich.com/83276/beginning-adaptive-layout-tutorial
Ray gives a decent starting guide on how easy it is to create a single adaptive view now, which has caused me to switch from being completely programmatic.
Previous to iOS 8 it was much harder to build complex layouts using Interface Builder. You were essentially limited to stretching or pinning to edges. Now you can build layouts that adapt to size classes and change their layouts or constraints based on the width and height of your device.
That being said, even in really difficult scenarios that IB can't handle, I still end up building chunks of views in XIBs and then laying out those chunks manually.
TLDR; Interface Builder is going to be helpful 99.9% of the time as long as you know how to use all its features.