Как сделать плотную связь между данными о корреляциях coredata/NSManagedObject с пользовательским интерфейсом приложений?

Question

TL; DR. Для упрощения всего описания, как реализовать интерфейс пользовательских интерфейсов представления не зависящих от вида таблицы, когда свойства базового объекта данных часто обновляются в фоновом режиме. И с этим визуальное представление данных необходимо немедленно обновить. [В Tableview очень легко обрабатывать, использовать КОПЫ и просто перезагрузить строку, когда обновление объекта, с помощью методов FRCS делегата.]

---

Я знаю о NSFetchedResultsController и отображение через что пользовательский интерфейс. Но это только тогда, когда интерфейс пользователя основан на списке.

В моем случае несколько аппаратных средств подобного типа подключены к моему приложению через bluetooth (BLE), и каждый обычно обеспечивает обновления частотой 1 секунду в целом. Например, температура, заряд меняется.

Так вот пример потока пользовательского интерфейса,

Список -> Подробнее

Подробности

1. Здоровье
2. Активность
3. Notification Установка

Подробнее просто представляет собой связанные с оборудованием данные (серийный номер, версию прошивки, дату производства и т. д.), и он имеет 3 кнопки, названные выше, которые при нажатии на нажатия на соответствующие контроллеры.

Модель Entity также разработана соответствующим образом, вот проблеск, у меня есть первичная сущность, допустим, ABC. Затем ABC имеет взаимно-однозначное отношение с другими объектами, такими как HealthDetails, Activity, NotificationSetting и HardwareDetails. ABC имеет несколько атрибутов, таких как identifier, connected, name и т.д.

ListViewController является UITableViewController и, следовательно, я использую NSFetchedResultsController. Теперь оставшиеся все остальные контроллеры представлений - это просто обычные контроллеры представлений, а только титры Title, такие как «последняя заряженная дата», которая является статичной и «меткой описания» ниже, которая показывает данные. Другие контроллеры вида также заполнены просто кнопками, надписями и т. Д.

Обновление контроллера списка с помощью кнопки NSFetchedResultsController.

[Когда строка/клетка касании пользователя, я просто получить объект, используя indexpath из FRC и ввожу его в контроллер вида назначения.]

Однако другие контроллеры вида не представление таблицы на основе. Поэтому я использую уведомление для управления другими обновлениями UI контроллера.

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

Все UIViewController s в иерархии, находящиеся в стеке навигации, подписываются как наблюдатели. И если идентификатор в уведомлении соответствует объекту объекта, отображаемому в настоящее время, я обновляю пользовательский интерфейс. В настоящее время все это прекрасно работает.

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

---

Я вижу несколько замечаний, которые предлагает обрабатывать все только через КОП, но я не уверен, если FRC может использоваться в представлении пользовательского интерфейса на основе не TableView. Я искал и не нашел много. Если кто-либо знает какой-либо учебник/блог с даже теоретическим описанием, это будет большой помощью.

Другое дело, что предложения по FRC для обработки всех, я не получил его полностью, мне нужно разместить один контроллер FRC для каждого контроллера? Разве нет другого пути?

Answer 1

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

В зависимости от того, что вы делаете, это может быть столь же просто, как внедрение controllerDidChangeContent(_:)

Если это не отвечает на беспокойство, вы будете иметь, чтобы предоставить более подробную информацию относительно того, что конкретный вопрос ,

Answer 2

Вы упомянули об изменении «ViewControllers», поэтому я предполагаю, когда вы нажимаете, как вы сказали в комментариях «Список> Здоровье> Деятельность> Настройки», каждый из которых - это классы UIViewController, не так ли? Если это так, реализуйте метод viewWillAppear в каждом из них и убедитесь, что вы выполняете всю инициализацию своего интерфейса. Поступая таким образом, вы гарантируете, что, когда поп произойдет, этот метод будет вызван, и ваш пользовательский интерфейс будет обновлен (b/c у вас есть логика в этом методе для обновления). Я использовал инициализацию UI в viewDidLoad, но имел ту же проблему, с которой вы сейчас сталкиваетесь. Перемещение его на viewWillAppear было решением в моей ситуации.

После этого, если вы все еще не видите правильные значения в пользовательском интерфейсе, установите точки останова в методе viewWillAppear и проверите данные, находящиеся в вашей модели. Возможно, модель неверна - в этом случае, возможно, вы выполняете запрос (поиск), чтобы вытащить то, что вам нужно снова. Этот не должен быть проблемой, если вы не используете контексты родителя/ребенка и не выполняете изменения дочернего контекста до родителя.

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

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

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

Answer 3

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

Я присоединяюсь к другим пользователям, предлагающим использовать FRC. Я не могу помочь вам в блоге/учебнике, но CoreStore ObjectMonitor - очень хороший пример того, что он может использоваться в другом (не табличном виде) контексте. Я уверен, что для вас это не проблема.

Answer 4

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

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

Я вас неправильно понял?

Answer 5

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

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

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

Альтернативный вариант, который не обсуждался, это KVO, который поддерживается всеми управляемыми объектами. Это наиболее подходящее решение для вас, потому что вам передают объект, и в результате вам не нужно делать более высокий уровень/контекстное наблюдение. Непосредственно работать с KVO иногда немного больно, поэтому вы хотите использовать некоторую вспомогательную библиотеку, например this one, поэтому вы можете использовать блоки для работы с специально обновленными элементами.

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