Кодирование ключевого значения
Когда я запускал простое приложение для iPhone, у меня был прямой подход к превращению пар «ключ-значение» из XML-отрывка в NSDictionary. Проблема в том, что мне нужно превратить те экземпляры NSDictionary, которые когда-то заполняли мой UITableView, в пользовательские классы, потому что они требуют поведения и дополнительной сложности. Проблема здесь в том, что теперь мне намного сложнее создать экземпляр объекта и заполнить его переменные экземпляра парами ключ / значение из веб-службы. Я больше не могу использовать его в методе, который выполняет итерацию по XML и использует KVC для установки своих переменных экземпляра.
Какие еще есть решения?
Ответы 2
Загляните в NSCoding. Вы можете использовать протокол NSCoding для сохранения вашего объекта, свойств и всего остального как данных.
Как только ваш объект станет совместимым с NSCoding, вы можете просто заархивировать весь массив объектов с помощью NSKeyedArchiver.
Обратите внимание: если у вас много объектов, это может существенно повлиять на производительность приложения на iPhone во время загрузки и сохранения.
Однако он работает с веб-службой XML, не спрашивая, как сохранить свои объекты в источнике данных.
Влияет положительно или отрицательно?
Шарбонно прав. Я получаю XML-канал, который соответствует объекту на клиенте iPhone / Mac. Обычно это будет что-то вроде <user><name>Bob</name><age>43</age> </user> У меня раньше был метод, который использовал бы экземпляры NSDictionary кода ключа / значения.
Вы по-прежнему можете использовать методы кодирования значений ключа в своем пользовательском классе, если вы правильно называете свои переменные, в этом нет никакой разницы. С учетом вышесказанного, когда я работаю с XML, я обычно заканчиваю тестированием имени каждого узла или созданием ключевой таблицы поиска, поскольку имена в источнике данных, с которым я работаю, не соответствуют кодированию значений ключа. Если у вас есть контроль над источником данных, вы можете просто продолжать использовать setValue:forKey:.
Я бы рекомендовал прочитать это руководство о кодировании значения ключа, если вы еще этого не сделали. Это фундамент для многих замечательных инструментов в Какао.
Звучит хорошо, Марк. Есть ли шанс, что вы можете объяснить, что вы имеете в виду, говоря, что имена в источнике данных не совместимы с кодированием ключа / значения? А на что вы тестируете свои узлы?
Использование заглавных букв играет роль, но имена узлов не всегда совпадают с именем переменной. Например, DetailPageURL может отображаться на pageURL, заголовок - на заголовок и т. д.
NSCoding выглядит отличным решением, август. Однако меня беспокоит снижение производительности за его использование. Мои объекты обычно содержат 5/6 переменных экземпляра, фундаментальные типы данных. Интересно, сколько потребуется, чтобы заправить мое приложение.