Организация Xcode 4, Представления и Контроллеры

Question

Спасибо, что прочитали это.

Это мои первые шаги в программировании приложения для iPhone Ipad. Чтобы учиться с нуля (и поскольку я знаю, что моему приложению потребуются динамические представления), я решил не использовать Interface Builder.

Мой вопрос (относительно того, что я не использую IB): как можно использовать Views и Controllers?

Мне кажется, я понимаю концепцию MVC, поскольку она повторяется снова и снова в учебных пособиях, которым я следую, но после части «Объяснение MVC» ничего не сделано, чтобы прояснить ее «на месте» и приблизиться к реальной ситуации. мир (Земля, являющаяся Xcode здесь). Хуже того, иногда кажется, что некоторые учебники смешивают эти две концепции и используют одно слово, чтобы сказать другое.

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

Для того, что, я думаю, я понял, UIView - это статическое представление, когда контроллер представления - это логика, которая связывает представление с данными, и эти три понятия должны быть разделены. Это разделение, хотя и немного более понятное с использованием Interface Builder, кажется довольно размытым, когда вы кодируете все, что становится виртуальным супом.

Технически, я должен создать определенный файл ".h" и ".m" для каждого Представления И ТАКЖЕ для каждого связанного Контроллера? Если я понимаю шаблон MVC, кажется, что мне следует это сделать, но когда я следую учебным пособиям (без IB), это никогда не происходит, и представления и контроллеры создаются и управляются в одних и тех же файлах реализации.

Какой-нибудь высокий уровень (я нуб, не забывай), но все еще применимое объяснение использования и лучших практик?

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

• xxxappDelegate.h
• xxxappDelegate.m
• xxxView.h
• xxxView.m

Что еще?

1) Куда мне поместить второе представление (вместе с первым в «xxxView» или я должен создать другой файл класса h и m?)?

2) Что будут делать контроллеры для такого рода приложений? В каких файлах они будут создаваться и в каких файлах они будут вызываться и как они «контролируют» связанный вид?

3) В основном, относительно шаблона MVC и того факта, что не было бы IB, как бы вы организовали это приложение?

Я знаю, что это много, если вы вдаваетесь в детали и код, но здесь дело не в этом.

Спасибо. Это - как бы просто это ни казалось - очень помогло бы и не так легко найти в уроках, как вы думаете. Я понимаю учебники, которые я прочитал, но они такие особенные. Как только я пытаюсь создать что-то свое, не являющееся экраном «Hello World», я понимаю, что чего-то не хватает, по логике.

Большое спасибо за вашу помощь.

Answer 1

Извините, но я не могу пройти ваш первый абзац. Если вы не используете Interface Builder, вы не станете успешным программистом iOS. Это так просто. Лучший совет, который я когда-либо читал об этом, - в этом интервью Аарона Хиллегаса :

Опытные программисты Какао поместили много смысла своего приложения в файл NIB. В результате их проект имеет намного меньше кода. Программисты, которые провели несколько лет, работая в Visual Studio, приходят в ужас. Они спрашивают меня что-то вроде: «Могу ли я писать приложения для какао без использования Interface Builder? Мне нравится видеть код. Может быть, я могу просто явно создать свои окна и представления, которые идут по нему?»

Трудно объяснить, как файл NIB (и несколько других страшных идей) создают рычаги. Это тот рычаг, который позволяет одному парню в его подвале конкурировать с командой инженеров в Microsoft или Adobe. Как будто я показал цепную пилу раннему американскому колонизатору, и он сказал: «Могу ли я срубить дерево, не запуская двигатель? Мне не нравится шум. Может, я могу просто ударить его об дерево?»

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

Answer 2

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

Для облегченной конфигурации представлений, что часто делается в методе viewDontLoad viewController (или, я полагаю, в вашем случае loadView).

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

Поскольку вы только начинаете, я бы начал с использования ARC и IB - хотя я уверен, что вы устали слышать это от всех, я дам вам альтернативный вариант. Меньше кода означает меньше ошибок. И тот факт, что так много опытных разработчиков говорят вам использовать его, должен быть гигантским ключом к пониманию того, каков продуктивный путь вперед. Я имею в виду, вы делаете это, чтобы создавать приложения или изучать каждый уголок класса UIView?

Чтобы поговорить с примером кода, вам не нужен пользовательский класс UIView. Просто создайте, используя основной вид UIViewController в качестве контейнера, поместите UIView внутри с фоном, установленным на красный. При смахивании (с помощью распознавателя жестов, прикрепленного к представлению контейнера) вызовите метод UIVew, чтобы заменить новый зеленый фон UIView на существующее красное представление, вы даже можете определить стиль перехода.

Или создайте представление прокрутки в представлении контейнера, настройте красное и зеленое представление внутри представления прокрутки, установите размер содержимого и включите подкачку на представлении прокрутки.

Или создайте пользовательский класс UIView, как вы это делали, слушайте сенсорные события и медленно настраивайте две позиции подпредставления, чтобы следовать за действием перетаскивания.

Или используйте вид с поддержкой OpenGL и на основе распознавателя жестов панорамируйте сцену, которую вы наблюдаете, двумя треугольниками для зеленого прямоугольника и двумя треугольниками для красного прямоугольника.

Answer 3

Ранним:

Для того, чтобы учиться с нуля (и потому что я знаю, что моему приложению понадобится динамические просмотры), я решил не использовать Interface Builder.

Позже:

Как только я пытаюсь создать что-то самостоятельно, что не Мир "экрана, я понимаю, что чего-то не хватает, логика мудрая.

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

В собственной документации Apple они обсуждают тот факт, что иногда полезно иметь объединенные роли - контроллеры моделей и контроллеры представлений - и это стоит прочитать, поскольку это может объяснить некоторые примеры кода, которые вы ' повторное рассмотрение. Но мой главный совет: прежде чем предполагать, что вы знаете лучше, чем люди, создавшие инструменты, попытайтесь использовать их так, как они рекомендуют. Это может быть откровением.

Дополнения позже: ОК, чтобы попытаться ответить на ваши вопросы ...

1) Куда мне поместить второй вид (вместе с первым в "xxxView" или я должен создать другой файл класса h и m?)?

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

2) Что будут делать контроллеры для такого рода приложений? В какие файлы они будут созданы и в каких файлах они будут вызывается и как они "контролируют" связанный вид?

Был бы контроллер представления, который реализовывал бы поддержку жестов и предоставлял бы метод для изменения цвета элемента в представлении между синим и красным, когда этот жест смахивания был успешно принят. Я хотел бы иметь ViewController.h и ViewController.m. Я думаю, что если бы вы реализовывали View полностью в коде, он был бы реализован в ViewController.m, а не в отдельном View.m. (Если бы вы использовали IB, у вас были бы ViewController.h, ViewController.m и ViewController.xib, причем последний обеспечивает базовую настройку элементов и слоев вида.)

Вы должны создать экземпляр ViewController в своем AppDelegate.

3) Главным образом, относительно схемы MVC и того факта, что нет IB, как бы вы организовали это приложение?

Как указано выше.

Answer 4

Если вы действительно настаиваете на том, чтобы обходиться без IB (и я согласен на 100% с SSteve), то в дополнение к перечисленным файлам вы также захотите использовать UIViewController.Теперь важно знать, что вам нужно создавать заголовочные файлы и файлы реализации только тогда, когда вы добавляете или изменяете поведение по умолчанию.

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

Вы бы создали экземпляр контроллера представления в делегате (в данном случае в любом случае) и создали бы представление в методе loadView контроллера представления.Это необходимо, так как вы не будете использовать IB.

Лично я считаю, что IB отлично справляется с поощрением правильных паттернов MVC, и если вы только начинаете, то вам следует использовать IB.