I have a question. I'm writing an app where in one of its views I want to achieve the next:
the view itself doesnt rotate meaning all the controls etc are pinned to their places BUT the objects (buttons for example) DO rotate on their place place.
The problem is that Autorotate is either rotates everything, including position change of the buttons, or locks everything including keeping button orientation.
From what I understood I can lock the view and do a manual transform every time orientation changes but it seems to me very long and ugly, when Xcode has now all this Autolayout and class sizes etc ...
Is there a more elegant way to do it ?
Related
To keep things simple, let's say I have a window containing a single view, which has auto layout constraints binding all 4 sides to the window container view with offset 0. And assume that this view also has a constraint setting its aspect ratio to a constant value. If I resize the window manually, then then window nicely maintains the desired aspect ratio. But if I click the little green zoom widget, then the window fills up the whole screen, regardless of the aspect ratio, with part of the view being above the top of the screen. Is there some way I can make zooming resize the window as big as it can be, without violating auto layout constraints?
I couldn't very well detect this problem in the delegate method windowWillResize:toSize:, because that doesn't tell me which screen it's thinking about putting the window on. I could try to fix the window size in the windowDidResize: delegate method, at which time I do know what screen it's on, but I'm not sure exactly how to do that without reinventing Auto Layout's wheel.
Apparently someone thinks I wasn't explicit enough, so I'll try again. Steps to reproduce:
In Xcode, create a new macOS App project using XIB interface.
Open MainMenu.xib and select the window.
Reshape the window to be approximately square.
Using the Attribute Inspector, set the Full Screen behavior for the window to Auxiliary Window.
Drag an Image View from the library and drop it in the window.
In the Attributes Inspector, set the image view to show the NSComputer image and scale axes independently.
Expand the image view to fill up the window content area.
With the image view selected, click the button to add new layout constraints.
Add 5 constraints, binding the 4 sides to the container, and setting the aspect ratio. (see screen shot)
Build and Run.
Observe that if you resize the window by dragging an edge or corner, the aspect ratio remains fixed.
Click the green zoom widget in the title bar of the window, and observe that the window expands without regard for the aspect ratio constraint, cutting off part of the image.
I just set up a test project exactly as you specified, and when I invoke the window zoom widget, the window expands and retains its aspect ratio i.e. it works as expected. The only thing I can think of that might be causing your issue: maybe your content hugging and content compression resistance priorities are at odds with your constraints? Mind you, I just left them at the default values and it worked fine. Unfortunately Mac/AppKit development (esp. when using IB) is rife with these kind of odd bugs and weird behaviour, probably because Apple has not given it any love in years, so bugs creep in/fester and they are clearly so DONE with developing UI the 'old fashioned way'. (Using SwiftUI to make a Mac app is just as frustrating, in different ways, so I'll stick with what I know). FYI, I used Xcode 13.4.1 to create this test project. Good luck!
I have a tab view controller with 3 tabs, custom icons. I used insets to enlarge them slightly and compensate for the lack of titles. All of this is done in the story board, the only code for these items is setting the text to "" since it always wanted to pick up the View title no matter what I set in the story board.
It look like this:
now, if I repeatedly tap a tab bar item, this happens:
It happens to all three, and it will keep growing if you keep tapping. I'm not setting the size, these are image sets and all I did was change the insets in IB
Any idea what's happening here? (Xcode 6.4 iOS 8.4.1)
I finally found an similar question here :
iOS Tab Bar icons keep getting larger
it seems that any inset that makes the image larger will be applied every time you touch it. It doesn't really make sense but if I use insets to only center the image and not enlarge it the issue goes away
Good morning,
I am new to Xcode and am learning to create iOS applications.
When I open a single view application and click on main.storyboard, my size is w Any h Any. When I decide to add a label and run the iOS simulator (iPhone 6 or iPhone 5S), the label appears somewhere else.
This is really frustrating and I have tried many approaches such as disabling use size classes, changing the storyboard size by clicking the w Any h Any button, and even messing with the constraints as mentioned here: Xcode 6 Storyboard the wrong size?
I am really trying to continue with this but I have seem to hit a wall for a couple of hours now, if someone could shed some light to why I am messing this up, that would be amazing.
EDIT: How can I get it to be a "normal" sized iPhone, such as the iPhone 5s?
You can click on the w Any h Any to change it to a normal iphone size by mousing over the squares and reading which devices they encompass.
You are going to have to use constraints though in order to make anything go where you want it to, I really didn't want to learn them but I couldn't do without them now: they are very useful.
EDIT
Constraints are simple in concept but can be tricky in certain situations:
For any view to have valid constraints that work correctly, it needs to know what the size of the view is and its position in it's "parent container" which is just whatever view or viewController it is inside of.
The little |-O-| shaped button and its neighboring buttons next to "w Any h Any" give you options for positioning and sizing the view. So if you click on a view and then click on that square button in the middle, check the width, height boxes and click the left and top lines in that top positioning thing with sizes in it like so:
Then click on add 4 constraints. You will notice blue lines appear around your view saying that it can properly put it where it needs to go when running the app. If there is any orange or red that means there are conflicting constraints on the view.
Sometimes that can mean you put to many constraints (more than you need) and you just need to delete them in size inspector tab. But more often than not, if that doesn't fix it, I've noticed that I usually have a neighboring view that isn't properly "constrained" and is actually the cause for the other views problems.
How can I get it to be a "normal" sized iPhone, such as the iPhone 5s
You don't. The view controller's main view will be resized correctly when the app runs (on a device or in the simulator), as appropriate for the device type and other aspects of its surroundings.
Your job is to use auto layout so that no matter how the view is resized, its subviews (labels and buttons and so forth) will look good. That is what auto layout is for - it's to help you compensate for the fact that you have no idea what the real size of this view will be at runtime.
I am trying to create a resize toggle animation on this simple custom TUIScrollView class (from TwUI open source project and very similar to UIScrollView) that I have built. It is called TUILayout and supports horizontal layout as well as vertical, animated insertions and removals and has a more declarative way of supplying data to it's cells that I prefer over delegation. It recycles views similar to TUITableView or UITableView. Anyway if you want to follow along, it's just one class and is here.
https://github.com/mrjjwright/TUILayout.
In the example code, the user clicks the blue button in the lower left and all the rows shrink smoothly to a size where the user can reorder and delete some rows (right click on a row in the example to see this in action), etc... and then the user toggle the rows back out to their original size by clicking the blue button again.
While doing this resize in setObjectHeight:animated I first resize my model objects that represent the rows, recalculate and set the contentSize on the TUIScrollView, cycle in all the new views (say 10 more views will fit in the shrunk view so dequeueReusableView and addSubview gets called 10 times) and finally I animate the frames of all the views to their size and location in layoutSubviews.
The result is that the scrollview correctly shrinks to a size where the scrollbar no longer displays, the views that are on screen animate smoothly down to their reduced size, but the newly added subviews that can now fit in the visibleRect animate in much later as one block of subviews.
So all the newly added subviews lag behind the views that were on the screen and I can't figure out why the animation isn't all happening together. I have tried lots of different combos of things with no luck including CATransactions. I am wondering if it has to with how a CAScrollLayer works or if somebody can help me think through this.
The more general issue is how to smoothly handle resizing animations on scrollviews that recycles their views and I have looked at several other grids out there in the iOS world and have got some inspiration but am looking for more.
Thanks!
I think I might have solved my own issue here (as I was making my bed this morning it hit me). I forced the current runloop to run after cycling in all the necessary subviews and very importantly not setting the contentSize of the scrollview until after the run loop completes and adds the needed subviews for the animation. In order to get the run loop to fire I used the trick from this SO question:
skipLayout = YES;
[[NSRunLoop currentRunLoop] runMode: NSDefaultRunLoopMode beforeDate: [NSDate date]];
skipLayout = NO;
If skipLayout is set TUILayout just returns from layoutSubviews so that the views just added are not immediately removed by the recycling layout code. Forcing the run loop to run made sure that all subviews were on the screen for the animation. After this I performed the resize animated layout. I updated the code on github if anybody is interested. I will leave this question open for a while to gain some further insight.
I have a custom view in my application, which is layer-backed and embedded in an NSScrollView. I allow the user to zoom in (which is accomplished by increasing the size of my custom view). I'm having trouble zooming in on an arbitrary point, though, since the NSScrollView keeps getting in the way and causing the view to jump around (typically to the view's origin) before I point it to the new scroll point. I would really like to use a CAScrollLayer, since I know I could definitely get the zooming right with it and have it move smoothly, but then I lose all built-in scrolling facilities.
Is there any way to leverage CAScrollLayer within an NSScrollView, possibly backing the NSClipView? If not, what purpose does CAScrollLayer actually serve? Is it possible, with a different approach, to change my view's size and the scroll point atomically and have that animate?
In short, is CAScrollLayer completely useless, or mostly useless?
Update
I've gotten my inner view to jump around less by making a CALayer subclass to display my view's contents. Rather than sizing with layout constraints, I have it sizing in an override of -resizeWithOldSuperlayerSize:. I still can't change the frame size and origin of my view simultaneously and get a smooth animation, though. To get a sense of what I'm looking for, open an image in Preview and zoom in and out. It zooms about the center of the image in a smooth manner.
In the limit, you can use an NSScroller instead; that way you would be able to use CAScrollLayer, if that’s your preferred implementation.
Note that on some (older) versions of Mac OS X, NSScroller has a bug that causes it to invoke an Apple private method on its containing view. You’ll know if this happens because you’ll get an exception about your custom view not responding to a method starting with an ‘_’.