Question

I have a UITableView, with a SearchBar that has a visible ScopeBar. I have implemented all the requisite delegate and data source methods to support table indices. Yet, when the table view is shown, there are no section indices displayed. When the search results table is shown, there are section indicies displayed.

I implemented the code snippet from this answer and confirmed that the main table is, in fact, indexed.

I am really stumped. Logging suggests that everything is in place to have this work, but I cannot for the life of me figure out why the main table doesn’t show indices. And yes, the indices for the main table are setup; I can see them in my logging.

For the main table, I can see that the index titles are requested and returned, but not displayed.

For the search results table, the same logging appears (titles are requested and returned), and they ARE displayed.

One thing to note, although I can’t see how this would cause the indices in the table not to appear, is that the SearchBar class is actually a subclass that simply overrides setShowsScopeBar: to force it to YES. I tried my app with and without this override. Same result: no index in the main table view.

So the question is: What would prevent the index from showing, even when all the requisite delegate and data source methods for supporting indices is in place (and working at least for the search results table, because the methods are called and the index is shown for that view.)

Thanks!

Answer 1

So after all these months, here’s the solution to this problem.

First off, it would appear that -reloadSectionIndexTitles in iOS 4.3 SDK still does not seem to do anything with respect to (re)displaying the section index titles in the view. I still have to use -reloadData, which is unfortunate, but in the end it’s ok. (Have not tried under any newer iOS versions, FWIW…)

Now, the original problem was that the index titles appeared squeezed into the top half of the right edge of the screen, as if a keyboard were showing. But no keyboard was showing!

So I got to thinking: What makes a keyboard show? Something is marked at first responder that would normally cause a keyboard to show! (Or, something else is erroneously indicating that a keyboard is showing.) The only thing in my view that would do that is the search bar.

Here’s where the plot thickens. My search bar has a scope bar, which I wanted to be visible always. This is non-standard. So to do that, I sub-classed UISearchBar and overrode -searchBar:setShowsScopeBar::

- (void) setShowsScopeBar:(BOOL) show
{
    [super setShowsScopeBar: YES]; // always show!

    [self resignFirstResponder];
}

My initial implementation did NOT include the call to resignFirstResponder. So, whenever this method was called on my UISearchBarinstance (simply telling the superclass to set the scope bar visible), the search bar (or perhaps the scope bar) was being marked first responder but not showing a keyboard. This in turn, as best I can tell, was having the effect that when it came time for the table view to display the section index titles, it believed something was first responder and presented a squished index. This erroneous assumption on the part of the table view was further evidenced by the fact that the lat row of the table was allowed to scroll up just above mid screen — as if a keyboard were showing!

Adding the call to resignFirstResonder solved the issue by clearing whatever state was set erroneously to indicate (somewhere) that a keyboard was showing. Now the index appears at full screen height, as expected.

Very. Bizarre.

I spent a lot of time figuring this out. Perhaps this behavior is a by-product of my implementation which is admittedly non-standard (the scope bar acts more like a UISegmentedControl for 2 of its 3 choices). In any event, the behavior before I added the call to resignFirstResponder was at a minimum unexpected.

I thought I’d post the resolution for anyone who might stumble upon this in the future. Hope it helps.