I'm working with an iPhone developer on an application. I know very little about the iPhone. I'm writing the server-side code in Grails. I'm wondering what is available to me as far as approaches to using a RESTful JSON service with an occasional poll of the service.
From the iPhone:
Is there a way to put these calls on a background thread? when the data comes back is there a callback mechanism? Looking for some basic information on how to accomplish this on the iPhone / Objective-C.
Yes, typically you either provide a delegate that is notified when an asynchronous request has some kind of event (e.g. more data comes in, the request fails, etc.), spawn a background thread that performs synchronous requests, or pass success/failure blocks to an asynchronous request that executes them when appropriate.
But if you are working with an iPhone developer, shouldn't he be dealing with this, not you?
Have a look at NSURLConnection. It automatically puts the request on a background thread and has some callback methods that get called on its delegate.
I prefer using the ASIHttpRequest library for my integrations with RESTful rails apps. One of many advantages is the completion block:
request.completionBlock = ^{ NSLog(#"I'm finally complete!"; };
[request startAsynchronous];
Related
I am currently trying to build a (simplified) stock app (like the one built-in on the iphone). I setup a simple server with a REST-interface which my app can communicate with.
However I am struggling to find the right/best way to build this kind of (streaming data consumer) client on the iphone.
My best bet at the moment is to use a timer to regularly pull the xml payload from the server (the connection is async but the xml parsing is not therefor the interface is blocked sometimes. I am a bit shy of thread programming since I learned some lessons the hard way on other platforms).
I read about websockets but it is not clear for me if and how they are supported on the iphone.
How would you do it?
Any hint would be appreciated, Thanks.
websockets aren't going to help you -- that's a server-side technology to make a socket-like interface work over HTTP.
If you don't want to block the GUI, you need to use another thread. You are right to be scared of doing this, so share as little as possible (preferably nothing) between the two threads. Use a message passing mechanism to get information from the background thread to the UI thread.
Take a look at ActorKit: http://landonf.bikemonkey.org/code/iphone/ActorKit_Async_Messaging.20081203.html
Take a look at this question.
It talks about asynchronous vs synchronous connections. You will want to use an asynchronous call to get your data so you don't lock up your UI. You could use that in conjunction with a polling timer to get your data from the server.
You can find more info about the NSURLConnection in apple's documentation here
Is there a way to implement NSURLConnection without it leaking? A number of Apps including NYTimes and others (including mine) suffer from this. Anyone have a working implementation?
It appears that best practice is to use NSURLConnection asynchronously.
According to the documentation, +[NSURLConnection sendSynchronousRequest:returningResponse:error:] is built on top of the asynchronous loading code made available by NSURLConnection. It would not be difficult to reimplement this by spawning and blocking on an NSThread, running the request asynchronously in the background on a run loop and ending the thread once either connectionDidFinishLoading: or connection:didFailWithError: is received.
Of course, you are better off using the asynchronous code in the first place; it makes for a much better user experience
I am trying to work on application in which images should be loaded asynchronously.
Are there any examples related this?
I tried pokeb-asi to understand asynchronous transmission, and it works within that application fine.
But I want to know how to do it from scratch
I am facing following problems.
I don't know the exact way to do it?
what kind of files / frameworks should be added?
The ASIHTTPRequest class is a subclass of NSOperation, so it's typically used by adding the request to either an NSOperationQueue or an ASINetworkQueue. Each request is pulled off the queue, run in a background thread, and then the delegate for that request is notified via a callback method on the main thread.
You could wrap NSURLConnection in an NSOperation and achieve the same thing, however NSURLConnection has an asynchronous API which may suit your needs a bit better.
Try:
http://allseeing-i.com/ASIHTTPRequest/Setup-instructions
I have an iPhone app which uses ASIHTTPRequest to communicate to a REST service on my server. When I'm running on the simulator, it works just fine, but when I get onto the phone itself, I get weird behavior.
The very first time I click the button that initiates the request, I get the results back immediately, and all is fine. From that point on, when I click the button to initiate the connection it takes about 2-3 minutes to connect. It almost seems like the ASIHTTPRequest that I kicked off first (and from which I've already received the correct results) has not completed. Is there some sort of magic I need to use to terminate the original request before starting the next one? I assumed that since the -start method returned, and I have results from the server that the original request was completed and I could start another.
Any ideas?
Thanks
--Steve
Steve - What you've described is a common problem that will occur if the requests are attempting to keep a persistent connection. Try this out:
[request setShouldAttemptPersistentConnection:NO];
You're not suppose to call the -start method, it belongs to the NSOperation. The ASIHTTPRequest interface is either -startSynchronous or -startAsynchronous.
However, it's highly recommend to use the asynchronous call otherwise, your main thread (ie., UI) will be blocked.
From the ASIHTTPRequest documentation[1]
In general, you should use
asynchronous requests in preference to
synchronous requests. When you use
ASIHTTPRequest synchronously from the
main thread, your application's user
interface will lock up and become
unusable for the duration of the
request. Synchronous requests are only
really suitable for software without a
UI (like a script that runs from the
terminal), or if you are running the
request from a separate thread that
you maintain (perhaps from inside your
own NSOperation, for example).
[1] http://allseeing-i.com/ASIHTTPRequest/How-to-use
I have some slow internet task to save and load file, I'd like to do those slow tasks in some background thread. I am wondering whether that's doable, and if it is, any sample code?
Then after it is finished, I'd like it to notice back to the main thread, so that I could update the UI.
Take a look at NSURLConnection. It will load an NSURL (using NSURLRequest) in the background, and send delegate methods regarding its status.
Ultimately the device you are running your code on has a single processor and cannot possibly load large quantities (gigabytes) of data. The best route, by is likely that suggested by Ben (NSURLConnection asynchronously) which gives you the added advantage of being able to cleanly cancel and handle error messages. While it isn't technically threaded in the way you probably think you want it to be, it is well integrated with the event loop and is non-blocking. If that is still not enough, I would suggest looking at NSOperation and NSOperationQueue. You can fire off an NSOperation sub-class object and perform the download there (I would still advise doing it asynchronously there so as to enable canceling, pausing, etc).
Log in to the iPhone Developer Center and search for Introduction to Threading Programming. Or, maybe you can log in and use this link:
http://developer.apple.com/iphone/library/documentation/Cocoa/Conceptual/Multithreading/Introduction/chapter_1_section_1.html#//apple_ref/doc/uid/10000057i-CH1-SW1
If you do decide you need a background thread even after using asynchronous HTTP calls to gather the data, don't forget to wrap the background thread code in a new NSAutoReelasePool and then release it at the end.