I have noticed that during very processor or memory intensive processes that my app is running, notably during initial download or executing a query, the clock inside the status bar will stop running and stay at the time that the process started. Is there any way to prevent this from happening, in case something like this causes the app to be rejected? I don't have any code to provide, as I am unsure to where the app does this at exactly.
Considering your comment, you should not perform memory-intensive or cpu-intensive work on the main thread. Only interactions with UI should be performed on the main thread, otherwise the UI will seem frozen, including your app and status bar.
Related
I have a large application that uses a number of third-party libraries and am now seeing the following error in the logs: "This application is modifying the autolayout engine from a background thread after the engine was accessed from the main thread. This can lead to engine corruption and weird crashes."
From what I have found here on SO, this is probably being caused by a UI element being changed on a background thread, which is triggering the autolayout. Unfortunately, we have so many UI elements being changed by so many different moving parts that I do not know the best way to find the culprit.
Can anyone tell me how can I found out what exactly is triggering the autolayout change from a background thread?
Sometimes it's not a completion block, but anything that is performed in the background.
In my case it was notifications that where sent. I implemented iCloud in my app, which means that when data was edited or added on another device, the other app(s) receive an iCloud update/notification, which triggered an update of the UITableView.
The code to update the UITableView was not done in the MainThread. Adding the code as shown in the comments fixes it.
My app makes use of UIBackgroundMode, i.e. it gets relaunched by iOS when Bluetooth events occur even while the app is not active. Therefore Bluetooth events are dispatched by iOS onto a background queue (queue is specified by me).
Can I however dispatch code back to the main queue, i.e.
DispatchQueue.main.async { } (Swift)
dispatch_async(dispatch_get_main_queue(), ^{ }) (Objective-C)
and assume that its run loop is running, that is my blocks get dispatched? Or is the main queue suspended in background mode and thus I should avoid adding dispatching blocks to it?
It should be safe to dispatch to the main queue while in the background.
When your app is in the background, everything it does is technically done on background threads because the system marks your app as a lower priority. However, in order for the system to let your code run it needs to at least have a main queue. Therefore, it is safe to assume you will have access to the main queue. You can create other work queues from there if you want, but everything will most likely be shoved onto the one background thread for execution, so you may not see much benefit.
Also note that testing background threading can be a little tricky. Background threads will always be executed and seem to never be shut down while in the simulator. The same happens when testing on a device if Xcode is connected and debugging. The system also lets your app run continuously for 10 minutes (last I checked, it's possible this has changed in the last year or two) after entering the background if needed, and after it will require something like the bluetooth event you mentioned to get additional time in the background.
Source: An unfortunate amount of experience dealing with backgrounded apps.
My iOS app launch screen takes about 3 - 5 seconds. I have a map that will load after the launch screen. My users have to wait for the launch screen to load and then wait another 3 seconds for the map to load.
Is there a way to minimize launch screen time?
Basically this delay means that you are doing something very wrong during launch. Your job is to launch immediately. Indeed, the WatchDog app will kill you dead if you don't.
There are excellent WWDC videos on this topic, and you should watch them. But in general there are two ways to go wrong:
You must do nothing time-consuming on the main thread. If you have a time-consuming thing to do, like loading your map or networking, you must do that on a background thread. You need to get out of the way so that the runtime can launch your app now.
Just the other way around, you must not touch the interface on any other thread but the main thread. Doing this wrong causes just the kind of delay you are reporting. Do your work on a background thread, but then get back on the main thread to talk to your views, view controllers, etc.
Finally, I should point out that you might be able to get some idea what you're doing wrong by using Instruments. Unfortunately it works rather badly against app launch, but it can be worth a try. Above all, watch those videos!
I'm having an issue with this code (I have it in didFinishLaunchingWithOptions). I need it to finish executing the code inside before the app continues because it sets up some critical things in core data. It sends this to the background though and starts running the rest of the app and it doesn't finish quick enough for the data to be usable.
DataManager.getDataWithSuccess { (data) -> Void in
//code to execute here
}
How can I force the app to wait for this code to finish before moving on?
You shouldn't block the didFinishLaunchingWithOptions method from returning so that it can wait on an asynchronous task. It's crucially important to note that iOS applications are only given a limited amount of time to complete launching before the application is killed by the operating system.
An approach I have used in the past when waiting on asynchronous things to happen that need to happen before I really launch my app is to create a LaunchViewController. The interface for this view controller matches perfectly to the app's splash screen. From an end-user perspective, you can't even tell we've left the splash screen.
Here, we do any set up code such as asking your DataManager to get data. Then, when it (and any other set up actions) completes, you simply present the next view controller in much the same way you'd move between any other view controllers.
A huge positive side effect here is that you can have much nice looking animations from your splash screen into the first screen of your application.
This is very difficult issue, since it doesn't occur every time.
When an app is just launched, returning from background, it is fine without any freezing.
After some time being in background, when I re-activate it, the whole UI is frozen for while, even the activity indicator is not animating. As time goes on, this freezing gets longer and finally causes the app to be terminated by iOS for not resuming in time.
I would like to learn what are the generic causes of an app to be unresponsive, especially if the app is supporting background running feature and re-activating after a period of being in background.
It looks like I have missed some fundamental techniques that should be respected to avoid freezing problems.
UPDATE: I am suspicious if saving UIImage into Core Data object can be the main reason. At launch, it's not visible, however, as time passes, numerous saveManagedObjectContext are performed while UIImage is still referenced.
Maybe I should have listened to the instruction not to save any image in Core Data?
check for your crash log if you are getting this
Exception Codes: 0x8badf00d
then its most probably your application is taking much time either in launch or while moving in background or terminate, actually app take much time in launch/shut iOS suspend it and our app freeze, there is no such time define in documents but as i experienced it should not be more then 4-5 seconds. check your app delegate applicationDidFinishLaunch or multitasking delegates there is some code which is taking time in completion. For more info lokk at these
http://developer.apple.com/library/ios/#technotes/tn2151/_index.html
http://en.wikipedia.org/wiki/Hexspeak