У меня есть UIViewController, который содержит UIScrollView, который содержит как UITableView, так и еще UIScrollView. Внутри вложенного UIScrollView есть еще UITableView (есть способ этого безумия, голый со мной).Большое UITable останавливает приложение до остановки
Когда в ViewDidAppear из UIViewController рассчитать, насколько большой таблицы должны быть (намного больше, чем экран) и установить их размеры, а затем установить размер содержания UIScrollView, чтобы соответствовать таблицам, которые они содержат (UIScrollView обеспечит прокрутка, а не сама таблица). Все это отлично работает в симуляторе, но на самом устройстве он останавливается, привязывая процессор на 100% в течение десятков секунд. Это, очевидно, неприемлемо. Кто-нибудь знает, почему? Или как я могу обойти это?
код выглядит примерно так:
OuterScrollView.ContentSize = new SizeF (View.Frame.Width, tableHeight);
InnerScrollView.ContentSize = new SizeF (InnerTable.Frame.Width, tableHeight);
InnerScrollView.Frame = new RectangleF(InnerScrollView.Frame.Location,
new SizeF(InnerScrollView.Frame.Width, tableHeight));
// So far so good
OuterTable.Frame = new RectangleF(OuterTable.Frame.Location,
new SizeF(OuterTable.Frame.Width, tableHeight)); // this slows everything down!!
InnerTable.Frame = new RectangleF(InnerTable.Frame.Location,
new SizeF(InnerTable.Frame.Width, tableHeight)); // and so does this
Удаление обоих утверждений настройки таблицы .Frame и все работает достаточно быстро, но с ними это очень медленно. И медлительность не приходит прямо здесь, а где-то после звонка на базу ViewDidAppear.
Update: У меня было прозрение и подумал , если изменение размера таблицы является проблемой, просто сделать таблицы достаточно большим, что они не нуждаются в изменении размеров. В настройках, которые у меня есть, прокрутка обрабатывается просмотром прокрутки, а не самой таблицей, поэтому я мог бы просто установить таблицу как действительно большой и позволить прокруткам ContentSize позаботиться об обрезке пустой части таблицы. Это работает в том смысле, что он показывает, как я хочу, но это на самом деле еще медленнее! Поэтому я пришел к выводу, что проблема не в изменении размера таблицы, а в присутствии очень долгого (в этом случае я установил высоту 4000, а размер изменил ее на 2,354).
Фон: Чтобы добавить немного больше к тому, что я пытаюсь сделать. Поскольку Apple в своей мудрости решила, что никто не нуждается в сетке, такой как контроль, я пытаюсь настроить ситуацию, когда у меня есть вид в виде сетки, где левые столбцы остаются на месте, но вы можете горизонтально прокручивать правую часть экрана, большинство столбцов, и при прокрутке по вертикали все будет оставаться в синхронизации. После некоторого поиска я наткнулся на решение (извините, не могу вспомнить, где именно), что с небольшими настройками (в симуляторе). В принципе, вы вставляете таблицы в виде прокрутки, чтобы вид прокрутки мог обрабатывать прокрутку. Раскладка выглядит примерно так:
+-------------------------Outer Scroll-------------------------+
| +---------------Inner Scroll---------------+|
|+--Fixed Table--+ |+---------Scrolling Table----------------+||
|| | || |||
|| | || |||
|| | || |||
|| | || |||
|| | || |||
|| | || |||
|+---------------+ |+----------------------------------------+||
| +------------------------------------------+|
+--------------------------------------------------------------+
Неподвижной таблица имеет собственную ячейку с парой колонн, а в таблице скроллинга имеет другую пользовательскую ячейку (шире, чем экран) с остальными столбцами. Вы можете прокручивать таблицу прокрутки по горизонтали (благодаря внутреннему просмотру прокрутки), и вы можете прокручивать все по вертикали благодаря внешнему виду прокрутки.
Другое обновление: Таким образом, проблема заключается в том, что таблица не повторно использует ячейки при ее установке. Я предполагаю, что логика повторного использования ячеек распространяется только на определение того, находится ли ячейка внутри фрейма таблицы, а не какая-то часть таблицы. Таким образом, с 50 элементами вместо отображения 6-7, а затем повторного использования этих ячеек, он создает все 50 независимо.Поэтому я отказался от моей ранее попытки и попытался синхронизировать скроллинг между двумя таблицами, как это:
OuterTable.Scrolled += (sender, arg) =>
{
InnerTable.ContentOffset = new PointF(InnerTable.ContentOffset.X,
OuterTable.ContentOffset.Y);
};
InnerTable.Scrolled += (sender, arg) =>
{
OuterTable.ContentOffset = new PointF(0, InnerTable.ContentOffset.Y);
};
Это почти работает, за исключение IOS не любит горизонтальную прокрутку для таблиц, так что внутренняя таблица все еще должна быть обернута вид прокрутки (устанавливается с помощью ContentSize, чтобы покрыть ширину, которую мне нужно прокрутить). На данный момент это почти работ. Обычно это будет происходить без сглаживания, но с небольшим количеством беспорядков вы можете получить, например, внутреннюю таблицу для прокрутки по диагонали (несмотря на то, что установка блокировки на всех), и в некоторых случаях можно получить их вне синхронизации , который выглядит действительно глупо. Таким образом, это не совсем так же визуально, но, по крайней мере, оно не повредит поток пользовательского интерфейса так же плохо.
любой шанс, что они перекрываются одним пикселем? Попробуйте помещать пространство между ними. Но в основном это звучит как сумасшедший дизайн пользовательского интерфейса (и обратите внимание на документацию, говорящую о том, чтобы не встраивать объекты UITableView в объекты UIScrollView). – Dad
@Dad: На самом деле выяснилось, что когда я определял высоту представления прокрутки на 'ViewDidLoad', но он был изменен iOS (чтобы принять во внимание панель вкладок внизу) к тому времени, когда он попал в' ViewDidAppear ', поэтому он думал, что он должен быть вертикально прокручиваемым, когда это должно быть. Я просто переместил размер прокрутки в «ViewDidAppear», и теперь он отлично работает, и у меня больше нет проблемы с синхронизацией. –
спасибо за обновление. – Dad