Doing so may lead to strange bugs when manipulating the sizes of elements in a cell. In almost all cases you will want to create your own types of cells that have components and layout matching your needs. As with any other view in UIKit, there are three ways you can design your custom cell type: within a storyboard itself via prototype cells, creating a separate NIB via Interface Builder, or programmatically laying out your cell.
We'll continue our previous example by creating a custom cell that has two separate labels with different font sizes for the city name and state initials. To use prototype cells you must be in the Interface Builder and have already placed a table view in your view controller. In order to create a prototype cell, you simply drag a Table View Cell from the Object Library onto your table view.
You can now layout and add objects your prototype cell as you would with any other view. Once you are satisfied with the design of your cell, you must create a custom class and associate it with your UI template. You must now associate your class with your prototype cell. In the storyboard editor, select your prototype cell and then select the Identity Inspector.
Set the Custom Class property of the prototype cell to the name of the class you just created. You will now be able to select your custom cell class in the Assistant Editor tuxedo mode and connect IBOutlets from your prototype cell into your class as you would with any other view.
Note that you must select the "content view" of your prototype cell in order for your custom cell class to show up under the Assistant Editor's automatic matching. One you are satisfied with the design of your cell and the corresponding code in your custom class, you must register your cell for reuse by providing it with a reuse identifier. In the storyboard editor, select your prototype cell and then select the Attributes Inspector. Set the Identifier field Reuse Identifier to a unique string that can be used to identify this type of cell.
You can now use this identifier when calling dequeueReusableCell withIdentifier: for: in your implementation of cellForRowAt indexPath:. Notice that the compiler cannot infer the type of your custom cell class from the reuse identifier and you must explicitly cast the resulting object to the correct class.
There may be times when you do not want to use prototype cells, but still want to use Interface Builder to layout the design of your custom cell. For example, you may be working on a project without storyboards or you may want to isolate your custom cell's complexity from the rest of your storyboard. Most files you create with Interface Builder will have the. We'll use the two names interchangeably throughout this guide.
The procedure in for working with a separate NIB is almost the same as working with prototype cells. The only difference is that you must now explicitly load your NIB and register it for reuse. This will create a. You can now open the. You do not need to set the reuse identifier attribute in Interface Builder as we did for our prototype cell. This is because once you are ready to use your new cell you must explicitly load the NIB and register it for reuse in your view controller:.
By default, your NIB will be in the main resource bundle, although you may change this in larger projects by editing your build steps. Finally, you may work with projects that do not use Interface Builder at all.
In this case, you must lay out your custom cell programmatically. In order to be able to register your custom cell for reuse, you must implement the init style:reuseIdentifier: method since this is the one that will be called by the UITableView when instantiating cells.
As with any other UIView , you can also take the advantage of other entry points in the view's lifecycle e. Once you are ready to use the cell, you must then register your custom cell class for reuse in your view controller similarly to how we registered the NIB for reuse above:. Depending on design you may want the height of rows in your table to be fixed across all cells or to vary depending on the content of the cells.
There are a few pitfalls to aware of when manipulating the height of rows in a table. One of the implementation strategies that keeps UITableViews performant is avoiding instantiating and laying out cells that are not currently on the screen. However, in order to compute some geometries e. Thus one of the goals when specifying the height of your rows is to defer if possible performing the layout and configuration logic for each cell until it needs to appear on the screen. If you want all the cells in your table to the same height you should set the rowHeight property on your UITableView.
There are two ways to have different row heights on a per cell basis. If project is targeted only for iOS 8 and above, you can simply have Auto Layout adjust your row heights as necessary. In other cases, you will need to manually compute the height of each row in your UITableViewDelegate. One way to help iOS defer computing the height of each row until the user scrolls the table is to set the estimatedRowHeight property on your UITableView to the height you expect a typical cell to have.
This is especially useful if you have a large number of rows and are relying on Auto Layout to resolve your row heights or if computing the height of each row is a non-trivial operation. If you are targeting exclusively iOS 8 and above you can take advantage of a new feature that has Auto Layout compute the height of rows for you.
You should add Auto Layout constraints to your cell's content view so that the total height of the content view is driven by the intrinsic content size of your variable height elements e. If you are using Auto Layout, you may wish to still have Auto Layout figure out the row height for you. One way you accomplish this is to instantiate a reference cell that is not in your view hierarchy and use it to compute the height of each row after configuring it with the data for the row.
A more detailed discussion of this technique can be found here. In some cases, the height of your cell may be entirely dominated by one or more elements so that you are able to figure out the row height by simply doing some arithmetic and without actually needing to lay out the subviews. For example, if the height of you row is determined by an image thumbnail with some padding around it, you can simply return the value of the size of the image added to the appropriate padding.
In many cases, the height of your row will be determined by the height of the text in one or more labels. In these cases, you can compute the the space a piece of text will occupy without actually rendering it by calling NSString 's boundingRectWithSize method.
A discussion of how to do this in Swift can be found here. UITableViewCell and every subclass of you create comes built-in with an accessory view that can be useful for displaying a status indicator or small control to the right of your cell's main content view.
If the accessory view is visible, the size content view will be shrunk to accommodate it. If you plan on using accessory views, be sure the elements in your content view are configured to properly resize when the width available to them changes. You can use either the built-in accessory views via the accessoryType property or use any UIView by setting the accessoryView property. You should not set both properties. There are a few built-in accessory views that can be activated by setting the accessoryType property on your UITableViewCell.
By default this value is. Returning to our prototype cell example, you can see what each accessory type looks like below. If you use the. DetailDisclosureButton or. You should be aware of the same performance considerations regarding the creation of UIViews per row when using this feature. Also, note that if you want to handle any events from a custom accessory view, you will have to implement your own event handling logic see how to propagate events below.
For more complex situations, you might opt to simply include this custom "accessory view" as part of your main content view. Rows in a UITableView can be grouped under section headers. You would then need your cellForRowAtIndexPath implementation to support multiple sections and return the correct row under the correct section specified by the indexPath.
NB: The above discussion regarding section headers applies equally to footers by replacing "header" with "footer" throughout. The above code can produce two different behaviors depending on whether our UITableView is configured to have the Plain style or the Grouped style. Plain is on the left and Grouped is on the right below. Notice that the section header sticks at the top of the table while we are still scrolling within the section.
The table view section style can be changed in Interface Builder under the Attributes Inspector or can be set when the table view is initialized if it is created programmatically.
UITableView and UITableViewCell have several built-in facilities for responding to a cell being selected a cell and changing a cell's visual appearance when it is selected.
Here is one way we can implement a simple checklist:. These screenshots show how section rows, headers, footers, edit controls and the index are displayed. The header can be set with a string value or a custom view can be supplied to allow for a different layout or style. Cells are the main user interface element for a table. When implemented correctly, cells are re-used for memory efficiency. There are four built-in cell styles, and you can create your own custom cells — either in code, or in the Designer when using Storyboards.
The optional section footer can be set with a string value, or a custom view can be supplied to allow for a different layout or style. Section headers and footers can be set independently. The index appears as a strip of characters down the right edge of the table. Touching or dragging on the index accelerates scrolling to that part of the table. An index is optional but is recommended to help navigate long lists. An index is not usually used with the Grouped style. This will cause a type error because the SectionItem needs to implement the Hashable protocol to be usable in a Dictionary - make this requirement explicit by requiring the SectionItem to be conforming to the Hashable protocol:.
Extract the GroupedSection type into a separate Swift source file and create a group Common for it. The finished type should look like this GroupedSection.
Last update: September 19, Tested with: Xcode About the author Ralf Ebert has been working as a software developer, interaction designer and trainer for 18 years.
0コメント