Easy and fast XML node access with TBXMLEx

I recently added a very nice feature to one of my Open Source projects, TBXMLEx, which is the possibility of directly access any node without having to loop through all its parent nodes. This is very useful when you know beforehand where the node is located at. The sintax is very clean and concise. Suppose you have the following XML:

NSString *xml = @"<data> \
        <a> \
            <a1/> \
            <a1/> \
            <a1/> \
        </a> \
        <b/> \
        <b/> \
        <c/> \
        <d> \
            <d1> \
                <d11/> \
                <d21/> \
            </d1> \
            <d2> \
                <d21/> \
                <d22> \
                    <d221/> \
                </d22> \
            </d2> \
        </d> \

and that you need to access the “d221” node, which is pretty deed inside the structure. Using TBXMLEx it is straightforward do to so:

TBXMLEx *parser = [TBXMLEx parserWithXML:xml];
NSArray *result = [parser.rootElement query:@"/d/d2/d22/d221"];
TBXMLElementEx *element = [result objectAtIndex:0];

The key point in the previous code sample is the “query” method (a member of TBXMLElementEx), which takes a path as argument and returns all nodes that matches the criteria, as TBXMLElementEx instances. Right now it supports only simple expressions, but nevertheless it’s a quite useful feature .

You may wonder why not use XPath instead. The point is, while very powerful, you’ll need extra libraries to work with XPath, and it can take some time to master its syntax. The “query” method I implemented does not intend to take over XPath nor reimplement its features, it is just a convenient, syntax sugar method to do regular tasks we face on a daily basis, and while someday it may be improved to be more powerful, XPath will always be the choice when you need to do nasty thigns with XML.

TBXMLEx is an Open Source library freely available at https://github.com/rafaelsteil/tbxmlex

Fast XML parsing in iOS / Objective-C with TBXMLEx

Have you ever wondered which is the best way to parse a XML file in Objective-C / iOS? There are certainly a lot of options available to those who know where to lot at, but many of them are just awful to use: hard to configure, cryptic API, inexistent documentation and so forth.

Ray Wenderlich once wrote a post called “How To Choose The Best XML Parser for Your iPhone Project“, which greatly covers many XML parsers available to iOS, and was there that I discovered TBXML, which is by far one of the best parsers available to iOS. While TBXML is great, it’s “non-OO” API and some intolerance to bad formed XML had me wonder if there were anything I could do to make it better.

With that motivation, I created an extension to TBXML called “TBXMLEx” (TBXML with Extensions) which adds some syntax sugar on top of the original library and better handle bad XML files, all of that with a more OO-friendly interface.

The design goals for TBXMLEx are (taken for the original TBXML goals):

  • XML files conforming to the W3C XML spec 1.0 should be passable
  • XML parsing should incur the fewest possible resources
  • XML parsing should be achieved in the shortest possible time
  • It shall be easy to write programs that utilise TBXML
How to use it
Below is a quick example of how to use TBXMLEx:
#include "TBXMLEx.h"

NSString *xml = @"<files> \
    <file timestamp='1234567890' size='123' createdAt='01/01/20011'>file1.jpg</file> \
    <file timestamp='1234567890' size='8934'> \
        <name>file2.jpg</name> \
        <attributes> \
            <createdAt>01/01/2011 13:45:56</createdAt> \
            <owner>john</owner> \
        </attributes> \
    </file> \

TBXMLEx *xml = [TBXMLEx parserWithXML:xml];

// "files" is the rootElement
if (xml.rootElement) {
    TBXMLElementEx *fileNode = [xml.rootElement child:@"file"];

    while ([fileNode next]) {
      // You can access the attributes through a dictionary
        NSDictionary *allAttributes = fileNode.attributes;
        NSLog(@"Timestamp: %@", [allAttributes objectForKey:@"timestamp"]);

        // Or you can have direct access to any specific attribute
        NSLog(@"Size: %d", [fileNode intAttribute:@"size"]);

        NSObject *createdAt = [fileNode attribute:@"createdAt"];
        NSString *filename = fileNode.value; // or fileNode.text

        if (!createdAt || !filename) {
            // Look for the properties someplace else
            TBXMLElementEx *nameNode = [fileNode child:@"name"];

            if (nameNode) {
                filename = nameNode.value;

            TBXMLElementEx *attributesNode = [fileNode child:@"attributes"];

            // If an attribute does not exist it will simply return "nil", but nevertheless it's
            // always good check if it exists if you really need it
            if (attributesNode) {
                NSLog(@"Created at: %@", [attributesNode child:@"createdAt"].value); // Will not crash if attribute is nil
                NSLog(@"Owner: %@", [attributesNode child:@"owner"].value);

        NSLog(@"Filename: %@", filename);

You can find more information about the project, as well the source code, at https://github.com/rafaelsteil/tbxmlex

Crappy iOS APIs – UINavigationController

While Apple has some great products and has achieved excellence designing beautiful UIs, the same can’t be said for many of its APIs. Anyone who has tried to do even the simplest of the things just by looking at the documentation or based on assumptions of how one could expect that a given thing would work based on context and method names, would know what I am talking about: literally hours trying to correctly setup a more complex UILabel, or pulling the hair out of the head after not being able to easily change the color of an UINavigationController or UIToolBar. The list goes on ad-infinitum.

Take UINavigationController for instance: it has methods to set the title, the left and right buttons, and for the back button when a new controller is pushed into the stack. So imagine you are in controller A,which pushes controller into the stack by calling [self.navigationController pushViewController:b animated:YES]. The view slides left with a nice looking animation, and b’s view pops in the screen. By default, iOS will automatically set up a working back button for you – which is great – and that button’s label is set to the previous screen’s title – that, again, makes a lot of sense.

However, if for any reason you’d like to change the label of the back button to another text. you can’t just do

self.navigationItem.backBarButtonItem.title = @"Back";

on b. Well, you can, but it won’t work. It does not crash the app, but also does nothing. Now imagine for a moment that doing the previous code is the most natural thing anyone could possible do, but it does not work. “Ok then, maybe if I override the entire button”:

self.navigationItem.backBarButtonItem = [[[UIBarButtonItem alloc] initWithTitle:@"Back"
	style:UIBarButtonItemStyleBordered target:nil action:nil] autorelease];

only that it also does not work: you’d still get the default button, despite assigning a new one. Lots of tries here and there, and you finally figure out (by looking a Google or deciphering the poorly written documentation) that the only way to get it working is to set the title BEFORE you push b into the stack, in the PREVIOUS controller. In other words, you must the the title you’d like to see in b in the a controller. Genius, right?! Apple just killed SoC. It will look like this:

// Somewhere in AController
BController *b = [[BController alloc] init];
self.title = @"Back"; // Scream in pain
[self.navigationController pushViewController:b animated:YES];
[b release];

There simply can’t be any good reason on earth to do that. It get’s worse then you need to have a custom method called before the view pops out of the stack, as it is not possible to override backButton‘s selector.

So that one should do, instead? Well, what I do is the following: I force backButton to be hidden when the new controller slides up on the screen, and then set up a “left” button:

// BController
-(void) viewDidLoad {
	self.navigationItem.hidesBackButton = YES; // Important
	self.navigationItem.leftBarButtonItem = [[[UIBarButtonItem alloc] initWithTitle:@"Back"
		style:UIBarButtonItemStyleBordered target:self action:@selector(myCustomBack)] autorelease];

-(void) myCustomBack {
	// Some anything you need to do before leaving
	[self.navigationController popViewControllerAnimated:YES];

it just works. It’s a lot of work, of course, but works. Now, if you’d like to have a different layout for such button, that’s a whole new story.