I use RestKit with Object-mapping. This runs asyncronus and after receiving the Data from Server an object is updated.
The point is, i need to inform another class that a property of an object has changed.
Right now i run into an error:
bool _WebTryThreadLock(bool), 0x1ae420: Tried to obtain the web
lock from a thread other than the main thread or the web thread.
This may be a result of calling to UIKit from a secondary thread. Crashing now...
I tried to overwrite the setter for the property, but it looks like the property is set in another thread, not the main thread. calling a delegate there does not work.
What can i do to solve this?
Any help is appreciated!
Maybe you need send message like this:
[obj performSelectorOnMainThread:#selector(method)]
Related
In my view controller I am calling a method to request data to populate my tableView and handle any notifications at viewWillAppear and also with a notification observer for UIApplicationDidBecomeActiveNotification.
This appears to cause problems when I am initially launching the app (not from the background) because my loadJSON method gets called twice, causing cellForRowAtIndexPath to crash as my data is changing.
Anyone have a suggestion on how this is typically handled?
You can test you loadJSON task is or not is executing before call it.
Or you can cancel privious loadJSON task before perform it.
I use global object to manage data, that I should download from different places.
My object (for example, named DataManager) has notifications, block-callbacks or delegate to notify listeners about data updating.
Also it has method to check his state, for example: isDownloading. If my DataManager more complex class, it has enum for states or many methods for any aspect.
Now I do not like to use Singleton for implementation of DataManager, I prefer to creating a property in AppDelegate to store instance of the manager inside.
I have a iOS construction where I get callbacks from an underlying class.
This callback make changes to a NSMutablearray.
At the same time I have a NSTimer that makes a callback to a method that makes changes to the same NSMutable array.
I see a potential problem here if the callbacks "collide" working with the NSMutablearray.
I am not sure how to deal with this. Could NSLock do the trick or should I instantiate my NSMutablearray as atomic?
You should make sure that any change to the mutable array occurs on the same thread. This will make sure there can be no 'collisions'. If your timer fires on the main thread, and your callback also occurs on the main thread, everything is good.
If the timer and the callback are on different threads, you can serialize the access to the array using a serial GCD-queue. When you do this, ANY AND ALL access to this array should be done on this queue (keep a reference to this queue in a property for instance).
NSLock might help you, but if you are working on the main thread, this is usually not a good idea, as you might be blocking the main queu, which affects user-interaction / scrolling behviour.
Also, atomic only means that getting or setting the pointer to the array is thread safe, i.e.: a valid value will be returned or set (dors not mean it will be the correct value though). Any operations you do on it have nothing to do with the property being atomic or nonatomox.
I'm learning about blocks from a Stanford video. I'm now at the part which explains core data. The teachers mentions something about:
- (void)openWithCompletionHandler:(void (^)(BOOL success))completionHandler;
He said that completionhandler block will be called in the thread which called the method. So basically the method runs async but the blocks get called on the thread, lets assume main.
So my question is do all blocks run on the thread from where the method call was made. To illustrate why I ask this question, I have a Async class which does request to a server.
The format of all these methods is like this:
- (void) getSomething:(id <delegateWhatever> const)delegate{
goto background thread using GCD..
Got result from server...
Go back to main thread and call the delegate method...
}
When I use blocks I do not need to worry about going back to main thread if they will be called where the call was made?
Hope this is clear,
Thanks in advance
If something runs asynchronously, you should read a documentation to know on which thread, e.g. the completion block will be executed. If it is your code, you are in charge here, you can use global GCD queues, you can create your own queue and execute it there or whatever...
In general, blocks behaves like a function or a method call, it is executed on thread, which calls it. It is even possible that the same block will be executed from 2 different threads at the same time.
And just to be clear: Even if you are using blocks, you need to care about going back to main thread, of course if it is necessary
Nothing forces blocks to be called on a particular thread, so it depends on the specific method whether or not you need to worry about its callback being on the main thread. (In practice I don't remember ever seeing a library where a method called on the main thread would not call its completion handler also on the main thread. But you still need to read the documentation of the specific library and method you are using, as always.)
Memory management is being done manually, ARC is not used in this project..
The message object is created using alloc init and the code below is being called on background thread.
I pass a message object before the following call:
[self performSelectorOnMainThread:#selector(serverConnectionResult:) withObject: message waitUntilDone:NO];
After the call I want to do:
[message release];
I am confused whether I should do this, because I am concerned whether the message object will be always valid when serverConnectionResult is called? Is the method call performSelectorOnMainThread retaining the message object itself? What's the rule to know that the called method retains my passed object?
It is safe to do this. -performSelectorOnMainThread:withObject:waitUntilDone: will retain both the target of the message and the object. Similarly -performSelector:withObject:afterDelay: will also retain the target and the object.
You could also use Grand Central Dispatch and use dispatch_async on the main thread and pass in a block that calls your method and afterwards releases the message.
On iOS, if there is a single view app, and a new thread is created using:
[NSThread detachNewThreadSelector:#selector(consumeData:)
toTarget:self.consumer withObject:self.queue];
where the consumer is a Consumer object that will process data inside the method consumeData, and the queue is a Queue object, which is where the data comes from for the consumer to process.
But what if the thread needs to check whether a Switch on the main view is set to on or off? That is to toggle whether the Consumer object should do the work or pause at the moment. Should the withObject:self be used instead, so that the whole ViewController reference is passed to the thread, and then the thread will use viewController.view.______ to access the switch's value, and use viewController.queue to access the queue, or is there a better or alternative method?
Absolutely not. Nothing UI-related can ever be touched from another thread. It's simply not safe. If the other thread needs to know the switch's current value, then it needs to call back to the main thread before asking for it.
If you create a subclass, you could store your state in variables in the object, then access these variables from any thread; provided of course these operations do not call methods defined by UIKit.