Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 days ago.
Improve this question
I wonder how the UIView.animate method works.
because just UI method must be used from main thread only?
try it
UIView.animate method was called without Dispatchqueue.main.async
so, I check Thread.isMainthread in UIView.animate result -> main
I think that because UIView use #MainActor annotation
But, Is there any counter case where #MainActor doesn't guarantee the main thread?
Questions
Why does the main thread guarantee the UIView.animate method?
Is my guess correct?
if my guess correct {
2-1. Is there any counter case where #MainActor doesn't guarantee the main thread?
}
The main thread guarantees the UIView.animate method because it manipulates UI elements, which should only be done on the main thread to ensure thread safety and avoid unexpected behavior.
Your guess is partially correct. The #MainActor attribute is used to mark methods that must be executed on the main thread. However, there may be cases where the attribute is not used correctly or where it does not fully guarantee that the method is executed on the main thread. For example, if a method marked with #MainActor calls another method that is not marked as such, or if a method is marked with #MainActor but also includes asynchronous code that is not properly managed, it could result in the method being executed on a background thread. Therefore, it's important to use #MainActor carefully and ensure that all related code is properly managed to avoid potential issues.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 1 year ago.
Improve this question
Is #MainActor just a syntactic sugar for DispatchQueue.main.async or else is there any other use to it?
If we take a look at the declarations for both UILabel and UIViewController, we can see that they’ve both been annotated with the new #MainActor attribute:
#MainActor class UILabel: UIView
#MainActor class UIViewController: UIResponder
What that means is that, when using Swift’s new concurrency system, all properties and methods on those classes (and any of their subclasses) will automatically be set, called, and accessed on the main queue. All those calls will automatically be routed through the system-provided MainActor, which always performs all of its work on the main thread — completely eliminating the need for us to manually call DispatchQueue.main.async.
Source: https://www.swiftbysundell.com/articles/the-main-actor-attribute/
In iOS, we have GCD and Operation to handle concurrent programming.
looking into GCD we have QoS classes, and they're simple and straight forward, this question is about why DispatchQueue.main.async is commonly used to asynchronies X tasks in the Main Thread.
So when we usually handle updating something in the UI we usually use that function since to prevent any irresponsiveness from the application.
makes me think is writing code inside the UIViewController usually executed in the main thread ?
but also knowing that callback & completionHandler usually execute without specifying on what thread they are in, and the UI never had a problem with that !! so it is on the background ?
How Swift handles this ? and what thread am i writing on by default without specifying anything ?
Since there are more than one question here, let's attempt to answer them one by one.
why DispatchQueue.main.async is commonly used to asynchronies X tasks
in the Main Thread.
Before mentioning a direct answer, make sure that you don't have confusion of understanding:
Serial <===> Concurrent.
Sync <===> Async.
Keep in mind that DispatchQueue.main is serial queue. Using sync or async has nothing to do with determining serialization or currency of a queue, instead they refer to how the task is handled. Thus saying DispatchQueue.main.async means that:
returns control to the current queue right after task has been sent to
be performed on the different queue. It doesn't wait until the task is
finished. It doesn't block the queue.
cited from: https://stackoverflow.com/a/44324968/5501940 (I'd recommend to check it.)
In other words, async means: this will happen on the main thead and update it when it is finished. That's what makes what you said:
So when we usually handle updating something in the UI we usually use
that function since to prevent any irresponsiveness from the
application.
seems to be sensible; Using sync -instead of async- will block the main.
makes me think is writing code inside the UIViewController usually
executed in the main thread ?
First of all: By default, without specifying which thread should execute a chunk of code it would be the main thread. However your question seems to be unspecific because inside a UIViewController we can call functionalities that are not executed on the main thread by specifying it.
but also knowing that callback & completionHandler usually execute
without specifying on what thread they are in, and the UI never had a
problem with that !! so it is on the background ?
"knowing that callback & completionHandler usually execute without specifying on what thread they are in" No! You have to specify it. A good real example for it, actually that's how Main Thread Checker works.
I believe that there is something you are missing here, when dealing when a built-in method from the UIKit -for instance- that returns a completion handler, we can't see that it contains something like DispatchQueue.main.async when calling the completion handler; So, if you didn't execute the code inside its completion handler inside DispatchQueue.main.async so we should assume that it handles it for you! It doesn't mean that it is not implemented somewhere.
Another real-world example, Alamofire! When calling
Alamofire.request("https://httpbin.org/get").responseJSON { response in
// what is going on here work has to be async on the main thread
}
That's why you can call it without facing any "hanging" issue on the main thread; It doesn't mean its not handled, instead it means they handle it for you so you don't have to worry about it.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question appears to be off-topic because it lacks sufficient information to diagnose the problem. Describe your problem in more detail or include a minimal example in the question itself.
Closed 8 years ago.
Improve this question
Can someone show me how to create block for this method that holds multiple parameters as I only know how to create blocks for a single parameter method.
addObserverForName:object:queue:usingBlock:
What I do is sending a single parameter that is actually an NSDictionary ... so I can send lot of information in a single parameter.
GL HF
The notification center method addObserverForName:object:queue:usingBlock: has a fixed block signature for the block that gets invoked. You can't add additional parameters to the block.
However, that isn't usually a problem. Blocks inherit the scope in which they are defined. If you pass a block to the notification center from an instance method of an object, all the instance variables and properties of the object that makes the call are available, as are local variables in the actual method that makes the addObserverForName:object:queue:usingBlock: call.
The system plays some games to make that happen. Local variables are copied from the stack to the heap at the time the block is passed.
Referring to "self" in a block is generally a bad idea however. That can cause the object (self) to be retained and create retain cycles. In that case I usually create a local variable "myself" that points to self and set it up at the beginning of the method.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
I'm using blocks inside a NSOperation. The main method of my NSOperation looks like this:
- (void) main {
[self callMethodOfALiraryUsingCompletionBlock:^() {
//this method takes time to execute, will call this block when done
}];
}
I'd like my NSOperationto terminate when what's inside the block is done. Currently, it returns directly, before what's inside the block is executed ... Any idea how I can solve this ?
Little detail in your question, here is one possible outline which may help:
Create a semaphore (dispatch_semaphore_create)
Execute your library code asynchronously (dispatch_async)
Have the completion block for your library code signal the semaphore
Have your main method wait on the semaphore
HTH
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
How does -performSelector:withObject:afterDelay: work?
I often use this code to let the UI finish its business before calling a long-running method:
[obj performSelector:#selector(go) withObject:nil afterDelay:0];
But what does it do?
My personal interpretation has always been that the go method is called on the next run loop, but surely that's not even right.
Calling it with delay 0 will indeed invoke this method on the next pass through the runloop.
IIRC, what it does is set up a struct that represents the target and action, and attach a CFRunLoopSource to the runloop that, when triggered, will invoke the action on the target. It then signals the runloop to tell it that it has a ready source. This means that the next time the runloop processes its sources (i.e. the next pass through the runloop), it will perform your delayed selector.