I would like to know if there is any way (or fork project of RESTKit) that allows to do streaming of the HTTP response body instead of loading everything in memory like RESTKit is currently doing.
Thanks a lot
Looking over the code, it doesn't look like that RestKit suports streaming of the response body.
It looks like you might need another solution. I hear AFNetworking is really good for doing the networking part of it (I haven't used it yet myself). And I've used "YAJL" to do a streaming JSON parser. Apparently AFNetworking can hook into YAJL... not sure how this would work, but you might look into this.
Related
Basically I have a Go server which parses some XML file and creates a structure with the data which I want to send over TCP to an IOS app.
At the moment I tried to use Protocol Buffers, but I am having problems with this on the IOS side. So from your experience is this the best way I should transmit my data ? Any other suggestions ?
The first thing I am looking for it's speed.
There is no best way. There are plenty of cross-platform serialization formats out there. Just pick the one you are the most comfortable with, and which suits your needs.
An obvious choice is json (human readable and well supported on all platforms).
If you favor speed, then have a look at msgpack:
http://msgpack.org/
https://github.com/msgpack/msgpack-go
https://github.com/msgpack/msgpack-c
https://github.com/msgpack/msgpack-objectivec
Ponydebugger looks like a very useful tool.
Is there any way to use it with Xamarin's Monotouch?
It looks like a very nice approach (I won't pray for rain but there's a long weekend coming in... ;-).
At first look you should be able to use it with MonoTouch just like any other native library (i.e. create bindings) and link the .a with your application.
The good news is that it should be relatively simple since the API is small (versus the code base and the features you get).
The bad news is that I'm pretty sure it won't, without changes, handle System.Net.WebClient, HttpWebRequest ... since they are not built on top of NSUrl* classes.
I'm building an application that needs to communicate with a REST service.
The application is using ARC so ASIHTTPRequest is NOT an option.
Also RESTKit horribly failed when we tried to use it.
How should we tackle sending the http request? (preferably asynchronicly) and 'storing' the data to be parsed by an XML parser (I don't really need help with that, just need to know how to feed it the data).
You don't need to use ARC everywhere, check out this question and answer, you could just disable ARC for the third party libraries.
Disable Automatic Reference Counting for Some Files
You can use AFNetworking its a very good Lib for REST communication protocol. And you can just disable ARC for AFNetworking as well.
I would like to understand advantages of using RESTKIT/ASIHTTPREquest libraries over the traditional NSURLconnection for calling RESTFUL/SOAP webservices. I had used both type of webservices(RESTKIT/SOAP) in my project with nsurlconnection and I am successful...
Hence anyone pls help me to understand the benifits of going to RESKIT/ASIhttprequest...
RestKit has good integration with CoreData. ASIHTTP uses blocks which can be nice for firing one off requests. The more I use different network libraries, the more I think there is no one-solution to this problem yet.
Be careful with ASIHTTPRequest. Yeah, it is great and all but it was last updated May 2011 and the author has stopped development on it. See http://allseeing-i.com/%5Brequest_release%5D;
I'm looking to port my working Android XML parser to Blackberry, but the latter's Java feature set isn't as rich? I didn't want to have to write two parsers.
The following code yields "The method getXMLReader() is undefined for the type SAXParser":
SAXParserFactory spf = SAXParserFactory.newInstance();
SAXParser sp = spf.newSAXParser();
XMLReader xr = sp.getXMLReader();
Am I just out of luck here?
It's true I am trying to use org.xml.sax. I've read all the XML parsing discussions I can find out there. I wonder now if I can do this? Should I be using org.kxml2 instead because org.xml.sax makes no sense in BlackBerry land?
Thanks for any advice!
Russ
You don't need to use the getXmlReader() method.
Now that you have your SAXParser use it to parse a document or stream.
SaxParserFactory spf = SaxParerFacter.newInstance();
SAXParser parser = spf.newSAXParser();
Open your stream or file and call and assign it to a variable. Let's call ours input.
parser.parse(input, handler)
The handler file will implement all of the call backs to handle the events the parser encounters.
I found this explanation of SAX to be quite helpful.
I'll answer this though I suspect there are others who know better.
My assessment of BlackBerry is that it's very poor in its API set. So, the SAX XML parser isn't available as it is on Android. Okay, that's cool. It's older and from a "smaller" time.
Worse though, it appears very challenging even to add a third-party library to a BlackBerry application. I followed various posts out there and failed to incorporate my own "third-party" JAR convincingly into a BlackBerry project despite the collective wisdom of a number of web pages on the topic.
I was thinking then of writing my own parsing engine to replace SAXParser.parse(). How hard could it be since my expectations for it are childishly simple?
Very hard indeed since it appears that the JavaME support for java.lang.Class is impoverished as well; it doesn't support the important reflection methods such as getDeclaredMethods() for use in creating the engine (into which I naturally wanted to plug my existing XML parser-handler).
Alas, this makes me wonder just what BlackBerry apps out there are able to do? I'm probably giving this world short shrift, but a couple of days were sufficient for me to go from zero to parsing XML texts off the web on Android, so I expected a very easy time of it here too.
Please feel free to shred my answer. If you can and do, especially if you add a real one, it will doubtless greatly benefit other folk new to BlackBerry development including me later when I come back to the problem (so that I can avoid brute-force stringing through the XML stream instead of cleanly parsing it).