Similar things have been posted a hundred times here at SO, but I just cannot get my specific situation to work.
My specific problem is:
I have a UILabel that gets various amounts of text dynamically from a plist.
This label is inside a prototype cell in a table & I can get the cell to grow according to the amount of content.
I can get the 8 views that are below that cell in my prototype cell layout (two UIImageViews, a couple of other UILabels, and a few UIButtons) to move down based on the size of the dynamic UILabel.
Here's the problem:
When I scroll down to see the full cell on the 3.5" iPhone in the simulator, the cell cuts off before the bottom of the cell, and on the 4" iPhone it is perfect.
When I fiddle with the height of the UITableView in the storyboard, it either cuts off more or not but it never hits the same way in both devices.
Oddly, when I make the tableView shorter in the storyboard, it makes the view longer (and the cell shows up) in both devices.
There's just no rhyme on the space below the last element in the prototype cell, and I can't seem to equalize it at all.
Any help would be appreciated.
I can't believe this is so difficult for me.
Related
I am working on a project to get custom news feeds from Bing news. I created a custom table view cell and populated various UI items in it. But I am having a hard time to make it occupy the entire screen, it starts from extreme left and ends on the right, leaving large gap from the right margin as show in the image. Can anyone help me out, how to correctly fix it with a detailed explanation of how constraints work in Table views and Tableview cells.
Here' what it looks like in the simulator
Remove previous constraints and add constraint to your UITableView like as shown in below image.
So you UITableView will have 0 margin from edges.
Create a UITableViewController. Just drag drop a TableViewCell into it. Add identifier for that cell and use it. By default it will occupy the whole screen.
In your case I guess you might have added constraints to UITableView. Here what you should do is pin your UITableView to Top,Bottom,Right & Left or make UITableView's width equal to SuperView.
Foreword:
I've read many different approaches to this question, but most are old and rely on checking device orientation and making assumptions about the device being used.
I'm interested in a solution or best practice that works in an iOS 9 world, where "orientation" becomes (mostly) irrelevant and any (universal) app can be presented not only in Compact or Regular size classes, but with wildly varying view sizes within those size classes. See: Split View.
Problem
I have a UITableViewCell. Auto Layout is enabled, and constraints have been added to all subviews within the cell.
Because a UITableView cell can display radically different widths across presentations (e.g. the same cell on an iPhone 5 in portrait vs landscape, or the cell within a modal form sheet presented on an iPad) I need to change the cell's layout/appearance based on the width of the table view, or at least present a different cell that has a different layout/appearance.
i.e. when the cell has a short width (e.g. portrait iPhone), I need to display one set of content. When the cell has a larger width (e.g. landscape iPhone or within a form on an iPad), more elaborate content needs to be displayed.
But...
This does not appear to be a job for Size Classes: the Compact vs Regular division is too broad.
e.g. a tableview presented on an iPhone 5 in portrait will have a Compact horizontal trait. But when the tableview is presented within a form on an iPad (in portrait or landscape), it will also be horizontally "Compact". Yet the two presentations have very different widths for the tableview.
Possible Approach
First, create two versions of the cell in IB: one for short widths, another with a layout for longer widths.
Then, in tableView:cellForRowAtIndexPath: check for the table view's width. Call dequeueReusableCellWithIdentifier with the required cell ID, depending on the table view's width.
This requires doubling up on the work required, but would seem to be plausible.
Problem: tableView:cellForRowAtIndexPath: is not called for visible cells until that cell is scrolled off the screen and back on again.
Possible fix: implement viewWillTransitionToSize:withTransitionCoordinator: and in there call [tableView reloadData]; This will force tableView:cellForRowAtIndexPath: to be called on all visible cells.
Good/bad?
Any suggestions for a sustainable, device-agnostic approach to handle this?
This should be pretty straight forward, but it appears I need to reach out and ask if others have encountered this...
I've got a project on xcode 6 that's targeting iOS 7+. I'm using a storyboard and autolayout. I've created a UIViewController, dropped on a UITableView, and on that UITableView I've dropped on 3 different prototype cells, each with varying height. Each proto cell has its own UITableViewCell class, with UIElement linked accordingly.
These proto cells are designed in the GUI editor of the storyboard, and each of them have a fixed height. The will never grow in height like this: Using Auto Layout in UITableView for dynamic cell layouts & variable row heights
The problem with all examples I keep finding is that they all use a single prototype cell, and vary the height based on the content (i.e. they're using a UITextView and sizing the cell height based on how much text in in the view).
Since my proto cells are already designed in the storyboard, and they will never exceed their design height with dynamic content, all I want to do is show them as they are designed, when they are added to the table.
I'm using a switch statement in the cellForRowAtindexPath to determine which UITableViewCell class to use based on indexPath.row.
I created some dummy data in an array and use it to build a table with 3 rows, to see each of the 3 types of cells being rendered in the table.
This all works perfectly on iOS8. On iOS7, however, all three of my cells visually end up piled on top of each other.
For grins, I then implemented a heightForRowAtIndexPath method, and simply use a switch to determine what indexPath.row I'm dealing with, and then return back the height of the prototype cell (from the dimensions shown in the storyboard designer). This was supposed to be a simple, hard-coded approach to see if heightForRowAtIndexPath was needed to solve the issue.
Again, works great on iOS 8, but on iOS7 all 3 cells are piled on top of each other.
I guess a basic question is: since I'm using storyboard-designed prototype cells, that have fixed sizes and constraints on all of the UIComponent within those proto cells, why doesn't this work on iOS 7?
I'm trying to avoid adding tons of code just make this work on iOS7.
iOS7 doesn't support self-sizing cells, implementing heightForRowAtIndexPath: and returning the correct height is the right way to do it.
Do you calculate height in "tableView:heightForRowAtIndexPath:" ? Maybe you should try to do it in "tableView:estimatedHeightForRowAtIndexPath:", because being dequeue cells copts from storyboard
I have a table view with a prototype cell containing both disclosure and detail accessories. I want to use a font size of 12 in the cell and reduce the row height accordingly. Thus the size of the two accessory icons need to be reduced in size as well. I assumed this would be one of the more obvious things one might want to do with a table view but fail miserably in figuring out how?
Assuming you are have a nib or storyboard, you should see a resize handle on the cells when you select a cell in the editor. Just grab and resize.
Context:
Building an app that populates a table that takes in data from a asyc json dump.
The cells are of a custom class (I defined). The main label in the cell can be very long.
It is "placed" in storyboard within a prototype cell but customized via code (pretty standard stuff).
Labels are resized in cellForRowAtIndexPath and rows are resized via heightForRowAtIndexPath -- rows are resized by forcing a call to cellForRowAtIndex like Massimo's answer here
So per the question at hand - I've noticed some interesting (bad) things that happen.
First issue: When the table loads, the rows and labels are dynamically resized correctly! Great! However, when I scroll down and then scroll back up, the label heights will be incorrect -- (for example) the first row was correct at loading. Then when I scroll down and then scroll back up to see it again, it will be truncated. Specifically, the row size will be fine but the label height will change and become truncated to 2 lines only. Wondering if this is because I did both storyboard and coding to customize the cell. Anybody see this before?
Second issue: When I scroll down, while the rows are sized correctly (large), the labels are short (truncated.) Wondering if it's some reverse of the above "potential answer".
"potential answer" is that the rows are all calculated and stored "up front" so that scrolling down/then back up doesn't affect it. However, when cells go "out of view" and are dequeued then when they re-viewed (scroll down/then back up) it will rely on the storyboard.(inappropriately?)
All three of your issues are symptomatic of returning the wrong height in heightForRowAtIndexPath. In my data model classes I have a calculateHeight method that I call in heightForRowAtIndexPath. The model also caches the answer so it doesn't have to recalculate it after the first call. The cell class uses the model's calculated height to layout its subviews.
"ANSWERED" by deleting the prototype cell from the storyboard and making them fully in code, the issue went away. The fundamental workings are still not understood (ie. the interactions between storyboard vs. code when cells are put queued and then viewed again)