I encountered this image on Apple's UI Design Do's and Don'ts:
Of course the UI on the left is the one I am shooting for, my question is what is the best way to go about getting this UI on the left? My initial thought was to use a static table view, with the top cell being the image and the cell below it but I came up with two problems with that approach:
How would I get that little water droplet image to span across both cells?
How do I make sure that the text field below the image is always the right length no matter how much text is put in (i.e. resizing the text field and the cell depending on the amount of text)?
My second thought was to use a UIScrollView and put the image at the top, constrain the water droplet in between them and then contain a text field below it, but then:
How would I make sure that the text field always the right length no matter the amount of text put in?
It is pretty impossible to constrain these items in a UIScrollView, how do I properly constrain this in a UIScrollView?
Why not use a UITableView, and make your cell in the interface builder that can be called through a reuse identifier. And each cell would have the image along with the relevant information that's required. This would fix your first option since you would be able to place the water droplet image over your image and your text.
For your second issue, making sure the cell is of correct height can be done by giving the UITableView dynamic height.
For example, you wouldn't need to insert a heightForRowAtIndexPath function on this tableview, and you can also define:
tableView.estimatedRowHeight = 100; //Can be any value really, but giving a reasonable estimate is helpful
tableView.rowHeight = UITableViewAutomaticDimension;
Also, your the textView you want to use shouldn't be set with any fixed width's or height in the interface builder.
TableView Image . Your imageView would be set up somewhat like the blue section in this picture (but fitting the entire width of the screen instead) and your textView would be like the red one. They would all fit in one cell and would make it much easier to organize than using 2 separate cells for one set of content, and you wouldn't have to get into the hassle of setting up the UIScrollView.
Related
My use-case is like this:
The user defined some tags (text like "#asdf", "#qwerty", "#let_me_think_about_it" and "#decide later"). I want to display these in a box without scrolling (and don't know, how many tags the user created until I display the box).
The box itself should not be scrollable at all but be shown in a UITableViewCell (which is being scrolled). So it must compute the proposed height and respond to Autolayout mechanisms. If a (ARM) Mac user resizes the window to be smaller than before (or an iOS user rotates the device), the box should increase/decrease its height, as necessary (within the limits of Autolayout, since I know of some issues). Each of the tags should be (de)selectable at the same time (UILabel with UITapGestureRegognizer attachted?) and be able to displayed 'selected' (via a background view).
So, the box should primary try to align all content horizontal. If There's not enough horizontal space, do a "line break" and continue on the next "line".
My current solution is a UIScrollView that the user can scroll horizontal and tap any of the (UILabel) views. The displayed views itself are being loaded from a NIB file, like a UITableView does. The issue here is that not any of the selected tags might be visible at the first glance.
If there was no Autolayout, I'd exactly know what to do. But since there it is, I want to use Autolayout in my NIB files and wonder what you would do?
(How do you compute the required width of such a view and decide when a line break is to be done (and how?))
I think I need a simple hint. But if it needs code to explain, ObjC and Swift is both acceptable. :-)
So, the box should primary try to align all content horizontal. If There's not enough horizontal space, do a "line break" and continue on the next "line".
This sounds like a job for UICollectionView with UICollectionViewFlowLayout. You can disable scrolling, and the layout object will tell you the size of the content so that you can adjust the size of the box.
(How do you compute the required width of such a view and decide when a line break is to be done (and how?))
If you're doing it yourself, you add up the widths of all the items on the first line, and if it's larger than the available space, you move the item that extends past the limit and any subsequent items to the next line. Repeat as needed. But that's exactly what a flow layout does for a collection view, so there's no need to roll your own.
Nowadays fortunately it's trivial to have an iOS table where every cell has a dynamic height. So in the cell vertical constraints ..
---- top of content view
- vertical constraint to
-- UILabel, with, .lines set to zero
- vertical constraint to
---- bottom of content view
Assume the UILabel texts vary greatly one word, 20 words, 100 words,
In the table set
tableView.rowHeight = UITableView.automaticDimension
tableView.estimatedRowHeight = 200 // say
and you're done, these days it works perfectly of course.
However, I had the common situation where you load the table, imagine ten cells.
I populate the UILabel with "Loading..."
Only then - say, a second or two later - do we get the information for the text content. It arrives say a second later and the cell changes the text to "Some long text .. with many lines".
In fact I was surprised to learn it seems UITableView does NOT handle this. The cell in question gets stuck on the original short height.
So, after the larger text is set, I tried all permutations of the usual:
maintext.sizeToFit()
contentView.layoutSubviews()
contentView.layoutIfNeeded()
on the cell, doesn't work.
I tried sending a setNeedsLayout and/or layoutIfNeeded to the table itself, doesn't work.
I thought about .reloadData() on the table itself but - doh - that would again trigger the content being drawn from the server and loaded again, so that's not ideal.
Please note that:
Obviously there are any number of workarounds for the specific example such as not using dynamic data
I am completely aware how to manually animate the height of one cell (like when you "expand" one to show something else when the user taps)
This question is about autolayout and table view - which, thanks Apple, nowadays flawlessly handles completely dynamic cell heights involving UILabels with lines zero.
But what about if the text in such a label changes?
It seems that the table view system does NOT handle this.
Surely there's a way?
When the content of a cell changes the layout (in this case, the height) you must inform the table view that the layout has changed.
This is commonly done with either:
tableView.beginUpdates()
tableView.endUpdates()
or:
tableView.performBatchUpdates(_:completion:)
Why is that not triggered automatically?
I suppose it could be to allow you to do your own animation, or you may want to delay the update, or some other reason that doesn't come to mind at the moment.
Or, it may be due to maintaining backward compatibility?
I don't know. I imagine Apple could tell us...
I am building an app about meetings where I want to show a preview of the VIP participants in each meeting cell.
These participants are not clickable nor scrollable, the only purpose it's to quickly see them at a glance.
The problem is that the view is very dynamic:
VIP's appear with image or initials
The rest of the attendees is just a number
if >5 VIP's, the circles start going together overlapping (spacing goes smaller)
if 9 VIPs, big wrapping circle “All VIPs in Attendance"
This is how it will look:
What should I do?
CollectionView (seems over-kill as I am not interested in any kind of interaction with the images)?
StackView?
Images (and change constrains programmatically)?
NOTE:
These is just one kind of Table View Cell, but we have a lot more variations, so we are building the custom cells in xib files. Xcode doesn't allow me to add a Collection View Cell in to the Collection View within the xib.
Interesting task - I'm sure there are numerous approaches, but here is one using UIStackView plus some on-the-fly calculations.
The idea is to define a maximum gap between views; a maximum width for all views; calculate the actual gap needed, and then let UIStackview handle the actual positioning.
Certainly not every feature you need, but should get you going in the right direction.
You can see/download the source for this here: https://github.com/DonMag/ScratchPad
Look at the Swift3/SpreadingViews sub-project for this example.
The problem with scrollable views (UIScrollView based views as UICollectionView), is that you will have to deal with the scroll, or pre-compute the width of your content, which is not always easy. For this reason, if you don't want to have scrollable content, I'd not use a UICollectionView, neither any UIScrollView based view.
Then you have the option to go with an UIStackView. Stack views are great to "append" multiple views and create some kind of "pile" of views in a very easy way. However, if you don't control how many items you need, you will overpass the boundaries of your container view.
Therefore, this is what I'd do:
"Fixed container view width" case: If your container view (your cell) has a fixed width (that never changes), I'd manually add as many UIImageViews I want to support in the XIB itself, and then hide/unhide them depending on the number of items I want to display.
"Variable container view width" case: If your container view (your cell) has a variable width (that changes depending on the screen size or whatever other factor), then you will have to compute in any case (do the math!) the amount of items you are able to display within the width you have available. Then, you can choose between using an UIStackView or adding your views & constraints manually to your container view.
Does what I say make sense?
Thanks,
I'm building something similar to the compose page of the native iPhone Mail app.
But, I'm putting two text fields on one row, and I want to separate them with a vertical divider (an additional view) that's the same color & weight as the horizontal cell separators.
Apple's docs say:
If you want to customize cells by simply adding additional views, you should add them to the content view so they will be positioned appropriately as the cell transitions into and out of editing mode.
But, what if I know, like in this case, that my cell will never go into editing mode?
Also, the horizontal cell separators are subviews of the cell, not the cell's content view. So, I think it'd also make sense if I added the vertical divider to the cell, not the cell's content view.
Can I just add additional views to the cell itself, instead of its content view?
You can add additional views directly to the cell, but it's best practice to add them to the cell's content view. Even if you're cells never go into editing mode, this is what Apple and other developers that may be working on your code (or you in the future) are expecting. So, this will make it easier for them to work with your app.
For example, what if Apple hypothetically decided to put gutters on the left & right side of plain style table views in a future release of iOS? Then, they would probably inset the cell's content view but not the cell itself. That way, if you position your additional views relative to the content view, your app has a better chance of looking good and the additional views have a better chance of not getting clipped by Apple's hypothetical gutters. OK, I doubt Apple would do such a thing, but the point is that if you add your additional views to the cell's content view instead of the cell itself, you're code will be more robust.
For your specific case, I still recommend adding the vertical divider to the cell's content view because you can. You might even consider setting the tableView.separatorStyle = UITableViewCellSeparatorStyleNone and redrawing custom separators by adding a separator view to the bottom of each of your cells' content views. This way, you can be sure that the style of the vertical divider you add will always match that of the separators. Again, this will make your code more robust and protect you if Apple decides to change the style of their separators. Sure, you can use cell.separatorColor. And, you can guess the separator weight with cell.frame.size.height - cell.contentView.frame.size.height. But, such cleverness might get you in trouble.
As the Buddha admonishes Siddhartha, "Beware of too much cleverness!"
(please forgive my english)
I'm new at IOS developing but I've a good skill on other programming languages (mainly c#).
I'm trying to develop a test app with a main window.
Inside that window there is a scrollview with fixed size. inside that scrollviewer there is a view containing some stacked couples of one TextField and one Label: I can't know - ad design time - how many "rows" of them I have to put into.
My problems is:
I can put on the view the first couple (a textfield and, next, a label). Label size can be one or several rows high ,so I've to set multiline and sizeToFit
How can I put the second couple (and so on) without overlap the existing labels..? I can't use a table because between rows there are other labels (title of section).
Do I have to calculate the height of each label and programmatically calculate where to draw the next? Is there a more efficient way?
I don't need code, please just some hints or some keyword to googling on.
Many thanks.
I don't see why you can't use a UITableView, you can set up cells with all the controls you need in it. Either way, using a UITableview won't make the job any easier (just more memory efficient if you have many rows).
The only way that I see is, as you said, to calculate where the next 'row' should be placed (depending on the height of your previous rows). You'll also need to calculate the entire height, in order to set it to the contentSize of the UIScrollView.
Instead of UILabel you can also use a non editable UITextView, since it'll be easier to get its size (after you set the text, you can set the size of a UITextView to be equal to its contentSize)