2013-12-06 6 views
2

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

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

Приносим извинения, если не использую нужный словарный запас. Я все еще пытаюсь услышать много о таком материале.

+0

Почему вы не помещаете все полученные данные в пользовательский класс, а затем используете этот класс в каждом VC? – CaptJak

+2

Не хранить данные в представлениях, хранить их в каком-то «образном» объекте. Обновите представление, когда вид станет видимым. В противном случае вы просто отбрасываете работу, обновляя представления и заставляя взгляды нести бремя модели. – BergQuester

+0

Спасибо, я не знаю, почему я делал свою жизнь намного сложнее. –

ответ

0

Вы слышали о шаблоне проектирования MVC или Observer раньше?

Представьте свое состояние данных, инкапсулированное в вашу модель, и как только появится экран UIViewController, спросите текущее состояние из вашей модели и покажите его там. enter image description here

Теперь вопрос заключается в том, как реализовать это? В приведенном выше изображении Дверной объект - это данные, полученные от bluetooth, а слушатели или наблюдатели - это ваш взгляд (i.e UIviewcontroller)

Будет ли UIPageController выполнять работу?

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

enter image description here

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

Предлагаемое решение: используйте NSNotifications и сделайте каждый контроллер UIView зарегистрированным на нем, и как только вы получите данные от Bluetooth, отправьте его, чтобы просмотреть контроллер.

1

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

0

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

1

Это звучит для меня так, как будто вы имеете в виду несколько активных режимов CONTROLLERS, а не виды.

Эти две вещи: не сменный. Контроллер представления управляет иерархией представлений и обеспечивает посредничество между этими представлениями и данными модели, которыми он управляет.

Начиная с iOS 6, довольно просто использовать раскадровки, чтобы контроллер просмотра управлял частью экрана. Вы добавляете представление контейнера в свой родительский контроллер представления, а затем соединяете и вставляете segue между представлением контейнера и контроллером представления, который будет там нарисован. Затем система устанавливает все, чтобы в контроллере был установлен вид контроллеров дочерних представлений.

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

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

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

Возможно, вы захотите настроить один сингл-узел диспетчера bluetooth, который управляет связью Bluetooth с другими устройствами, а также передает уведомления по мере поступления данных. Таким образом, контроллеры просмотра могут регистрироваться для уведомлений, которые они интересуют по мере необходимости, и un -регистр, когда их больше не нужно уведомлять. (обязательно отмените регистрацию уведомлений в своем методе dealloc или вы потерпите крах, когда ваш менеджер bluetooth попытается отправить уведомление об освобожденном объекте.)

Смежные вопросы