2013-03-18 2 views
4

Объект должен быть отправлен на сервер, и я хочу указать пользователю, что объект должен быть отправлен, отображая дату/время lastModified и lastSubmitted дата/время.Добавление записи «lastModified» в объект, управляемый основными данными

(Да, запись должна быть вручную представлены.)

Я в настоящее время прослушивает NSManagedObjectContextObjectsDidChangeNotification, проверяя, если объект объекта является RetailLocation, и если да, установив его lastModified даты/времени (конечно, только если lastModified не является единственным измененным объектом). Поскольку это, похоже, сильно путает менеджера отмены, я использую performSelector:SOMESEL withObject:retailLocation afterDelay:0.0 для установки свойства lastModified.

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

Может ли кто-нибудь рекомендовать хороший способ реализовать атрибут lastModified в записи, управляемой данными с помощью Core? В качестве альтернативы, что мне не хватает?

+0

Отметьте ответ Martin R на аналогичный вопрос здесь: http://stackoverflow.com/questions/20098544/set-a-lastmodificationdate-attribute-after-nsmanagedobjectsdidchangenotification. Это решение отлично сработало для меня. – stuckj

ответ

1

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

Если вам это нужно, вы можете получить указатель на NSUndoManager, вызвав undoManager в свой NSManagedObjectContext, но если вы работаете в iOS, вы должны иметь его уже.

Также обратите внимание, что Apple рекомендует использовать уведомление NSManagedObjectContextWillSaveNotification, поскольку изменения могут не обязательно сохраняться.

+0

Я использую диспетчер отмены 'NSPersistentDocument' (который является таким же, как' NSManagedObjectContext'), на OS X. Отказ от отмены регистрации не помогает, но это не идеальное решение; если пользователь выполняет отмену, время изменения и действие должны отменяться в рамках той же операции отмены. В идеале это можно было бы сделать с помощью групп отмены, но здесь это не вариант, поскольку Core Data - это тот, который добавляет операции для отмены стека, основанные на изменениях, вызванных Cocoa Bindings, которые запускаются на основе пользовательского ввода в глубину основной runloop. .:/ –

+0

Я бы воспользовался решением '... WillSaveNotification', но пользователь должен сразу увидеть, что необходимо предоставить обновленные данные на сервер. Этот мягко сложный набор требований - вот почему я побежал к SO; Я не вижу чистого способа сделать это, кроме как: 1) не интегрирует отслеживание изменений в качестве атрибута Core Data или 2) делает отслеживание, переопределяя каждый набор существующих атрибутов Core Data (таким образом, чтобы отслеживание выполнялось в пределах та же группа отмены). Мне не нравится ни одно из решений. –

+0

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

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