Катастрофический отказ при попытке переместить строки UITableView

Seems like something somewhere is requesting element 6 from an array that only has elements at indexes 0-5 (meaning 6 elements).

This usually happens when the code tries to do:

NSUInteger index = [somearray count];
id obj = [somearray objectAtIndex:index];

because count is upper boundary and arrays start from 0 the last element is at count - 1.

This might not be directly in your code but you may be restricting something to a number of elements and then requesting one past the last element.

Я только что обнаружил ту же проблему в моем приложении.

Ситуация такова, что у меня есть два раздела таблицы. Элементы можно перетаскивать внутри и между разделами. Пользователи могут перетаскивать ячейки в любую строку в первом разделе, но во втором разделе элементы сортируются, поэтому для любой данной ячейки существует только одна допустимая строка.

Если я прокручиваю вид так, чтобы были видны нижняя часть раздела 1 и верх раздела 2, возьмите элемент в разделе 1, который сортируется в конец раздела 2, и перетащите его в верхнюю часть раздела 2, вызывается мой метод tableView: targetIndexPathForMoveFromRowAtIndexPath: toProposedIndexPath: , и я возвращаю правильную позицию назначения, которая находится на несколько строк ниже нижней части экрана. В пользовательском интерфейсе вы можете видеть, что в нижней части экрана создается пустая ячейка, которая не является правильной строкой назначения.

Когда вы отпускаете ячейку, эта фиктивная ячейка, созданная в нижней части экрана (в середине раздела 2), остается там! tableView: cellForRowAtIndexPath: никогда даже не вызывается для этого. Как только вы попытаетесь что-нибудь сделать с этой ячейкой, вы рухнете.

Моим первым решением было просто вызвать [tableView reloadData] в конце tableView: moveRowAtIndexPath: toIndexPath: . Но это вызывает сбой, поэтому вместо этого я вызываю его косвенно после задержки. Но есть еще одна ошибка : после отложенного вызова reloadData tableView: moveRowAtIndexPath: toIndexPath: снова вызывается с поддельным запросом на перемещение элемента за конец первого раздела в та же позиция. Итак, мне пришлось добавить код, чтобы игнорировать поддельные запросы без операции.

Итак, вот код:

- (void)tableView:(UITableView *)tableView moveRowAtIndexPath:(NSIndexPath *)pathSrc toIndexPath:(NSIndexPath *)pathDst
{
  // APPLE_BUG: after doing the delayed table reload (see below), we get a bogus
  // request to move a nonexistant cell to its current location
  if (pathSrc.row == pathDst.row && pathSrc.section == pathDst.section)
    return;

  // update your data model to reflect the move...

  // APPLE_BUG: if you move a cell to a row that's off-screen (because the destination
  // has been modified), the bogus cell gets created and eventually will cause a crash
  [self performSelector:@selector(delayedReloadData:) withObject:tableView afterDelay:0];
}

- (void)delayedReloadData:(UITableView *)tableView
{
  Assert(tableView == self.tableView);
  [tableView reloadData];
}

Обратите внимание, что все еще есть ошибка пользовательского интерфейса. На экране перетаскиваемая ячейка анимируется в фиктивную пустую ячейку. В конце анимации пустая ячейка перерисовывается с правильными данными для этой строки, но наблюдательный пользователь заметит, что перетаскиваемая ячейка анимируется в неправильном месте, а затем мгновенно трансформируется в другую ячейку.

Это определенно тупой интерфейс. Я подумал о том, чтобы прокрутить нужную строку назначения на экране, но если бы я сделал это, он заполнил бы экран вторым разделом, и тогда любая попытка перетащить обратно в первый раздел постоянно мешала бы моей (теперь уже раздражающей) автопрокрутке. Возможно, мне придется изменить пользовательский интерфейс, но это потребует некоторых сложных и утомительных изменений в моей модели данных.