10

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?

Community
  • 1
  • 1
  • 2
    not at all and I ll add : on the contrary. You ll have a better understanding and code mastering – Jan ATAC Sep 07 '15 at 11:00
  • 1
    I'll second that! And creating them in code does not preclude using autolayout and even (in my opinion) makes it much clearer what your constraints are. – Rupert Sep 07 '15 at 11:14
  • I would also add you shouldn't really be using device detection — using autolayout should allow your views to layout appropriately for the screen size. If you want more advanced handling, look into iOS size classes. – Rupert Sep 07 '15 at 11:16
  • Using code to create your views is often easier for non-trivial tasks. During this summer, I've worked on a large enterprise iOS application. The application often contained the company logo along with some text and additional annotations. The original developer of the app achieved this by drag'n'dropping a `UIImageView`, a `UILabel` and other views directly onto a view controller. It was messy. Later, the designer decided that we should center the logos vertically. It was a pain to rearrange all the views; it would have been much easier if the original dev created them using code. – The Paramagnetic Croissant Sep 07 '15 at 11:27
  • "So I never used AutoLayout", you can use it programmatically. I don't understand. – GaétanZ Sep 07 '15 at 11:29
  • 4
    @Poql We all know that most autolayout is traditionally **not** used programmatically. Search Google for 'AutoLayout Tutorial' and 49/50 will not use this programmatic approach. Saying "I don't understand" sounds fairly condescending as anyone can see that in the context of this question, saying "I never used AutoLayouts" infers a non-programmatic approach. – Reece Kenney Sep 07 '15 at 11:44
  • Most of your Google tutorials are for beginners, that's the only reason. AutoLayout is good. What sounds fairly condescending is thinking that Apple released AutoLayout for nothing. Watch some Apple WWDC videos, read some good books and understand what AutoLayout really is before giving it up. – GaétanZ Sep 07 '15 at 11:52
  • 1
    Using Autolayout in code is awkward. To use it effectively, you have to use libraries. There are at least 20 different libraries so usually when you come to a code that uses such a library, you have to learn it first. It's very difficult to debug constraints in code - you never see what you have missed. However the big difference is time spent on mantainance. Maintance on constraints created in IB is always faster and easier. Don't write code you don't have to write. IB is the most powerful development tool you have. Use it. – Sulthan Sep 07 '15 at 13:14
  • 1
    @Poql Thinking AutoLayout was released for nothing (which by the way nobody is doing) is not condescending so you may want to just double check your definitions. Anybody with iOS development knowledge knows what the OP meant by "So I never used AutoLayout". You should have worded your comment like: "`You have inferred that AutoLayout is non-programmatic. FYI, you can use this programmatically too`" – Reece Kenney Sep 09 '15 at 11:38

4 Answers4

3

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

Esqarrouth
  • 38,543
  • 21
  • 161
  • 168
  • Thanks, If you use the programatic approach, how do you deal with having maybe a SplitViewController for iPad and just a standard ViewController for iPhone? –  Sep 07 '15 at 12:49
  • That I have no experience in. But I don't think it will be that hard. Since everything I do is compared to screen size, I am guessing everything will work out fine but I might add a method to reload the view when splitviewcontroller is initialised. There might be a little problem with screensize, and might have to change those to current appsize instead. Also editing my answer one more disadvantage came to mind – Esqarrouth Sep 07 '15 at 13:02
  • 1
    add to your algorithm: - Are you planning to port the app to different form factors? Use auto layout. - Are you making a game or other app that uses views in unconventional ways? Use programmatic UI. – e.w. parris Sep 08 '15 at 14:17
  • thanks. you can send an edit request – Esqarrouth Sep 08 '15 at 14:22
1

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

Shamsudheen TK
  • 30,739
  • 9
  • 69
  • 102
0

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.

Michal
  • 15,429
  • 10
  • 73
  • 104
0

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:

  1. Easy to copy-paste and reuse GUI. It could be critical if you have several similar views or want to reuse some old code.
  2. Easy to resolve merge conflicts and check commits.
  3. Easier to make styles - like the same font for all labels depending on the country.
  4. More powerful (there are things that could not be done with IB) so you have to use it sometimes.

IB advantages:

  1. 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.
  2. 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.
  3. 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.

Avt
  • 16,927
  • 4
  • 52
  • 72