I am trying to hide the separator for a specific UITableViewCell and am using cell.separatorInset = UIEdgeInsetsMake(0.0, CGFLOAT_MAX, 0.0, 0.0);. This causes very weird problems on older devices and works perfectly on newer devices. On an iPhone 5 for example, it will cause the cell to flicker and be blurry. Changing CGFLOAT_MAX to a fixed number like 5000.0 makes all of the issues disappear. Any idea why this happens?
That approach sounds unwise. You’re probably best off just disabling the table’s default separators and having your cells (minus the one you want it hidden for) draw their own, either in their -drawRect: or by adding a thin view at the top or bottom of each cell.
There’s also the solution described here—setting the horizontal insets to half the width of the cell, so the separator ends up being 0pt in width—but given the history of changes listed in that article you can probably expect that to end up breaking as well.
Running on iOS 9.1, I am seeing a similar issue on iPad.
In my case the screen flickers black whenever it's launched (my cell is on the initial screen); or whenever I use Split View on iPad Air 2; resizing my app causes flickering when my app is rendered.
I have bug reported this to Apple as I think we should be able to use CGFLOAT_MAX instead of a magical high number to achieve the same effect. In fact I've even suggested that perhaps we should have an API to hide the separator; I'm sure many before myself have asked for this though.
rdar://23768136 (I will update here whenever I get any news on it). In the mean time, just use a silly big number that's for sure going to get the separator hidden - something like 5000.
Related
I've been doing iOS for a while now, but when it comes to dynamically hiding / showing elements, I'm a bit lost.
Coming from Android, I'm used to being able to simply set views to visibility gone, but this doesn't exist on iOS.
So let's say I have the following scenario:
Basically I want to have a table, but the table should not fill the entire view controller. Instead it should leave place for optionally either a button, a multiline label, or possibly both at the bottom (if visible, these should be fixed, not scroll).
One way to solve this would be to use auto layout and modify constraints, like adding a zero height constraint. But that would make iOS kill one of the other constraints, which would make it hard to change it again. For the label, I wouldn't always want to have a height constraint, because it could be multiline, and should take the size it needs.
Maybe it's easier to skip autolayout here and modify frames instead, I don't know.
My question is: What approach would be best here?
Is there some other way of doing this I haven't thought of, or do I have to try to do what I described above?
I'm not primarily looking for code (code can be ok), but I'm more interested in a description of how it can be done.
I'd like to support iOS 7.
This problem had a variety of solutions, and opinion based, but I'm facing such questions a lot, when I don't know what to choose and what would be the "right thing".
So, I my opinion, the best solution here is using autolayout, you need to set height of label manually, but you have a few methods for this, at least you can play with it and if you don't succeed ask question about it. Using frames, you'll face same problem of calculating height, right? But with auto layout, you only need to set height, vertical space to 0, when you need to hide message.
You can also use constrains with priority lower 1000, and remove completely constraints from message (button, label) if you don't need it at all anymore.
For example, taking your layout image, you can make UIView with subviews: button, label. Top constraint connect to the UITableView, other constraints to the sides.Label and button will calculate the view's height. The only question here is label height.
So in ios assuming that the background of both these objects is opaque only the front most view in the Heirarchy will be visible and interactable, An easy solution would be to change the different frames of these two things you need and make sure they are in the back of your view heirachy, and when you need them to appear use view.bringSubviewToFront(mySubview) and view.pushSubviewToBack(mySubview) to make it disappear again. View obviously would be referring to main view of your view controller.
So I have a UITextView, and in viewDidLoad I rotate its layer so it appears to be slanted back into the screen (sort of like the Star Wars opening crawl).
The problem is that scrolling is all messed up. Dragging up will scroll for a bit, then jump backward or similar; on the simulator it will even crash sometimes with an error about a coordinate containing NaN.
Similarly, when I try to automatically scroll the UITextView via [UIView animateWithDuration:...] I also get unexpected skips, jerks, etc.
I assume this has something to do with the fact that I've manipulated the layer, but the touch events as well as the animations are registered on the view... Or something like that?
Anyway, I'm pretty stumped.
Are you using constraints to position the text view? There seem to be issues with using transformations and constraints together. A common workaround seems to be to wrap the offending item in another view. The big issues are on iOS7, but some applies to iOS8 as well. This link discusses the issues which may be your issue:
How do I adjust the anchor point of a CALayer, when Auto Layout is being used?
I have issue with autolayout.
I have three different views (could be n views as well). When I pin first one to top of super view and connect one next to the other everything seems fine. But if I want to change height of first one the other two does not follow (they stay on the same position). What I find weird about this is that if I connect only two views this works perfectly.
To have better understanding what I am trying to achieve I made simple, example solution with three views:
http://i.stack.imgur.com/cMwiB.png
So, when I set height of green view to 0 ( can be any other number as well ) and only red view is connected, this works fine, red will move as it should. Blue one is not connected and it remains where it is:
Here is screenshot when I connect blue to red:
What I tried to do:
connect blue one to green as well ( not working)
connect blue only to green ( not working )
"boxing": have boxes with views at the time ( ugly, hard to manage, not working in all cases)
What I would like to know:
what makes this happen? Can I change this kind of behavior?
What is the best practice to have flexible length for height (Besides UITableView)
Thanks in advance.
Ok, I think you're falling into the same trap I did, when I investigated autolayout some time ago. It's tricky to explain, but I'll do my best. When you work with autolayouts, you need to forget completely about setting a view's frame at all. And that, my friend, includes changing size and positioning. When you use autolayout, you define some constraints, some "rules", that the view tries to respect when rendering the screen, so the more specific the rules are, the less random will be the behavior of the view. I mean, if you just define the spacing between views, you're implying that the height of the views doesn't matter, so it's possible that some views grow or shrink when the re-layout is called (that is, if you don't specify a constraint for size. You probably want to always specify the size of some views in every layout...)
By the way, you're allowed to violate the constraints by manually changing the frame of an element AFTER a re-layout is called, but when the re-layout method is called again, the constraints will be forced so the size and positioning of the views will change. Quick tip: an easy way to force the re-layout method is to change orientation (command+left / command+right in the simulator).
So after saying that, I have to say that the layout you provided is completely working as intended, at least to me. When you change orientations the constraints you specified are ALWAYS being respected. If you want, you can try to apply some frame-setting in the viewDidAppear method, because this one is called AFTER the autolayout (and thus, you're able to violate the constraints temporally). After doing this, your view will be broken but once you change orientation the constraints should be respected again. Make sure it's that way.
From here I can only wish you luck ;) Oh, and refer to the documentation, it was a life saver to me when I looked at this half a year ago. https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/AutolayoutPG/Introduction/Introduction.html It might seem a classic, but it's a pretty nice doc.
EDIT: one last thing. I have the impression that constraints are not designed to be dynamic. You define them once, and they're there always. Their main purpose is to ensure that subviews are rendered as intended in every screen resolution without fail, so if I were to make an application with moving views, I would leave them outside of the autolayout, or avoid using it at all. Just a personal impression though :)
I have UIScrollView in which UIImageView is held like on the screenshot:
My problem appears when I zoom and instead of being able to scroll only in the area of my image (subview of scroll view) I'm able to scroll around the original size so I get a lot of white space around my image which isn't what I want. You can see what happens on the screenshot below:
I wonder what should I update to keep my scrolling area only the size of the image?
After some research, some trials and errors I've finally achieved what I was planning to do.
First of all, I wanted to use only autolayout with IB which sure can be done but with some effort. After some digging I've found this technical note which by "Pure Auto Layout Approach" understands adding contraints in code but I was aiming at only IB which led me to this simple but beautiful solution called ios-imagescroll. After investigating this code with joy that I've finally found solution I came with some error but only on iOS 8 devices... iOS 7 worked like charm out of the box.
I assume that due to big changes in iOS 8 autolayout is more strict and you must be 100% sure what you want to accomplish. It turned out that this slight change MATTERS on iOS 8:
Of course, this bug, fix (call it whatever you like) was fixed by experimenting with everything but I guess that UIScrollView's content view (in that case UIImageView) must be the first item in constraint.
[yourScrollView setContentSize:CGSizeMake(yourScrollView.size.width, yourImage.frame.origin.y + yourImage.frame.size.height+35 )]; //let's say just 35 ...
yourImage may have x,y origins like (0,0) [I see a lot of space above it, so I assume you have set other values for x,y]
I've been searching through here and googling like crazy for a possible solution to this problem. Thus far I'm turning up exactly nothing that actually fixes it so I'm hoping someone can help.
I'm working on the UI for a iPad app. I'm doing it using interface builder. I worked with storyboards briefly but I don't like them all that much so I'm sticking with IB for now. Unfortunately I'm not very experienced with the workings of IOS Ui but it's been going relatively smoothly so far. In my app, I have a view controller, which holds a view containing a pair of sub views. One subview contains a rather windows like header bar (i like the look). The second contains a UITableView. The UITableView is set up properly as far as I can tell, and feeds it's info from a data source using custom UITableViewCells. The UITableView is set to grouped though currently there is only one section. The table is in edit mode by default because I want the user to be able to add new items and use the VC as a selection dialog. The view controller is presented (rather than pushed) using UIModalPresentationFormSheet (again, because I like the view) but I don't know that has any bearing on the problem. The cell border is flush with the X origin, the only reason the text isn't currently starting there is because I went into my cell and move the label over, leaving a gap between the edge of the cell and the label containing my text.
The Offending View http://bit.ly/144cbjT
The Problem: The UITableViewCells, for some reason are positioning themselves at X: 0. This puts them outside the border drawn on the UITablewView when you set it to grouped style. I could probably just turn off the border and get away with it, but I like the look so i want to keep it. I've tried messing around with constraints and anchor points on the cells, the content of the cells, the table itself, the view... I've tried simply moving my cell's labels over a bit. I've also had clipping subviews turned on and off. I've made sure the controls are being loaded properly from the XIB. I've made sure everything is added as a subview where needed. I've made sure I've tried everything I could think of short of setting the cell's X position in code. But since I'm not sure how to tell where the border is, I'd rather have the tableview or the cell do the work itself.
The question: How do I fix this? The selection accessory should be outside the grouping box. The text should be inside, not bleeding out onto the background like it is.I believe the content of the cell should be displayed inside the border within the yellow area.
The odd thing is, this is my fifth or sixth table in this app and I've been doing them all basically the same. Thus far this is the only one I've had trouble with.
Can anyone shed some light as to what's going on?
Thanks in advance
I think that to get this in code, you'd have to do something explicit, so the most likely candidate is a messed up IB file.
Since it doesn't cost anything, I'd just delete the tableView from the IB and then re-add it. If that doesn't work, try recreating the complete IB.
Hope that helps