Do you tag your UIViews or retain them as properties?

Question

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.

Answer 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.

Answer 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.

Answer 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.

Answer 4

I always bind them with Interface builder to IBOutlet ivars