Guidelines for Designing and Implementing XML Parsing with Multiple Connections / Channels / Views

Launching my first iOS project and you want to learn how to structure your application. The application retrieves the XML feed, parses it, and displays a list representing the elements in the XML feed. When you click on an item in the list, the application will pull the new XML feed using one of the attributes from the previously pulled XML feed. This happens with several layers of pull, parse, display and user selection, which are repeated over and over. Now, most of the XML element structure looks something like this:

(These are simple examples to demonstrate what is happening)

returns (Show new view information):

<items> <item id="123" name="item 1" /> <item id="124" name="item 2" /> <item id="125" name="item 3" /> </itmes> 

returns:

 <itemDescription> <description itemId="123" name="desc 1" description="blah 1" /> </itemDescription> 

Need to know:

  • Should I have a connection class / object or new connection in each view?
  • Should I have a parser class / object or parse an XML feed in each view?
  • I also want to save some of the returned data, so I don’t need to call the XML feed again if the user goes to the list of main elements, but I will need to parse the XML feeds itemsDescription each time.

I looked through several XML parsing guides, and I understood the point, wanting to focus more on design and reuse, rather than duplicating code in each new view. Or I don’t know how it works.

+7
source share
2 answers

The best way to do this in accordance with the recommendations of the Apple Guide is to check one of my examples, a few months ago I made an application similar to yours, following this example. You can also see how to make the application offline.

Main structure (without offline mode):

The SeismicXML sample application demonstrates how to use NSXMLParser to parse XML data. When you launch the application, it downloads and analyzes an RSS feed from the US Geological Survey (USGS) which provides data on recent earthquakes around the world. It displays the locations, dates, and magnitudes of each earthquake, as well as a color chart that indicates the severity of the earthquake. XML parsing occurs in the background stream using NSOperation and updates the presentation of the earthquake table in batches of analyzed objects.

Extended structure (with offline mode):

Demonstrates how to use basic data in a multi-threaded environment, after the first recommended template specified in the master data of the Programming Guide.

Based on the example of SeismicXML, it downloads and analyzes an RSS feed from the United States Geological Survey (USGS), which provides data on recent earthquakes worldwide. What makes this sample different is that it constantly stores earthquakes using Core Data. Each time you launch the application, it downloads new earthquake data, analyzes it in NSOperation, which checks for duplicates and stores the newly created earthquakes as managed objects.

For those new to Core Data, it may be useful to compare the SeismicXML sample with this sample and pay attention to the necessary ingredients for entering Core Data into your application.

Regarding the cwieland answer, I would not use ASIHTTPRequest because it is deprecated , so if you want to follow its approach, I would recommend that you use AFNetworking , where you can easily and quickly process the XML request:

 NSURLRequest *request = [NSURLRequest requestWithURL:[NSURL URLWithString:@"http://api.flickr.com/services/rest/?method=flickr.groups.browse&api_key=b6300e17ad3c506e706cb0072175d047&cat_id=34427469792%40N01&format=rest"]]; AFXMLRequestOperation *operation = [AFXMLRequestOperation XMLParserRequestOperationWithRequest:request success:^(NSURLRequest *request, NSHTTPURLResponse *response, NSXMLParser *XMLParser) { XMLParser.delegate = self; [XMLParser parse]; } failure:nil]; NSOperationQueue *queue = [[[NSOperationQueue alloc] init] autorelease]; [queue addOperation:operation]; 
+4
source

This is how I implement it. I would use ASIHTTPRequest for all connection elements and not worry about this part. It can handle your entire data load asynchronously very easily with simple delegation methods.

I will have a parser class that takes a URL, loads it asynchronously and then parses the returned data. Then it will return an array of parsed children through the delegate method to a table that will display the children in the xml data.

I would create a subclass of UITableViewController that would handle any type of url / data, in which case you would only need to write one tableview class and not worry about how the user navigates. This will make it so that you only need to write one class, and it will handle any number of abbreviations or combinations. This implementation is highly dependent on how complex the various layers of XML data are. If they are very different from each other, it makes sense to have a cleaner code in the table view and not have if's checking the data type in creating the cell.

Using a navigation style application will eliminate the need to reanalyze the data each time the view is loaded as you view the stack. At any time forward, although it will be reassembled, a simple urls-> array cache can solve this if needed / required. This will require a reload of data every time the application starts. Of course, if you get a warning about 3 memory levels, you will need to re-analyze or search the cache to restore the backup.

If you want to use the caching system, I would write a class that is between the view controllers and the URL parser that checks the repository, and if it is there, return the data array, otherwise return nil and go it.

I personally used NSXMLParser, as that is what I am familiar with. You may want to place elements in the class shell, in which case you just need to check what type of element you have on didStartElement , and set the enumeration to include through creation. it's pretty easy using nsxmlparser. I did not use any other parser for comparison, but found that debugging NSXMLParser was fairly simple and the coding was simple, so it was not difficult to start and run it. Here is a great site on all of the different XML parses:

http://www.raywenderlich.com/553/how-to-chose-the-best-xml-parser-for-your-iphone-project

So, I would get a subclass of NSObject that takes a URL, loads it through ASIHTTPRequest, parses it. The UITableviewController subgroup, which on a cellular connection, allocates the same class as the class controller with the new URL and pushes it onto the navigation stack. A loading screen appears in the view until the array is returned, and then just reload the data. Hope this will be a very DRY KISS.

I would put as much code as possible in global classes. If each data attraction has only one main category, as in

 <items> <stuff></stuff> .... <stuff></stuff> </items> EOF 

I would use an array to place all the values. If there is more than one main section, I would save everything in the dictionary with the parent attribute as the key and values ​​in the array. Then on the table there are different sections based on dictionary keys.

I hope this answers some of your questions. I'm not sure how low you were looking. I speak from the development of quite a few applications and the writing of an RSS reader. Let me know if you want me to clarify.

+2
source

All Articles