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.
Related
For a very large ios project with the huge amount of features and complex user interface, would like to have the suggestions for following -
Will it be more easy and convenient if we use different storyboards
for iPhone and iPad Screen sizes as developers used to do a couple of years back when UIStackView was not there?
What are the best practices to achieve the complex UI using storyboards, Auto Layout and also have a maintainable code? Please share your experiences.
Will it be more easy and convenient if we use different storyboards for iPhone and iPad Screen sizes as developers used to do a couple of years back when UIStackView was not there?
Using different types of storyboard / xib will increases your bundle size. So it is not a good idea. Before xcode-7, developers do not have any good choice instead of this. Now you can use auto-layout, it can easily maintain your whole screen.
If your design is something like master-detail (like device setting) then you can use different VC's.
What are the best practices to achieve the complex UI using storyboards, Auto Layout and also have a maintainable code? Please share your experiences.
You can auto-layout, size classes, even vary of traits is more helpful to maintain the designs.
I think it's better to use only storyboard for iPhone and iPad , where you can create constraints in proportional to screen size , and tweak constants with add variations plus using size classes for handling screen variations with adaptive layout
I would advise to use Adaptive Layout with Size Classes and Auto Layout.
On quite a large universal projet, it saved me a lot of time, especially, as you pointed out, since UIStackView!
https://www.raywenderlich.com/162311/adaptive-layout-tutorial-ios-11-getting-started
Using sub storyboards is also a great relief on very large projects.
Having two sets of storyboards is quite painful as you have to duplicate many things. I only use a specific storyboard, when the UI on both platforms is really really different.
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
I have been in a struggle for a long time with this one.
Lets say I have a UIViewController and need to place an UIImageView with an UIImage in that controller.
So I have two ways to do it:
1.) Via Storyboard
2.) UIImageView *imageView = [UIImageView new];
imageView.frame = CGRectMake(bla, bla, bla);
[self.view addSubview: imageView];
Also I need to support different screen sizes (from iPhone 4 till iPhone6+), and autolayout with constraints isn't fully clear for me. And I'm sh*tcoding like
int wrapperHeight = (screen.height == 480) ? 100 : 200
I feel that i'm doing something wrong.
When i started to learn objective-c, I have seen some opensource projects, and there was no storyboard at all, so i thought that adding views programmatically is a good practice.
Could you please explain me the "right way" ?
I'd say that most of the times storyboard with autolayout is the best choice. It has a number of advantages:
It separates presentation from the logic. Creating the entire interface in a controller is usually a bad design. And for simple interfaces declaring them in an imperative way brings in to much overhead. Very often you'll end up having hundreds of lines of code for the interface that could be done in a storyboard or xib in a 10 minutes without any effort.
With storyboards you have a great WYSIWYG editor, where you can see how the screen will look like on different devices without having to rebuild the project and run it on dozens of devices or simulators. Well, not dozens but 4 different resolutions for iPhones + 2 resolutions for iPads stills a lot. Also there may be tiny differences in text sizing and rendering between retina and non-retina screens
Autolayout. Of course, you can use it in code as well, but default apple's interfaces for them suck. There are some 3rd party libs which make working with autolayout a bit easier, but anyway with storyboards you're not gonna worry about autolayout in code at all in ~80% of the times. And the rest 20% would be just something like adding constraint outlet to the controller and then changing it's constant or priority with a single line of code
Size classes. Again, you may work with them in code, but with storyboards you'll probably wouldn't have to. Size classes allow you to have one single interface for all possible device form-factors, different device orientations, etc. Before size classes developers had to have 2 different sets of interfaces for iPhones and iPads.
However, there are certain places where storyboards aren't the best way to achieve the goal. For example, if you have some view that is used in different places of the app. With storyboards-only approach you'd have to have copies of this view in many places, so when making changes in one of them - you have to remember to make this changes in other copies as well. In such cases it's better to use a separate xib file with such view and then use it in a storyboard.
Also, autolayout may be quite expensive in terms of performance. So if your app starts lagging and you determined (with profiler) that autolayout routines are the reason of the lags - then it may make sense to handle creation and layout of certain views in code manually. But this could be the case only for a really complicated interfaces. Most of the times performance wouldn't be an issue.
You said that autolayout isn't clear for you. That's not the reason to deny using it. You'll have to do a lot more work to make an app look good on all devices without autolayout than with it. "some opensource projects" that you saw could have been written for the first iPhones (4s and before), which all had the same resolution in points and where all sizes and positions could be just hardcoded. Now, as I said earlier, we've got almost a dozen of different resolutions. And handling that all in code manually is a real struggle. Autolayout would make you life easier :)
Also you may take a look at these debates about when and where to use storyboards, xibs and manual view handling: http://www.raywenderlich.com/51992/storyboards-vs-nibs-vs-code-the-great-debate
And on the same site (http://www.raywenderlich.com) you could also look up for autolayout tutorials to understand it better.
Both ways has its own advantages, as a programmer you should be comfortable with both, and to use which one depends on your situation, sometimes its easy to use storyboard/xib and sometimes its easy to build view programmatically
Some advantages of creating views programmatically -
Better to work with team. It's easier to merge code and resolve conflicts when committing to a repository than it is in case of storyboard.
When debugging it's easier to trace errors and you don't have to look to IB.
Creating views programmatically gives you more control
Some advantages of adding views in storyboard -
It's faster to develop view in storyBoard, it helps you to put everything together, like centering views,aligning them, connecting their actions etc.
Your code is not crowded with UI related stuffs, so you have much cleaner code.
Also for people who just start developing apps, its pretty easier for them to use storyboard, and gives them confidence as they can see things they are building.
Bottom line is it depends on your situation and you should choose wisely, suppose you have static UI that doesn't change much or animate, its always easier and faster to use storyboard, but if you have some dynamic UI like it has lot animations and you need to manipulate your constraints then its easier to build your UI programmatically
Also keep in mind that XIB file loading time is longer than build UI programmatically.
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.
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.
I've read around that Apple is hinting to developers at a larger-screen iPhone by pushing developers to use Storyboard and auto-layout. I understand why auto-layout would be useful, to organise items according to screen size, but what do Storyboards have to do with anything?
I may be missing an obvious advantage (in relation to larger screens), so any help would be much appreciated. :)
A. You say that there are some notice from Apple about the larger screen of the iPhone6: This is impossible because Apple doesn't release any information until the date of Keynotes and WWDC.
B. You can or not use Storyboard, and you can or not use AutoLayout: the 2 things are separate because you can also use AutoLayout in nib or programmatically.
C. What developers don't know, is that Storyboard are just a market move. I spoken directly with a my friend engineer in Apple about this and the information is real. The reason is also obvious. Is not the topic to speak about this but you can search on google and you will find a lot of information about the advantages to don't use storyboard.
Yes, storyboard are easy, but are not developer friendly if you think to work in a serious project with a big team. In a team you can use GIT, you can use shared repositories, you can export a part of code with the interface...in all this thing, Storyboard are BAD!
So i encourage developers to DON'T USE storyboard and use at max NIB file, or write the UI directly by code.
There currently doesn't appear to be any advantage to using storyboards versus XIBs or programmatic layout as far as multiple screen sizes are concerned. Auto-layout is definitely advantageous as it allows you to define your interface elements in relation to each other (and the screen), as opposed to using fixed numerical values for location and size. This would allow the UI to then easily adapt to varying screen sizes and aspect ratios.
The only potential reason storyboards could become useful for multiple screen sizes in the future is if Apple adds functionality to them to allow you to define entirely separate views based on device/screen size. So for example, they might make it easy to show a view with an extra sidebar on a larger screen, but show a separate view without the sidebar on a smaller screen (they might make it possible to configure this easily in a storyboard, versus writing a bunch of code to detect the screen size and load the appropriate view programmatically). As of now, though, no such functionality exists, but that could be a potential source of the rumors regarding storyboards being useful for multiple screen sizes.