Это плохая идея? - PullRequest
       5

Это плохая идея?

0 голосов
/ 25 февраля 2011

Я работаю над этой проблемой уже два дня.Я работаю над приложением для iPhone, которое на данный момент имеет «двухслойный» вид (см. Рисунок). Полупрозрачная оранжевая панель, покрывающая левую треть экрана, была создана путем простого изменения размера подвид (в IB) занимать менее половины экрана, чтобы при загрузке этого вида исходный вид оставался справа.Это позволило бы левому представлению быть «представлением меню», позволяющим пользователю выбирать, что он или она хотели бы видеть в главном окне просмотра (которое на самом деле представляет собой UIWebView ... см. Снимок экрана.)

----- Нажмите здесь для снимка экрана -----

Если я собираюсь сохранить эту настройку (при условии, что это не структурный грех), слева-вид явно нужен способ общения с основным видом.Могу ли я вызвать методы в файле ".m" основного вида (WebViewController.m), например viewDidLoad и другие, с помощью кнопки "ETG" на оранжевом подпредставлении?Или это просто плохая идея?И если это не плохая идея или грех против структуры iPhone, как бы вы ее реализовали?Я заранее благодарю вас за любые полезные мысли или предложения, которые могут у вас возникнуть.Спасибо!

Ответы [ 4 ]

1 голос
/ 25 февраля 2011

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

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

Опять же, это общие правила, и всегда есть исключения.

0 голосов
/ 05 марта 2011

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

В вашем случае оранжевый слой может публиковать уведомления и контроллердля UIWebView можно слушать их.

Поэтому, когда вы нажимаете кнопку в оранжевом слое, сделайте что-то вроде этого:

[[NSNotificationCenter defaultCenter] postNotificationName:@"etgTapped" object:self];

И в контроллере, который следит за веб-представлением, добавьте что-то подобное в ваш метод viewDidLoad:

[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(etgTapped:) name: @"etgTappe" object:nil];

И затем создайте метод уведомления etgTapped: (NSNotifaction *) в этом классе.

Наконец, в viewDidUnload отмените регистрацию в центре уведомлений:

[[NSNotificationCenter defaultCenter] removeObserver:self];
0 голосов
/ 26 февраля 2011

Умм, а веб-вид является основным?

В любом случае, я бы сделал это:

Один контроллер представления, который содержит две основные области. Один из них - ваш UIWebView, а другой - ваш переход. Если вы сделаете это в Интерфейсном Разработчике, поместите Layover поверх UIWebView.

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

Затем используйте один контроллер вида для обоих.

Рекомендуемый метод связи между контроллерами представления, если он подчинен, - это создание в контроллере представления свойств, которые вы можете передать. Например: веб-представление должно указывать основному виду, на каком сайте он находится. Поэтому поместите строку NSString в ваш главный контроллер как свойство, а затем передайте ему строку в viewWillDisappear или как там это имя.

(Или используйте viewWillAppear на верхнем уровне и заставьте его захватить это свойство из второго представления).

По сути, это просто ветвящееся дерево, и вам нужно передать данные на один узел, чтобы добраться до других.

Вы можете «использовать» сам делегат приложения / (приложение) и откуда угодно, вызвать [UIApplication sharedApplication] .property (после создания свойства) и использовать его как глобальный, но это не считается повторно используемым кодом. Поскольку вы привыкли к базовому, это может сработать для вас.

Наконец, глобальные переменные C ++ работают, и в Интернете есть много примеров использования глобальных переменных в программе iPhone с externs. (еще меньше рекомендуется).

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

Нет, это неплохая идея. Но без понимания слоев, просмотра анимации и дизайна, возможно, так оно и будет, пока вы этого не сделаете.

NazCode

0 голосов
/ 25 февраля 2011

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...