wavWasSavedAtLocation – not always "WasSaved"

[BergeracMatt]

Hi Halle,
I’ve finally implemented SaveThatWave and I came across many cases (about 20% of the time) on devices and in the simulator where wavWasSavedAtLocation is called before a file exists at “location”.
Is this behaviour expected?

I’ve written a scheduledTimerWithTimeInterval loop, polling to check the files existence before proceeding. Is there a better way to deal with it?
Thanks
Matt.

[Halle Winkler]

Hi Matt,

The notification that results in this delegate method isn’t sent out until the fail/success result of the actual writeout is received, meaning that it can’t start until after the writeout is not just complete but its result status is also known. Although it is possible for the notification to be delayed, I can’t see a way for it to be premature to the existence of the file unless the bug is in NSData.

Based on this design and that I haven’t received this issue report before (I have had reports of delays, which is sometimes expected), my expectation in this case is that the issue lies elsewhere, but if you don’t have any leads on any peculiarities of the implementation that could result in an issue on the filesystem side, rather than polling, I would recommend just padding the action that you take after receiving that delegate callback using some type of sleep, by whatever number of milliseconds gives you consistent results. It’s likely to be a small number. If you don’t want to pad it generally, it would probably work fine to make one attempt and then if that fails make one time-padded attempt.

[BergeracMatt]

Sorry Halle, I’ve suffered the consequences of doing 18 hour days here. I was doing something stupid, I thought I was calling a routine from the wavWasSavedAtLocation delegate but was in fact calling it from pocketsphinxDidReceiveHypothesis… my bad, sorry for costing your time.

[Halle Winkler]

No problem, glad you found the cause and I also appreciate your setting my mind at ease about it.

[Author]

Posts