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
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 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.
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/
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 6 years ago.
Improve this question
Using a singleton object in a block will create a strong reference cycle in the code ?
As I have more then 5 singleton object in application.
You have to use weak reference of singleton inside blocks.
YourSingleton *singletonInstance = ---- //get your singleton instance here
typeof(YourSingleton) __weak weakSingletonInstance = singletonInstance;
// your block
^
{
// Now use weakSingletonInstance inside the block.
}];
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 8 years ago.
Improve this question
I'm having trouble creating completion blocks. I found the solution here
. It works for me, but I don't quite understand this. Now I'm still confused and don't know how to write a block myself. Are there any batter ways to understand blocks? Also, when should I use it? Is there anything that can replace blocks?
Should I create it as a property? Method perimeter? Do they have difference in efficiency?
Thank you!
check out http://fuckingblocksyntax.com for syntax.
For personal choice I like to return value and error in the completion block (similar to iOS framework pattern)
As an example;
declaration
- (void)fetchStuff:(void (^)(id value,NSError *error))completion;
calling the function
// async fetch
[object fetchStuff:^(id value, NSError *error) {
// do stuff with value
}];
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 8 years ago.
Improve this question
Still trying to get the hang of retain cycles when using blocks.
My question is.. which of the following (if any) would cause retain cycles?
1
[self.someProperty runSomeBlock:^{
[self.someOtherProperty doSomething];
}];
2
[self.someProperty runSomeBlock:^{
[self doSomething];
}];
3
[self.someProperty runSomeBlock:^{
[someObject runAnotherBlock:^{
[self.someProperty doSomething];
}];
}];
4
[self.someProperty runSomeBlock:^{
[someObject runAnotherBlock:^{
[self.someOtherProperty doSomething];
}];
}];
Thanks!
None of them, on the face of it. The thing that causes a retain cycle with a block is e.g. when the thing you hand the block to persists and retains it (over time) and you retain that thing over time, and the block mentions you — and there's no obvious evidence that that would be happening here.
In other words, it's really no different from the basic thing that always causes a retain cycle: A retains B but B retains A. But in your code, I see no evidence that anyone is retaining anyone.
In any case, if all the objects just execute their blocks instantly when they are handed them, there's nothing to worry about in the first place, since it's only persistence that is the problem.
It sounds like you're just way over-thinking this.