iOS XML Разбор на много документи

в моето приложение трябва да направя няколко HTTP заявки. Всички тези заявки връщат XML-документи, които трябва да бъдат анализирани и след това да отидат в таблични изгледи или каквото и да е... Това са около 10-20 документа в цялото приложение. Атрибути с едно и също име могат да се появят в различни документи, така че трябва да ги разгранича в моите делегирани методи.

Моят подход беше да имам само 1 клас с методите NSXMLParserDelegate, използвайки различни парсери за документ (но със същия делегат) и да правя разлика между анализаторите (известни още като документи), използвайки аргумента на анализатора в методите на делегата. но това става доста сложно и не искам да се окажа с тонове различни променливи на екземпляр на анализатора и if клаузи. няма ли по-прост начин да направите това? мислех да имам 1 клас на операция за анализ (=> различни делегати), но предполагам, че това е още по-лошо..


ios iphone objective-c xml nsxmlparser
person urz0r    schedule 08.09.2012    source източник
comment
Можете да имате отделни екземпляри на класа или, ако е по-просто, използвайте DOM анализатор с libxml2   -  person Richard J. Ross III    schedule 08.09.2012
comment
С какво отидохте в крайна сметка?   -  person bryanmac    schedule 09.09.2012

Отговори (2)


arrow_upward
2
arrow_downward

Една от опциите е да поставите обратните извиквания на делегата на XML и/или методите за конструиране на данни върху обекта, който ще бъде създаден от анализиране на този конкретен xml тип. Това би поставило дефиницията на обекта заедно със знанието как да го създадете от xml или части от данни на едно място. Като се опитвате да поставите цялата логика на анализиране за всички типове в един делегатен метод, това усложнява този един делегатен клас и разделя знанията за всеки от типовете, с които работите.

Единственото предизвикателство с този подход са съставните обекти. Например, ако имате обект изпълнител, обект албум, който съдържа изпълнител, и извикване, което получава списък с изпълнители. Един подход там е съставният обект, който анализира, да бъде отложен към този друг обектен клас (може би с вашия собствен протокол). Например обектът албум се анализира и попада на елемент „изпълнител“. Така че той знае да разпредели изпълнител и докато удря части от данни от обратните извиквания на делегата (докато не достигне елемент близо изпълнител) - той ще продължи да извиква вашите протоколни методи, въвеждайки данни в тях. Това отлага знанието какво да прави с тази част от данни към класа, който дефинира този обект. За клас, който обработва списък с артисти, той би направил това n пъти, като състави списък. Повикване, което получава един изпълнител (делегати в класа на изпълнител), все пак ще извика тези методи за пълнене на част от наситени данни на обекта на изпълнител.

И накрая, конструирането на обекти, докато XML се анализира, ако се направи правилно, може да има предимството да поддържа паметта по-ниска и да работи по-бързо. За разлика от буферирането на целия xml низ, създаването на пълен XML DOM може да използва повече памет, което също може да бъде по-бавно за потребителя. Така че помислете и за ефективността.

person bryanmac    schedule 08.09.2012
comment
благодаря, харесвам този подход, защото следва моето разбиране за чист дизайн. за съжаление, момчетата, които създадоха XML документите, не мислеха много обектно-ориентирани... но ще се опитам да се справя с това. - person urz0r; 10.09.2012

arrow_upward
0
arrow_downward

Ако вашият XML кодира само куп записи, погледнете https://github.com/ZaBlanc/RaptureXML В RaptureXML анализирате с блокове, така че не е нужно да се занимавате със създаването на нови обекти. Можете да подадете името на документа като аргумент към блока за анализ. Освен това е милион пъти по-сбито, отколкото да го правите с NSXMLParser.

person Maciej Trybiło    schedule 08.09.2012
comment
хей, благодаря за отговора. докато вашето решение вероятно щеше да е по-просто, в крайна сметка се спрях на подхода на bryanmacs главно защото исках първо да разбера солидно обработката на xml. - person urz0r; 10.09.2012