Web services -> core data -> controller -> view and then reverse...
Sound right?
Or is there a better way, one that avoids the complexity of SOAP?
Additionally can core Data recognize XML coming from SOAP?
Thanks // :)
There are several good REST libraries that work on the iPhone if you want to avoid SOAP.
HTTPRiot - http://labratrevenge.com/httpriot/
ASIHTTPRequest - http://allseeing-i.com/ASIHTTPRequest/
ObjectiveResource - http://iphoneonrails.com/
I've used the first and last and between those two, I really like HTTPRiot - really easy to use, doesn't get in your way and converts both XML and JSON responses into NSArrays and NSDictionaries.
Core Data doesn't have any relation to Web services natively but you can easily populate managed objects from the data you receive from one of the above libraries.
Related
I'm not sure this question is appropriate here but I hope I could get some help. What i'm looking to do is basically to make a server based iPhone application. I've got an ubuntu server ready to be used. I'm thinking of making a web service which my application then can use but I have virtually no experience in this field so i'm looking for some help to get pointed into the right direction, what language to write the web service in etc. It isn't required to be a web service but anything that make's the iPhone app depending on the server.
This little mission is simply for learning experience.
Probably PHP is what you will use to write the webservice. REST based services are the most popular, but it could be as simple as a form POST passing in parameters. The PHP script (no matter which way you write it), will then pass those parameters and any other needed info to a server method that either executes a SQL query (preferably using a stored procedure) or uses some other server resource. That data would then be output via the webservice as either XML or JSON (I personally like JSON better).
Check out Ray Wenderlich's tutorial on just this kind of thing:
When it comes time to handle the request in iOS, my personal choice is AFNetworking. It uses blocks instead of delegate methods and is blazing fast. I can hook you up with examples if needed.
Ok, First you need to learn how to write web services in PHP. Which will return you response in XML format. I personally prefer .PLIST format because it gets easier to parse on the iOS.
Once your web services are up and running. You need to use NSURLConnection and NSURLRequest to talk to your web services. Implementing the NSURLConnection Delegate methods correctly, you can download your XML response, maybe save it in a file on your Documents Directory.
Then once done downloading start parsing that response using NSXMLParser. implementing the delegates and what not, you can create your data structure the way you feel comfortable with manipulating it and store the parsed results in them and populate your View accordingly.
I just want to get a few pointers on the best way to architect my first Core Data app, and the main objects and interactions I will require.
The data is stored remotely and I will need to access it via HTTP and it will respond in JSON format. I want to cache this on the device using Core Data. Each day there will be new data on the server, so I need to access this and update the Model accordingly.
Are there any SDK classes I can use to help me with this, or am I going to hand roll it?
I guess I'm looking at a Model Controller that I call to get the data, it will return the core data cached data and maybe make a background call to the web service to get latest data too and then notify the view that there is new data. When I get the data from web service in JSON format - i will need to map this to ManagedObjects an add to my core data context.
Thanks dtuckernet, here is what I did do - gathering info from lots of sources, which I believe is the best solution. Anyone feel free to criticise (constructively)....
I have my Core Data stack in CoreDataStack.h (singleton) - not entirely necessary, but it unclutters my app delegate class.
I have a base CoreDataBackedTableViewController : UITableViewController
Each of my table view screens extends CoreDataBackedTableViewController and have an ivar to a ModelController class.
An example ModelController class has a - (NSFetchedResultsController *) getData method which constructs the NSFetchedResultsController (also keeps a ref to it) and returns it to the view controller which also stores it in CoreDataBackedTableViewController (which listens for updates and edits to the data). Having the ModelController class allows me to encapsulate my data access to potentially have 2 different view controllers use this (iPhone and iPad perhaps)
In getData - i make a call to my backend webservice asynchronously. Using delegates for callbacks
The backend is using SBJSON for parsing and NSHttpConnection and a hand rolled HttpService class.
When the backend returns with data, it calls the delegate on the ModelController which updates core data - and my fetchedResultsController knows about this and automatically updates my interface ! How cool is this bit - not a lot of effort involved on my part. I have to do some detection on whether i've already downloaded the data before or not to avoid duplicates.
Ready to roll this out to the rest of my app....
If anyone wants any clarification on any of the steps, just let me know.
There are a lot of different pieces at play here. Allow me to make some suggestions:
For fetching the data from the server, I would look at ASIHTTPRequest. This is a good solution for managing your HTTP requests (whether you are using JSON, XML, or whatever..). http://allseeing-i.com/ASIHTTPRequest/
For JSON translation, I would look at SBJSON. The site has documentation on how to get started: http://code.google.com/p/json-framework/
For your overall architecture, I would implement a delegate pattern that wraps your service calls. In this delegate, you would handle the translation of the JSON data to actual Objective-C classes before the data gets passed to the rest of the application.
Once the data is parsed and placed into Objective-C objects (and I would have these objects be subclasses of NSManagedObject which ties to your data model directory), I would perform a save.
I would then use an NSNotification to inform the needed views that the data has changed.
You absolutely, definitely want to use RESTKit. This is a direct connection from your RESTful web service to Core Data. Define your data model using Xcode's built-in tool, define a mapping layer for your web service using RESTKit, and let the library do the heavy lifting. It's wonderful.
I currently have a MySQL database that I wish to create a web service for.
One of the main purposes of this web service is to be used in an iPhone app. Because of this I would like to used CoreData, as it will make parsing on the iPhone side so much easier. How would I use CoreData to get the data from my MySQL database? Are there any good tutorials around?
To get the data from the server to the iPhone I would recommend JSON.
Then you need to write some code that will turn that JSON into an object that you can put into the CoreData database. You have a couple choices there, but I would recommend providing your own implementations of the NSCoding protocol. The great part about the NSCoding approach is that the object itself defines what it needs to save/restore one time, then you simply do additional implementations one time to support other formats (e.g. XML, JSON, simple serialization).
Here is the tutorial to sbjson, a JSON parser on Objective-C: sbjson project
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.