I need to implement basic RESTful functionality in my app e.g. post/get/delete + json parsing.
What would you suggest to use as a framework:
1) Resty http://projects.lukeredpath.co.uk/resty/ (ARC?)
2) http://restkit.org/ (ARC?)
What the advantage of each of them?
The reason I am asking is because yesterday i implemented some RESTful features using ASIHTTPRequest, but today I read is not being supported anymore :(
One more thing, I have heard there is a build in JSON support in iOS5 SDK (GCD Dispatcher or something like that), would it work for iOS4 client? (is it compile time or run-time dependency?), and can it do post/get requests?
Depends on your requirements.
If you just need some RESTful communication with a server then Resty isnt too bad (Though I never used it, it looks straightforward).
Restkit on the other hand is one powerful package because of 1 ultimate feature. Integration with core data. Restkit is able to parse Json responses, make them into objects and save these objects to core data with minimal coding out of the box. This makes it highly useful in case this is the type of functionality you are looking for.
I would encourage you to define the functionality you need and have a look at the frameworks. If it basic stuff, as you say, then one can argue that Restkit may be too powerful.
As for the inbuilt JSON parsing library, well it is way down the list in priority. These framework already includes a Json parser and they work pretty well. I would seriously consider the advantages before I go on to retrofit these packaged frameworks with a JSON parser of choice.
Related
I have a GraphQL service that I need to hit from an iOS app, and I'm trying to survey what my options are for client libraries geared towards this purpose. My initial impression is that there are not many good options out there, and I'm a little surprised by this since Facebook's mobile app is always cited among the motivational material for GraphQL itself.
What follows is my current understanding of my options. My questions is: what client library options am I overlooking? I'm also curious if you were to imagine the ideal GraphQL client library for iOS, what might it look like?
Just Alamofire, AFNetworking, or NSURLSession directly, passing in lovingly hand-crafted Query Documents and spelunking through a Dictionary representing the resulting JSON, or
Chester
GraphQLicious
Swift-GraphQL
This question was asked a long time ago - I think today the standard answer to this will be to use Apollo Client.
It uses a similar API as the Apollo Client on the web and has a couple of really nice features:
Static type generation based on GraphQL Queries & Mutations
Normalized cache
Query watching & automatic UI updates
Manual store updates
It has not yet reached 1.0 but overall is a super promising project!
Here are some resources that should help you get started:
Apollo iOS Quickstart
Apollo iOS on GitHub
Ray Wenderlich GraphQL Tutorial
Learn Apollo iOS Track
I would not build queries by hand, and I think both Chester and GraphQLicious would be fine for you.
If I had to imagine the perfect library, it should not only build queries but also parse the result into Swift objects. This, as you may know from JSON parsing libraries, is not a small task and that's why most of the GraphQL-Builder libraries don't do it.
Disclosure: I'm one of the guys behind GraphQLicious
I need to write an app to deal with a Rest and SOAP API (both).
What do you think is better? RestKit or AFNetworking? Neither? Both frameworks work easily with REST. Can SOAP be a problem?
Ideas:
RestKit ( + XML parser for SOAP cases)
AFNetworking ( + XML parser for SOAP cases)
I've read that the latest version of RestKit is built on top of AFNetworking.
What do you think is a better practice?
RestKit is great at REST. Yes, it is built on AFNetworking so you have a lot of flexibility. The power of RestKit is in its ability to map from the received data to your data model. If you will be able to leverage this ability then it should be worthwhile.
Otherwise, you may want to look at things like SOAPEngine or pico (but they aren't as actively developed as RestKit or AFNetworking).
I am trying to get the data of UserProfiles from SharePoint 2010 site using Objective-C within xCode.Now I am using the SOAP service in my project. Is anyone able to point me in the right direction here? Thank you....
You probably mean "iOS" or "Cocoa" instead of Xcode.
If possible, avoid SOAP. It's much easier to access a web service via REST and using JSON as transport format - and in 99.8% of all use cases, a RESTful web service and JSON will fulfill all your requirements up to 100%.
What you need to accomplish your task can be summarized into "networking development", which involves NSURLConnection (and related friend classes), and NSJSONSerialization and a few other system classes depending on your needs.
Unless you stay with a RESTful web service and JSON and moderate requirements, networking may become quickly complex. And it becomes unnecessarily complex when using SOAP. Possibly you may want to utilize a third party library which may help here.
I'm assuming you are already familiar with the basic major principles when programming in Objective-C and for Mac OS X and iOS. So, I would suggest to start with reading examples from the Apple docs involving networking and utilizing NSURLConnection (e.g. MVCNetworking).
I'm trying to find a straightforward way to consume arbitrary iOS libraries from MonoTouch. At the moment, I need this calendar functionality, but the question applies to any such component.
I've read the Xamarin article on creating iOS bindings, but the process of building these bindings looks so complex (and tedious and likely error prone) that I think it would actually be easier for me to re-implement the given functionality in C# from scratch than it would to go through this process. Creating these bindings would require a deep dive into ObjectiveC, and I'm using Xamarin precisely so I don't have to do that.
As it stands, I am torn because I really want the ability to access some iOS libs, but don't have the time to master this process enough to create these bindings. Is there any other way to access these libraries?
(I wonder if there is or could be any sort of automated binding generator? It seems to me that 95% of the work is boilerplate translation of ObjectiveC headers to C# idioms, and an automated tool could do this, and then the final tweaking could be done by hand.)
You can:
Consume the ones that are already bound: you can find many on github, in particular in monotouch-bindings, and in the (just announced) Xamarin's Components Store;
Bind them yourself. That does require some Objective-C knowledge. Some tools/scripts exists but, in the end, the manual by hand editing is where the Objective-C knowledge is needed. There are general unit test (e.g. for Touch.Unit) that you can re-use that will dramatically reduce the number of bugs in them (blog post will be coming up soon to describe them in details).
Convert (or write from scratch) some into C# components;
I do realize that this question seems very well known, but since I don't have a lot of experience using SOAP web services and as far as I could find this is not very common topic on iOS and especially OS X, I will ask it again.
I have tried wsdl2objc and sudzobjc and both solutions seem to be pretty much complex. I have a feeling that there is a lot of overhead, too, especially with all those types defined and pointers used.
If I compare this to simply using standard Cocoa classes NSURLConnection and NSXMLParser like in this example:
http://abhicodehelp.blogspot.com/2010/12/handling-soap-with-iphone.html
like when using RESTful web services, it feels like overkill...
I would appreciate anybody to give me a hint, why this more complete approach is better and wouldn't it be better to use any other C or C++ libraries that at least by first look seem much lighter and easier to use?
The problem of SOAP is that it's really, really bloated! It's called Simple Object Access Protocoll but it's anything but simple. It's based on XML and (mis)uses all of it's complexity with WSDL and XMLSchemes and all that stuff. I started working with SOAP in my Java time as it was just invented. And we had OutOfMemoryExceptions more than once because of the size of the XML message.
That said: calling SOAP services with Objective-C will be as complicated as it is with Java or any other language. The problem is you need to create rather (or even very) complex XML structures to call a service. I knew wsdl2java and that helped a bit but it created a whole bunch of classes and abstractions and stuff.
I understand the idea behind WSDL and all the XMLSchema stuff that's used in SOAP. It's to create a service and it's specification so that others can call it without problems. But I don't think that's the way to do it.
If you've got the choice take REST! REST is the real "Simple Object Access Protocoll" as it really is simple. And it can also use XML as a message format, even though you wouldn't want to. REST with JSON is the way to go. You only need to understand HTTP to understand REST, IMHO.