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 5 years ago.
Improve this question
I lay everything out in code, and like the control and ability to copy code easily (when reusability doesn't make sense). I do use lightweight wrappers around NSLayoutConstraint to cut down on verbosity, but I noticed that my files are pretty large because of the required instantiate-then-layout structure for every single view.
Is this crazy? Is using storyboards/XIBs better/faster?
I lay out my views -and their subviews- in code, so I belong to the same school you come from. But as a fellow scholar, take a look at UIStackView, it will save you tons of NSLayoutConstraints work, since you basically place everything as a subview of the StackView -without worrying about constraints-, then only work on the constraints of the StackView in relation to its superView. You still need to work on the UIStackView properties, but it's nothing compared to having to work on layoutConstraints of every single subView of any given view.
I believe there is a 101 ways to skin an app, code, Interface Builder, 3rd party stuff, I don't believe anyone who say their way is the right way -or that someone else's is wrong-, it's simply different schools of life, and some developers are simply code masochists.
This is an opinion question, but I'll weigh in anyway. I'm a senior/lead iOS developer, and I think that aside from doing it as a learning exercise, or in limited cases where there's a good reason, doing your view layout and Auto Layout in code is a very bad idea, and I would not hire somebody who insists on doing it that way.
It's more work in the first place, and much more work to maintain.
If it is written with the code I agree to the opinion of use Masonry(Objective-C) or SnapKit(Swift)
Visual Format Language may also be simple
Xib or storyboard constraints are not suitable for multiplayer development
If personal development xib or storyboard is also a good choice
Maybe you can use Masonry(Objective-C) or SnapKit(Swift) replace NSLayoutConnstrant
Related
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 8 years ago.
Improve this question
I'm learning iOS and I've gone through a few tutorials now, and one or two of them had you draw all the controls in the IB, and one or two of them had you create them all programmatically.
This leads me to wonder whether I can safely mix and match these approaches. I know the answer is yes, of course, since it would make no sense otherwise.
But what are the advantages/disadvantages? Particularly with regard to proportions and sizing for different screens, that bit is still an obstacle to me as a beginner.
This is mainly a matter of taste. I like to make my controls in code others prefer the Interface Builder. I see the following advantages for the Interface Builder:
More visual. You can see how you interface will look like while you put it together.
You can use the Preview assistant editor and see you interface without compiling.
You don't have to remember what the options are called because you can scan the checkboxes for what you are searching.
You can faster prototype with storyboards.
Maybe your designer can learn to build the interface using storyboards.
The advantages for code are:
No context shift. All you do is coding.
Still you have less merge conflicts when you are working with a team on a project.
All the options are in one place. In Interface Builder you have to click through all the inspectors to find what you are searching for.
It's easier to post code than screenshots in case you need help on Stackoverflow ;).
If you finde code on github you can see without downloading how the interface is build.
I had a few times that a project could not be opened by Xcode when I opened it in a beta of Xcode because the Interface Builder file structure had been changed.
Code is easier to refactor than storyboards (Thanks #Spectravideo328 for the suggestion in the comments).
It is impossible to inherit from a storyboard scene. I code you can easily make subclasses to reuse code. Using a storyboard you have to make two scenes even if they share 90% of their UI elements.
One thing which is very important: Don't put all you screens in one storyboard. Try to keep the storyboards small. Something between 1-6 screens is working for me with good performance.
There are no such thing like advantages or disadvantages. Just take a example. if you already have those controls to use it via Xcode. why will you code it. We only code things when we need to make special controls or you can edit your controls by connecting your controls to the code(you can google it "how to connect buttons in iOS"). In short, you only create controls when its kind of a special control which is not pre build in Xcode.
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 9 years ago.
Improve this question
I'm implementing a settings screen in my app that has several sections.
Section-wise:
May be something like general app settings like:
only download over WiFi
disable auto dimming
May be something for a different category of settings lik:
default text size
etc.
So... In total I'll have 4 or 5 of these sections and each will contain 2 - 5 options.
Some of the sections will have headers and others may not.
I've attached a screenshot of the Vesper app to show the idea I'm talking about.
My question is this:
Is it best to use a UITableView with Sections (grouped) to accomplish this, or just separate UIViews manually placed at the positions I want them?
(For what it's worth, I'm not using Interface Builder)
In the end, UITableViews only take care of presenting and reusing UITableViewCells, which inherit from UIView, so your question is basically "should I reinvent the functionality the table view already provides?"
And the answer is no, you shouldn't.
Even though you won't be getting much out of the "reuse" mechanic of table views, you will still be able to use everything else, the ability to hide/show rows animatedly, maybe some of the cells are identical (like text weight cells) and can be reused from the same identified queue, etc.
And if you want to implement a settings outside the app, then take a look at the settings bundle, you don't even need to code, you just link a few plists together and get an interface done for you.
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 9 years ago.
Improve this question
I should create an app compatible with the screen sizes of the iPhones 4 and 5. On the web I found some ways to organize my project. The best ways to do it are to:
create two storyboards,call one when screen size is 568 and the other when screen size is 480
use autolayout and have an unique storyboard
I don't know how to use autolayout and I should learn its implementation in my project.
Then in this situation, I want to know by your experience what's the best approach.
I think that first approach is very intricate and slow, with two storyboards you can make mistakes and don't have the same situation in each device.
In my experience I used xib files, and I used two xib file for each viewcontroller, a solution which is very very noisy.
Then, what can you tell me about these approaches?
AutoLayout will make it easier to adjust your UI for both screen size, but even with the old UIViewAutoresizing you will be able to get everything working.
I would suggest that you do not use 2 storyboards or NIB for that mater, because if a some point an other screen size is introduced you need to create a third storyboard/NIBs.
You can even use the UIViewAutoresizing in NIB and in code.
Just set the autoresizing mask correct to grow/shrink with the screen size and you will be good to go.
Well , if you want to make app that run on both iOS 7 and iOS 6, than its better to use Autolayout, because it is easy to use, and also too much flexible.
Because your other options are too much complex and time consuming as well.
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 9 years ago.
Improve this question
Apple introduced storyboard which saves lots of coding time. It seems that it doesn't support iOS4 and below. So is it mature enough to use storyboard for development now? How are other application doing?
Storyboards are only supported in ios5. Mainly because they support segues
I can recommend you using storyboards just because it brings your project screens to something logically bound, so if random developer sees it he can quickly figure out everything.
Coding layouts is time thrown to trash. Your time and time you'll support the project, and time you'll spend trying to find bugs in this code, and time of other people that would be very much demotivated when they see the code for layouts.
In storyboards you are also forced to use MVC, so u'd never create a separate view for anything but tableview cells. (like you can do in XIB)
You should be sure that you have more than 2GB of RAM to use storyboards, because they usually contain more than 5 screens and DO lag on slow computers. The monitor size is also better be big or you'd be forced to scrolling over things all the time.
Yes story board is okay to use. Just set your deployment target above 4.0. If you do that you should be fine.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I am trying to learn some of the basics about creating views and view controllers on iOS. All the samples and documentation I've come across use the Interface Builder and NIB files to create UIViewControllers and UIViews. How to create the controller and the UIView programmatically and not use the interface builder?
You may do that, that's for sure. But you should see the pros and cons here;
You create and manage everything in code, neat huh?
Well this means, you will retain/release everything yourself.
You will write lots of boilerplate code just to create a complex view with more than one layer of component hierarchy.
You will not see the properties you may change, instead you need to see the Class Reference document for each component.
You need to play with pixel values a lot, i cannot emphasize how long this "a lot" will eventually be.
So, consider Interface Builder, it is easier to keep everything seperate, and then bind them as needed. Code maintenance is much more important in the later phases, as the app becomes mature.
I have been through both ways, and my vote is +1 for Interface Builder, and override stuff only when needed. That is in practice less than like 5% of your UI development time.
The short answer is that yes, of course you can create views and view controllers programmatically.
As someone who had this same feeling when I first started out, let me impart this short bit of wisdom: Do not try and remove all .xib files from your project until you know a lot more about what you are doing!
There are tutorials out there on how to remove the .xib files entirely from your project, and remove dependency on MainWindow.xib. In my experience it is definitely not worth your time. Just leave the .xib files in your resources folder, close it up and pretend they don't exist.
Eventually, you may even be happy they are still there.
Yes,
You can create UIViewController and UIView programmatically,
See the Apple documentation for UIViewController and UIView, there are many function which start with init, used to create programmatically.
Suggest you to invest some time reading Documentation.