I'm setting up a new tvOS app with a UISplitViewController and a UICollectionView as a detail view. To achieve some nice out-of-the-box focus behaviour, I'm trying to use TVCardView inside the UICollectionViewCell and adding an image view and a label to the card views content view (in interface builder). That works, but the problem is that the card views always applies rounded corners to the content once they have been selected. Initially all views have sharp corners, but as soon as a cell has been selected, it switches to rounded corners.
First of all, I don't even want rounded corners and in Apples examples, I never see those rounded corners anyway: https://developer.apple.com/documentation/tvuikit/tvcardview
But even then, it's kind of useless to have rounded corners only partially after selection.
Has anyone experience with TVCardView and knows about this strange behaviour? I cannot find any example code or more detailed documentation. I also tried to use TVLockupView instead, but that doesn't seem to be supported by interface builder.
This was an SDK bug and is fixed in newer versions of Xcode/tvOS - just verified in Xcode 13.2.1 Simulator.
For older versions you have to work around it (I mentioned one here in the comment - TVCardView rounded corners strange behaviour)
Be aware of the issue that:
typically you have a UIImageView inside of the card view.
Confusingly, you have to TURN OFF
adjust on ancestor focus
user interaction enabled
on the UIImageView.
If you don't, the image view will "doubly" expand, when the card view expands!
This can be incredibly confusing, as it may/may not round corners when "not doubly expanded" and often there are weird margin issues, parts of the image never visible and so on.
Related
I'm trying to understand how autolayout works under XCode6, but there's a lot of mysterious things that runs away from my mind. Autolayout and constraints philosofy can be very hard to learn, but I realized that life can be easier using these tools...
For your information, I need to build a chat view with a table (the messages) and a view containing a text field (the send message pane) nested in a UIView that is again nested in a UIScrollView, so I can shift up the scroll view as the keyboard appears under the textfield.
I read a lot of tutorials and watched a lot of video until I found the useful tutorial Using UIScrollView with Auto Layout in iOS. There's a Xcode project in Github of what the tutorial explains, too.
In his tutorial, Mike Woelmer tells that
One of the big pain points with the old way of setting up a
UIScrollView was communicating the content size to the scroll view. It
was fairly straightforward to calculate your content size if the
content in the UIScrollView was an image. But it was not as easy if
your scroll view included a mixed bag of buttons, labels, custom
views, and text fields. Lengthy code adjustments were needed to
reflect constant changes in device rotations and phone size
differences.
So Mike explains the way to adapt the UIView, using placeholder and forcing the view inside the scrollview to fits the device's screen, creating in viewDidLoad some NSLayoutConstraint:
The solution is to look outside the scroll view and attach a
constraint to the view controller’s main view. This cannot be done in
interface builder, so we will have to write some code. Interface
builder is still complaining, though, so we have to add a placeholder
width constraint to make it happy.
I tried to use parts of the code of the tutorial for my project, but I cannot get a working view controller for my needs (I always get errors). Which is the best approach to do this? Am I on the right road?
Last but not least, I'm italian, so pardon for my english. If something is not clear enough, please leave me a comment.
Basically you have to set both alignment and size constraints in order for Autolayout to take care of the rest for you. If you don't provide enough information you get warning. If you provide conflicting information you get errors.
You need basically to provide enough information for Autolayout to calculate the UIView frame property (i.e., x-position, y-position, width, height).
For example, by providing the distance constraints from the top, right, bottom, and left edges, Autolayout has enough information to draw that UIView's frame rectangle. But you could also provide just the distance constraints from the top and left edges and then provide a size and height constraint.
You can also configure the key constraints you need and then click 'resolve auto layout issues' and choose 'add missing constraints' though sometimes it doesn't give you what you want. It is better to understand that how Autolayout accomplishes what I described above.
If you mess up, it's usually easier to clear all the constraints and start over. Do it a few times and you'll get the hang of it.
I've got a strange UIImageView behaviour:
I've got a UIViewController with an embedded UIImageView and a close button. Very basic stuff, done a thousand times. I didn't use Auto Layout that much in the past, but another view controller in the same Storyboard has nearly the same config and doesn't appear as strange as this specific one.
In my Storyboard the Controller looks like that:
...and on the device it looks like that:
That image is 1024x768, so it should be filled to the bounds. Content mode in the image view is Aspect fill. When i dismiss the view, i can see that the upper part of the image view must be hidden at the top with some negative Y or something.
I need Auto Layout in this storyboard, because it's an iPhone + iPad App with both orientations.
Has someone hat a behaviour like that before?
Thank you!
Edit:
Here is the layout panel:
First, get rid of the alignment constraints, they are not needed if you're already anchoring your view to every side with a set distance.
Second, check the mode property of your UIImageView in the interface builder. If the image was not big enough and you had it set for "TOP" instead of, say, "aspect fill", you'd see something like this even though the view is actually covering the whole screen.
I'm sorry that I have to say this, but it was, as you certainly thought, my own fault.
The problem was that I made a photo with the iPad, and the iPad can be used in both orientations in this app. The photo was taken and was then used for an own view that allows the user to put annotations on the image.
The image gets then saved, and that was were the problem occured: I call
UIGraphicsBeginImageContextWithOptions(self.view.frame.size, NO, 0.0);
The landscape image was now taken into a portrait frame. After adjusting this and only allowing portrait mode, everything worked well.
Thanks anyways for your answers. And sorry for asking a question when the problem was another one and my own fault.
The recent release of iOS 7 includes a change to UIPopoverController where the popovers are now flat, with no shading underneath (none of the betas for iOS 7 included this change - the change only appeared with the GM release). Unfortunately this change is really not working with our iPad application; without the shading effect and the dark border, our popover is blending in with the underlying screen.
Do I have any options at all as far as customizing this effect or (even better) making popover look the way it used to look?
Take a look at popoverBackgroundViewClass. Not sure this will give you the result you are looking for, however. When a popover is displayed, the system dims the background view hierarchy, but there are no shadows underneath the popover. If this is not enough, you should look at implementing a custom popover controller or using an open source.
I am having layout problems with the storyboard editor with a fairly simple screen. I have a UIViewController to which I have added a 320x440 UIScrollView at 0,0 followed by a 320x20 UIProgressBar at 0,440. It looks fine in Storyboard editor. I'm not entirely sure how the 20 pixel status bar at the top of the screen is accommodated given the CGRect frame coordinates that Storyboard calculates.
On loading ( in -(void)viewDidLoad ), the UIScrollView frame seems to be set to 320x460 pixels at 0,0 but the UIProgressBar is still 320x20 at 0,440.
When I add subviews to the UIScrollView, (UIImageViews in particular), they get stretched and get clipped on the screen because although the UIScrollView thinks it is 460 pixels high, it only has 440 pixels of screen to display in.
Can anyone point me to a solution?
Thanks
OK - I have identified what was going on - there were a number of issues, nearly all to do with mutually incompatible settings in storyboard attributes on various view controllers.
In summary, the main view controller containing the UIScrollView had the 'wants full screen' checkbox ticked - goodness knows how, but it appears that I had then gone through other views trying to compensate for that initial error by clipping, resizing, setting layout constraints etc. which resulted in rather confusing outcomes.
My advice would be to not touch ANYTHING in storyboard editor unless you know what it's effect will be - it is a dangerous place. I found the issue by going back to basics and creating a trivially simple replication of my app and then observing the differences between that app and my own. Sorry if I wasted anybody's time researching an answer.
Thanks
Couldn't find anything on the net about this and wondered if anyone on SO has a solution.
I have an NSView with several subviews that are centered by removing the left and right anchor points. When I resize my view, programatically or with the mouse, to a smaller width than the subviews: it pushes them off center. Has anyone come across this before and do you have a solution?
EDIT: I want to be able to resize my view to a zero width. The reason being, the view is actually part of a split view and I have hooked up a button to 'collapse' it. When it collapses all of the subviews are pushed off-center and aren't re-centered when the view is resized, effectively un-collapsing it.
I have solved my problem now and thought I would share incase anyone comes across this issue in the future.
No amount of playing with autosizing options or view layouts in Interface Builder seemed to stop my subviews from getting moved off center. I did manage to find this link here and from this page, the advice:
Springs and struts, as currently
implemented, are really no good for
anything but keeping either one or
both sides of a view "stuck" to the
nearest edge. Any sort of centering
behavior, division of gained/lost area
between multiple views, etc. has to be
done by hand.
Based on this I overrode my view's setFrame: method and manually laid out my subviews using their setFrame: method. This works great and gives me the results I'm looking for.
There is the same issue using NSSplitView, resizing here one Subview to be smaller than the Subview Subviews makes sense,e.g. having small charts in the upper subview, and an rss reader in the lower subview.
If you want to show only the rss reader in the lower subview, you can "hide" the upper subview, but after resizing the upper subview the NSImageView are not layed out the same as in the beginning. Check this nib/xCode Project and the following screenshot to see this behaviour.
Only workaroung is to override the resize function to stop getting smaller.