In my iOS app, I am trying to get and post data from a (RESTful) server. I think for that both RestKit and AFIncrementalStore are good candidates.
However I also need to be able to save data offline and push it to the server when the app is online.
I am trying to understand which is a better framework to use for the application.
Also, from some of the online resources, it seems that using faulting on AFIncrementalStore could potentially cause the thread handling ManagedContext (usually the mainThread) to get stuck while furnishing the network request to get a property. Is it a big deal?
PS: Adding afnetworking tag since afincrementalstore tag is not available
AFIncrementalStore works within Core data, sending back to your Web service. It uses the relatively new API Apple provides called NSIncrementalStore.
RestKit works from outside Core Data, binding HTTP requests to Core Data loosely using the object mapping architecture RK provides.
Here are some pros & cons for both:
New RestKit version (0.2.x) is ligther than the 0.1 version
RestKit now use the really good AFNetworking for all his HTTP request work, just like AFIncrementalStore.
ResKit has A LOT of test coverage
AFIS is really light since it's built on NSIncrementalStore
AFIS give you a bit more flexibility, since you're pretty much on your own
RestKit is pretty huge and can be scary at first
RestKit is a complete solution, but takes time to fully wrap your head around all its concepts
My final recommendation would be to take the time and try both. What I can confirm is you'll need to drop a bit more lines of code using AFIS, since it does not take you by the hand as much as RestKit, so it's really a matter of preference.
Hope this will help you make the right choice!
Related
I have a web app, that also has an iPhone and Android app using the same API. It hasn't yet been made publicly available, so I wanted to look to convert from SOAP to REST.
I was only able to find a few tutorials that go into thorough explanations of how to code a REST web service, and of those I only found the MSDN one useful. The problem is I got really confused when they started using URI data types inside the object.
My question is, if you are converting SOAP to REST, do you have to recreate all the objects to add the URI? Am I not able to just have a REST entry point, then call one of the classes that retrieve the data?
Once the REST service is made it will only be used by my mobile apps, but not the website (since that can directly access the classes), which makes me not want to change the objects to add a URI. Is that a correct assumption to make, or should the web services also be called by the website?
Sorry if these are newbie questions, but I am struggling to get my head around REST, and I haven't had much experience creating the architecture of potentially high user base apps.
If anyone is able to point me to an actual code set, that would be helpful.
Edit: I am using VS2010, coding in C# and .Net 4.
Thanks a lot,
Andy
Im doing a very similar thing right now :). Rest via wcf isnt too hard, you do have to sometimes add your endpoints in the web config and give it the [webget]/[webinvoce] attributes in the refrence.cs of the web refrence when consuming though c# which is annoying.
Here is a code set i used when getting started. There are a few more on code project too.
we were asked to develop an iphone app like the one in the figure.
The problem is: we have no experience in IOS development.
For the basic part I can handle the learning curve, but i need suggestions, best practices on the UIKit model and controls.
This is a newspaper app.
The accordion control shows/hides content based on categories retrieved by an ASP .NET CMS on which we have no control.
I can suggest to the CMS holder to develop a couple of web services (WCF) but i'm not sure how to interface iOS with MS technology.
Furthermore, i have the idea that simple aspx that returns XML/JSON data will be easier to call, and support, but slightly less secure.
So, suggestions? Tutorials?
If you like to use JSON and a very good HTTP-request-framework I have two links for you. Both sites contain various tutorials on how to use them.
json-framework
ASIHTTPRequest
Concerning the request and delegate stuff: For a start, I would skip the delegate part and use a synchronized HTTP request called in a thread (you'll see what that is on the second website). That makes the response handling a lot easier for the start. But I personally think, that using an asynchronous request is not a must. It's just nicer, if the architecture allows it. In my application, it wasn't realizable without lots of code overhead.
You want to output an XML feed in "plist" format (look it up, its simple theres lots of info on it).
Then you can do:
NSArray *plistContents = [NSArray arrayWithContentsOfURL:[NSURL URLWithString:#"http://theinternet.com/pathToMyPlist.asp"]];
That will get all the output into an array.
Some other resources you may find interesting/useful include NSURLRequest and NSURLConnection. For the latter you will have to learn about delegate methods and such - its complicated, but its incredibly useful information.
We did several applications here using XML parsing like what you're suggesting at the end of your question. If you are concerned about security, you can implement handshaking or other security measures over that.
EDIT: XML parsing done using NSURLConnection to gather the content and NSXMLParser/NSXMLParserDelegate to do the actual parsing.
EDIT2: There is an official sample, called SeismicXML from Apple. It should get you started with iPhone XML parsing and data downloading.
The description page for my .NET web Service includes 4 different protocols to use to consume it.
SOAP 1.1
SOAP 1.2
HTTP GET
HTTP POST
In my work-in-progress iPhone application I have used both SOAP 1.1 and HTTP GET to access the XML data and am then parsing to get the information I want.
I'm now refactoring the application and am creating a Data Library class that will use code-reuse to make my current data operations easier to maintain.
SOAP 1.1 seems straight forward enough, if a little unwieldy, are there any benefits for me to use SOAP 1.2 on the iPhone. I'm presuming the differences will have little consequence when all I'm doing is basic XML parsing for strings.
Also HTTP Get seems the easiest of the lot! A simple dataWithContentsOfURL appears sufficient to get what I need, I don't even need to do a post.
Are there any idiosyncrasies on the iPhone that make any of these techniques better than others?
I'm going to research a REST services now. I think I understand the concept of stateless but not sure how it applies to the 4 options above.
Thanks in advance!
dataWithContentsOfURL
Has always worked for me with no problems.
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.
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.