I'm showing alert in a function which I call from VC. I don't want main VC to be blocked. I'm calling this alert function in async. The function in turn has another async. Is this good practice or I'm doing it wrong?
Can anyone suggest good practice for following code?
class MyVC: UIViewController {
override func viewDidLoad() {
super.viewDidLoad()
// Don't block main thread
DispatchQueue.main.async {
self.showAlert(title: "Title", message: "Message")
}
// Do other stuff ...
}
}
func showAlert(title: String = "", message: String) {
alert = UIAlertController(title: title,message: message, preferredStyle: .alert)
let cancelAction = UIAlertAction(title: "Ok", style: .cancel, handler: nil)
alert.addAction(cancelAction)
DispatchQueue.main.async {
UIApplication.shared.keyWindow?.rootViewController!.present(alert, animated: true, completion: nil)
}
}
Showing an alert doesn't block the thread. present(_:animated:completion:) is not a blocking operation, so there's no reason to add any of these .async calls.
That said, you wouldn't want to try to present an alert inside viewDidLoad. That's far too early. Your view controller isn't on the screen yet. You should put showAlert() in viewDidAppear, and remove all the .async calls.
As a general rule, these kinds of modal alerts should be a last resort in any case, especially when a view controller is coming on screen. Generally, you should integrate whatever message you want to present to the user into the view itself rather than blocking the entire UI. But if an alert is appropriate (and sometimes they are), then you can just present them directly as long as you're on the main queue.
It seems you have a problem with DispatchQueue :)
Your program uses operation queues while running. This queues can be system-defined(like main) or user defined. When you use DispatchQueue.main.async(_:) you enqueue a code block to main queue. When their time comes, main queue execute them.
But in viewDidLoad(_:), you are already in main queue. Also, cause of calling an AlertController is a UI operation and UI operations can't be done on any queue except main, you don't need to send your code block to any queue and you shouldn't.
And also, Like #SeanRobinson159 said, AlertController does not block main thread when it is on screen. It works like your orther ViewControllers.
So, Which cases you should use DispatchQueue to call an AlertController
You should use DispatchQueue.main.async(_:) to send code blocks that performs UI operations (like calling AlertController or changing UILabel's text), to main queue from different queue. For example, maybe you work on an network operation. You make your operation in different thread and when result comes, You can send your code block that makes UI operations, to main queue.
You can google GCD(Grand Central Dispatch) for deatiled information.
You should only put what you have to on to the main thread. So you shouldn't wrap it in the main.async block in the viewDidLoad function.
You should wrap it in a DispatchQueue with a different priority.
i.e. DispatchQueue.global(qos: .userInitiated).async { }
Related
I am writing a chess GUI in Swift 3 and use nvzqz/Sage as the chess model/library. Now I face a problem with a Sage closure used for piece promotion.
Sage uses (in its game class) the execute(move: promotion:) method for promotion move execution which has a closure that returns a promotion piece kind. This allows to prompt the user for a promotion piece or perform any other operations before choosing a promotion piece kind, as follows:
try game.execute(move: move) {
...
return .queen
}
I implemented a promotion view controller ("pvc") which is called in this closure so that the player may select the new piece:
// This is in the main View Controller class
/// The piece selected in promotionViewController into which a pawn shall promote
var newPiece: Piece.Kind = ._queen // default value = Queen
try game.execute(move: move) {
boardView.isUserInteractionEnabled = false
// promotionview controller appears to select new promoted piece
let pvc = PromotionViewController(nibName: nil, bundle: nil)
pvc.delegate = self
pvc.modalPresentationStyle = .overCurrentContext
self.present(pvc, animated:true)
return newPiece
}
When the button for the new piece in the pvc is pressed, the pvc dismisses itself and the data of the selected piece (the constant selectedType) is transferred back to the main view controller via delegation:
// This is in the sending PVC class
protocol PromotionViewControllerDelegate {
func processPromotion(selectedType: Piece.Kind)
}
func buttonPressed(sender: UIButton) {
let selectedType = bla bla bla ...
delegate?.processPromotion(selectedType: selectedType)
presentingViewController!.dismiss(animated:true)
}
// This is in the receiving main View Controller class
extension GameViewController: PromotionViewControllerDelegate {
func processPromotion(selectedType: Piece.Kind) {
defer {
boardView.isUserInteractionEnabled = true
}
newPiece = selectedType
}
The problem I have is that the closure (in the game.execute method) does not wait until the player made his selection in the pvc (and immediately returns the newPiece variable which is still the default value) so that I never get another promotion piece processed other than the default value.
How do I make the closure wait until the player pressed a button in the pvc?
Of course, I tried to find a solution and read about callbacks, completion handlers or property observers. I do not know which is the best way forward, some thoughts:
Completion handler: the pvc dismisses itself upon button-press event so the completion handler is not in the receiving (main) view controller. How do I deal with this?
Property observer: I could call the try game.execute(move) method only after the promotion piece was set (with didset) but that would make the code difficult to read and not use the nice closure the game.execute method provides.
Callbacks may be related to completion handlers, but am not sure.
So your block in game.execute(move: move) will fully execute which is so designed by the Sage API. You can not pause it as easy but it is doable, still let's try to solve it the other way;
Why do you need to call the presentation of the view controller within this block? By all means try to move that away. The call try game.execute(move: move) { should only be called within processPromotion delegate method. You did not post any code but wherever this try game.execute(move: move) { code is it needs to be replaced by presenting a view controller alone.
Then on delegate you do not even need to preserve the value newPiece = selectedType but rather just call try game.execute(move: move) { return selectedType }.
So about pausing a block:
It is not possible to directly "pause" a block because it is a part of execution which means the whole operation needs to pause which in the end means you need to pause your whole thread. That means you need to move the call to a separate thread and pause that one. Still this will only work if the API supports the multithreading, if the callback is called on the same tread as its execute call... So there are many tools and ways on how to lock a thread so let me just use the most primitive one which is making the thread sleep:
var executionLocked: Bool = false
func foo() {
DispatchQueue(label: "confiramtion queue").async {
self.executionLocked = true
game.execute(move: move) {
// Assuming this is still on the "confiramtion queue" queue
DispatchQueue.main.async {
// UI code needs to be executed on main thread
let pvc = PromotionViewController(nibName: nil, bundle: nil)
pvc.delegate = self
pvc.modalPresentationStyle = .overCurrentContext
self.present(pvc, animated:true)
}
while self.executionLocked {
Thread.sleep(forTimeInterval: 1.0/5.0) // Check 5 times per second if unlocked
}
return self.newPiece // Or whatever the code is
}
}
}
Now in your delegate you need:
func processPromotion(selectedType: Piece.Kind) {
defer {
boardView.isUserInteractionEnabled = true
}
newPiece = selectedType
self.executionLocked = false
}
So what happens here is we start a new thread. Then lock the execution and start execution on game instance. In the block we now execute our code on main thread and then create an "endless" loop in which a thread sleeps a bit every time (the sleep is not really needed but it prevents the loop to take too much CPU power). Now all the stuff is happening on main thread which is that a new controller is presented and user may do stuff with it... Then once done a delegate will unlock the execution lock which will make the "endless" loop exit (on another thread) and return a value to your game instance.
I do not expect you to implement this but if you will then ensure you make all precautions to correctly release the loop if needed. Like if view controller is dismissed it should unlock it, if a delegate has a "cancel" version it should exit...
I use DispatchQueue.main.async in UIViewController and i need to cancel async task when dismiss UIViewController
Grand Central Dispatch does not allow tasks to be cancelled from the outside when already running.
You basically have to check inside the asynchronously running task if your view controller still exists.
Assuming your call to GCD is directly in your UIViewController, so self refers to that view controller:
DispatchQueue.global().async { [weak self] in
// Do work
// Check if self still exists:
guard let _ = self else {
return // cancels the task
}
// Continue working
}
As self is only a weak reference to your view controller it will not stop the view controller from getting deallocated when dismissed. When it gets deallocated, self inside your GCD block becomes nil and you known that you can stop your task.
So you just have to check if self is nil every once in a while in your asynchronous block.
Note: Do not perform long running tasks on the main queue but in a global queue or even a private queue. Using the main queue blocks the main thread from performing other work like UI updates so your app freezes.
Let's say I have a ViewController A and a class B.
when I press some button inside A, it calls an IBAction that calls a function B.foo() which returns an Int
B.foo() takes 8~10 seconds to finish and while it runs I'd like to put an Loading... animation on A, and when B.foo() finishes, the animation would stop.
How can I do this? this is an pseudo-code example of what I wish:
#IBAction func buttonPressed(_ sender: UIButton){
UIView.animate(blablabla......)
DO({
self.answer = B.foo()
}, andWhenItFinishesDo: {
self.someone.layer.removeAllAnimation()
})
}
This is a very common problem. One way to solve it would be to use different queues (You can think of them as lines of work that can happen in parallel).
The the basic idea is that once your button is pressed, you show your loading indicator and "dispatch" the long work to a secondary queue, that will operate in the background and do the work. This ensures that your main queue does not block while the work happens and the user interface stays responsive.
The trick is now that you want to get notified when the long work is finished so that you can stop showing the loading indicator (and possibly do even more).
While you actually could use some kind of notification system, there are other, sometimes more appropriate ways. It would actually be even more convenient, if you could just tell the long running function to call you back specifically with code that you provide.
That would be the basic concept of a "completion handler" or "callback".
The whole thing would look something like that:
// Some made up class here
class B {
// This is only static because I do not have an instance of B around.
static func foo(completion: #escaping (Int) -> Void ) {
// The method now does all of its work on a background queue and returns immediately
DispatchQueue.global(qos: .background).async {
// In the background this may take as long as it wants
let result = longCalculation()
// VERY important. The caller of this function might have a certain
// expectation about on which queue the completion handler runs.
// Here I just use the main queue because this is relatively safe.
// You could let the caller provide a queue in the function
// parameters and use it here
DispatchQueue.main.async {
// The completion handler is a function that takes an Int.
// That is exactly what you are providing here
completion(result)
}
}
}
}
#IBAction func buttonPressed(_ sender: UIButton){
self.showLoadingIndicator()
// The foo function now takes a completion handler that gets the result in.
// You have to provide this function here and do something with the result
//
// The completion handler will only be run when the foo function calls it
// (which is after the computation as you can see in the method above.
//
// I am also telling the completion handler here that self should not be
// held on to as the view controller might already have gone away when the
// long calculation finished. The `[weak self]` thingy makes that inside
// your completion handler self is an optional and might be nil (and it
// doesn't hold a strong reference to self, but that's a whole other topic)
B.foo(completion: { [weak self] result in
// Do something with the result
// Since we are called back on the main queue we can also do UI stuff safely
self?.hideLoadingIndicator()
})
}
I hope this helps a bit.
Asynchronous programming can be quite difficult to learn but there are tons of tutorials and examples you can find on this topic.
Hey Hamish you can do this in two simple ways,
First one is using the defer statements provided for functions.
Defer statement block is executed after the functions goes out of scope.
here is a simple example to describe the same.
func print1000000() {
//start displaying the loading indicator
defer {
// hide the loading indicator and move to the next ViewController
let seVC = storyboard?.instantiateViewController(withIdentifier: "SecondVC") as! SecondVC
self.navigationController?.pushViewController(seVC, animated: true)
}
// here goes the task you want to execute such as downloading a file or the one i did here
for index in 0...1000000 {
print(index)
}
}
The above function prints numbers upto 1000000 and then pushes the control to another ViewController
=========================================================================
Second way of doing it is by using closures, as described by Thomas in his answer.
I'm attempting to perform a storyboard segue inside of a completion handler like so:
movieWriter.finishRecordingWithCompletionHandler({ () -> Void in
//Leave this view
self.performSegueWithIdentifier("decisionSegue", sender: self)
})
and getting the following warning:
This application is modifying the autolayout engine from a background thread, which can lead to engine corruption and weird crashes. This will cause an exception in a future release.
The completion handler is running on a background so I understand why I'm getting this error, my question is what are my options for performing this segue without getting this error?
The reason I'm performing the segue in the completion handler is that the completion handler is called after a recorded movie is done being written to file and the view being segued to plays the movie, hence it needs to be on file before segueing.
Whenever your perform any operation on UI/active view then it has to be on main thread and not background thread.
Do as following:
__weak typeof(self) weakSelf = self; //Best practice
//Provide a weak reference in block and not strong.
movieWriter.finishRecordingWithCompletionHandler({ () -> Void in
dispatch_async(dispatch_get_main_queue(),{
weakSelf.performSegueWithIdentifier("decisionSegue", sender:weakSelf)
})
})
Put it in dispatch queue :
dispatch_async(dispatch_get_main_queue(),{
self.performSegueWithIdentifier("decisionSegue", sender: self)
})
Hope it will work
For more detailed information : This application is modifying the autolayout engine from a background thread, which can lead to engine corruption and weird crashes
This Error is telling that You are performing some UI update task from Background Thread and it's not possible to Update UI from background thread so you have to access main Thread and then perform segue.
Objective-C:
dispatch_async(dispatch_get_main_queue(), ^{
// update some UI
// Perform your Segue here
});
Swift:
DispatchQueue.main.async {
// update some UI
// Perform your Segue here
}
Hope it will help you.
Instruments shows a memory leak from simply opening and closing the alert controller.
#IBAction func delBtnAc(sender: AnyObject) {
let deleteAlert = UIAlertController(title: "Delete Image?", message: "", preferredStyle: .Alert)
let cancelIt = UIAlertAction(title: "Cancel", style: .Cancel, handler: nil)
deleteAlert.addAction(cancelIt)
presentViewController(deleteAlert, animated: true, completion: nil)
}
I have reduced the alert to only a cancel button for testing.
Edited: Removed deleteAlert.dismissViewController in closure. Fixed retain cycle, but still shows a memory leak. Perhaps a bug.
Your alert action's completion handler has a strong reference to your alert controller.
Your alert action has a strong reference to its completion handler.
Your alert controller has a strong reference to the alert action.
So here we have a classic retain cycle.
The problem is the strong reference from the completion handler to the alert controller itself, which in this case, happens to be completely unnecessary. The alert controller dismisses itself after running the appropriate completion handler.
We can completely eliminate the line.
If we were doing something non-redundant in the completion handler, we would need to create a weak reference to the completion handler so that we could use that in the completion handler.
I found the same problem.
I solved it by setting the alert to null after button action:
deleteAlert = null inside your cancel button action