I'm not very good with Constraints, so basically, my idea is to place all the objects on the View Controller manually for every screen size (iPhone 4, 5, 6, iPad, etc).
Is it possible?
Can I place all of them in one View Controller, or will I have to create a new View Controller for each screen size?
It is possible and you can do it in a single ViewController for each screen size. In Interface Builder if you open a ViewController or any other UI element, on the Attributes Inspector you can see small + signs next to most properties, using which you can add screen size specific properties. Using this approach you can manually create different sizings/font sizes/label texts, etc. for each screen size.
However, I would really recommend learning how to use Autolayout. It is one of the most powerful features of iOSs UI design and working on a large project with a complex UI you will pretty soon regret not learning how to use it. In the long-term it definitely saves you a lot of time and effort. With all the different screen sizes Apple has introduced in the past years, handling them manually is a real pain.
Related
This is my first time working in and with xCode. I am coding a drum pad but am struggling with the User Interface.
Right now i have two views each containing a 4x4 button grid. The first one is for "triggering" the audio samples once a button is pressed. The second one contains a set of toggle buttons used to control a step sequencer.
The app itself is working fine. But im not sure how to build the interface in 'good fashion' So far I have used Interface Builder to create the grid.. set up the constrains manually so that the pads adapt to the device width, and stretch evenly across the screen.
The thing that makes me insecure is how laggy the interface builder runs since i have created these constrains.. might this also affect App performance and launch time?
So i looked up ways to create the grid programmaticaly and came across UICollectionViewwith its reusable cells it seems to fit my use case.. but it also seems a bit like overdoing it.
Its for school, due date is coming closer and somehow i am stuck since days at this point. So could someone please point me in the right direction... how would a modern ios developer set up this grid.
thank you very much
You can use Stack View for the solving of this issue.It could be filled by buttons programmatically or just from storyboard.
This is example form the storyboard.
And this how it is looks at the emulator.
I just started making an app, and I have done a lot but I was not working with auto-layout. My whole app is in landscape mode, and I want it to work on all iPhone's. I now designed it for the iPhone 5, but when I open it on iPhone 6, there is a lot of whitespace. Is there a button to automatically resize everything? Or must I add auto layout and do every designing bit again?
Unfortunately you're probably going to have to layout everything again with auto-layout. A way to expedite your process would be converting the storyboard to auto-layout and then selecting "Reset to Suggested Constraints". You can access this option by pressing the small triangle icon in the bottom left.
Despite this, you probably will need to update a lot of the constraints manually. But this should give you a step in the right direction.
Have you tried Size Classes? Or Stack Views?
Size classes:
Apple documentation # https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/AutolayoutPG/Size-ClassSpecificLayout.html
Apple documentation on Stack Views #
https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/AutolayoutPG/LayoutUsingStackViews.html#//apple_ref/doc/uid/TP40010853-CH11-SW1
A good tutorial on "Stack Views":
https://www.raywenderlich.com/114552/uistackview-tutorial-introducing-stack-views
I've got a fairly intricate IOS application with icons, tables, text fields, etc spanning across over 20 different view controllers. I built the entire application in portrait mode, and have of course realized that things look screwy when in landscape.
For the really simple screens I've had little issues using autolayout's constraints to accommodate any orientation changes. However, when there are multiple (5+) items on the screen I've found it incredibly hard to use constraints to manage everything. In fact some views look like they need the entire layout transformed to flow well.
Is there a better alternative to constraints? My only other thought is to make duplicate views, one for portrait and one for landscape. Then I can just switch on the deviceOrientationChange listener.
You can always switch off constraints by selecting the xib/storyboard file and unchecking Use Autolayout. To do this only for the more complicated views, I think breaking out into separate xibs is feasible.
Also, sometimes landscape really calls for a complete rearrangement of the view (or even adding / hiding certain elements). You should not shy away from defining separate views for this, with or without xib documents.
Been trying to find some tips on suggested approach for this and not having much luck.
All I'm looking for is to know what is the best approach to handle custom layouts for portrait/landscape modes.
I've seen some posts say in the storyboard add 2 views to the same ViewController and show/hide based on orientation change while some people suggest to use a totally separate ViewController for each orientation.
Which of this is the preferred method. I'm just starting my application, So I'd rather go for the widely accepted method than have to deal with complications later on.
Apple documentation still keeps talking about nib files and not storyboards in this aspect, so not being of much help.
My main focus is performance (I'm fine with having to code stuff instead of depend on the graphical interface for it). separate ViewControllers seem to keep the code in a clean way however if that involves populating views / clearing them every time orientation changes, seems kind of expensive(not sure if it is relevant).
Also if each scene in the application has 2 layouts then managing them I'm not sure how much of a pain it's going to be when the application grows big.
Please point me in a suitable approach for my case,
am not concerned about backwards compatibility. Just worried about the latest Xcode and ios6 if it matters for the decision
Thanks
I would say this really depends on the level of customization of the UI in portrait vs landscape. A large number of implementations I have done can be handled by either autoresizing/autolayout when switching orientation, or simply moving the elements yourself when the UI is rotated and the callbacks are fired. Moving the elements around should not be an expensive operation at all as it is a very common occurrence (again this depends on the complexity of your UI though).
Like I understand, an Window has a lot of Views. A View is an object that can draw something on the screen, and the Window provides the space for drawing. So where's the point, that I dont have an window? What's the difference here between them?
On the iPhone, a window really is just a special kind of view. If you look at the docs for the UIWindow class, you'll see that it has additonal methods above and beyond what a regular UIView has. However, most of those methods seem to have analogous UIView counterparts.
The one thing I've found windows useful for is that UIViews have a "window" property that can be used to instantly access the window. If you have many nested views and need to immediately get to the top level from a 3rd or 4th level deep view, that window property can come in handy.
In a View based application we can create the foreground layout and the appearance of the application including text fields,buttons,labels..... depending upon the requirements of the project and how effective an application view has to be in order to make the application shine
In a Window based application we have the background of the view and we can also create a view using a window by using Interface Builder connections.But for building applications that work basing on the background we need to have Window based applications that runs on the console.