Background:
I am trying to create a table view with around 4 types of different cell layout.
At first, I considered using static table view to solve the issue since the number of rows are somewhat fixed (nor more than 10)
But, after some thinking, I decided that I don't really want to be tied up to the UITableViewController. Thus, I tried to implement it with dynamic table view.
Question:
After I create 4 prototype cells, I found out that I'll need to access the child views in cell (to update their value). But the only possible ways I know seem to be:
1. Create a subclass for each prototype cell, and create `IBOutlet` to the child views
2. Assign `tag` for each child view for later access
But I don't really like these two methods...
The first one is too cumbersome, and the tag in the 2nd solution does't seem to be very sepcific (access the child view by just some magic number..)
So, I would like to know:
Is there any better practice for implementing this kind of
tableview. (multiple cell prototypes, and fixed row numbers)
Is static table view a better way to do it? If yes, will there be
any limitations when I am tied up to UITableViewController?
For example, if I need more complex UI, and decide to add more views on to it, will UITableViewController be less flexible than UIViewController
Thank you so much!
If the cells are very similar but with different layouts they could share a common UITableViewCell subclass provided the class doesn't need to know the layout it is in just configure the available outlets.
If the code does need to be aware of the layout used then it is probably best to make them separate subclasses.
For Swift use is or as? to confirm the correct subclass for the cell (for Objective C it would be the isKindOfClass method).
1.You do need to subclass the UITableViewCell if you want to access his IBOutlets.
In order to distinguish between the cell just use isKindOfClass
2.It depends how different your cell are from one another. If they have slightly different structure you might want to consider lodging the elements in cellForRow. Try to take a look at the built in structure cause it might save you some subclassing.
These structures have built in parameters such as: image,text etc.
Their structure is more strict though
Theses are the available types:
UITableViewCellStyleDefault, // Simple cell with text label and optional image view (behavior of UITableViewCell in iPhoneOS 2.x)
UITableViewCellStyleValue1, // Left aligned label on left and right aligned label on right with blue text (Used in Settings)
UITableViewCellStyleValue2, // Right aligned label on left with blue text and left aligned label on right (Used in Phone/Contacts)
UITableViewCellStyleSubtitle // Left aligned label on top and left aligned label on bottom with gray text (Used in iPod).
I don't really understand why you want to use tags?
Related
Imagine this scenario:
I've 10 different and custom UITableViewCell: one with a textfield,
one with a button, one with some labels, one with a textview, one
with an imageView and so on.
I've a ViewController with a tableView where I wanna display these cells.
The number of cell displayed can vary based on some conditions (and also the height, the background color and other parameters)
The user can interact with these cells
What is the best way to design this in respect of the MVC and maintain the ViewController lightweight and maintainable as possible?
How to take advantage of Swift language in doing this?
Is there any famous and consolidate design pattern to apply?
i will try to share some of my experience:
Create separate custom UITableViewCelll as per requirement like : textfield, textview, imageview, label etc. this class must not dependent on data calculation it is only for cosmetics UI. that means there must not be any method like updateCellWithData:(someDATAObj). This logic must go in some cetegory as discussed below.
Register separate custom UITableViewCelll with your tableview.
Create separate class (NSObject) as datasource and delegate for your UITableView.
Use category to populate data in your custom UITableView Cell. some thing like updateCellWithData:(someDATAObj).
Use constant file for your constants like height for tableView Cell, reuse identifier names, notification name.
try with some code atleast, then we can help you with best.
My goal is to have a Swift implementation of a UICollectionView with dynamic content where each cell hold parts of a sentence. Each part of the sentence can be edited by the user. The problem is that some parts of a sentence might be longer than the container itself. Using sizeToFit is not an alternative because all content should have the same font size to maintain readability throughout the collection view.
Right now the behaviour I get, when I have a part of a sentence longer than the container is the following:
As you can see the third row has leading ellipsis.
What I would like to achieve is the following, the overflowing part of the cell should wrap as analogous to a span tag in HTML, like so:
Is this possible? How can I achieve such a thing?
As far as I can tell, it's possible but complex - here are a few pointers of what I'd say you're going to need:
2 additional collection view cell types: in the first, only the left edges are rounded, in the second only the right
Use Core Text API to measure where your text needs to be wrapped
In your datasource, you're going to have to then recognize the situation before you create the cells and then instead of creating a single cell, you create two, using those new types you have.
I need to display a table with in my iPhone app:
neither the number of cells nor the contents are known at compile time, but only at run time.
Views for each cell may differ, one cell has textField and another may have some other view control.
Should I consider Static or prototype cells?
Should I consider tableViewController or viewController with tableview in it?
Any thing I need to consider before I start coding? Thanks in advance
For The issue of dynamic Number of cell at Run time, you can call reload data for table view at any time you have the data source ready.
Prototype Cells should be used with no problem.
Simple Table View will be sufficient for the task.
You have to make cell, either in code or in storyboard, for each type of cell you want, 1 table View can have multiple types of prototype cells, Just name them differently and then make the objects of only the specific cell of which the data is best suited.
It is not that difficult but do handle the data source with extreme care.
Should I consider Static or prototype cells?
If you know all possible subview combinations that your cells might need to display the data appropriately, and they are relatively few, make one prototype for each. for example:
One text field,
Two labels,
One image view and a label,
...etc.
Otherwise, just use the plain-vanilla UITableViewCell (no subclassing) and remove/add subviews at runtime when reusing them (that is, inside the method -tableView:cellForRowAtIndexPath:).
Should I consider tableViewController or viewController with tableview
in it?
The only reason I would choose UIViewController + UITableView over UITableViewController is if -for example- I needed the table view to only take up part of the main view's bounds/screen, and display some other subview in the remainder. Otherwise, you get so much "for free" with UITableViewController that there's just no point in implementing all of that from scratch.
You have to choose prototype cell, u can create different types of cell depending upon your requirement.Any think ok for u, u can create tableview controller or view controller.
Please see my mockup pictured above. I am a bit puzzled as how to code this. I guess I would use one UITableView and have all customizations on one cell. Any other ideas? I wasn't sure if it would be better to have multiple tableviews on one controller or something instead.
First off, this design really won't work except on iPad. It's just too much to try to cram onto an iPhone screen.
Collection views are like a more flexible form of table view. You can arrange collection views in rows, columns, rows AND columns, circles, or whatever you want.
You can make a collection view act like a table view, but it's more work, and a little more confusing.
If your UI is a vertical list of cells, a table view might still be a better fit, since it matches what you're doing.
Assuming this app is iPad only:
Create a custom subclass of UITableViewCell, with it's own XIB file. Define the contents as desired. Making each "tile" (the 5 boxes shown in each cell) in the table view cell a separate custom subclass of UIView might make sense, or it might not, depending on how you expect to use them. If they are always in the same order, and never used anywhere else but in this table view, then no. Just build the cell from components. If you ever think you might use one of these tiles somewhere else, or if you might ever display them in a different order, then yes, make each tile a separate custom UIView subclass, and use those custom views in constructing your cell.
Having multiple UITableView is bad idea – when you scroll one of them others will remain static. I would recommend you to use one table view but decouple a cell in the separate views (or even view controllers) and have a special view (maybe with .xib) for each of 5 components.
I'm creating a Table View in Interface Builder (Storyboard). I'd like to have a couple of different Dynamic Prototype cells with different sets of Labels and Images in them and so on, and I can give them different reuseIdentifiers so I can pick which ones I want at runtime.
In Interface Builder, I create several Dynamic Prototype cells in my UITableView, which is controlled by a UITableViewController.
In the first cell, I drag and drop in various views and so on.
In the second cell, IB will not let me drag any views into it? I can resize the second cell vertically, but can't put anything into it at all, either by dragging into the cell or into the object graph in the left-side bar.
If I copy and paste the first cell, a second Dynamic Prototype will appear with all of the same contents, but I won't be able to modify the copied cell (can't add or move subviews). However--and this is strange--I can select the constraints and modify their values to resize and shift objects in the second cell.
As a note, running XCode 5-DP3. Tried restarting it (didn't expect that to help, and it didn't). Otherwise, unsure what to try, and unsure if I'm doing something very braindead, or if this is a bug I need to report to Apple.
So, am I crazy? Has anyone experienced this/can anyone recreate this?
EDIT:
After further testing, if I stick a big UIView into the first cell, and then copy that cell, I can edit inside my added view. (Does this make sense?) I can't edit anything that lies within the second UITableViewCell, but if it contains a UIView copied over from the first cell, I can put new views into that view and move them around and so on. Super-strange.
For the sake of posterity, I'm answering my own question:
The way I solved this was to take a UITableViewCell object from the Object library and drag it onto the UITableView. Sounds simple, right?
The problem I was running into was only if I copied existing dynamic prototypes through Cmd+C & Cmd+V, or by incrementing the number in the Attributes inspector for the table view. The Storyboard Editor wouldn't allow me to modify those ones.
Dropping in new cells from the Object library let me tweak them all separately.
XCode 5-DP6 solved issues with not abling to resize cell's subviews.