I am creating a video editing app for iPhone.
When the user sets up the video editing and then starts the rendering, obviously it takes time. When the user presses the home button, the application is minimized but the rendering still continues and applicationDidEnterBackground: is not getting called unless the rendering process finishes.
Can you post the code that performs the rendering?
If it's a blocking call that takes a lot of time to complete and you are doing it in the main runloop, you are clogging up the run loop. Your rendering code would need to finish before applicationDidEnterBackground would be called, and if this takes too long, iOS will simply kill your application instead. IT would also freeze the UI, which you definitely don't want.
The most likely solution would be to move your rendering code to a background thread, but it really depends on what you are doing.
Related
The for loop is running fetching the data(images and text) from array but when i press home screen button the loop still continues in background and lasts more than 5 seconds which is default time, it should not be more that that as i studied while googling. And when i press home button even then the app delegates respective method like appEnterBackground also called after completion of this loop containing method. So, is it possible to break the loop when the home button is pressed.
Please guide.
If you wanted to detect the entering into background, in addition to responding to the app delegate applicationDidEnterBackground method, you could alternatively register yourself as an observer of the UIApplicationDidEnterBackgroundNotification notification (e.g., using the addObserverForName method of [NSNotificationCenter defaultCenter]).
Note, if you want to cancel your requests, you will want to ensure that (a) the requests are run asynchronously; and (b) they're cancelable. If you're targeting iOS 7 and later, you can accomplish this with NSURLSession (e.g., dataTaskWithRequest or dataTaskWithURL which return a NSURLSessionDataTask object, on which you can call the cancel method if and when desired). Then you can write a handler for the notification that cancels any pending requests.
If you really want to cancel the requests, you can do something like the above, but you alternatively could simply request additional time to complete the requests if the app happens to go into background while the requests are running. This way you get a few minutes to finish requests rather than just a few seconds. See Executing Finite-Length Tasks in App Programming Guide for iOS: Background States.
Or, perhaps even better, you could add your tasks to a background NSURLSession. See the Downloading Content in the Background section of the aforementioned App Programming Guide for iOS: Background States. This way the tasks will continue even after your app is suspended (or, if you app is terminated due to memory pressure). For more information, see WWDC 2013 video, What's New in Foundation Networking.
I'm using a background task to complete a few operations when the user suspends my app.
This works fine, but I just noticed that if the user reactivates the app before the background task is finished the screen stays black and applicationWillEnterForeground: is never called.
Once the background task is done all is fine again and applicationWillEnterForeground is called, but is there a way to make the app reactivate while the task is running?
All I could find is to have the background task constantly check the remaining time and notice that this becomes very high when the app is reactivated. It can then end itself and the app appears, but this still means the app is black for half a second or so.
Quick question. Are you using beginBackgroundTaskWithExpirationHandler?
And are you running the actual work asynchronously? As shown in this answer?
objective c - Proper use of beginBackgroundTaskWithExpirationHandler
If not, you should run your long running work on a-sychornously because else it will be executed as part of your main RunLoop. Which will indeed block your apps redraws and responsiveness until the long running task is completed.
I have an app with locationServices on in background. and have some back ground handle code also.
All I want that when user double click the home button and kill my app I should get notify.There is no application delegate method that is called every time (100%). though the method applicationWillTerminate: according to apple will be called on terminating the app but it is called in very rare cases ( 5 times in 100).
Does any body has some idea about it?
Did you consider implementing applicationDidEnterBackground: method? The doc says that, "In iOS 4.0 and later, this method is called instead of the applicationWillTerminate: method when the user quits an application that supports background execution".
When an app is hidden using the home key, the operating system will suspend it in memory. When this happens, applicationDidEnterBackground: is called. If, at that point, the system decides it needs memory, it will start close apps that are in the background. Sometimes, your app will be on that "hit list". When your app is killed, it is removed from memory completely, just after the pplicationWillTerminate: method is called. The method doesn't get called all the time because sometimes, iOS doesn't need the memory and so it won't actually terminate your app, but rather it will suspend it.
Hey I found a very nice observation, that if your App is running some code in background and user tries to kill it the method applicationWillTerminate is called.
I have an IBAction which starts a number of timers.
I would like to have a second or a pause for a certain time. How can I pause execution?
I know of the [self performSelector:#selector(someMEthod:) withObject:someObject afterDelay:1.0];
but how can I just cause a delay without calling anything?
Thanks
You can call sleep() or +[NSThread sleepForTimeInterval:] but please don't do that on the main thread. Pausing execution of the main thread means your app's UI will be blocked for that time and appear to the user as if it had crashed. If you blocked the main thread for more than a few seconds, Apple's watchdog timer would kill your app instantly.
See this blog post by Jeff LaMarche for more on this issue: http://iphonedevelopment.blogspot.com/2010/05/psa-respect-main-thread.html
You don't want to cause a delay without calling anything. It's bad for the UI, and does not fit Cocoa Touch's event driven paradigm.
Cut the routine in which you want to pause into (at least) two parts/halves. Have the first half set up a delayed call to the second half (perform selector with delay, timer, queue, etc.) and then return to the main loop. The OS will call the second part, later, after potentially doing useful stuff in the mean time (giving the user a responsive UI or saving battery life, catching up with background email, etc.)
You may have to learn how to save state between parts (loop variables, etc.), something that some new programmers seem to miss in their learning.
You can use sleep(int_No_of_Sec); // eg. sleep(1);
I made a game that uses many timers throughout the code. However the timer has to deal with many tasks in such a small amount of time which leads to the problem where there is lag in my game. For example, my timer runs at an interval of (0.05) and it needs to draw and update many of the images on the screen. Is there any way I can distribute the work flow so that the program runs much smoother?
Thanks
Kevin
I would use an NSThread instead of an NSTimer. I have had more success in this area using NSThread because it runs on an independant thread and is not fired off your main ui thread. In the loop for the thread sleep it for 1/20 (your 0.05) of a second. Because the thread is not running on the UI thread all of its tasks should not slow your UI down. However beacsue it is not running on the UI you will have to call performSelectorOnMainThread to get the UI to update from this background thread. I put a lock on my update method (a simple boolean) that says if the last ui update has not happened, just skip this one. then if im running out of processing time i just drop a frame or two here and there. I also do a lot of checking to see if anything has actually changed before i redraw.
Simple solution: Ditch NSTimer.
Move your redrawing code to a single method, then use CADisplayLink. The issue with using your NSTimer approach is that everything is being redrawn too fast or too slow for the screen. By using CADisplayLink, you can synchronize your redraw code to the screen refresh rate. All you need to do then is touch up your code so that it can deal with not being called at a specific time.
And yes, check to make sure you don't need to redraw as Aran Mulholland said above. Just make sure the checks don't take as long as a redraw.
And remember to optimize your code. A lot. Use ivars to access objects, but the whole property (self.myObject =) to set your objects.