I am currently trying to get the hang of Auto-layout in Xcode, and with it, i have found some problems.
Now, i don't have a 100% grasp on how auto-layout works exactly, so as i learn on it might become easy, but i think it is very hard to be honest. I am usually making games, and of thus, i programmatically add a lot of views to the screen. Now, auto-layout seems to mess everything up when i do this, so i constantly have to make sure that every single auto-layout feature is just right, and there are a bunch!
So, if you do not want to support other orientations, is auto-layout really needed? i mean, if i am making a game for the iPad and using landscape mode only, is there any reason for me to use auto-layout?
Thanks on advance
A couple of thoughts:
Auto layout is not mandatory.
But auto layout provides a mechanism for dealing with situations when views change sizes and/or locations:
changing orientation, as you pointed out;
supporting different screen sizes (e.g. iPhone 3.5" screen vs 4.0" screen);
controls whose size changes based upon content (e.g. a UILabel whose width expands to fit the text or whose lineCount is set to zero, meaning that its vertical will grow based the number of lines needed to fit all the text); with auto layout you can establish dependencies between controls so that, for example, as one control changes its own size/location, others can move/resize accordingly (e.g. to stay aligned with or make room for the other control); and
automatically update contentSize for UIScrollView objects.
Auto layout requires a little time to gain proficiency, but for dynamic, complex user interfaces, it can save you from having to write code to manually change layouts of views programmatically. But if you don't find yourself doing this sort of code, then you don't necessarily have to use auto layout.
I should acknowledge that there are some tasks that are trivial in a non-autolayout environment (e.g. animation of moving views), doing the same task in auto layout can be frustratingly complicated. But if you have complex interdependencies between views (either between the superview and its subviews or between sibling views), auto layout can be useful.
Autolayout simply provides rules for the views how they appear in all orientation.It is upto the user to define how to use it or you may follow the struct and spring model .
The major difference between the two is that there no dimensions involeve in the struct and springs while autolayout says the dimensions and values in whch views should be rearranged
An excellent beginner tutorial fo autolayout
Related
I'm working on a MacOS application that needs to display large images. if I naively set the ImageView to be the full size image, the application's window can be forced to become larger than the screen size. What I'd like to be able to do is work out how large I can make the image while keeping the entire window (which also contains other UI elements) on screen.
I know I can query the amount of available screen space using NSScreen:visibleFrame() but that does not seem to be much help since unless I make a whole load of assumptions about how much space the rest of the UI will take up which then defeats the point of having constraint based UI layout.
The other approach could be to find a way to constrain the window size and then let Cocoa work out the sizes of the views. However, it looks like the UI editors in Xcode only allows static sizes to be specified which is not much help.
It looks like this is possible in SwiftUI (https://www.hackingwithswift.com/quick-start/swiftui/how-to-adjust-the-way-an-image-is-fitted-to-its-space)
Image("example-image")
.resizable()
.aspectRatio(contentMode: .fit)
However, the application I'm working on needs to run on older versions of MacOS than supported by SwiftUI so I need to know how to do this in swift but using plain Cocoa.
The first thing I would try is to modify the priority of the constraints that make the image view large enough to accommodate the image. That would be its content compression resistance priority. I think if you set it to .dragThatCanResizeWindow then you might get the behavior you want for free. That's because the system already constrains a window to the screen size when you drag its edges. So, presumably, that implicit constraint has a higher priority than .dragThatCanResizeWindow.
If that doesn't do it, you can programmatically set a window's maximum frame size by setting its maxSize property. You'll want to set that each time the screen configuration changes or the window moves to a different screen. For the former, you can observe NSApplication.didChangeScreenParametersNotification. For the latter, your window delegate can implement windowDidChangeScreen(_:) or you can observe NSWindow.didChangeScreenNotification.
I find one solution is using extension to detect current iPhone model at runtime; however, it indeed involves massive of changes from my current code and design (i.e. change a lot of buttons location and size in single storyboard, a lot of constraints need to be updated as well etc). Are there any better solutions than this one? Thank you!
I always vote for creating constraints in IB as possible as you can , because it cuts time less than in code as you'll see the result instantly and do constraints fastly , the tip is to create it proportional as much as you can , look to the current device you do the constraints with as a generic device for example instead of setting a static height like 200 , look to design scale an make it proportional say 0.2 of screen height , same for width , you can make it also with origin constraints like top , leading but it needs some advanced constraints , make use of size classes and adaptive layout , also font adjustment , if all that fails hook the constraint and play with it in code
I've been playing around with the auto-layout feature of XCode 6 in developing a Swift application for the iPhone.
It works well for a small number of controls but I now find myself with a section on the screen which will consist of a matrix of eight by eight small text controls (in portrait mode) of the form 7☐ and 42☑ (all three characters), each which can be selected by the user (toggling the checkbox).
I'm wondering what's the best way to handle this. I started by simply laying out all sixty-four text controls but this quickly became a nightmare in trying to join them all together with constraints.
I then wondered whether it would be easier to have one text control in a fixed-width font (or in a font where all digits are the same width and a space character of that width is also available) so I could control the layout manually (with newlines). The downside of that is that I'll then need to perform hit-testing on the control to see which item should be toggled.
Both these approaches have the downside that they don't adjust well when switching to landscape mode or to other resolution changes.
So my question is, how do I handle this in a way that can take full advantage of auto layout (i.e., minimal work for the developer). Ideally what I'm looking for is something like the Java Swing FlowLayout container, to which I can just insert those text controls in order, and it will fill it out as if it's a book (populate top line, left to right, then next line and so on).
If you have a matrix like layout and you want it to flow like the FlowLayout from Swing, you can use a UICollectionView.
I think that matches best what you are trying to achieve.
I add a PickerView to one of my views in an app, but its size is too small(in height). I find that I cannot drag to make it "longer". How to change its size then?
The only way is by adjusting the pickerView.frame.size.height, but you'll get some pretty bad visual artifacts.
I would think long and hard about attempting to circumvent the established design of this control. If you have so many items or your items are too big for this view, a UITableView is probably what you want to go with. It's far more customizable and can handle items/cells of all different shapes and sizes.
Please pardon my lack of Photoshop skills, but I'm curious what type of strategy Apps like Facebook and AP Mobile News are using for the 'label slider' in their applications. Here's a quick snippet outlining what I'm talking about as I'm sure the name I'm labeling the utility as is being butchered: http://dl-client.getdropbox.com/u/57676/slider.jpg
Essentially the user can touch the label and glide it along the X axis. It has a smooth bounce effect also once it hits the edges. This gives quite a bit more real estate if you need to present more on the screen than what your portrait mode allows for and is thus very valuable.
Is it a matter of just creating a UILabel that's wider than the screen with a bit of Touch API + Core Animation? Would love insight on how to start tackling this thing.
You'll most likely want to use a UIScrollView, with a UILabel as its content view. Size the label appropriately to your content, and then set the contentSize property of the scrollview to that size.
I created a similar control, and it's much easier than you think. It's just a UIScrollView with a series of UIButtons added to it. You could use labels instead of buttons - just depends on the feel you want. I think Facebook is probably using labels for theirs.
In any case, you'll probably want to use a series of components rather than one component (which is what Ben suggested) in the event that you want to, say, style the "selected" label differently from the others. It also makes hit detection a little easier.
You get the bounce effect for free by default - you may have noticed that most scroll views in iPhone apps do the same thing. It can be turned off as well.