Почему ячейки таблицы просмотра исчезают при перезагрузке с помощью reloadRowsAtIndexPaths?

18

Здесь у меня есть пример с образцом:

Ссылка

В этом проекте UITableView имеет пользовательский UITableViewCell. В каждой ячейке находятся 3 UIViews, содержащие метку.

Цель состоит в том, чтобы развернуть ячейку при нажатии, а затем свернуть ее при повторном нажатии. Сама ячейка должна изменить ее высоту, чтобы открыть подзоны. Вставка или удаление строк неприемлема.

Демо-проект работает почти так, как ожидалось. Фактически, в iOS 4.3 он работает отлично. Однако в iOS 5, когда строки рушится, предыдущие ячейки волшебным образом исчезают.

Чтобы повторно создать проблему, запустите проект в симуляторе или устройстве с помощью iOS 5 и коснитесь первой ячейки, чтобы развернуть ее. Затем снова коснитесь ячейки, чтобы свернуть ее. Наконец, коснитесь ячейки непосредственно под ней. Предыдущее исчезает.

Продолжение прослушивания для каждой ячейки в секции приведет к исчезновению всех ячеек, где отсутствует весь раздел.

Я также пытался использовать reloadData вместо текущей настройки, но это разрушает анимацию и в любом случае немного похож на хак. reloadRowsAtIndexPaths должен работать, но вопрос в том, почему это не так?

Смотрите изображения того, что происходит ниже:

Появится таблица:

Ячейка расширяется:

Клетка разрушается:

Ячейка исчезает (при нажатии на ячейку внизу):

Продолжайте повторять, пока не исчезнет весь раздел:

EDIT: Переопределение альфы - это взлом, но работает. Вот еще один «взлом», который также исправляет его, но ПОЧЕМУ он его исправляет?

JVViewController.m строка 125:

if( previousIndexPath_ != nil )
{
    if( [previousIndexPath_ compare:indexPath] == NSOrderedSame ) currentCellSameAsPreviousCell = YES;

    JVCell *previousCell = (JVCell*)[self cellForIndexPath:previousIndexPath_];

    BOOL expanded = [previousCell expanded];
    if( expanded )
    {
        [previousCell setExpanded:NO];
        [indicesToReload addObject:[previousIndexPath_ copy]];
    }
    else if( currentCellSameAsPreviousCell )
    {
        [previousCell setExpanded:YES];
        [indicesToReload addObject:[previousIndexPath_ copy]];
    }

    //[indicesToReload addObject:[previousIndexPath_ copy]];
}

ИЗМЕНИТЬ 2:

Сделал несколько незначительных изменений в демонстрационном проекте, стоит проверить и рассмотреть метод JVViewController didSelectRowAtIndexPath.

    
задан TigerCoding 10.03.2012 в 20:29
источник
  • Переопределение setAlpha: в JVCell блокировать setAlpha: 0 похоже на обходной путь, и я не вижу никаких негативных побочных эффектов, но это уродливо. Я буду держать себя в курсе, посмотрим, смогу ли я понять, почему он хочет скрыть клетки. –  davehayden 11.03.2012 в 02:42
  • Проверьте мое редактирование. –  TigerCoding 11.03.2012 в 02:53
  • У меня есть пример, похожий на это, и хотите? –  Dhara 20.03.2012 в 12:03
  • Если он делает то же самое, конечно. Он должен иметь изображения для фона и изменять высоту ячейки при ее расширении. Он не может добавлять или удалять ячейки. Он также должен быть анимированным. Вы можете отправить его в ответ и добавить исходный код или ссылку на него. Что делает ваш код по-другому? –  TigerCoding 20.03.2012 в 12:19

12 ответов

20

Ваша проблема в setExpanded: в JVCell.m вы непосредственно редактируете кадр целевой ячейки в этом методе.

- (void)setExpanded:(BOOL)expanded
{
    expanded_ = expanded;

    CGFloat newHeight = heightCollapsed_;
    if( expanded_ ) newHeight = heightExpanded_;

    CGRect frame = self.frame;
    frame.size.height = newHeight;
    self.frame = frame;
}

Обновить его до:

- (void)setExpanded:(BOOL)expanded
{
    expanded_ = expanded;
}

Затем удалите вызов -reloadRowsAtIndexPaths:withRowAnimation: в строке 163 JVViewController.m и он будет оживлять, как ожидалось.

-reloadRowsAtIndexPaths:withRowAnimation: ожидает, что для предоставленных indexPaths будут возвращены разные ячейки. Поскольку вы только регулируете размеры -beginUpdates & amp; -endUpdates достаточно, чтобы снова отобразить ячейки таблицы.

    
ответ дан user349819 21.03.2012 в 20:34
  • В качестве опоры причина, по которой альфа устанавливалась в ноль, состояла в том, что таблица обрабатывала одну ячейку как старую, так и новую ячейку. Поведение табличного представления заключается в постепенном исчезновении старой ячейки с новой ячейкой за ней. Таким образом, его альфа устанавливалась в 1 как «новая» ячейка, но затем исчезла с 1 до нуля как «старая» ячейка. –  Mar 21 '12 at 20:02 21.03.2012 в 21:02
  • +1 - проверено, что это работает в симуляторе как для 4.3, так и для 5.1. –  Scott Marks 21.03.2012 в 21:32
  • Это наиболее полно отвечает всем ответам. Я бы предпочел не заставлять ячейку перезагружаться, если она может просто автоматически изменить ее высоту. Анимации также гладкие. Очень хорошо! Но разве «взломать» использовать beginUpdates и endUpdates? Является ли мой код правильно использующим эти методы? –  TigerCoding 22.03.2012 в 08:04
  • Это не взлом, и это подходящий способ сделать это. Ссылка явно не заявляет об этом, но одна из функций begin / endUpdates заключается в том, что она будет анимирована для нового макета. beginUpdates / endUpdates - единственный метод, который будет вызывать информацию от делегата (где возвращается ваш rowHeight) и анимировать на основе изменений без перезагрузки ячеек. Единственной жизнеспособной альтернативой является вызов reloadData и все анимации из одного состояния в другое, которое я лично избегу. –  Mar 22 '12 at 14:23 22.03.2012 в 15:23
  • Похоже, что ваш ответ наиболее уместен, хотя @Deniz также предоставил способ заставить его работать. Спасибо за вашу помощь в этом, я почти думал, что это не будет разрешено. Теперь мои таблицы выглядят очень красиво. Еще раз спасибо! –  TigerCoding 22.03.2012 в 15:52
7

Возможно, мне не хватает точки, но почему вы просто не используете:

UITableViewRowAnimationNone

Я имею в виду вместо:

[tableView reloadRowsAtIndexPaths:indicesToReload withRowAnimation:UITableViewRowAnimationAutomatic];

использовать

[tableView reloadRowsAtIndexPaths:indicesToReload withRowAnimation:UITableViewRowAnimationNone];
    
ответ дан Deniz Mert Edincik 21.03.2012 в 11:04
  • Думать обо всем этом. Это моя вторая награда за этот вопрос, и я начал думать, что это не будет разрешено. Остается вопрос: ПОЧЕМУ это работает, и следует ли использовать методы начала / конца обновления? Благодаря Deniz –  TigerCoding 21.03.2012 в 14:20
  • Эта проблема исправлена ​​в моем случае. –  Kof 17.04.2013 в 20:49
6

Чтобы оживить изменения высоты таблицы, просто вызовите.

[tableView beginUpdates];
[tableView endUpdates];

Не вызывайте reloadRowsAtIndexPaths:

См. Можете ли вы оживить изменение высоты на UITableViewCell при выборе?

    
ответ дан Collin 21.02.2014 в 00:14
  • Я рад, что прокрутил в нижней части страницы, чтобы увидеть этот ответ :) –  lukas 30.10.2014 в 00:00
  • Можете ли вы объяснить, почему beginupdates должен быть таким? Кроме того, это не объясняет, почему reloadRow заставит ячейку исчезнуть @. @ –  Happiehappie 09.11.2016 в 07:43
  • спасибо, что это сработало для меня, должен быть принятым ответом! –  Vrutin Rathod 09.03.2018 в 10:43
5

Ячейка, которая исчезает, является предыдущей ячейкой, которая не меняет размер. Поскольку в документации reloadRowsAtIndexPaths:withRowAnimation: указано:

  

Таблица оживляет новую ячейку, поскольку она оживляет старую строку.

Что происходит, так это непрозрачность, равная 1, а затем сразу же устанавливается на 0 и поэтому исчезает.

Если и предыдущий, и новый размер изменения ячейки, он работает по назначению. Это происходит из-за того, что обновления для начала / конца уведомляют об изменениях высоты и создают новые анимации на этих ячейках, переопределяя reloadRowsAtIndexPaths:withRowAnimation: .

Ваша проблема связана с злоупотреблением reloadRowsAtIndexPaths:withRowAnimation: , чтобы изменить размер ячеек, когда он предназначен для загрузки новых ячеек.

Но вам вообще не нужно reloadRowsAtIndexPaths:withRowAnimation: . Просто измените расширенное состояние ячеек и сделайте обновления начала / конца. Это будет обрабатывать всю анимацию для вас.

В качестве побочной заметки я обнаружил, что синяя селекция немного раздражает, в JVCell устанавливают selectedBackgroundView на то же изображение, что и backgroundView (или создают новое изображение, которое имеет правильный вид выбранной ячейки).

EDIT:

Переместите оператор, добавив previousIndexPath_ к indicesToReload в оператор if (в строке 132), чтобы он был добавлен только в том случае, если предыдущая ячейка была расширена и ее необходимо изменить.

if( expanded ) {
    [previousCell setExpanded:NO];
    [indicesToReload addObject:[previousIndexPath_ copy]];
}

Это удалит случай, когда предыдущая свернутая ячейка исчезнет.

Другим вариантом было бы установить previousIndexPath_ на nil, когда текущая ячейка будет свернута и только установить ее, когда ячейка расширяется.

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

    
ответ дан Nathan Kinsinger 18.03.2012 в 23:56
  • Я попытался прокомментировать строку # 149 в JVViewController (reloadRowsForIndexPaths), но изменения высоты все еще не плавно анимируются. Обратите внимание, как при нажатии на вторую ячейку предыдущий вид «привязок» на месте? Вы можете увидеть фон в виде таблицы между ячейками на короткое время. Как этого можно избежать? Что касается синего цвета, я согласен и добавил несколько строк кода в JVCell setupImageView, чтобы также установить выбранное фоновое изображение как одно и то же изображение. Это всего лишь демонстрационный проект, который будет использовать разные графики. Загрузите обновленный проект. –  TigerCoding 19.03.2012 в 05:41
  • Я вижу, что вы говорите об анимации центра. Очень странно, что время анимации отличается в зависимости от местоположения в таблице. Я создал больше ячеек в каждом разделе, и все центральные ячейки ведут себя одинаково. Только верхняя и нижняя ячейки оживляют правильно. –  Nathan Kinsinger 19.03.2012 в 05:59
2

Короткий, прагматичный ответ: изменение UITableViewRowAnimationAutomatic до UITableViewRowAnimationTop решает проблему. Больше никаких исчезающих рядов! (тестируется на iOS 5.1)

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

Еще несколько соображений относительно оживления перезагрузки одной и той же ячейки:

UITableViewRowAnimationAutomatic , похоже, в некоторых случаях разрешает UITableViewRowAnimationFade , то есть когда вы видите, что ячейки исчезают и исчезают. Предполагается, что новая ячейка исчезнет, ​​в то время как старый погаснет. Но здесь старая ячейка и новая - одно и то же. Итак, может ли это работать? На уровне Core Animation: возможно ли постепенное исчезновение представления и его постепенное исчезновение? Звучит сомнительно. Таким образом, вы видите, что вы просто исчезаете. Это можно было бы считать ошибкой Apple, поскольку ожидаемое поведение может заключаться в том, что если одно и то же представление изменилось, свойство alpha не будет анимировано (так как оно не может одновременно анимировать 0 и 1 одновременно), но вместо этого будет только анимированный кадр, цвет и т. д.

Обратите внимание, что проблема находится только на дисплее анимации - если вы прокручиваете прочь и обратно, все будет отображаться правильно.

В iOS 4.3 режим Automatic , возможно, был разрешен для чего-то другого, кроме Fade , поэтому все работает там (как вы их пишете) - я не вникал в это.

Я не знаю, почему iOS выбирает режим Fade , когда он это делает. Но один из случаев, когда он делает , когда ваш код запрашивает перезагрузку ранее обработанной ячейки, которая сбрасывается, и отличается от текущей задействованной ячейки. Обратите внимание, что ранее перехваченная ячейка всегда перезагружается, эта строка в вашем коде всегда называется:

[indicesToReload addObject:[previousIndexPath_ copy]];

Это объясняет описанный вами сценарий исчезновения скрытых объектов.

Кстати, beginUpdates / endUpdates кажутся мне взломанным. Предполагается, что эта пара вызовов содержит анимации, и нет никаких анимаций, которые вы добавляете в дополнение к строкам, которые вы уже просили перезагрузить. Все, что было сделано в этом случае, вызвало магический повод для того, чтобы режим Automatic не выбирал Fade в некоторых случаях. Но это просто затмило проблему.

Последнее замечание: я играл в режиме Top и обнаружил, что он также может вызвать проблемы. Например, включение следующего кода приводит к тому, что ячейки исчезают funkily:

- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath
{
    [tableView reloadRowsAtIndexPaths:[NSArray arrayWithObject:indexPath] withRowAnimation:UITableViewRowAnimationTop];
}

Не уверен, что здесь есть реальная проблема (аналогичная той, которая затухает в одном и том же виде одновременно) или, может быть, ошибка Apple.

    
ответ дан Danra 17.03.2012 в 02:03
  • Спасибо за попытку, но я также попробовал «Топ» раньше с теми же результатами. Сначала это работало, но потом я играл с ним, и я обнаружил, что у него есть свои проблемы. Я также согласен, что начальные / конечные обновления - это взлом, но я могу заставить его работать. Я просто хотел бы знать, почему он не работает или это действительно ошибка. Я также опубликовал отчет об ошибке с Apple, но я не знаю, действительно ли это ошибка. Все еще жду, чтобы услышать от них. –  TigerCoding 17.03.2012 в 15:01
  • @Javy Обновленный ответ с другим вариантом решения - использование другой ячейки при смене кадра. Кстати, вы написали, что вас не интересует вызов -reloadData, но ваш -heightForRowAtIndexPath: метод вызывается каждый раз, когда tableView перерисовывается для всех ячеек, а в вашей реализации это вызывает -cellForRowAtIndexPath :. Таким образом, все ячейки повторно извлекаются, что, я думаю, является основной частью того, что reloadData делает в любом случае. –  Danra 17.03.2012 в 15:24
  • Если вы попытаетесь перезагрузить его, он убьет анимацию. Попробуйте. Ячейки видят «привязку» на место вместо оживления. «используя другую ячейку при изменении рамки». Не могли бы вы уточнить больше? Я не видел изменений в тексте ответа. –  TigerCoding 17.03.2012 в 15:39
  • «Еще один короткий, прагматичный ответ, поскольку, как говорят, UITableViewRowAnimationTop вызывает свои проблемы: создайте новый вид ячеек вместо изменения существующего фрейма. В реальном приложении данные, отображаемые в представлении соты, должны находиться в Модельная часть приложения в любом случае, поэтому, если правильно спроектировать, не должно возникнуть проблемы с созданием другого представления ячейки, которое отображает одни и те же данные только по-другому (в нашем случае это кадр). " –  Danra 17.03.2012 в 15:43
  • Хммм, это может сработать, но приложение не должно этого делать. Это все еще вроде хак, например, настройка альфы или использование обновлений / окончаний. Решение этой проблемы не может быть проблемой, если на самом деле это ошибка в SDK. –  TigerCoding 17.03.2012 в 15:51
Показать остальные комментарии
1

Я только что загрузил ваш проект & amp; нашел этот раздел кода в didSelectRowAtIndexPath delegate, где используется reloadRowsAtIndexPaths .

[tableView reloadRowsAtIndexPaths:indicesToReload withRowAnimation:UITableViewRowAnimationAutomatic];
[tableView beginUpdates];
[tableView endUpdates];

вместо вышеизложенного, почему бы вам не попробовать это?

[tableView beginUpdates];
[tableView reloadRowsAtIndexPaths:indicesToReload withRowAnimation:UITableViewRowAnimationAutomatic];
[tableView endUpdates];

Я предполагаю, что я считаю, что reloadRowsAtIndexPaths:... работает только при завершении между вызовами:

- (void)beginUpdates;
- (void)endUpdates;

Вне этого поведение не определено и, как вы обнаружили, довольно ненадежное. Цитирование соответствующей части « Руководство по программированию таблиц для iPhone OS ":

  

Чтобы анимировать пакетную вставку и удаление строк и разделов, вызовите методы вставки и удаления внутри блока анимации, определенные последовательными вызовами beginUpdates и endUpdates. Если вы не вызываете методы вставки и удаления в этом блоке, индексы строк и секций могут быть недействительными. beginUpdates ... endUpdates блоки не являются вложенными.

     

В конце блока, то есть после возврата endUpdates - представление таблицы запрашивает свой источник данных и делегирует, как обычно, данные строки и раздела. Таким образом, объекты коллекции, поддерживающие представление таблицы, должны обновляться, чтобы отражать новые или удаленные строки или разделы.

     

ReloadSections: withRowAnimation: и reloadRowsAtIndexPaths: withRowAnimation: методы, которые были представлены в iPhone OS 3.0, связаны с описанными выше методами. Они позволяют запрашивать представление таблицы для перезагрузки данных для определенных разделов и строк вместо загрузки всего видимого вида таблицы путем вызова reloadData.

Там может быть и другая веская причина, но позвольте мне немного подумать об этом, так как у меня тоже есть код, я мог бы с этим справиться. Надеюсь, мы должны это выяснить ...

    
ответ дан Srikar Appalaraju 16.03.2012 в 04:31
  • Если вы поместите beginUpdates перед reloadRowsAtIndexPaths, ячейки сразу исчезают при нажатии. Размещение его после работы reloadRowsAtIndexPaths. Попробуйте тестовый проект и посмотрите, что произойдет. Что касается документов Apple, «Чтобы оживить пакетную вставку и удаление строк и разделов ...» Я не вставляю и не удаляю строки или разделы, я просто меняю высоту ячеек, не более того. Я использую reload, поэтому он знает, чтобы проверить их высоту, так как он изменился. ;) –  TigerCoding 16.03.2012 в 04:47
  • круто, позвольте мне сохранить этот ответ как есть. Попробуем кое-что и вернемся к вам на этом ... –  Srikar Appalaraju 16.03.2012 в 04:50
1

Когда вы используете этот метод, вы должны быть уверены, что находитесь в основном потоке. Обновление UITableViewCell следующим образом должно сделать трюк:

- (void) refreshTableViewCell:(NSNumber *)row
{
    if (![[NSThread currentThread] isMainThread])
    {
        [self performSelector:_cmd onThread:[NSThread mainThread]  withObject:row waitUntilDone:NO];
        return;
    }

    /*Refresh your cell here
     ...
     */

}
    
ответ дан Matthias 12.07.2013 в 11:25
0

@Javy, я заметил некоторое странное поведение при тестировании вашего приложения.

Во время работы на симуляторе iPhone 5.0 переменная previousIndexpth_ имеет класс NSArray (это похоже.) вот вывод отладчика

(lldb) po previousIndexPath_ (NSIndexPath *) $ 5 = 0x06a67bf0 & lt; __ NSArrayI 0x6a67bf0 & gt; (

,

,

)

(lldb) po [previousIndexPath_ class]

(id) $ 7 = 0x0145cb64 __NSArrayI

В то время как в симуляторе iPhone 4.3 он имеет тип NSIndexPath.

lldb) po [previousIndexPath_ class]

(id) $ 5 = 0x009605c8 NSIndexPath

(lldb) po previousIndexPath _

(NSIndexPath *) $ 6 = 0x04b5a570 2 индекса [0, 0]

Знаете ли вы об этой проблеме? Не уверен, поможет ли это, но подумает о том, чтобы сообщить вам.

    
ответ дан apalvai 16.03.2012 в 07:38
0

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

- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath
{
BOOL currentCellSameAsPreviousCell = NO;
NSMutableArray *indicesToReload = [NSMutableArray array];

if(previousIndexPath_ != nil)
{
    if( [previousIndexPath_ compare:indexPath] == NSOrderedSame ) currentCellSameAsPreviousCell = YES;

    JVCell *previousCell = (JVCell*)[self cellForIndexPath:previousIndexPath_];

    BOOL expanded = [previousCell expanded];
    if(expanded) 
    {
     [previousCell setExpanded:NO];
    }
    else if  (currentCellSameAsPreviousCell)
    {
        [previousCell setExpanded:YES];
    }
    [indicesToReload addObject:[previousIndexPath_ copy]];

    if (expanded)
        previousIndexPath_ = nil;
    else
        previousIndexPath_ = [indexPath copy];         
}

if(currentCellSameAsPreviousCell == NO)
{
    JVCell *currentCell = (JVCell*)[self cellForIndexPath:indexPath];

    BOOL expanded = [currentCell expanded];
    if(expanded) 
    {
        [currentCell setExpanded:NO];
        previousIndexPath_ = nil;
    }

    else
    {
        [currentCell setExpanded:YES];
        previousIndexPath_ = [indexPath copy];
    }

    // moving this line to inside the if statement blocks above instead of outside the loop works, but why?
    [indicesToReload addObject:[indexPath copy]];


}

// commenting out this line makes the animations work, but the table view background is visible between the cells

[tableView reloadRowsAtIndexPaths:indicesToReload withRowAnimation:UITableViewRowAnimationAutomatic];

// using reloadData completely ruins the animations
[tableView beginUpdates];

 [tableView endUpdates];
}
    
ответ дан vishy 22.03.2012 в 07:34
  • Если вы запускаете эту демонстрацию с изменением кода, анимация привязывается вместо плавного перехода, а части фона видны между ячейками. –  TigerCoding 22.03.2012 в 08:02
  • это происходит в устройстве, я пробовал в симуляторе работать нормально .. –  vishy 22.03.2012 в 08:54
  • Да, я просто попробовал свои изменения кода, прежде чем опубликовать последний комментарий. Обратите внимание, что в симуляторе пространство между некоторыми ячейками одновременно не оживляется, и вы можете видеть фон между ними. Это выглядит довольно плохо. @Saltymule имеет хороший ответ выше, который только изменяет размеры ячеек, а не перезагружает их, что очень хорошо работает. –  TigerCoding 22.03.2012 в 09:17
0

Эта проблема вызвана возвратом кэшированных ячеек в cellForRowAtIndexPath. ReloadRowsAtIndexPaths ожидает получить новые новые ячейки от cellForRowAtIndexPath. Если вы сделаете это, вы будете в порядке ... никаких обходных решений не требуется.

Из документа Apple: «Перезагрузка строки заставляет представление таблицы запрашивать свой источник данных для новой ячейки для этой строки».

    
ответ дан Dan Mardale 12.11.2012 в 17:06
0

У меня была аналогичная проблема, когда я хотел развернуть ячейку, когда переключатель активирован, чтобы отобразить, и дополнительную метку и кнопку в ячейке, которая обычно скрыта, когда ячейка имеет высоту по умолчанию (44). Я пробовал разные версии reloadRowsAtPath безрезультатно. Наконец, я решил сохранить его проще, добавив условие на heightForRowAtIndexPath так:

    override func tableView(tableView: UITableView,heightForRowAtIndexPath indexPath: NSIndexPath) -> CGFloat {
    if ( indexPath.row == 2){
        resetIndexPath.append(indexPath)
        if resetPassword.on {
            // whatever height you want to set the row to
            return 125
        }
    }
    return 44
}

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

        @IBAction func resetPasswordSwitch(sender: AnyObject) {

        tableView.reloadData()
        }

С этим подходом нет отставания, нет видимого способа увидеть, что таблица перезагружена, а расширение продажи происходит постепенно, как и следовало ожидать. Надеюсь, это поможет кому-то.

    
ответ дан Vrezh Gulyan 20.08.2016 в 00:05
-1

Попробуйте эту надежду, это поможет u Расширение ячеек

    
ответ дан Dhara 20.03.2012 в 12:39
  • Это не относится к проблеме. Он вставляет и удаляет строки. Строки для динамического изменения их высот. –  TigerCoding 20.03.2012 в 16:17
  • @Javy он не удаляет его, просто проверяя, является ли строка открытой, если она открыта, тогда она вернет число строк> 0 else. ok np. –  Dhara 21.03.2012 в 06:02
  • В интересах справедливости я еще раз взглянул на ссылку выше, но он не показывает анимированные изображения, что является большой частью этой проблемы. Я ценю вашу помощь, поэтому, пожалуйста, не принимайте это неправильно. Спасибо, Дхара. –  TigerCoding 22.03.2012 в 15:52
  • @Javy приветствую его в порядке. –  Dhara 23.03.2012 в 08:08