Sometimes trying to remove a listener inside it’s self won’t work because the function is still running. The timer lets the function return and complete it’s processing then a few milliseconds later, you can remove the handler.
That still doesn’t account for cases (which I’ve experienced) that the function doesn’t execute inside the expected time window which results in the performWithDelay call failing and not removing the runtime listener.
If the remove can’t be executed while the listener function is still executing, we need to be able to ‘queue’ or set a ‘finished event’ callback so that the listener can be removed immediately after the function is complete without guessing in milliseconds as to when the function ‘should’ be finished.
I’ve tried using closures and tables to do this myself but none of my or your workarounds/fixes are a complete solution (so far.)
I understand that technical limitations exist but this isn’t an advanced feature, just about any modern language (even js) has this ability.
Not being able to remove a listener from inside a listener function is a serious bug that is far bigger than the scope of Maps and location, it needs to be fixed.
Have you tried to put the remove inside of a short timer.performWithDelay()? Perhaps 10ms would do.
Rob
Unrelated timers are not a fix, if the location request takes longer than 10 seconds and the code isn’t catching the exception (which it shouldn’t have to) it will cause a potentially app breaking bug.
Your workaround works perfectly assuming you don’t need the event which isn’t passed though in build 2520, instead you get a function?
Sometimes trying to remove a listener inside it’s self won’t work because the function is still running. The timer lets the function return and complete it’s processing then a few milliseconds later, you can remove the handler.
That still doesn’t account for cases (which I’ve experienced) that the function doesn’t execute inside the expected time window which results in the performWithDelay call failing and not removing the runtime listener.
If the remove can’t be executed while the listener function is still executing, we need to be able to ‘queue’ or set a ‘finished event’ callback so that the listener can be removed immediately after the function is complete without guessing in milliseconds as to when the function ‘should’ be finished.
I’ve tried using closures and tables to do this myself but none of my or your workarounds/fixes are a complete solution (so far.)
I understand that technical limitations exist but this isn’t an advanced feature, just about any modern language (even js) has this ability.
If you update this and any similar code samples doing so in the docs, I think you’d make a bunch of threads unnecessary! At least that link is where I went first thing.
Don’t forget to include the forward declarations before the two recurrent functions! At least it wouldn’t resolve the matter for people looking at the docs if you didn’t, since it’s the main cause of the difference in handling of the lua file on IOS 7.1.
If you update this and any similar code samples doing so in the docs, I think you’d make a bunch of threads unnecessary! At least that link is where I went first thing.
Don’t forget to include the forward declarations before the two recurrent functions! At least it wouldn’t resolve the matter for people looking at the docs if you didn’t, since it’s the main cause of the difference in handling of the lua file on IOS 7.1.