I am currently using the TouchJSON library in my iOS app. I currently deserialize JSON on the main thread and this seems to work well. The Earthquakes XML example in the iOS Developer Library demonstrates XML parsing on a secondary thread and I'm wondering if this would be a good idea for deserialization from JSON as well? My JSON objects are small so it seems unnecessary. What do you think?
It should be possible, however, start the performance tuning only if you need it. So many sins have been commited in the name of perfomance optimization!
Have a look at Comparison of JSON Parser for Objective-C (JSON Framework, YAJL, TouchJSON, etc) for some discussion about performance of the various frameworks.
Here's a review about the performance of the different frameworks, also linked in the Q&A I posted above:
Related
If a iphone app needs to communicate with a server, is xml the best route in most cases?
how hard is it to parse xml in obj-c?
It really depends on the type of data you wish to exchange, but XML will at the very least be able to handle any complexity of data structure you require. (If you only want to exchange a minimal amount of information, you might want to consider JSON that said.)
There are quite a few XML parsers available for Objective-C, most of which are discussed on this existing question: Navigating XML from Objective-C
Finally, there's a great blog post on Ray Wenderlich's web site that discusses the various XML parsers with a view to speed/memory footprint which might be important if you're parsing a large amount of data.
Depends on what is beeing transmitted.
That said I use JSON for 90% of my server to app communication. Easy to parse as libraries are readily available.
Nope. Not hard. But when it comes to APIs it seems many prefer JSON.
JSON is easier to work with than XML, regardless of parser used. Lots of server side people will understand JSON quite well because of the need to use it to work with Javascript.
The iPhone JSON parser I'd look at using first is YAJL.
I would either go with XML or JSON ( http://www.json.org/ ).
It's very easy to parse XML on the iPhone. There are quite a few XML parsers out there based on your preference. For a DOM parser you can use TBXML, otherwise Apple's built-in NSXMLParser does the job.
I use JSON, which is a great (and popular) solution for your server as well. Try out SBJSON for a good obj c library:
http://code.google.com/p/json-framework/
We are going to set up a solution where the iPhone is requesting data from the server. We have the option to decide what kind of solution to put in place and we are not sure about which way to go.
Regarding SOAP I think I have the answer, there are no really stable solution for doing this (I know there are solutions, but I want something stable).
How about REST?
Or is it better to just create our own XML? It's not going to be so complicated reguest/respons-flow.
Thanks in advance!
I've created an open source application for iPhone OS 3.0 that shows how to use REST & SOAP services in iPhone application, using XML (using 8 different iPhone libraries), SOAP, JSON (using SBJSON and TouchJSON), YAML, Protocol Buffers (Google serialization format) and even CSV from a PHP sample app (included in the project).
http://github.com/akosma/iPhoneWebServicesClient
The project is modular enough to support many other formats and libraries in the future.
The following presentation in SlideShare shows my findings in terms of performance, ease of implementation and payload characteristics:
http://www.slideshare.net/akosma/web-services-3439269
Basically I've found, in my tests, that Binary Plists + REST + JSON and XML + the TBXML library are the "best" options (meaning: ease of implementation + speed of deserialization + lowest payload size).
In the Github project there's a "results" folder, with an Excel sheet summarizing the findings (and with all the raw data, too). You can launch the tests yourself, too, in 3G or wifi, and then have the results mailed to yourself for comparison and study.
Hope it helps!
REST is the way to go. There are SOAP solutions, but given that all people end up doing with SOAP can be done with RESTful services anyway, there's simply no need for the overhead (SOAP calls wrap XML for data inside of an XML envelope which must also be parsed).
The thing that makes REST as an approach great is that it makes full use of the HTTP protocol, not just for fetching data but also posting (creating) or deleting things too. HTTP has standard messages defined for problems with all those things, and a decent authentication model to boot.
Since REST is just HTTP calls, you can choose what method of data transfer best meets your needs. You could send/receive XML if you like, though JSON is easier to parse and is smaller to send. Plists are another popular format since you can send richer datatypes across and it's slightly more structured than JSON, although from the server side you generally have to find libraries to create it.
Many people use JSON but beware that it's very finicky about parsing - mess up a character at the start of a line, or accidentally get strings in there without escaping "'" characters and there can be issues.
XML Property-lists (plist) are also a common way to serialize data in Cocoa. It is also trivial to generate from other languages and some good libraries exist out there.
You are not saying how complex your data structures are and if you actually need state handling.
If you want to keep your network traffic to a minimum, while still keeping some of the structured features of XML, you might have a look at JSON. It is a very light weight data encapsulation framework.
There are some implementations available for iPhone, for instance TouchJSON
Claus
I would go with simple HTTP. NSURLConnection in the Cocoa libraries make this pretty simple. Google Toolbox for Mac also has several classes to help parsing URL-encoded data.
I think it's obvious that REST is the new king of servers communication, you should definitely use REST, the questions should be what REST methodology you should use and what coding language, in my post I present few very simple implementations for REST servers in C#, PHP, Java and node.js.
There appears to be at least three different libraries for extracting JSON data from an HTTP request.
TouchJSON (http://code.google.com/p/touchcode/)
BSJSONAdditions (listed at json.org - http://blakeseely.com/blog/archives/2006/03/29/bsjsonadditions-12/
json-framework (http://code.google.com/p/json-framework/)
Any reason I would select one of these over the other or all they all about the same, in terms of speed and least bugginess?
The data I'm dealing with will probably have some semi-complex JSON strings.
I'd recommend TouchJSON. It's worked well for me performance-wise and at the time seemed easier to set up than json-framework (although json-framework works just as well). I have not used BSJSONAdditions.
Other related (or duplicate) questions: JSon and objective-c and Saving and Editing JSON on iPhone/iPod
I'm using the json-framework right now, and have no complaints. I've also heard good things about TouchJSON.
I'm writing a simple application that communicates with an external server.
The server currently supports yaml, xml and json.
Which encoding is fastest on IPhone?
Which has better support?
What libraries do you suggest?
I worked on a project that connected Motorola handsets running J2ME with a speech server in the network. We found that total bandwidth was worth optimizing (this was on a 2.5G network in 2004). So I'd suggest you measure how many bytes each serialization format takes and go with the smaller one (which will be JSON or YAML). You might even consider using a binary protocol like Hessian or Google's Protocol Buffers.
We also discovered that minimizing the number of messages decreased latency, so be on the lookout for ways to send data to the iPhone in fewer, larger chunks, use an HTTP cache on your phone, use HTTP entity tags and If-Modified headers, and so on. Since you're using REST, you're well positioned to leverage all these nice features of HTTP.
Of course this can all very easily be premature optimization, so code it up the easiest way possible and measure first.
I've created an open source application for iPhone OS 3.0 that shows how to use REST & SOAP services in iPhone application, using XML (using 8 different iPhone libraries), SOAP, JSON (using SBJSON and TouchJSON), YAML, Protocol Buffers (Google serialization format) and even CSV from a PHP sample app (included in the project).
http://github.com/akosma/iPhoneWebServicesClient
The project is modular enough to support many other formats and libraries in the future.
The following presentation in SlideShare shows my findings in terms of performance, ease of implementation and payload characteristics:
http://www.slideshare.net/akosma/web-services-3439269
Basically I've found, in my tests, that Binary Plists + REST + JSON and XML + the TBXML library are the "best" options (meaning: ease of implementation + speed of deserialization + lowest payload size).
In the Github project there's a "results" folder, with an Excel sheet summarizing the findings (and with all the raw data, too). You can launch the tests yourself, too, in 3G or wifi, and then have the results mailed to yourself for comparison and study.
Hope it helps!
Using json-framework, making your classes interoperate with JSON is ridiculously easy.
Well, if you want to use XML, use a plist, since its supported natively on the iphone.
JSON is not, but there are some good c libs available. I support JSON and XML in my app.
Same with XML - there's a bunch - just search around.
It also depends what media-types your server supports - btw, REST isn't really a protocol.
I have some benchmarks comparing the performance and payload sizes of the different serializers available here:
http://www.servicestack.net/benchmarks/NorthwindDatabaseRowsSerialization.1000000-times.2010-02-06.html
Basically, if you're developing with .NET web services than you are going to be making a compromise on payload size vs performance, unless you go with another serializer.
Marc's protobuf-net shows the smallest and fastest implementation:
6.72x faster and 4.68x times smaller than MS's fastest Xml Serializer; and
10.18x faster and 2.24x smaller than MS's JSON DataContract Serializer;
Although being a binary protocol, it may be harder to debug.
If your developing with MonoTouch (i.e. C#/Mono for the iPhone) and want to use a text-based format, than you may be interested in my Javascript-like type serializer that has been optimized for size and speed, it also shows modest gains over the available XML and JSON options, namely:
3.5x quicker and 2.6x smaller than the XML DataContract serializer; and
5.3x quicker and 1.3x smaller than the JSON DataContract serializer.
Here's a MonoTouch tutorial showing how to call web services from an iPhone:
http://www.servicestack.net/monotouch/remote-info/
IF you are ok with a c++ library in your iPhone projects, then please have a look at yaml-cpp:
http://code.google.com/p/yaml-cpp/
has native iPhone support (via it's cmake build system)
has no dependencies beyond a good compiler and cmake
is very c++ friendly (thus, the name) with solid documentation (see the wiki/HowToParseADocument page)
It really depends on your need and what kind of data you are going to transfer between server and application. If you want to execute queries to select some piece of data you should choose XML because of XQuery language support. JSON is not supported, as I know. I can nothing to say about YAML.
I have not seen any YAML libraries (though it does not mean there are none). I know TouchJSON works pretty well, and there is at least one other.
JSON takes less space than an XML or PLIST feed, BUT needs a little more thinking ahead of time to get the structure right.
One nice aspect of pLists is that you get back dates as objects without parsing. If you pass dates in a JSON decide on a format and use the same format everywhere. NSDateFormatter is not thread safe so you have to make an instance per thread, if you want to use a single date formatter to save resources.
there is support for all three formats in Objective-C. Just google for them. I would suggest writing a serializer that supports all three. Just make your URL resource request end with .xml|.json|.yaml and have the server decided what to serialize to based on that extension. Then you don't actually have to decide you can switch to whatever you want. Making the serializer pluggable is really easy in most server side implementations.
I have a fair bit of experience working with the iPhone SDK. I have a couple fully developed apps including a utility application for tracking data and a board game. I would consider myself a novice on the iPhone SDK. I also have no issues with reviewing documentation and examples for hours until I understand something, as long as the documentation exists and makes sense.
I am not however an expert at XML documents and parsing attributes and creating documents. I have written in the past PHP code to access web services and complete transactions via SOAP XML messaging. I need to do a similar application using iPhone SDK. Here is what I need.
1) Create XML messages to send to a SOAP service
2) Receive XML messages from a SOAP service
3) Parse the XML response messages into a custom object
All of the URL and SOAP part is relatively straight forward. Where I start to get discouraged is the area of creating and parsing the XML messages. Using PHP these tasks are very simple as the language has built in SOAP clients and you can easily class map objects to SOAP messaging and the heavy lifting of the XML processing is just taken care of automatically. I have considered writing a proxy PHP service and simplifying what is needed on the iPhone side but this just complicates what I want and adds a dependency on another app to work in conjunction with the web service I'm accessing.
It seems that in the iPhone SDK or objective-c in general you have to be a pro at the construction and the parsing of XML messages on your own. I am really discouraged at the idea of creating tons of custom code to parse each message element by element. I've taken a small look at TouchXML / KissXML and I am not thinking they are what I need.
The real key objective here is that I want to easily receive an XML message and some how get the elements and their values copied over to an object. How can this be done without hours of writing parsing classes and understanding all of the guts of creating XML documents?
I have used Matt Gallagher's XPathQuery to great success on the iPhone. It's simple and straight-forward.
I've found, though, that the messages I have need to parse are drastically simpler than what XML (and even his simplified parser) is capable of. I've modified his source to return a data structure that's much easier to work with -- instead of having keys a bunch of keys (nodeName, nodeContent, nodeAttributeArray, attributeName, ...) for each node, I simply create nested arrays and dictionaries with the node name as the key and the content as the object directly. I completely ignore attributes, and I only use arrays if there's more than one node with the same name. Here's that code. Note that it's only been tested on the XML that I care to work with. :)
Edit: whoops, I just realized you're also looking for XML creation. This just does parsing. I'll leave it here as a partial answer.
It seems like what you really want is this:
http://code.google.com/p/wsdl2objc/
As it will create objects for you from a WSDL, and provide support code to send/receive them.
However what is mostly happening, is that people are not using SOAP for mobile web services, but instead are going to RESTFUL approaches.
That includes posting form data in HTTP POST requests or querying via GET, then getting back either JSON or plists which turn into dictionaries (JSON is more widely understood by server developers BUT you have to be more careful to correctly define the structures being passed, since you can do things like have a dictionary with the same key repeated... plists are more robust in that you can't really build anything "wrong" but is less standard on the server side).
If you have to use SOAP though, WSDL2ObjC is probably going to save you a lot of mapping.