Чувствительное поведение UITableViewController после появления регулятора вида

У моего UITableView есть куча многоразовых ячеек, и когда я нажимаю на один из них, он переносит меня на другой контроллер вида (через push segue), показывающий детали этой ячейки (скажем, это элемент, поэтому он будет показывать подробности об элементе - имени, цене, изображении и т. д.). Когда я выхожу из этого контроллера просмотра (нажав кнопку «Назад»), UITableView имеет странное поведение:Чувствительное поведение UITableViewController после появления регулятора вида

a) если он прокручивается до конца, он будет автоматически прокручиваться (около 50 точек), оставив последнюю клетку едва заметной, поэтому мне нужно снова прокрутить назад. Моя ячейка имеет 60 точек для высоты.

b) Полоса прокрутки всегда показывает, а затем исчезает, указывая на то, что что-то движется, что UITableView (хотя, если не прокручивать снизу, содержимое не будет перемещаться автоматически).

Это происходит в нескольких UITableView в моем приложении. Я не заставляю перезагружать представление таблицы в viewWillAppear, поэтому я не понимаю, что происходит. Мое содержимое статично после загрузки с сервера (если пользователь не изменит его, а затем перезагрузится). Но просто показывая детали элемента и выскакивая, что VC ничего не меняет в представлении таблицы.

Редактировать: Хорошо, я понял, в чем проблема: я скрываю UIToolbar при нажатии этого сегмента. Если я держу его всегда видимым (чего я не хочу), он по-прежнему показывает анимацию прокрутки при появлении в моем представлении таблицы, но не прокручивает представление таблицы, если в последних нескольких строках.

источник

2013-07-12 swiftcode

Мне удалось исправить первый выпуск. Похоже, что табличное представление не учитывает 44 точки UIToolbar.

Сохранить в Tableview смещения в prepareForSegue: (сохранить его в CGPoint собственности)

self.tableViewScrollOffset = self.tableView.contentOffset;

Тогда, в viewWillAppear:, проверьте, если он был изменен. Если да, восстановите его.

if(self.tableView.contentOffset.y != self.tableViewScrollOffset.y) { 
     [self.tableView setContentOffset:self.tableViewScrollOffset]; 
     self.tableViewScrollOffset = CGPointZero; 
    }

источник

2013-07-12 16:14:35 swiftcode

Не могли бы вы объяснить более подробно, почему это происходит? Или может кто-то. – Krtko

Его удивительная ... решена аналогичная проблема ... Проблема в том, что всякий раз, когда вы переходите назад с viewcontroller, смещение прокрутки таблицы меняется соответственно. Поэтому вам нужно зафиксировать значение contentoffset в свойстве внутри метода prePareForSegue: (то есть перед навигацией), а затем проверить, что в том же классе внутри viewWillAppear: method. И если он изменился, установите значение свойства scrolloffset в ноль –

Просто догадайтесь, у вас есть мошенник scrollToRowAtIndexPath:atScrollPosition:animated висит вокруг?

источник

2013-07-12 15:16:29

Неа, я искал весь мой проект для этого в Xcode и ни строки кода не всплывал. – swiftcode

Я обновил свою проблему с некоторой дополнительной информацией. – swiftcode

Добавить следующее для просмотраDidLoad.

self.automaticallyAdjustsScrollViewInsets = NO;

Это решило мою проблему с просмотром таблицы вниз после навигации назад для просмотра контроллера.

источник

2015-03-02 05:09:14 Prasad

Такое поведение действительно является ошибкой в iOS 8.x.

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

Один из способов решения этой проблемы можно найти здесь: UITableView layout messing up on push segue and return. (iOS 8, Xcode beta 5, Swift) (так что этот вопрос является даже дубликатом этого).

Однако решение при условии наличия излишества, и есть определенные ситуации, почему это кэширование утратит (например, устройство UIContentSizeCategoryDidChangeNotification не считаются)

Но есть довольно простое решение, даже если это странно:

Если вы используете руководство performSequeWithIdentifier в didSelectRowAtIndexPath, просто добавьте [self.tableView reloadData] как раз перед этим.

Если вы используете коробку IB из ячейки, просто добавьте [self.tableView reloadData] в свой код prepareForSeque.

Причина, по которой это решает проблему, заключается в том, что это заставит iOS переоценить видимые ячейки и, следовательно, больше не будет прокручивать содержимое в другое место. К счастью, tableView reloadData здесь не стоит слишком дорого, так как только видимые ячейки будут переоценены.

источник

2015-03-21 11:03:07 Marcus

Я также столкнулся с этой проблемой. Мне удалось это выяснить. Причиной в моем случае является высота заголовка tableview, вычисляющий текст на основе, а высота текста отрицательна, из-за чего табличное представление смещалось вниз, даже если contentinset и scrollinset равны нулю.

Это произошло только в первый раз. В следующий раз он вычисляет правильно. Одна вещь, которую я нашел, - это то, что когда класс А (имеющий табличное представление) вытолкнул другой класс B из init. Когда открывается клавиатура из класса B, вызывается вызов классаDidLoad класса A. и до того, как класс B будет выгружен из навигационного контроллера. Tableview перезагружается для класса A.

источник

2016-02-05 14:59:34 GDSM

Настройка автоматическогоAdjustsScrollViewInsets, как предложено выше, не работает, так как кэширование и настройка tableViewScrollOffset не выполняются.

Следовательно, появился обходной путь, который работал как шарм для меня.

Обходной путь состоял в том, чтобы добавить Dummy UIView, который имеет высоту 1 пиксель и ширину 320 пикселей, и поместить его между «Руководством по верхнему макету» и UITableView. Фон этого представления можно установить так, чтобы он был невидим.

Теперь, используя Autolayouts, исправьте верхнюю часть Dummy View сверху. Теперь установите верхнее ограничение tableview в отношении Dummy View. Установлено, что это решило проблему неправильного использования таблицы.

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

источник

2017-10-24 13:29:17 Marimuthu

Чувствительное поведение UITableViewController после появления регулятора вида

ответ

Смежные вопросы