I really need help here. I'm desperate at this point.
I have NSOperation that when added to the NSOperationQueue is not being triggered.
I added some logging to see the NSOperation status and this is the result:
Queue operations count = 1
Queue isSuspended = 0
Operation isCancelled? = 0
Operation isConcurrent? = 0
Operation isFinished? = 0
Operation isExecuted? = 0
Operation isReady? = 1
Operation dependencies? = 0
The code is very simple. Nothing special.
LoadingConflictEvents_iPad *loadingEvents = [[LoadingConflictEvents_iPad alloc] initWithNibName:#"LoadingConflictEvents_iPad" bundle:[NSBundle mainBundle]];
loadingEvents.modalPresentationStyle = UIModalPresentationFormSheet;
loadingEvents.conflictOpDelegate = self;
[self presentModalViewController:loadingEvents animated:NO];
[loadingEvents release];
ConflictEventOperation *operation = [[ConflictEventOperation alloc] initWithParameters:wiLr.formNumber pWI_ID:wiLr.wi_id];
[queue addOperation:operation];
NSLog(#"Queue operations count = %d",[queue operationCount]);
NSLog(#"Queue isSuspended = %d",[queue isSuspended]);
NSLog(#"Operation isCancelled? = %d",[operation isCancelled]);
NSLog(#"Operation isConcurrent? = %d",[operation isConcurrent]);
NSLog(#"Operation isFinished? = %d",[operation isFinished]);
NSLog(#"Operation isExecuted? = %d",[operation isExecuting]);
NSLog(#"Operation isReady? = %d",[operation isReady]);
NSLog(#"Operation dependencies? = %d",[[operation dependencies] count]);
[operation release];
Now my operation do many things on the main method, but the problem is never being called. The main is never executed.
The most weird thing (believe me, I'm not crazy .. yet). If I put a break point in any NSLog line or in the creation of the operation the main method will be called and everything will work perfectly.
This have been working fine for a long time. I have been making some changes recently and apparently something screw things up. One of those changes was to upgrade the device to iOS 5.1 SDK (iPad).
To add something, I have the iPhone (iOS 5.1) version of this application that use the same NSOperation object. The difference is in the UI only, and everything works fine.
Oh, and this only fails on the actual device. In the simulator everything works ok.
Any help will be really appreciated.
Regards,
If the operation is concurrent, you need to implement -start, not -main.
Ok, I finally solve this issue.
The problem I was having was due to an NSOperation running in the background all the time (but in a different queue). This operation was blocking any other thread (NSOperation) to be executed. This was happening only in iPad 1 because is not dual core.
My NSOperation was doing something like this on the main method:
- (void)main
{
while (![self isCancelled]) {
//Do stuff
}
}
And the NSOperation was contantly doing it the whole time
Silly me, I didn't give the OS time to work with other threads, so adding a sleep made the trick
- (void)main
{
while (![self isCancelled]) {
[NSThread sleepForTimeInterval:0.5];
//Do Stuff
}
}
That sleep gives the OS chance to work with other threads.
Why putting a breakpoint was doing the work? ... the debugger stopped all the threads and because the breakpoint was in my other NSOperation, that thread was executed.
I had the same issue, but the resolution to mine was not the same, so I thought I'd throw my answer in here too for future people like me.
My problem was that in my NSOperation subclass, I had:
#property CGPoint start;
which, when synthesized, creates the method:
-(CGPoint)start
which overrides NSOperation's -(void)start; method, which is the signifier for a non-concurrent NSOperation, and was preventing all the regular stuff that goes on in -(void)start from happening, which thus prevents the -(void)main method from being called at all.
Once I renamed my property to something other than start, it worked fine.
Ok, this issue is only happening with iPad 1 devices with application compiled with the SDK 5.1.
I tried with an iPad 1 with iOS 4.2.1 and iPad 1 with iOS 5.1. Both gives the same problems.
For sure this was working in both iPads with application compiled with SDK 4.3
Related
Sorry, it's a bit wordy, but I wanted to make sure I was clear! ;-)
I have an iOS app that uses FFMPEG for streaming RTSP. I've multi-threaded FFMPEG using NSOperationQueue such that most its work, other than painting the image to the screen, of course, happens in background threads.
Works great! ...except for the fact that threads the NSOperationQueue creates never die!
I init the Queue in the class' init method with:
self->opQ = [[NSOperationQueue alloc] init];
[self->opQ setMaxConcurrentOperationCount:1];
I add methods to the Queue using blocks:
[self->opQ addOperationWithBlock:^{
[self haveConnectedSuccessfullyOperation];
}];
Or
[self->opQ addOperationWithBlock:^{
if (SOME_CONDITION) {
[self performSelectorOnMainThread:#selector(DO_SOME_CRAP) withObject:nil waitUntilDone:NO];
}
}];
Later, when I need to tear down the RTSP stream, in addition to telling FFMPEG to shut down, I call:
[self->opQ cancelAllOperations];
Which does indeed stop the threads from doing any work , but never actually destroys them. Below, you'll see a screen shot of threads that are doing nothing at all. This is what my threads look like after starting/stoping FFMPEG several times.
I seem to remember reading in Apple's documentation that NSOperations and the threads they are run on are destroyed once they are done executing, unless otherwise referenced. This doesn't appear to be the case.
Do I just need to destroy the NSOperationQueue, then re-init it when I need to start up FFMPEG again (I just realized I haven't tried this)? Anyone know how I need to kill these extra threads?
THANKS!
I solved it by creating NSBlockOperations so that I could monitor the isCancelled state, while also making the new NSBlockOperations' content more intelligent, such that I simplified the routine that would add the operations to the queue.
... Plus, I made an NSOperationQueue n00b mistake: I was adding operations to the queue on a looping basis, which fired up to 30 times per second (matching the video's frame rate). Now, however, the operation is added to the queue only once and the looping behavior is contained within the operation instead of having the loop add the operation to the queue.
Previously, I had something like this (pseudo code, since I don't have the project with me):
NSTimer *frameRateTimeout = [NSTimer scheduledTimerWithTimeInterval:1/DESIRED_FRAMES_PER_SECOND target:self selector:#selector(ADD_OPERATION_TO_QUEUE_METHOD:) userInfo:nil repeats:YES];
-(void)ADD_OPERATION_TO_QUEUE_METHOD:(NSTimer *)timer {
[opQ addOperation:displayFrame];
}
Which worked well, as the OS would correctly manage the queue, but it was not very efficient, and kept those threads alive forever.
Now, it's more like:
-(id)init {
self = [super init];
if (self) {
// alloc/init operation queue
...
// alloc/init 'displayFrame'
displayFrame = [NSBlockOperation blockOperationWithBlock:^{
while (SOME_CONDITION && ![displayFrame isCancelled]) {
if (playVideo) {
// DO STUFF
[NSThread sleepForTimeInterval:FRAME_RATE];
}
else { // teardown stream
// DO STUFF
break;
}
}
}];
}
return self;
}
- (void)Some_method_called_after_getting_video_ready_to_play {
[opQ addOperation:displayFrame];
}
Thanks, Jacob Relkin, for responding to my post.
If anyone needs further clarification, let me know, and I'll post better code once I have the project in my hands again.
I am quite new to iOS development and I'm facing a multithreading issue.
I'm using KTPhotobrowser with SDWebImage to create a photo and video gallery.
I have to load some external data on each picture, and I don't want to affect the smoothness of the gallery's scroll view.
So, I'm trying to do that using NSOperation and NSOperationQueue, but I'm not sure I'm doing right.
What I want is to stop the loading process if the user doesn't stay on the picture and keep scrolling.
My current code:
//setCurrentIndex is called when the scrollView is scrolled
- (void)setCurrentIndex:(NSInteger)newIndex {
[loadingQueue_cancelAllOperations];
currentIndex_ = newIndex;
[self loadPhoto:currentIndex_];
NSInvocationOperation *InvocationOp = [[NSInvocationOperation alloc] initWithTarget:self selector:#selector(loadInfosAtIndex:) object:newIndex];
[loadingQueue_ addOperation:InvocationOp];
[InvocationOp release];
[selfloadPhoto:currentIndex_ + 1];
[selfloadPhoto:currentIndex_ - 1];
[selfunloadPhoto:currentIndex_ + 2];
[selfunloadPhoto:currentIndex_ - 2];
}
-(void) loadInfosAtIndex:(NSInteger)index {
if (index < 0 || index >= photoCount_) {
return;
}
KTPhotoView* photoView = [photoViews_ objectAtIndex:index];
if([photoView infosAlreadyLoaded]){
NSLog(#"%d Already Loaded", index);
return;
}
//Get the extra information by calling a web service
photoView.infosAlreadyLoaded = YES;
}
I don't think this is the proper way to do this... has anyone got any advice?
Instead of relying on a scheduling-based cancel, which can leave you in an uncertain state, have a cancelling instance variable that has atomic access (either via an atomic property or a BOOL ivar with a mutex).
Then, instead of [loadingQueue_cancelAllOperations], you simply set the canceling flag to YES and check it in loadInfosAtIndex periodically. This is essentially polling for the cancel, and if the code is involved, it can be a pain. But it has the advantage of letting you be able to handle the cancel gracefully by reading the flag. As a part of handling, you can set an isRunning flag (also needs to be atomic/mutexed) to NO and exit the thread by returning.
In the main thread, after setting the cancelling flag to YES, you can wait till the isRunning flag is NO before opening up a new thread.
[loadingQueue_ cancelAllOperations], simply doesn't cancel the operations immediately, it only cancels the operations in the queue that has not yet started executing.
If the operation in the queue has already started then it is removed only after the operation is completed. More about cancelAllOperations
I think you might want to use GCD async for that where you might remove the currently executing block.
I'm using CMMotionManager for retrieving accelerometer data. The thing is that the accelerometer data gets printed periodically, the instance variables are changed in the view, but the view doesn't get redrawn. I have checked that hv is not nil and that everything is hooked. Is there a problem with calling setNeedsDisplay within a block?
-(void) viewDidAppear:(BOOL) animated
{
[super viewDidAppear: animated];
[motionManager startAccelerometerUpdatesToQueue:motionQueue withHandler:
^(CMAccelerometerData *accelerometerData, NSError *error)
{
NSLog(#"%#",accelerometerData);
HypnosisView *hv = (HypnosisView *) [self view];
hv.xShift = 10.0 * accelerometerData.acceleration.x;
hv.yShift = -10.0 * accelerometerData.acceleration.y;
[hv setNeedsDisplay];
}];
}
It's because your calling a UI method on a thread different from the main thread.
Add this to your block:
dispatch_async(dispatch_get_main_queue(), ^{
[hv setNeedsDisplay];
});
Remember that any method dealing with user interface elements must be called from the main thread.
I have done the same in other blocks and it did work, though not with the callback you use here. Maybe the block is not executed on the main thread? You can check that with:
NSLog(#"Main thread? %d", [NSThread isMainThread]);
If it is not, you could force setNeedsDisplay to run on the main thread.
Just wanted to test #cocoahero's answer. I tried to call setTitle for a UIButton in a non main thread. And the title did changed. I tried this both targeting iOS 5.1 and 7.0 using Xcode 5.0.1. Also I called setNeedsDisplay from a non main thread and it worked too.
[NSThread isMainThread] was how I made sure that my calls were not from main thread. I am not sure calling from non main thread was the cause to your problem but at least there are other possibilities there. You can take a look at my answer for another question.
I need your help. I have write my own custom NSOperation class called GetNewsOperation. I call it like this:
GetNewsOperation *getNewsOperation = [[GetNewsOperation alloc] initWithLocalNewsCategories:self];
[loadNewsOperationQueue addOperation:getNewsOperation];
[getNewsOperation release];
In GetNewsOperation class I have implemented init method for initialization and main method for executing operation and returning data back to the main thread.
Main method looks like this:
- (void)main {
NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];
AppSettingsController *sharedAppSettingsController = [AppSettingsController sharedAppSettingsController];
if( [type isEqualToString:#"getCategory"] ) {
NSMutableArray *parsedData = [[NSMutableArray alloc] initWithArray:[sharedAppSettingsController getLocalNewsCategories]];
[newsViewController performSelectorOnMainThread:#selector(loadDataResponse:) withObject:[NSArray arrayWithObjects:parsedData, nil] waitUntilDone:NO];
[parsedData release]; parsedData = nil;
}
[pool release];
}
Everything works fine but I have a minor problem. When this operation is called application does not rotate on device orientation change. It changes after operation is finished.
As far as I know this operation is running for sure in new thread (not in main) cos all other elements in the app are active (not freezed). But I have only problem with orientation. The app looks kind a crappy if application does not rotate only when this operation occurs...
How can I solve this?
Thanks!
Actually it works like predicted. I was doing something else on main thread that blocked application.
For example in a thread (because I can't wait in main loop) I have this code :
-(void) game {
for (Players player in players) {
if (player.type == IA) { // computer plays
answer = [player play];
else {
[ui showQuestion]; // user plays with the touch screen
// here waiting for the answer touch
answer = ???????????????? // return from waiting after touch callback
}
[answersArray addObject:answer];
}
answer = [self bestAnswer : answersArray];
[ui showTheBestAnswer : answer];
}
Is there a solution to wait for an UI Event in a fixed code place ?
without blocking the main loop of course.
Thank you very much for your help,
jpdms
First of all, I highly recommend that you read Apple's Concurrency Programming Guide, included with the Xcode documentation. In general, there are much better alternatives to threads, especially in the example you provide.
However:
If the game method is executing on a separate thread, then the proper way to signal the thread is using NSCondition. Create an instance and make sure both the code above and the touch handler has access to it.
NSCondition *playerDidTouchCondition = [[NSCondition alloc] init];
In the game method, you wait on the condition like this:
[ui showQuestion];
[playerDidTouchCondition lock];
[playerDidTouchCondition wait];
[playerDidTouchCondition unlock];
// do something with answer
Your game thread will sleep until the condition has been signaled. In your touch handler you would do this:
answer = whatever the user did
[playerDidTouchCondition lock];
[playerDidTouchCondition signal]; // wake up one of the sleeping threads
[playerDidTouchCondition unlock];
The example code you have above really doesn't demonstrate the need for a separate thread, however. You could very easily store a currentPlayerIndex somewhere and proceed to the next player inside of the button handler for the answer button.
Also, you MUST ensure that any UI updates are actually happening on the main thread. I hope that your lines like [ui showQuestion] are queuing calls on the main thread. In Cocoa you can do this easily with something like: [ui performSelectorOnMainThread:#selector(showQuestion)];
You really, really, really should not be using a separate thread for this.