Shulou(Shulou.com)06/02 Report--

This article mainly explains "how to use UITableView". The content in the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn how to use UITableView.

Pain point

In our iOS development, UITableView is a UI control used by almost all App. Because of the needs of the business, we often register a variety of Cell, and then in

-(UITableViewCell *) tableView: (UITableView *) tableView cellForRowAtIndexPath: (NSIndexPath *) indexPath

It's natural to write a bunch of code like this:

The code for event handling looks something like this:

There seems to be no problem with this, the code is clean and the logic is clear.

But after you maintain several versions, you may encounter a fickle product manager.

You will find that this kind of code is really dangerous to maintain, and if you don't pay attention to it, it will go wrong. The type used here as a judgment condition may be better than that of indexPath.

If you use indexPath as a judgment condition, and if your cell order changes or changes, then you may need to maintain at least the following areas:

Your model array

The judgment condition of cell dequeue

Judgment conditions for event handling

.

The more things you maintain, the more likely you are to make mistakes.

Is there any good way to deal with this kind of code?

Analysis.

In fact, let's think about it carefully. No matter how complex a UITableView is, all it needs is an array of models.

So it is obvious that if we maintain the model array, we will maintain all the cell in UITableView.

If we had N cell styles in our UITableView, then there would certainly be N models in the model array.

That is to say, each cell is paired with each model one by one, and the conventional model is bound to cell as described above.

The above idea is obviously not what we want, it is too inconvenient to maintain, and the coupling is relatively large.

Think about the process of showing a UITableView

Initiate a network request

JSON to Model to construct an array of models

Data filling

These are roughly the three steps.

In fact, when we construct the model array in the second step, can we determine the style of UI?

If we don't understand here, let's take a look at our above analysis. A cell style corresponds to a model, so if we know the model, do we know the cell style?

If you're still not sure, let's get into the actual combat part.

Actual combat

First look at such a simple page, you are sure to say: my friend, you TM is teasing us, what does this have to do with UITableView?

This interface requires UITableView?

Yes, this interface can be built directly in UIViewController.

Please look at the following again

Do they all feel similar, but there are many different places.

Scheme

Write one by one VC.

Disadvantages:

There is a lot of repetitive code, and where later changes need to be maintained, there is no high cohesion.

Abstract a parent class

Disadvantages:

Although the three VC seem to have a lot in common in UI, the business processes in them are completely different.

Abstract a UIHelper for building UI

Disadvantages:

This seems like a good solution, but you see, if you add or decrease a control in an interface, you have to redo the constraint, which is obviously not what we want.

Let's take a look at the UI built through UITableView

Show

The code in SignInVC:

The code in PasswordSignVC:

Take a look at the dequeue code of cell.

The binding of data is all distributed in each cell.

The code for Row.h

# import NS_ASSUME_NONNULL_BEGIN@protocol Updatable @ optional- (void) updateViewData: (id) viewData;@end@interface Row: NSObject@property (nonatomic, copy, readonly) NSString * reuseIdentifier;@property (nonatomic, strong, readonly) Class cellClass;@property (nonatomic, strong, readonly) id model;- (instancetype) initWithClass: (Class) cls model: (id) model;- (instancetype) initWithClass: (Class) cls;- (void) updateCell: (UITableViewCell *) cell;@endNS_ASSUME_NONNULL_END

The code for Row.m

Interface Row () @ property (nonatomic, strong, readwrite) Class cellClass;@property (nonatomic, strong, readwrite) id model;@end@implementation Row- (instancetype) initWithClass: (Class) cls {if (self = [self initWithClass:cls model:@ ""]) {} return self;}-(instancetype) initWithClass: (Class) cls model: (id) model {if (self = [super init]) {self.cellClass = cls; self.model = model } return self;}-(void) updateCell: (UITableViewCell *) cell {if ([cell respondsToSelector:@selector (updateViewData:)]) {[cell performSelector:@selector (updateViewData:) withObject:self.model];}}-(NSString *) reuseIdentifier {return [NSString stringWithFormat:@ "% @", self.cellClass];} @ end

The whole Row code is only 100 lines, which brings all the processing together. As long as we maintain the model array, we can manage the UITableView very well.

UI is built, but I'm sure there are two issues that you are more concerned about.

Cell height calculation

Callback of events on Cell

Cell height calculation

After iOS8, the function of Self-sizing is introduced in UITableView, so the height of Cell changes.

UIView * dummyView = [[UIView alloc] init]; dummyView.translatesAutoresizingMaskIntoConstraints = NO; [self.contentView insertSubview:dummyView belowSubview:self.textField]; [dummyView.topAnchor constraintEqualToAnchor:self.contentView.topAnchor]. Active = YES; [dummyView.bottomAnchor constraintEqualToAnchor:self.contentView.bottomAnchor]. Active = YES; NSLayoutConstraint * constraint = [dummyView.heightAnchor constraintEqualToConstant:60]; constraint.priority = 999; constraint.active = YES

If you are not familiar with this area, please jump. If you want to have an improvement suggestion for Auto Layout, take a look at Auto Layout Guide, if you want to know the role of systemLayoutSizeFittingSize, please read in-depth understanding of Auto Layout first play.

Callback of events on Cell

Some people will certainly disdain here, but I want to say: if you don't use block, agent, observer.

How do I call back events from button on cell to VC (button is not exposed to the outside world)?

Let's first look at how to add Action.

-(void) addTarget: (nullable id) target action: (SEL) action forControlEvents: (UIControlEvents) controlEvents

These three parameters are required here:

Target (action counterpart)

Action (click the appropriate method of the button)

ControlEvents (this is usually UIControlEventTouchUpInside)

As soon as we find the target, write the action to the target and the action binding is complete.

Target is actually our VC. All we have to do is pass the VC to Cell, but is Cell coupled with VC again? It doesn't make any difference to use block,delegate.

Now the problem we need to solve is to find the VC of Cell, and great work can be done.

This is the need for an important concept to make a brilliant debut iOS response chain (Responder Chain)

It's not going to expand here, but you have to understand this.

Problems that can be solved by the response chain:

Expand the corresponding area

It can still be passed beyond the parent class view.

Collapse layer transfer event

Find UIView's UIViewController.

-(UIViewController *) viewController {UIResponder * responder = self; while (! [responder isKindOfClass: [UIViewController class]]) {responder = [responder nextResponder]; if (nil = = responder) {break;}} return (UIViewController *) responder;}

ButtonCell event binding code:

Here we still have to use an agreement:

Be careful

This protocol is mainly used to facilitate the reading of the code, and it is necessary to use the protocol in Swift because this method cannot be found at compile time.

You can see that there is no such code in ButtonCell's code.

@ property (nonatomic, weak) id delegate

Or

@ property (nonatomic, strong) void (^ buttonAction) (void)

In this way, our ButtonCell will not be coupled with VC, so it is really convenient to modify it.

Thank you for your reading, the above is the content of "how to use UITableView", after the study of this article, I believe you have a deeper understanding of how to use UITableView, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.