4

Server side - C# or java

Client side Objective C

I need a way to serialize an object in C#\java and de-serialize it in Objective C. I'm new to Objective C and I was wondering where I can get information about this issue.

Thanks.

buc030
  • 425
  • 3
  • 14
  • 4
    JSON is pretty lightweight and should be easy to map between all three of those languages – Paul.s May 02 '12 at 23:13

5 Answers5

5

Apart from the obvious JSON/XML solutions, protobuf may also be interesting. There are Java//c++/python backends for it and 3rd parties have created backends for C# and objective-c (never used that one though) as well.

The main advantages are it being much, much faster to parse[1], much smaller[2] since it's a binary format and the fact that versioning was an important factor from the beginning.

[1] google claims 20-100times compared to XML

[2] 3-10times according to the same source

Another technology similar to protobufs is Apache Thrift.

Apache Thrift is a software framework for scalable cross-language services development. Apache Thrift allows you to define data types and service interfaces in a simple definition file. Taking that file as input, the compiler generates code to be used to easily build RPC clients and servers that communicate seamlessly across programming languages.

Greg Kopff
  • 15,945
  • 12
  • 55
  • 78
Voo
  • 29,040
  • 11
  • 82
  • 156
  • There's the toss up between speed and readability I guess. It will most likely be considerably more annoying to debug as it's binary... – Paul.s May 02 '12 at 23:36
  • @Paul I never understood that argument. If I have to debug messages, I'm usually already in the code and can just stop the debugger 3 lines later when I get the parsed classes back. If I really have to debug some stored data, writing a trivial script to get a human readable version is quite simple too. Imho the only real downside is that it's by far not as established for exchanging data with the outside world. For that purpose I can also understand the self describing nature of XML (without the protobuf file you'll have a hard time understanding what a binary blob is doing). – Voo May 02 '12 at 23:39
  • cont. In my own experience for internal data exchange, I can't remember the last time I looked at the XML/JSON data itself and not just the represented data structures after the parsing step - it seems simpler to me, but in the end that's all subjective – Voo May 02 '12 at 23:41
  • I may not have a debugger available - this object is coming over the wire and I may not be at my workstation with just the right set up/tools available, but I can simply curl the url and read it pretty easily - yes it's still a relatively weak example :), that's why I said it was a toss up. When I'm coding I often choose readability over raw performance until the profiler screams – Paul.s May 02 '12 at 23:41
  • @Paul I think that example goes in the direction of data exchange with the "outside world" ie 3rd parties, etc. I think in that case the self-describability (ugh, yes I know that's not a word) of XML is indeed quite useful. From an usability pov I think XML with modern libraries and protobuf are pretty much a toss up - XML with JAXB or the small protobuf classes are pretty identical, although I think I'd prefer the annotated version if everything else was identical – Voo May 02 '12 at 23:44
  • But the OP was talking server/client, you never know who will end up consuming your feed later down the line, imagine how much harder all of the twitter example app blogs would be if twitter didn't offer human readable feeds – Paul.s May 02 '12 at 23:45
  • Well you've sparked my interest - I read about protobuf a while back and forgot about it. It depends if you have the luxury of controlling server/client - we have a hard enough time trying to clients to output JSON... – Paul.s May 02 '12 at 23:50
  • @Paul Because of my own background I was thinking about controlling both client/server, but clearly that's only one possible interpretation - shows ow we're all shaped by our experiences. I agree that for a public service where it's expected to have lots of 3rd party clients not under direct control that protobuf probably isn't the best way to go, not only because of its binary format, but also because a **much** bigger audience knows JSON/XML. – Voo May 02 '12 at 23:54
1

JSON for relatively straight forward object graphs XML/REST for more complex object graphs (distinction between Arrays / Collections / nested arrays etc)

Tim Jarvis
  • 18,465
  • 9
  • 55
  • 92
0

Sudzc. I am using it. It is pretty easy to invoke a Webservice from i-os app.

You dont have to write code to serialize object.

Sandeep
  • 7,156
  • 12
  • 45
  • 57
0

JSON is probably the best choice, because:

  • It is simple to use
  • It is human-readable
  • It is data-based rather than being tied to any more complex object model
  • You will be able to find decent libraries for import/export in most languages.

Serialisation of more complex objects is IMHO not a good idea from the perspective of portability since often one language/platform has no effective way of expressing a concept from another language / platform. e.g. as soon as you start declaring "types" or "classes" of serialised objects you run into the thorny issue of differing object models between languages.

mikera
  • 105,238
  • 25
  • 256
  • 415
0

On iOS there are couple of JSON frameworks and libraries with an Objective-C API:

are probably the most prominent.

JSONKit is fast and simple, but can only parse a contiguous portion of JSON text. This means, you need to save downloaded data into a temporary file, or you need to save all downloaded JSON text into a NSMutableData object (kept in memory). Only after the JSON text has been downloaded completely you can start parsing.

SBJson is more flexible to use. It provides an additional "SAX style" interface, can parse partial input and can parse more than one JSON document per "input" (for example several JSON documents per network connection). This is very handy when you want to connect to a "streaming API" (e.g. Twitter Streaming API), where many JSON documents can arrive per connection. The drawback is, it is a much slower than JSONKit.

TouchJson is even somewhat slower than SBJson.

My personal preference is some other, though. It is faster than JSONKit (20% faster on arm), has an additional SAX style API, can handle "streaming APIs", can simultaneously download and parse, can handle very large JSON strings without severely impacting memory foot-print, while it is especially easy to use with NSURLConnection. (Well, I'm probably biased since I'm the author).

You can take a look at JPJson (Apache License v2):

JPJson - it's still in beta, though.

CouchDeveloper
  • 18,174
  • 3
  • 45
  • 67