I’m curious what strategy most of you are employing in order to build solid RESTful iPhone clients in respect to model hierarchies. What I mean by model hierarchies is that I have a REST server in which several resources have a correlation to each other. For instance, let’s say for hypothetical purposes I have a REST server which spits out information about a school. If I want to grab all the students in a particular class, I first need to query the REST server for information on the school, then I need to query the server for information on all of the classes the school has to offer, followed by a subsequent request for all students in a particular class. At the end of the day, the client is bringing in 3 unique XML trees. At that point, do most of you folks write your own algorithms in order to build the final tree which will end up being your data source? Do you not aggregate XML trees in this respect and instead use a different approach?
How do you prefer taking a myriad of related resources on the server and getting them into one tree that just makes sense onto the client?
Thanks for the insight.
How you choose to store manage your model data on the iPhone probably depends on how much the XML data you are dealing with is likely to vary, and how bloated it might get.
If this is a simple XML model that is unlikely to change, and doesn’t carry terribly much redundant information with it, you might do well to just use the XML trees you describe as-is.
But for anything even slightly more complex, I prefer to translate XML representations into a format that is most easily manipulated by my Objective-C code. Consider for example the possibility that your application expands one day to support other web-based services that provide similar data, but as JSON or SOAP formatted data. Now you start to run into the headaches of maintaining 3 different types of models in your application, when it would be preferable to maintain just one.
I would treat the XML-based REST resources as ‘foreign data’ that need to be massaged into a locally manipulatable format. If you adopt a local format that maximizes the ease of performing your app-specific operations, then you can adapt inputs from any other foreign format, and convert back to foreign formats as needed for uploads/edits/whatever.
Daniel