I am very new to iPhone development and previously was working with Java.
Currently I am using SOAP web services in my project and want to continue with the same.
But everytime i have to write the same code for all kinds of web services except for the parameters.
Can anyone guide me regarding how can i create a reusable code for web-services, so that i can use it as a static library or something for every project and then i wont need to write any code separately for each kind of web service?
I want to create a code which would be very generic and will be work for all kinds of web services irrespective of the number of parameters.
create the singleton class and method will be class methods then they will be globally used you can use them by doing a little modification in the code .
Create a seperate Webservices Manager Class (.h and.m) files where you have to write code for nsurlconnection and urlrequest creation in a method.
Also place all the NSURLConnection delegate methods(connection:didRecieveResponse: etc) in the same class to handle the response coming from server.
Create protocol methods to pass this nsdata response from the NSURLConnection delegate method(connection:didReceiveResponse:) to the appropriate classes. Implement the delegate method in those classes, get the response from this common nsurlconnection class.
Parse the response data.
So when you need to call a webservice, just make a call to the nsurlConnection creation method of the WebservicesManager class ( [webserviceManager connectTo:#""]) to actually initiate a webservice call.
Related
I just want to know what is the best practice for Networking in Swift? For example, if I want to fetch data using different Flickr methods, should I create a single NetworkingManager, that will send all requests, and appropriate DataModels? Or it is better to create only necessary DataModels and inside create a function that will do networking (but there will be a code duplication)??
THNX!
you can create as many clients as you want
e.g. loginClient class for the login call
profileClient class for getting profile data
or you can add both of them into a userClient(). it does not matter.You can make a folder name RestClients or Application Services.
for best practice what i would do is create necessary DataModels and map incoming data through it to create object.
In my opinion best practice would be using classes and protocols as networkManager:
1-a Client class where you define your get/post/... methods
2-Create an Enum and define ur APIs
3- create your data models
4- create Services class where you fully define your APIs and how they should work
I can send you a sample if you wish :)
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 have an application in which I have to hit many web services in same class and from another classes also and I have to parse the data each time.I cant write the delegate methods for webservice hit and XML Parse everytime as its not a good programming practice. So I thought of maintaining common classes for 'webserviceHandler' and 'XMLParsingHandler' in which I will write delegate methods for web service and XMLParsing respectively.
Now the problem is how to make it happen to call these delegates each and everytime I hit the webservice from another classes..??
Code for this is more appreciable..
Thanks in advance..
Cocoa Programming for Mac OS X Chapter 28. Web Services using NSXMLDocument
There is also an example from ADC SeismicXML using NSXMLParser
Accessing Web Services inside an iPhone app is a matter for which I did not find a clear, beautiful solution yet. I'm not talking about how to send queries or parse responses here, but about a "big picture" answer.
Disregarding the server-side technology, how do/would you plug your Model objects to your Web Service ? How do you design your proxy objects ? How do you cache your resources ?
If your web service happens to be a Ruby on Rails application, then Objective Resource is a great tool: http://iphoneonrails.com/.
If not, then what I tend to do is use ASIHTTPRequest (http://allseeing-i.com/ASIHTTPRequest/) which provides a nice network layer. Depending on the API, you might use ASI objects directly, or else you can subclass an existing ASI class if you want to add per-request functionality (such as authentication or response parsing).
You usually want to run requests in the background, so that the UI isn't blocked while waiting for the request to finish. You can always go the background thread route, but a nice "Objective C" style approach that ASIHTTPRequest provides is to instead provide a delegate which is called when the request finishes (see also "Creating an asynchronous request" at http://allseeing-i.com/ASIHTTPRequest/How-to-use). In many cases the request delegate is the view controller that initiates the request.
The model layer depends on the complexity, and also what format the data comes in. Most of the APIs I've worked with use JSON, for which you can use SBJSON or yajl-objc to parse. These usually give you the data parsed into base classes like NSString, NSArray and NSDictionary. Sometimes that's sufficient, or if you want your models to exist as their own classes, then you can have the models inherit from a base class that takes care of turning the NSDictionary/NSArray into properties.
Finally for caching, Core Data provides a good way to persist to disk. For caching in memory, you can have the requests occur in a separate "manager" class that is shared between controllers. These managers use the Singleton design pattern as described here: What should my Objective-C singleton look like?.
I'm developing an app that will talk with a web service exposing multiple methods. I'm trying to figure out what the best pattern would be to centralize the access to the web service, give options for synchronous and asynchronous access, and return data to clients. Has anybody tackled this problem yet?
One class for all methods seems like it would centralize everything well, but I'm thinking it would get confusing to return data to the correct places, especially when dealing with multiple asynchronous calls. Another thought I had was a separate subclass for each method, with some sort of factory brokering access, but I'm thinking that might be overengineering the situation.
(note: not asking for what method calls to use/how to parse response/etc, looking for a high level design pattern solution to the general problem)
I recently came across the same problem. While I don't believe my solution to be optimal, it may help you out.
I created a web service manager and an endpoint protocol. Each object that implements the endpoint protocol is responsible for connecting to a web service endpoint(method), parsing the returned data, and notifying its delegate(usually the web service manager) of completion or any errors. I ended up creating an EndpointBase class that I use 99% of the time.
The web service manager is responsible for instantiating the endpoints as needed and invoking them. All of the calls happen asynchronously.
All in all it seems to work pretty well for me. I did end up with a situation in which one endpoint relied on the response of another (I used the command pattern there).
SDK Components that you'll want to look at are:
NSURLConnection
NSXMLParser
Factories? We don't need no stinkin' factories.
I've done this a few times, and I basically do what you're saying: one object that provides methods for all the web service calls, encapsulating the details of communicating with the service, handling connection issues, etc. In one app it was a singleton, because it needed to keep session state; in another app it was just a collection of static methods.
Along with some formatting of the response data, that's the entirety of its responsibility.
It's left up to the callers is whether the call is synchronous or asynchronous; the class itself is written synchronously, and a caller just uses it in a separate thread if necessary. Cocoa's performSelector... methods make that easy.
If REST is a good fit for your data interactions, then I would suggest the ObjectiveResource library . It's designed to work seamlessly with a Ruby on Rails app, but it basically speaks JSON or POX (plain old XML) over HTTP using rails ActiveResource conventions.
It's basically a set of categories on NSObject and some of the primitive object types that will let you make calls like [Dog findAllRemote] to return a list of Dog objects, or [myDog saveRemote] to send changes made to the myDog object back to the server.