Какие есть best practice для проектов под iPhone?

Question

[mozilla9]

3+ месяца занимаюсь разработкой под ios. До этого разработка на Java.

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

1) Зависимость от сториборд, ручное проставление свойств элементов UI. Если два похожих экрана - то двойная работа и т.д.

Как пытаюсь решать:
- если экран не простейший (вью + пара кнопок) и позволяет ui, то стараюсь делать на таблице.
Привлекает следующее: Повторное использование ячеек - проставляю класс, накидываю и связываю элементы, всю кастомизацию выношу в методы для инициализации.

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

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

2) Использование нотификации [NSNotificationCenter defaultCenter] для связи между экранами (отправка каких-то эвентов).
Насколько это оправдано? Если по-хорошему нужно использовать паттерн делегат, но до нужного экрана ссылку на делегат приходится передавать по цепочке экранов или нужный экран лежит в массиве навиг-контроллера.
Коллега по проекту в таких случаях использует нотификации. Меня напрягает в этом код лапша. Перед закрытием, экран посылает куда-то нотификацию и чтобы понять логику, нужно искать экраны которые на эти нотификации подписаны.

3) Организация проекта
- нормально ли, если связанные файлы как в java выделяются в отдельные каталоги. Или просто в x-code создавать виртуальные каталоги (refs), а реально все файлы складывать в одну папку.
- именование классов контроллеров. ContactsEditorViewController vs ContactsEditor.

4) Локализация
- есть ощущение, что NSLocalizedString - самый правильный метод для локализации. Попробовал локализацию через сториборд...но что-то не то.

В общем, после Java ощущение, что в разработке под ios очень много ручного труда.
Подскажите как его можно уменьшить.
Как более правильно организовать структуру проекта.

Answer 1

[Ан]

1) Уже обсуждали эту тему. Считаю, что полный отказ от стори боарда - глупостью. Стори боард существенно упрощает жизнь при проектировании интерфейсов, особенно когда Вы поддерживаете весь спектр девайсов (ретина/не ретина, ios 6/7, ipad/iphone/iphone 4").
К примеру, у вас есть кнопка, которая повторяется на куче экранов. Объявляете класс XXXButton, унаследованный от UIButton. В нем реализуете метод
-(void) setupButton, где тем же кодом прописываете все нужные изменения (шрифт, цвет, бэкграунд)
Далее переопределяете метод -(void)awakeFromNib или метод -(id)initWithCoder и вызываете в нем метод setupButton.
В storyboarde добавляете обычную кнопку, но изменяете ей тип с UIButton на XXXButton. Аналогично для других элементов UI. Получаете эдакий кривоватый аналог css+html.
Еще есть вариант выноса кнопки в отдельный xib и загрузки ее от туда. Но от этого может очень упасть производительность.
Ну и да, иногда использование storyboardov действительно не оправдано...

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

2)stackoverflow.com/questions/5210535/passing-data-b... . Посмотртите ближе к концу ответ, отмеченный как правильный. NotificationCenter не самое лучшее решение. Более того, отсылая нотификацию нельзя быть уверенным, что ее вообще кто-то получит. Да мало ли там что на том конце провода, а если получатель ViewController еще не создан на момент отсылки нотификации?

3)

- нормально ли, если связанные файлы как в java выделяются в отдельные каталоги. Или просто в x-code создавать виртуальные каталоги (refs), а реально все файлы складывать в одну папку.

Мне кажется лучше первый вариант. Потому как с проектом можно взаимодействовать не только через xcode

- именование классов контроллеров. ContactsEditorViewController vs ContactsEditor.

Лучше указывать что это конкретно ViewController, и да, не забывайте о префиксах. А еще очень рекомендую заглянуть на developer.apple.com. Там есть несколько статей о соглашениях по именованию классов, методов и т.п. Некоторые фичи без "правильных" имен могут сломаться (kvo , arc)
Да и всегда можно почитать рекомендации от того же гугла...

4) Локализация
Это разные инструменты для разных целей. NSLocalizedString используется когда вам нужно перевести текст интерфейса. Storyboard localize - когда Вам нужно переделать интерфейс. Что бы Вам было понятней, представьте, что делается приложение ориентированное только на западного пользователя. NSLocalizedString хватит с головой, была кнопка Home, стала Домой :).
А вот если Вы захотите продавать приложение где-то на востоке, то тут окажется, что есть иероглифы, написание справа на лево/сверху вниз. Да и вообще, не умеют они думать квадратно гнездовым способом, им подавай абсолютно другой интерфейс.

Answer 2

[Alexander]

1 Нужно отказаться от storyboard, она была сделана для дизайнеров-программистов, имхо. Обычно, проект стилистически един, одинаковые поля ввода, одинаковые кнопки, отличаются только позиции, ну и всякие мелочи. В таких случаях создаю класс с статическими методами, которым передаешь CGRect и NSString, а они тебе кнопку или лабел например.
2 Нотификацию обычно используют, когда нужно оповестить несколько классов, например о загрузке данных. Для остального есть делегат и синглтон
3 Тут кому как больше нравиться, я раскладываю все по каталогам и создаю refs с иакими же именами. Именую так - RootVC, UserView, UserItem
4 Отказавшись от сториборда, использую только NSLocalizedString

Answer 3

[mozilla9]

Т.е. в сториборд только создавать контроллер - привязывать основные компоненты (таблица или скроллвью) и дальше уже в коде добавлять другие компоненты?

Ведь совсем от сториборда не уйти? Оутлеты проставлять и подобное.

Comments

[Alexander]

@mozilla9 можно полностью от него отказаться. И уйдет проблема с аутлетами. Вообще множество проблем уйдут.

[mozilla9]

А вы сами в каком стиле пишете? Полностью ушли от сториборда?

[Alexander]

@mozilla9 когда я начинал, сторибоарда не было, была куча xib'ов. От них я довольно быстро отказался.

[mozilla9]

@alexyat Спасибо

Буду уходить от сториборда.

[grigorov]

писал приложение, без xib и storeboarda, приложение тяжело писать, но кода меньше, чем с ними. да и предсказуемо всё.
Сейчас проблема с тем, что когда писал приложение, было iOS 5.1, под iOS 6.x работает норм, а вот если собрать исходники под iOS 7, то графика и размеры едут.