In my recent post on How To Choose the Best XML Parser for Your iPhone Project, Saliom from the comments section suggested writing a post on how to use an XML library to read and write XML documents, create your own objects based on the documents, and perform XPath queries.
This XML tutorial will show you how to do exactly that! We’ll create a project that reads a simple XML document that contains a list of RPG party members, and construct our own objects based on the XML. We’ll then add a new player to the party, and save it back out to disk again.
This XML tutorial uses GDataXML, Google’s XML processing library. I chose GDataXML since it performs well for DOM parsers, supports both reading and writing, and is so easy to integrate. However, if you are using a different DOM parser, it should be almost exactly the same as this but just slightly different API calls.
Special thanks to Saliom for suggesting writing this XML tutorial!
Our XML Document
We’re going to work with a simple XML document in this XML tutorial that looks like the following:
As I mentioned, this list represents a list of characters you might have in a RPG dungeon crawl game. I wanted to keep the document pretty small to make the XML tutorial easy to follow, but still show you some interesting things such as using different datatypes and having lists of objects.
Ok, so let’s get started on our project to read and write this thing!
Integrating GDataXML
You can integrate GDataXML into a new project with a few easy steps:
- Choose Project\New Project, and choose View-based Application, and name the project XMLTest.
- Download the gdata-objective-c client library.
- Unzip the file, navigate to Source\XMLSupport, and drag the two files GDataXMLNode.h and GDataXMLNode.m into your project.
- In XCode, click Project\Edit Project Settings and make sure “All Configurations” are checked.
- Find the Search Paths\Header Search Paths setting and add /usr/include/libxml2 to the list.
- Finally, find the Linking\Other Linker Flags section and add -lxml2 to the list.
- Test out that everything is working by adding the following to the top of XMLTestAppDelegate.h:
#import "GDataXMLNode.h" |
If your app compiles and runs GDataXML is integrated successfully!
Creating Model Classses
Next, let’s create a set of model classes that we want to represent our party of XML characters in our game. Basically, we want to make a set of objects that represent how we wish to work with our characters in our game.
First, let’s create our Player class. Click on File\New File, select Cocoa Touch Class\Objective-C class, choose Subclass of NSObject, and click Next. Name the file Player.m and verify that “Also create Player.h” is checked.
Then replace Player.h with the following:
#import <Foundation/Foundation.h> |
And replace Player.m with the following:
#import "Player.h" |
Again, all of this is straight Objective-C, nothing really to do with XML at this point. However, I’m still including it for completeness sake.
Follow the same steps as above to create a new subclass of NSObject named Party. Replace Party.h with the following:
#import <Foundation/Foundation.h> |
And Party.m with the following:
#import "Party.h" |
Ok, so far so good! Now let’s get to parsing our XML file and creating instances of these objects based on the XML.
Parsing the XML with GDataXML
Let’s get together some code quickly to use GDataXML to read the XML document and create a DOM tree in memory.
First, download Party.xml and add it to your project.
Next, we’re going to create a new class to hold all of our parsing code. Add a new subclass of NSObject to your project named PartyParser.
Replace PartyParser.h with the following:
#import <Foundation/Foundation.h> |
And then replace PartyParser.m with the following:
#import "PartyParser.h" |
Ok, finally some semi-interesting code here. First we create a static method called dataFilePath that returns the path to the Party.xml that we included in our project (and hence becomes part of our application’s bundle). Note that we have a boolean that indicates whether we want the path of the file for loading or saving – this isn’t used right now, but will be later.
Next, we create another static method called loadParty. This loads the raw bytes for the file off the disk with NSMutableData’s initWithContentsOfFile method, and then passes the data to GDataXML’s parser with the GDataXMLDocument initWithData method.
If GDataXML has an error parsing the file (such as a missing close tag), it will return nil and return an NSError with more information. For this XML tutorial, we’ll just return nil if this occurs.
However, if we receive a success, we just print out a description of the root element of the document (which should be the tag in our case).
Ok, let’s put this to use. Modify your XMLTestAppDelegate.h so it looks like the following:
#import <UIKit/UIKit.h> |
Note all we did here was declare a Party member variable.
Then modify your XMLTestAppDelegate.m so it looks like the following:
#import "XMLTestAppDelegate.h" |
Here we just add some include files and call the static method to load the party in our applicationDidFinishLaunching, and do some cleanup in our dealloc method.
Ok let’s see if it works so far! Compile and run your application, and if you go to Run\Console and scroll to the bottom, you should see something like the following print out:
2010-03-17 11:31:21.467 XMLTest[1568:207] GDataXMLElement 0x3b02530: |
Converting the XML to our Model Objects
Ok now that we see that it’s working so far, let’s continue the code to walk through the DOM tree and create instances of our model objects as we go.
The replace the code in the loadParty method starting with replacing the NSLog statement with the following:
Party *party = [[[Party alloc] init] autorelease]; |
This is the real meat of our work. We use the elementsForName method on our root element to get all of the elements named “Player” underneath the root “Party” element.
Then, for each “Player” element we look to see what “Name” elements are underneath that. Our code only deals with one name, so we just take the first if there is more than one.
We do similar processing for “Level” and “Class”, but for level we convert the string into an int, and for class we convert the string into an enumeration.
If anything fails, we just skip that Player. Otherwise, we construct a Player model object with the values we read from the XML, and add it to our Party model object, and return that!
So let’s write some code to see if it works. Add the following to XMLTestAppDelegate.m in applicationDidFinishLaunching, after the call to loadParty:
if (_party != nil) { |
Compile and run your project, and if all works well you should see the following in the console output:
2010-03-17 12:33:04.301 XMLTest[2531:207] Butch |
Querying with XPath
XPath is a simple syntax you can use to identify portions of an XML document. The easiest way to get a handle on it is by seeing a few examples.
For example, the following XPath expression would identify all of the Player elements in our document:
//Party/Player |
And the following would just identify the first Player element in our document:
//Party/Player[1] |
And finally, the following would identify the player with the name of Shadow:
//Party/Player[Name="Shadow"] |
Let’s see how we could use XPath by slightly modifying our loadParty method. Replace the line that loads the party members as the following:
//NSArray *partyMembers = [doc.rootElement elementsForName:@"Player"]; |
If you run the code, you’ll see the exact same results. So there isn’t an advantage of using XPath in this case, since we are interested in reading the entire XML document and constructing a model in memory.
However, you can imagine that this could be pretty useful if we had a big complicated XML document and we wanted to quickly dig down to find a particular element, without having to look through the children of node A, then the children of node B, and so on until we find it.
If you are interested in learning more about XPath, check out a nice XML tutorial from W2Schools. Also, I’ve found this online XPath expression testbed quite handy when trying to construct XPath expressions.
Saving Back to XML
So far we’ve only done half of the picture: reading data from an XML document. What if we want to add a new player to our party and then save the new document back to disk?
Well, the first thing we need to do is determine where we are going to save the XML document. So far we’ve been loading the XML document from our application’s bundle. We can’t save to the bundle, however, because it is read-only. But we can save to the application’s document directory, so let’s do that.
Modify your dataFilePath method in PartyParser.m to read as follows:
+ (NSString *)dataFilePath:(BOOL)forSave { |
Note that when we’re loading the XML, we want to load from the file in the documents directory if it exists, but otherwise fall back to reading the XML file that ships with the app, like we’ve been doing so far.
Now, let’s write a method to construct our XML document from our data model and save it out to disk. Add a new methdo to PartyParser.m as follows:
+ (void)saveParty:(Party *)party { |
As you can see, GDataXML makes it quite easy and straightforward to construct our XML document. You simply create elements with elementWithName: or elementWithName:stringValue, connect them to each other with addChild, and then create a GDataXMLDocument specifying the root element. In the end, you get an NSData that you can easily save to disk.
Next declare your new method in PartyParser.h:
+ (void)saveParty:(Party *)party; |
Then inside the party != nil check in applicationDidFinishLaunching, go ahead and add a new party member to our list:
[_party.players addObject:[[[Player alloc] initWithName:@"Waldo" level:1 |
And finally let’s save out the updated party list in applicationWillTerminate:
- (void)applicationWillTerminate:(UIApplication *)application { |
Compile and run your project, and after the app loads go ahead and exit. The app should print out to the console where it saves your XML. It will look something like this:
2010-03-17 13:34:14.447 XMLTest[3118:207] Saving xml data to |
Go ahead and find that folder with Finder and open up the XML, and if all goes well you should see your new party member in the XML:
Then run the app again, open up your console log, and see if you can find where Waldo is! :]
And That’s A Wrap!
Here is a sample project with all of the code that we’ve developed in the XML tutorial so far. Note that the app doesn’t show anything in the GUI as that isn’t important for this XML tutorial – it just shows a few output lines in the console.
By the way – before you use XML in your projects, you should take a second to consider why you want to use XML in the first place and if that is the best choice. In this example, if all we were using XML for was loading and saving characters for this particular app, XML would probably be overkill, and it would be better to use another serialization format such as property lists, NSCoding, or even Core Data.
However, XML really starts to shine when you start having multiple applications use the same data. If we had a Mac application that generated a list of characters and we wanted our iPhone app to be able to read and modify that list, that’s when it becomes to be particularly useful. This is because XML is a standard format for exchanging data that is quite easy to work with, as you’ve seen.
So any plans to use XML reading and writing in your apps? What are you using it for?
转载自:http://www.raywenderlich.com/725/xml-tutorial-for-ios-how-to-read-and-write-xml-documents-with-gdataxml