views:

197

answers:

2

Hi all, I have an XML file which contains lists of stores, a simplified version is below. What I would like help with is some high-level ideas on the simplest ways to move this data into objects for storage in Core Data. I see suggestions around key-value pairs but as you can see in my example below, I have child elements with the same name/key and there can be an arbitrary number of these for each store element.

I intend to store these objects within the app for future use (they will be annotations on a map). So, each duplicate field needs to be stored, one of them will not suffice. I know how to model it in Core Data I believe, I'll have a phone-number entity and a store entity and will just relate the two based on <store-id>. I'm just trying to use a simple method to move them from XML to Core Data via some other data structure.

XML sample:

<stores>
  <store>
   <store-id>1</store-id>
   <city>Dublin</city>
   <phone>011234567</phone>
   <phone>011234566</phone>
   <owner>Joe Bloggs</owner>
  </store>
  <store>
   <store-id>2</store-id>
   <city>Cork</city>
   <phone>019876543</phone>
   <phone>019876542</phone>
   <owner>Joe Bloggs</owner>
  </store>
<stores>

If key-value pairs are the way to go, please point me to a method where I can account for the duplicate elements. If there's another way, I'm all ears.

Thanks

+5  A: 

The harder part is going to be designing a data model that makes sense. You'll probably need an entity for store, one for phone, and probably one for owner. Store should be one-to-many with phone number, and one-to-one with owner (just looking at your data).

Once you have the data model laid out, then you can use either NSXMLParser or a third party library like TouchXML to parse the XML. Start with your element. For each item in there, create an object based on the store entity. For each phone in the element, create a phone entity, and so on.

Ben Gottlieb
So would you say creating objects on the fly as I'm parsing is the most simple method? Any performance impacts on doing it that way? I guess it's the one-to-many relationship I'm thinking of which may present some complications when it comes to parsing. But if I created a phone object for each phone element on the fly that might simplify things a little. However, since there are going to be over 250 of these entities with more elements than are in my example, I am just thinking about performance a little too. PS, owner won't actually be stored. I stuck it in as a sample field only
Griffo
@Ben Gottlieb - Just to clarify, I'm familiar enough with the parsing side of things, just the next step is where I'd like some help. Thanks
Griffo
There will probably be a performance hit when parsing this, so you might want to do it in the background. However you're WELL within the capabilities of both the device and Core Data.
Ben Gottlieb
A: 

I'd venture that a create-as-you-parse approach is likely to be not only the most straightforward, but also the least less resource-intensive approach. If you can use a stream-oriented parser to handle the XML, and save the stores as you finishing parsing them, that's much less stuff you have to hold in memory at a time.

I'd also think seriously about whether the attributes need to be full-blown entities, or just properties of the store. For example, would you be doing anything with the owner's name beyond display it on the map? (And, yes, I saw your comment about that particular thing just being an example.)

Unfortunately, Core Data doesn't really provide a good way to do a multi-valued property that isn't a relationship. (Phone numbers here really seem like they could just be an array of strings.) Though see this SO question and this cocoa-dev thread for some discussion of that.

Sixten Otto