This is a question about application architecture. I'm working on a iOS client app and (RoR) server backend. It seems like I spend needless mental energy creating data models on the RoR server, serving that model as JSON (that part is easy enough from Ruby), creating objective-C data objects, and writing JSON/NSDictionary serializer/de-serializers for said class.
It seems like I should be able to just, write a data schema (in ruby, yaml, json, whatever), and get the ruby object, obj-c object, and json serialize/deserialize for both for free. Anyone have any thoughts on this issue?
Thanks!
look at the different libraries available. the one that works the best is RestKit. http://restkit.org/
RestKit allows you to easily translate a JSON API into coredata objects that are synced on the client. you can tell it what objects to update and how.
Related
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!
I'm building an iOS client app to interface with an existing backend architecture. To reduce latency, API calls and payloads, it'd be nice to "cache" model data client-side for faster indexing and then make updates to both client/server sides accordingly as needed.
The current theoretical stack would look something like this:
Server Side >>>>>>>>>>>>>>>>> Client Side
-----------------------------------------
PHP >> JSON >> CORE DATA >> UIKit Objects
NOTE: It's also worth noting that the iOS client, while itself adhering to MVC internally would in essence be a "View" in a larger MVC client-server architecture. Thus, just like one updates the model after a user action or updates the view after a model change, the server would need to sync with a client change and the client would need to sync with a server-side change.
Some Context:
A. Many diverse data structures may be coming over the pipe and would have to be constructed into UIViews dynamically. A schema will likely have to be defined (I'm not sure if there's a "best way" to adhere to a JSON schema client-side other than remembering what the acceptable object structures are). I've realized the need to separate model data pertaining to the creation of custom views ("View" Models) from model data of what will be presented in those views ("Regular" Models).
B. End-users should be able to immediately CRUD (create, read, update, destroy) most data presented in these views (but not CRUD the views themselves). They may later need to view this in a web interface or other context.
C. RestKit looks like a good candidate for getting from the API to JSON to COREDATA. I need to find out if it structurally supports callbacks when client model copies need to be pushed to the server. Perhaps the best way is noting in the client model when a change has occurred and notifying whatever RestKit-based HTTP manager to pass it along to the server.
Ultimate Question:
Can anyone speak to best practices, pitfalls, tips, and frameworks with this type of architecture? (Particularly when it comes to performance and the distribution of work between client and server, but general advice is also much appreciated.)
I've done some work around this, hopefully I can provide some insight.
In regards to A) Yes if you're planning to use CoreData (or RestKit) you'll need to know you schema up front. You'll have no way to map dynamic objects otherwise unless you have some generic object type where you're just stashing the JSON string or something, but this doesn't sound like what you're trying to do since you mention users editing those objects.
B) RestKit will handle pushing to the server for you, but you'll still want some control over this I imagine. We handled it by always saving locally first then pushing up to the server on a successful save. This also enabled us to work when there's no network. You'll just have to handle the edge cases of what happens when the server rejects the update / create / delete your user is performing.
C) RestKit will likely get you 80% of the way there, as it did for us. Just having something to understand REST endpoints and object mapping, and abstracting the HTTP requests was a huge help. In terms of the system understanding changes, we kept a flag on managed objects as to whether the object needed a sync or not. We could fetch based on those flags and push the server up.
One thing with RestKit is that you can have other attributes in your CoreData model that aren't necessarily a part of the JSON schema, but you might need within your app. For instance I already mentioned the flag for knowing whether an object needed sync. We also kept pre-computed fields that we used to search on and some other random pieces of information for determining the order of objects to push up to the server (dependencies).
Hope this helps. If you have more specific questions I might have more answers.
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.