Блог

Любые советы о том, как сохранить простой пользовательский класс конфигурации в core data. Варианты, я думаю, были бы:

1. Объект с атрибутами «ключ» и «значение» — возможно, разные атрибуты для представления разных возможных типов (например, Integer16, String и т.д.)

2. Объект пользовательского класса, какие конкретные атрибуты для каждого элемента конфигурации я хочу — единственная загвоздка заключалась бы в том, что вы хотели бы иметь только одну запись в этом объекте, но преимущества заключались бы в том, что он должен быть более удобным, я думаю: например, для элементов конфигурации «FontSize» это было бы просто, как только вы получите 1-ю запись обратно из core data: «configRecord.FontSize». Нет необходимости получать доступ через расположение ключ-значение, а затем приводить результат или что-то еще.

Комментарии?

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

Если бы у вас было много таких, то Core Data и ваш второй вариант позволили бы упростить поиск и т.д. Но это не тот случай.

С точки зрения удобства «configRecord.FontSize», вы могли бы прочитать в NSUserDefaults в свой собственный пользовательский класс и предоставить методы получения / установки там — не прибегая к Core Data.

Всего лишь мои два цента 😉

Я запустил свои опции 2, которые, похоже, работают без проблем — и вместо любых предложенных недостатков (которые я еще не нашел)