Do you tag your UIViews or retain them as properti

问题:

This is mostly a stylistic question but I've been curious what others' thoughts are since I started programming for the iPhone. When you have a UIView in your iPhone application and you need to access it elsewhere in your application (generally in another function in a view controller), do you like to tag the view with an integer and retrieve it with the viewWithTag: message, or do you generally set it to a property in the view controller for easy access later?

Saving it as a property obviously makes it easier to retrieve later, but I would think there is some (perhaps negligible) amount of memory that is saved by tagging a view instead of setting it as an object property.

I've generally been creating properties on my view controllers, mainly because I'm lazy, and retrieving views with viewWithTag: is annoying.

回答1:

There is no memory to be saved by not using properties - a property is only generating a small bit of code that refers to an instance variable pointing to your view, that is going to be retained if you point to it or not.

Using viewWithTag would always be more expensive and slower, because that call has to go through the view hierarchy asking every view what the tag value is.

I always use IBOutlet instance variables, and add tags to controls sometimes where I don't need to do anything except tell which particular control called a delegate method that could be activated by a few different controls. It's a little less efficient but the code is easier to maintain in that case.

回答2:

I use properties. The memory impact is nowhere near being an issue to think about. viewWithTag: may also burn a little CPU to use, but the main reason I do it is the cleaner code that results. It's far nicer to access self.leftSideView than [self.view viewWithTag:LEFTSIDEVIEW], and you don't have to manage an enumeration to know what's going on.

I regard tags as being useful for debugging, but not day-to-day use.

回答3:

I recognize that this might be tangential to the OP's question, but this may be helpful in feeding Google.

One use that I've found for UIView tagging is actually not to find a view by the tag in the view hierarchy (which as referenced above, can become quite expensive), but rather to discriminate two or more views from each other by a delegate that's assigned to handle several of them, as a way of avoiding a ton of property assignments (which can certainly make UIViewController code more tightly coupled).

A classic case of this is a UITableViewController whose UITableViewDataSource delegate has been externalized to a separate class. Say the UITableViewController later wants a search bar added, and wants to leverage the same UITableViewDataSource. What that means is that UITableViewDataSource methods will be called, and the data source will need to frequently discriminate the real UITableView from the searchResultsTableView on the UISearchDisplayController. If the UITableViewController set a tag on each of the table views, then the data source could easily branch behavior based on the tag value, and without needing references of the table views or (worse,) the search display controller.

Again, I realize this wasn't exactly the tree up which the asker was barking, but it's the only use case I find myself really feeling good about using tags.

回答4:

I always bind them with Interface builder to IBOutlet ivars

回答5:

Just reiterating what Kendall said, viewWithTag: is expensive. I had a loop of a few hundred calls to it and the loop would take 2+ seconds to execute. Switched to an array and now I don't even notice the loop running.

回答6:

I'm late to this discussion, but I think it's worthwhile to extend Justin Searls' point about using tags to discriminate between views, particularly controls. Sometimes you need a group of buttons that all do essentially the same thing but represent different values. The buttons on a calculator are a good example: all the buttons, or at least all the numeric ones, will be connected to the same target and action. Although the target could have an outlet for each button and the action could compare the address of the sender to each outlet in turn, it's much simpler to give each button an identifier that helps the action discern which button was pressed. This is where tags are most useful.

If a view controller will need a reference to a view in order to configure it or otherwise send messages to it, it usually makes sense to use an outlet. If it just needs a way to tell one view from another, tags are a good choice.