I am developing a hello world application in iphone OS 6.0. Whenever a screen is rendered, a web service call is made to the server. But, i am making the web service call in the same main thread without starting in a seperate thread.
However, whenever i rotate the device to landscape mode, the web service call is stopped. Again when i rotate the device to portrait mode, web service call is started.
Any idea on why this happens ... Thanks in advance.
EDIT
I tested the application using iOS instruments (Network Monitor). I understand that device orientation did not stop the network operation.
The following links helped me arrive at a solution.
On iOS, can you make a synchronous network request (but not on the main thread) and still get progress callbacks (on a separate, non-main thread)?
http://tewha.net/2012/06/networking-using-nsurlconnection/
I understand that in Iphone, UI rendering happens in the Main Thread. So, i can control the application behavior with respect to device orientation similar to android OS.
Adding to this, I need not perform the network code in asynchronous mode. I can perform the synchronous network operation in a seperate thread. This solves my issue.
Thanks for all ...
Related
While the device is powered on, is it possible for iOS to automatically terminate my app (calling applicationWillTerminate:) while it's in the background?
I'm also curious what happens in two other cases, three in total:
Device is powered on
Device is powered off
Device loses battery
I'm asking because I want to know how often applicationWillTerminate: is likely to get called. I want to know this because that's where I'm registering for remote notifications. And if there's a failure sending the device token to the server, I want to know how likely it is that that method will get called again (i.e., retry sending the device token to the server).
If your application supports multitasking (the default for anything linked against iOS 4.0+), this method will almost never be called. The documentation says it may be called in cases where the application is running in the background and the system wants to terminate. However, in my experience, I've only ever seen this actually called when running a music app that's actively playing music in the background and the system is jettisoning everything. In cases where I have background tasks running (not music, but short-term background tasks), I've seen the app terminated without this method being called.
I wouldn't ever rely on this being called and try and do all the clean-up you need to do in your delegate methods for transitioning into the background and your background task completion blocks (which do get executed for at least a few seconds before the app gets jettisoned).
Not only can iOS terminate your app automatically, but the user can kill it manually. In fact, the only time the user can kill your app is when it's in the background. Furthermore, when your app is "in the background" it's more likely to be suspended than actually running, so don't count on doing a lot of processing when you're not the foreground app.
As for how likely it is that you'll get -applicationWillTerminate:, that'll depend on the user and how they're using their device. You should handle it appropriately when you get it, and go about your business otherwise.
When memory is running low, iOS can shut down your app, calling applicationWillTerminate.
The docs say this about the method:
... However, this method may be called in situations where the application is running in the background (not suspended) and the system needs to terminate it for some reason.
Check out iOS Developer Library : iOS App Programming Guide : App Termination.
I want to initiate a separate thread apart from main thread and do some operations continuously even when my app is closed. I tried detachNewThreadSelector, but it doesn't work continuously and that too it needs my app to be launched.
And whenever I don't need it, I want to stop the thread as well. It is possible in Android, don't know how to do in iOS. How can I achieve it, could someone guide me on this? I am developing on iOS 4.3 SDK.
You can't create a thread on a stock OS iOS device that will run in the background always. Some types of apps, such as for VOIP, audio play/record and GPS monitoring, can register for callbacks when the app is in the background.
I am trying to test an application that needs to run over an extended period of time and to aid initial testing I am trying to find a way to stop iOS moving the application to the background and suspending it. Ultimately I will add code to facilitate the use of multi-tasking but right now I just want to better test the core mechanics without iOS pushing it into the background all the time.
You can not prevent ios from suspending an app. The home button will close/resign active the application and even if you request for a background task apple can kill your app at any time as it sees necessary (More than likely for memory reasons).
As long as you, the user, don't stop this app, launch another app, or lock the device:
[[UIApplication sharedApplication] setIdleTimerDisabled: YES];
might keep your app running in the foreground. Don't forget to re-enable the idle timer, or this could keep the device running until the battery is dead.
Okay, so Apple apparently has this thing where if the app takes too long to load, iOS will automatically quit the app or something. So when I'm building my iPhone app, I have quite a few high resolution images, which take a while to load, and they never finish before the app is automatically killed. Can anyone help with this?
Thanks!
From the iPhone Application Programming Guide: "Initialization time is not the time to start loading large data structures that you do not intend to use right away ... If your application requires additional time at launch to load data from the network or do other tasks that might be slow, you should get your interface up and running first and then launch the slow task on a background thread."
As Alex said, I recommend you to load resources on a background thread. However, be careful to use UIKit on a background thread. For the most part, UIKit classes should be used only from an application’s main thread. You should use thread-safe API.
For example, UIImage +imageWithContentsOfFile: is thread-safe. UIImage +imageNamed: is not thread-safe.
(From Developer Forums thread)
which take a while to load ...
Not just app start up... If you want a responsive app, that app shouldn't do anything that takes more than a few dozens of milliseconds, synchronously, on the main UI thread or run loop.
I have a iPhone app that connects to an IP camera and retrieve MJPEG data using GET method. Everything seems to work find on the simulator, but on the device the UI seems to be blocking: Whenever i receive an image data, I load it into uiimageview. It seems like the only way out is to have AsyncSocket running on a background thread and set the image on the mainThread.
How do I do that for AsyncSocket?
There is a very simple asynchronous socket pattern that can be created using the NSStream object. Take a look at the WiTap sample on the iphone developer site for an example of how to implement it.
If implemented as in the WiTap example you probably wont have any need for a background thread. Should you still find a need for a background thread keep in mind you will probably have to manually process the runloop for that thread in order to keep your socket's operating properly. Take a look at the NSRunloop documentation for more information on that.