Веб-подобные вкладки для iPhone - PullRequest
6 голосов
/ 16 декабря 2009

Каков наилучший подход для реализации вкладок, которые выглядят как веб-приложения на iPhone, как на скриншоте ниже (обратите внимание на вкладки «Checkin-Info-Friends»)? Они не являются частью стандартной библиотеки UIKit, но, похоже, в последнее время очень распространены.

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

  • создать новый UIView для каждого содержимого вкладки и сразу добавить три подпредставления в основное представление?
  • создавать новые UIViews только тогда, когда пользователь нажимает на каждую из вкладок?
  • Поместить все содержимое в UIScrollView и просто изменить страницу, когда пользователь нажимает на каждую вкладку?

Может быть, для этого есть средства с открытым исходным кодом? Я ничего не смог найти.

alt text
(источник: foursquaregame.com )

Ответы [ 4 ]

3 голосов
/ 16 декабря 2009

Мой подход к подобной проблеме состоял в том, чтобы сделать все 4 (в моем случае) представления вкладок, но ответить на didReceiveMemoryWarning, освободив все, кроме текущего представления вкладок. (Тогда, конечно, вы должны убедиться, что создаете новое представление, если оно не существует, когда пользователь выбирает новую вкладку.)

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

1 голос
/ 17 декабря 2009

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

Для самих вкладок рассмотрим подклассы UISegmentedControl.

1 голос
/ 17 декабря 2009

Каждая вкладка может быть реальным контроллером представления с пером и всем. Единственный улов заключается в том, что вы должны перенаправлять вызовы стандартного контроллера представления, которые вы хотите получать (viewWillAppear и т. Д.), Но это делает кодирование намного чище, поскольку вы кодируете так же, как и для любого другого представления (хотя и для меньшего пространства).

Вы вызываете свойство «view» каждого контроллера, чтобы получить представление, которое вы добавляете в качестве подпредставления представления контейнера, которое имеется на вкладках.

1 голос
/ 16 декабря 2009

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

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

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

Правильно ли это сделать? Есть ли какие-то дополнительные детали, которые мне не хватает?

...