After upgrading to MT 4.0, my TableViews that previously were displaying indexes on the right hand border are no longer working. The tableview still displays in sections and works properly, but the index is not displaying.
I have these three methods defined in my UITableViewSource, and all three appear to be working:
public override string[] SectionIndexTitles(UITableView tableView)
public override int SectionFor(UITableView tableView, string Title, int atIndex)
public override string TitleForHeader(UITableView tableView, int section)
Is anyone else having this problem? Is this a bug with MT 4.0?
This is a known bug.
It appears that UITableView is not retaining the returned array, you can use
the following to work around this issue while we investigate it further:
NSArray array;
[Export ("sectionIndexTitlesForTableView:")]
public NSArray SectionTitles (UITableView tableview)
{
if (array == null) {
string[] titles = new string[RowsInSection(tableview, 0)];
for (int index = 0; index < titles.Length; index++)
titles[index] = index.ToString();
array = NSArray.FromStrings (titles);
}
return array;
}
This was showing to me just numbers (index for each item of the section 0 (like A letter of the index), so I found that must change this to:
NSArray array;
[Export ("sectionIndexTitlesForTableView:")]
public NSArray SectionTitles (UITableView tableview)
{
if (array == null)
{
array = NSArray.FromStrings (SectionIndexTitles(tableview));
}
return array;
}
To all people who don't get the workaround to work correctly:
For me it was because I left the MonoTouch override method SectionIndexTitles in there - as soon as I removed it (or in my case renamed it so it can be called from the workaround), it worked as described :)
Getting the same problem, but the above fix did not work, I am sure it is probably something simple that I am doing wrong. The below methods are part of a UITableViewSource. All working as it was before MT 4.0, however the textual Index is not appearing. Debug output listed below the code shows that SectionTitles is not being called. Any thoughts on how this differs from the solution above, and how to get it working? Happy to start a new thread on this, but thought that it might be useful to have more information on this question instead.
NSArray array;
[Export ("sectionIndexTitlesForTableView:")]
public NSArray SectionTitles(UITableView tableview)
{
Debug.WriteLine("SectionTitles");
if (array == null)
{
array = NSArray.FromStrings(SectionIndexTitles(tableview));
}
return array;
}
public override string[] SectionIndexTitles(UITableView tableView)
{
Debug.WriteLine("SectionIndexTitles");
var sectionIndexTitles = Root.Sections.Select(section => section.IndexTitle ?? string.Empty);
var applySectionIndexTitles = sectionIndexTitles.Any (sectionIndexTitle => !string.IsNullOrEmpty (sectionIndexTitle));
foreach (string s in sectionIndexTitles)
{
Debug.WriteLine(s);
}
Debug.WriteLine("applySectionIndexTitles = " + applySectionIndexTitles);
return applySectionIndexTitles ? sectionIndexTitles.ToArray () : null;
}
Debug output:
SectionIndexTitles
A
B
C
D
E
F
G
H
J
K
L
M
N
O
P
R
S
T
W
applySectionIndexTitles = True
Wow, the answers here are a extremely misleading. Where do I start?
First, why are the examples using a backing NSArray? Why not a string [] for the backing data? Just because the method returns a NSArray doesn't mean you have to back it with an NSArray. Yikes. Why would you use an NSArray unless you have to. You don't have to here.
Second, realistically, I always store my index titles in a backing string []. That is normal use I'd say. Why wouldn't you do that anyway? The answers here make it sounds like it's a special case or something where you have to store it. As far as I know you are always responsible for doing that anyway. And another example relying on the cells to get data... Why on earth? If you can't simply use an array then get a clue that your array is out of scope or something.
Also, some people mentioned to not override as you normally would. Ummm... I don't know about that. That completely contradicts all the monotouch code I've seen. I've seen a lot of examples do both and it makes sense. Look at some of the template UIViewController constructors. The internal calls that explicitly reference selectors will need the selector. Normally you wouldn't need one but in this case apparently something internal is broken referencing the selector. That is NOT a reason to ditch overriding it as you normally would. You still need to override it in case you have some external call that came from your own managed code. You should absolutely still override it. Unless you always explicitly referencing selectors in YOUR code... then keep it overriden.
Anyway, a lot of this is my general monotouch understanding and I could be wrong. I mean, I don't know... I'm seriously not trying to criticize. I just had to comment because it looks like to me there is A LOT of bad information in this thread and I'm hoping this post will help someone who might be getting misinformed.