I am under one project.In that I am using some image files and some button.
When i use to place button in my viewcontroller and see that preview using
assistants editor. My button are mis placed in different places.so i thought to use autolayout.But small confuse in that. I am beginner to ios.I have some question?
METHOD 1
When I uncheck this autolayout option like image (A)shown below.its working perfect in all iphone simulator(3.5, 4, 4.5, 5.5). By setting autolayout using below option (B)
[A]
[B]
METHOD 2
At the same time when i put check mark autolayout option and use like this image show below.I am getting some misplace (Not in arrangement].I know I miss some constraints.But its not better than my above question
please give me some suggestion about this.Which one should I use?
METHOD 1 (OR) METHOD 2. I am new to ios .kindly suggest me something about this?
Method 2! Autolayout. It is very powerful and (if you get the hang of it) quite easy and intuitive to use. You can create pretty much arbitrarily complex user interfaces using it. It has its limits, but in most of the cases you don't encounter them and most of the times they are fixable using constraints set up via code instead of the interface builder if needed.
Method 1 was fine while it was the only option and may still be okay for simple layouts. But as soon as you want to have a little bit more complex relations between different UI elements, like one UILabel being half the size of a UIImage, you will run against a wall.
You may check here for differences between autolayout(Method 1) and autoresizing mask(Method 2). Apple suggests devs to have their view layouting using Autolayout so there is not actually a question in here.
You probably messed up with constraints as every beginner does so I would recommend you to take a time in here and try to finish this tutorial.
Related
This question already has answers here:
Adding Views. Storyboard VS. Programmatically [closed]
(2 answers)
Closed 6 years ago.
Is it more efficient to add views and subviews programmatically than using a storyboard to add them ?
What is be the best practice ? Does the best practice depend on the situation ? If so, when is it preferable to use the one method over the other ?
Storyboard vs Code comes up an awful lot. And I think looking at it as which is better often starts flame wars. So instead I'll list out pros and cons for each, then you can hopefully make an informed decision.
This is by no means an exhaustive list. I'd love to see edits or comments adding additional bullet points.
Storyboard Pros
Storyboards are great for getting a concept working quickly.
They're great for seeing your actual app and previewing it on multiple devices.
They make it really easy to customize appearances and explore whats possible.
They're fantastic for beginners as they remove one barrier and let you focus on code for your app rather than some boiler plate UI.
Storyboard Cons
Storyboards and Xibs are not great for merging. Its possible to read the XML and make decisions about merge conflicts, but its certainly not enjoyable.
Overtime as you customize your app and build the custom parts that make it special, Storyboards can't keep up. This means that the benefit of seeing and previewing your app as you see it on device slowly loses its value as more and more of your app is done in code out of necessity.
Storyboards don't have a huge performance hit for actual users, but they definitely slow Xcode down on even the fastest machines.
You can't customize everything in Interface Builder that you can in code, so its inevitable you'll have some code and some Storyboard customization. Later when you want to change something, you'll have to check at least two places for the right place to change it.
If you're using the same fonts and colors throughout the app, its easy to change in code in one place. In Storyboard you'll need to change it for every single label or view you've set up. You can easily set fonts and colors in code while using Storyboard for the rest of your layout, but over time you'll find your storyboards represent less and less of your actual app.
While its possible to have pixel perfect designs in Storyboard, drag and drop isn't as precise as entering specific numbers. Storyboard does support entering those numbers, but you need to navigate to multiple places and if you drag it later the numbers are all reset.
Reusing views typically involves copy and pasting them. These causes issues later when you need to make changes.
Showing and hiding views at certain times is doable, but again leaves your storyboard in an unrealistic state compared to your actual app.
Programmatic Pros
All your code is in one place making it easier to debug or change later.
Subclasses and custom properties are no different from first class views and properties. Your customizations will be easy to manage.
Views that are reused throughout the app only need to be created once.
Merge conflicts are often easy to understand and make decisions.
Dependency Injection is one of the safest ways to instantiate UIViewControllers and ensure necessary information is passed in, its not possible with Storyboards leading to less straight forward and more bug prone code.
Programmatic Cons
The additional complexity can be a stumbling block for beginners.
Writing a few lines of code can take longer than clicking a few checkboxes.
When working with layouts, you'll need to visualize it in your head or run your app to see what your layout looks like as you make changes. This can be difficult or slower for some.
Storyboard exposes checkboxes and buttons for many customizable properties like background color, font, etc. This makes it easy to see at a glance what you can customize. (Though as mentioned above its not everything) In Code, you'll need to look at documentation or headers to understand what you can customize.
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.
For an iOS app i am currently working on, I need to manage the controls displayed on the screen based on the type of device the app is running on.
I will try to explain with a theoretical example (the actual numbers used below are not important, what interests me is best method to achieve the desired result).
Example:
In the case of the app in the screenshots, the button that overlaps the UIImageView should not be displayed at all OR displayed in another place on the screen.
So far I've worked with autolayout , but , from what i could figure, there's no way to say to xcode something like: hey, for a class size "Compact Width / Compact Height" , I want you to hide these buttons...but show them for "Regular Width / Compact Height" .
I also did some googling and saw some people talk about using different storyboards based on the device; I am also thinking, I could add/remove buttons dynamically based on the device type , but I think it's not so pleasant to have to add all of the constraints by hand (programatically that is).
So to resume, I would appreciate a suggestion of a 'best' way to do this , best meaning a combination of 'not so hard' + ' not so long'. Also, some code example (or links) would be highly appreciated.
Thank you all in advance !
I think it all depends how sophisticated it gets what you are doing overall. When you look at developer's code for large app projects very little is actually done in interface builder since the apps are so dynamic it's just too much work in IB.
Using multiple storyboards 'sounds' like a good idea, but often isn't. If you want to update/change one, in most cases you then have to change the other ones as well.
What I think is handy:
Use one storyboard (or multiple but for different parts of you app and not parallel ones) and then put in very 'special' cases multiple ViewControllers of the same class for the different size into the single storyboard. That way you won't forget about updating the second (and third) because they are all right there.
I would only use multiple 'parallel' storyboards for apps that support iPhone and iPad and it makes sense to really split them up..
Also:
I would as fas as possible still use just one representation and derive the other 'versions' from that in code. If you build a structured user interface you can then reuse (or just inherit) the code that 'hides' parts of the first viewController in the next. That way your code AND your IB files won't get cluttered.
Also think about internationalisation (if that is part of your future plans), since multiple IB documents and multiple instances of the same viewController layout really don't help for that ;)
New to iOS, coming from the Java / Swing world, where I'm used to creating UIs programmatically, letting components size themselves and using various clever layout managers to arrange things.
It already seems clear that the iOS way is to make heavy use of Interface Builder, with a lot of fixed sizing and positioning. I'm not sure IB is ever going to come naturally, but I guess fixed layouts make sense given that you're working with limited space and a fixed window size.
It still seems like I'm writing a lot of boilerplate, though, and violating DRY, and so on.
Can somebody point me to a good primer on laying out iOS UIs, particularly programmatic UIs?
You don't really need to use IB to write MonoTouch apps. I almost never do. The CocoaTouch API is fairly simple and straightforward to develop on.
I haven't really found any writeup on UI development other than the apple documentation (which is really good, by the way, worthy reading), so here goes a couple of tips, based on my experience:
Inheritance is key to maintaining the code clean. You can inherit from basically any class in the API, like buttons, controllers, views, etc. Inherit and add your customizations in those classes. Don't shove everything in the AppDelegate like many examples show. You'll thank me later on.
Have I mentioned inheritance already?
The one thing iOS doesn't have is a layout manager, so if you're used to Java like you mentioned, this will sound a little strange. Different from what Java people think, this is not a big deal. UITableViews help tremendously with this (vide next point).
A lot of iphone apps are built on top of the UITableViewController, even apps that don't look like tables. It's a great framework to do anything related to scrolling. Learn to use it well. Almost anything that scrolls vertically is a UITVC. Follow the guidelines that define when you create and when you dispose cells and objects.
Be careful every time you add a Frame location in your control. Instead of setting hardcoded values, try using offsets from other locations (x+40, for example) whenever possible.
Make sure you add your views to the proper container as necessary. For example, if you're adding a global "Loading" view, add it to the Window object, while if you're adding a image on the left side of a table cell, use the ContentView. iOS changes those special views automatically all the time (resizing screen to fit "on call" bar at top, or rotating phone).
Miguel de Icaza has created a great framework for managing forms and tables, called MonoTouch Dialog. Take a look, and enjoy.