On 25.02.2012 21:50, René Ruppert wrote:
one thing I have been wondering about is, how quickly apps written in ObjC
can cancel threads.
Just one example: I have an app where I can check train schedules. I tell it
from where to where and it starts searching. Whenever I click some other
element in the tab bar, the search is interrupted immediately.
I fail to see a correlation between a responsive UI and
the ability to kill threads really fast.
Back in the good old days of .NET I was told: “Thread.Abort()” is evil!
Don’t use!”. So as a .NET developer I always have to abort in a clean way
but that makes apps less responsive. If you have to wait for the next web
call to return, for the next page to be rendered, etc it will be slow(er).
What prevents you from:
- reacting on user interaction (user clicks "Cancel")
- updating the UI to reflect the cancel operation (remove
spinners, etc.)
- setting a flag in a background thread
- evaluating this flag from the background thread and leave it
gracefully some time later?
If I check MSDN now, I see that Thread.Abort() will no longer abort finally
clauses. For me this means, Abort() no longer is that evil as it was because
you actually have a chance to clean up using a “finally” clause.
Abort is still cumbersome.
Robert
_______________________________________________
MonoTouch mailing list
[email protected]
http://lists.ximian.com/mailman/listinfo/monotouch
