Подкласс UIViewController или создать пользовательский NSObject, если представление не является полноэкранным

Мне нужно создать контроллер класса для управления поведением пользовательского представления, которое я создал. Стандартный подход заключается в подклассе UIViewController, но в моем случае я вместо этого решил подклассифицировать NSObject по существу по трем причинам:

  • мое представление должно быть добавлено в виде небольшого подсмотра главного контроллера представления (он не будет отображаться с использованием чего-то вроде presentModalViewController или pushViewController …), и он не требует какой-либо панели инструментов или навигационного элемента управления внутри нее
  • Скорее всего, моему контроллеру не нужно будет уведомлять об ориентации устройства, потому что его представление всегда будет использоваться в портретном формате, поэтому мне не интересно получать обычные сообщения о ротации: willRotateToInterfaceOrientation и т. Д.
  • Мне нужно, чтобы этот класс был как можно более легким, чтобы минимизировать потребление памяти. Не подклассификация UIViewController имеет преимущество, чтобы получить более легкий класс без кучи методов, которые мне никогда не понадобится использовать

Интерфейс моего контроллера довольно прост, например:

@interface MyScrollTabBarController : NSObject <MyTabBarViewDelegate> { } /** * The view is created internally by the controller and the client class * can access to it in readonly mode */ @property (nonatomic, readonly) UIView *view; /** * A Property to change the view appearance */ @property (nonatomic, assign) MyScrollTabBarViewState viewState; /** * Others properties used to construct the view's subviews */ @property (nonatomic, retain) Location *rootLocation; @property (nonatomic, readonly, retain) Place *place; /** * Designated initializer */ - (id)initWithPlace:(Place *)aPlace; - (void)setRootLocation:(Location *)location animated:(BOOL)animated; @end 

Чтобы отобразить его внутренний вид с родительского контроллера представления, я буду использовать что-то вроде этого:

 tabBarController = [[MyScrollTabBarController alloc] initWithPlace:aPlace]; tabBarController.viewState = MyScrollTabBarViewStateXX; tabBarController.view.frame = CGRectMake(...); [self.view addSubview:tabBarController.view]; 

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

благодаря

Да, это правильный подход.

UIViewControllers предназначены специально для управления полноэкранными представлениями, а не для подэкранов. В iOS5 есть механизм для создания подэкранов с просмотром экрана таким образом, но это невозможно в iOS4 без большого количества хакеров.

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

Я думаю, что это приемлемое решение.

Другим решением будет создание «живого» представления, которое будет контролировать себя (например, MKMapView, UITextView и т. Д.). Это может сделать вещи немного более управляемыми, и если представление очень специализировано, и его контроллер предназначен только для работы с этим классом, вы действительно не теряете возможности повторного использования (потому что его мало).

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

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

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

Подклассификация UIViewController не потребляет необоснованный объем памяти, поэтому это не должно быть частью рассмотрения.

[…] если вы думаете, что в нем могут быть недостатки […]

Благодаря вашему решению вы получаете гибкость. Вероятно, вы повторно используете свое решение в контексте, где вам нужно ответить на UILifecyle-Messages или использовать другие функции UIViewController.

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

Привет Вы подклассифицируете NSObject и объявляете UIView внутри него

 @interface MyScrollTabBarController : NSObject <MyTabBarViewDelegate> { } @property (nonatomic, readonly) UIView *view; 

Я предлагаю вам подкласс UIView, поэтому вам не придется объявлять дополнительный объект просмотра.

поэтому вместо self.view вы можете просто ссылаться как на self

 tabBarController = [[MyScrollTabBarController alloc] initWithPlace:aPlace]; tabBarController.viewState = MyScrollTabBarViewStateXX; tabBarController.frame = CGRectMake(...); [self.view addSubview:tabBarController]; 
  • UIViewController возвращает недопустимый фрейм?
  • iOS 7 - Скрыть строку состояния на контроллере детского просмотра
  • вызов родительского метода uiviewcontroller из дочернего модуля uiviewcontroller
  • UIViewController pushViewController, показать navigationBar
  • Как я могу отклонить модальный сегмент, а затем выполнить push segue в новый контроллер вида
  • self.navigationController ноль второй раз, когда загружен ViewController
  • iOS - Открыть определенный контроллер просмотра с помощью схемы URL
  • iOS 10 UIViewController, представленный с помощью Current Current Context, не вращается при изменении ориентации устройства
  • Существует ли метод recursiveDescription для иерархии диспетчера представлений?
  • Ошибка iOS 7. Предупреждение. Попытка отклонить контроллер представления. <UINavigationController: 0x1568db40> во время выполнения презентации или увольнения.
  • iOS | Разница между подходом к представлению нового объекта ViewController и использованием Segue
  • Interesting Posts

    Почему статус приложения находится в ожидании контрактов в iTunes подключиться после продления Apple разработчика

    Неверное значение кадра при доступе к представлению из раскадровки в IOS

    Значение права доступа не допускается с помощью ошибки профиля создания

    HTML: Как сделать readonly textarea для копирования в iOS-устройствах

    Добавление пробела между символом текстового поля при вводе текста

    Как удалить ранее отправленные уведомления, когда новое уведомление поступит с UNUserNotificationCenterDelegate в iOS 10?

    Не удалось найти перегрузку для «init», которая принимает предоставленные аргументы SWIFT

    Проверка подлинности HTTP-прокси в iOS 4.3

    ReactiveCocoa takeUntil 2 возможных сигнала?

    NSTimer сбой с EXC_BAD_ACCESS на Iphone при аннулировании

    nsinvalidargumentexception «причина» avplayeritem не может быть связана с более чем одним экземпляром avplayer '

    @synchronized vs. NSLock Instance vs. pthread_mutex_t

    этот сертификат был подписан неизвестным органом

    isEqualToString всегда возвращает False

    Открытие пользовательской ссылки URL в Safari / GMail

    Давайте будем гением компьютера.