- This topic has 22 replies, 2 voices, and was last updated 9 years, 10 months ago by .
-
Posts
-
I have 2 view controllers (VC1 and VC2) each of them uses OpenEars for TextToSpeach.
I also implemented delegate <OpenEarsEventsObserver> to capture -(void)fliteDidStartSpeaking{}
-(void)fliteDidFinishSpeaking{} events.My problem: on VC1 everything works perfect, then I move on to VC2 and here when -(void)fliteDidStartSpeaking{} or -(void)fliteDidFinishSpeaking{} events occur it uses methods from the VC1 not the current VC2.
I tried nil-ing OpenEars object (cannot release in ARC) on VC1 before moving to VC2, app is crashing.
To make it work, I had to turn off ARC and manually release all OpenEars objects on VC1 before moving on to VC2.
Is there a way to make OpenEars use proper methods without turning ARC off?
Here is my VC1.h (that malfunctions with ARC on, to make it work: ARC=off in project build settings and release OpenEars objects in viewWillDisappear and alloc/init in viewWillAppear):
#import <Slt/Slt.h>
#import <OpenEars/FliteController.h>
#import <OpenEars/OpenEarsEventsObserver.h>
@interface VC1: UIViewController<OpenEarsEventsObserverDelegate>{
FliteController *fliteController;
Slt *slt;
OpenEarsEventsObserver *openEarsEventsObserver;
}
@property (strong, nonatomic) FliteController *fliteController;
@property (strong, nonatomic) Slt *slt;
@property (strong, nonatomic) OpenEarsEventsObserver *openEarsEventsObserver;VC1.m
@synthesize fliteController,slt,openEarsEventsObserver;
-(void)say_it{
[self.fliteController say:someTxt withVoice:self.slt];
}
-(void)stop_talking{
[self.fliteController interruptTalking];
}-(void)fliteDidStartSpeaking{
//do somthing when started speaking
}
-(void)fliteDidFinishSpeaking{
//do something when finished speaking
}
-(void)navToNextVC{//next view
UIViewController *nextVC= [self.storyboard instantiateViewControllerWithIdentifier:@”VC2″];
[self.navigationController pushViewController:nextVC animated:YES];
}
-(void)viewDidLoad{
fliteController = [[FliteController alloc] init];
slt = [[Slt alloc] init];
openEarsEventsObserver = [[OpenEarsEventsObserver alloc] init];
[openEarsEventsObserver setDelegate:self];
}VC2.h amd .m is essentially the same, just different methods for fliteDidStart(Finished)Speaking.
Thanks.
Welcome,
Is the issue that only VC1 is getting callbacks, or is it possible that VC1 and VC2 are simultaneously getting callbacks from the same speech but you are reacting to the callback in VC1 first and not getting the info that VC2 is also getting the callback? The expectation is that they would both get a callback from the same speech event if they are both instantiated with OpenEarsEventsObserver delegates.
Second question is about what is being set to nil. Did you set FliteController to nil, FliteController’s OpenEarsEventsObserver, or FliteController’s OpenEarsEventsObserver.delegate?
It should only be necessary to set the delegate of OpenEarsEventsObserver to nil – can you just do that and show the logging output and the backtrace for the crash? To get the backtrace you’ll type “bt” when the app suspends due to the crash and you have the lldb prompt. It’s surprising that it crashes without a set delegate (versus the crash originating from something else) since the delegate methods are optional.
OK. It’s actually working as designed that both view controllers get the events if they are both instantiated and have self as delegates. We can troubleshoot why you can’t make the first view controller no longer a delegate of the object.
That looks more like it’s crashing because you aren’t using the recommended memory management from the sample app and tutorial. Can you switch over to that instead? Take a look at how FliteController is set up in the sample app and then only called as a property with self.fliteController. It’s also demonstrated step-by-step in the tutorial.
These really seem like issues with the FliteController implementation in each view controller. The crash is very much a crash of FliteController, and the OpenEarsEventsObserver is a separate object (with very strong separation between the two objects in question) and there’s no reason for it to care whether it has a set delegate and in which view controller it is set or not set.
I think we actually need to just troubleshoot why your FliteController instance doesn’t work quite right. I would shut off OpenEarsEventsObserver entirely (don’t instantiate it, don’t make anything a delegate of it) and see if this crash replicates independently without anything going on but FliteController.
It’s always much better to test on a real device, but I think step one is to identify the actual issue, so it would be good to remove OpenEarsEventsObserver in order to verify that this FliteController crash isn’t related to it.
Don’t worry, we aren’t trying to remove the functionality of OpenEarsEventsObserver from your app permanently as some kind of workaround for the issue, we’re just starting to troubleshoot the crash you’re reporting by first finding out what it is/isn’t connected to, in order to fix the real issue (I don’t think it has to do with OpenEarsEventsObserver or ARC – to me it looks like it’s either an issue with FliteController or it’s Slt not being instantiated any more when it’s needed by FliteController).
So step one is to rule OpenEarsEventsObserver out as the problem by turning it off and seeing if the crash still happens. If the crashing behavior is the same, you can turn OpenEarsEventsObserver back on but stop troubleshooting it, because that suggests that the issue is independent of OpenEarsEventsObserver and you can spend the attention on FliteController. If the crash does not occur when OpenEarsEventsObserver is off, that suggests that it is related to OpenEarsEventsObserver. Both outcomes would tell us more about what is going on when your app is having this crash.
OK, that is useful info. I think this is just about the voices, maybe something about shared resources with the voices. Is Slt lazy-instantiated in both view controllers and only called with self.slt like in the tutorial?
OK, I nil-ed voices before leaving the view and it cured it. does not crash anymore.
I see, that’s quite interesting and may be a bug for me to check out. Glad the issue is clearing up, and let me know how it goes with the device.
OK, just go ahead with setting the voice to nil and I’ll take a look at the underlying issue when there is time.
- You must be logged in to reply to this topic.