How to update custom header views in a UITableView when sections are deleted?

Question

I have a multi-section UITableView with custom header views that need to know their section index. I currently record the section number in the tag field of UIView when creating the custom view in viewForHeaderInSection. However, when a row is deleted, the UITableView does not reload the section header views for header views visible on the screen, so their tag fields become out of sync. Calling reloadData on the table re-syncs the tag fields by recreating the header views, but calling reloadData interferes with the row deletion animation. Setting up a timer to call reloadData after a "short" period of time seems hacky and somewhat risky if the user ends up interacting with an out-of-sync header before the timer fires (I suppose I could add a state variable to prevent this, ugh).

I could I suppose keep track of all header views created in a container, and adjust their tags when rows are deleted (ugh again). But then how do I avoid leaking the Views? How do I know when the UITableView has released the view so I can delete my reference to them so they can be released?

This seems like way more work than it should be....am I missing something? I've noticed others have very similar issues and never seen a definitive approach to solving it.

Answer 1

You shouldn't need to reload the table; just update the tag property. In your code where you delete the rows; do you have access to the header views? If not, you can use the observing pattern to alert the header views when a row has been deleted.

Answer 2

I have a multi-section UITableView with custom header views that need to know their section index. I currently record the section number in the tag field of UIView when creating the custom view in viewForHeaderInSection.

How about a dictionary owned by the controller that records each section number for each view. Since you have the recorded section number dependent on the tableview you have to wait for it to refresh (which you shouldn't have to call often yourself.)

You just have to find/make a way to have keys for each view so you know which one is which regardless of the order.

Setting up a timer to call reloadData after a "short" period of time seems hacky and somewhat risky if the user ends up interacting with an out-of-sync header before the timer fires (I suppose I could add a state variable to prevent this, ugh).

I agree that it seems hacky, good instinct. Adding a state variable to prevent this would be less work than a dictionary and tracking system for each view, but I think it would also fall under 'hacky solutions'.