Re: Weird crash on iOS
Re: Weird crash on iOS
- Subject: Re: Weird crash on iOS
- From: Laurent Daudelin <email@hidden>
- Date: Wed, 19 Sep 2012 01:17:13 -0700
On Sep 19, 2012, at 00:36, "Glenn L. Austin" <email@hidden> wrote:
> On Sep 18, 2012, at 10:50 PM, Laurent Daudelin <email@hidden> wrote:
>
>> On Sep 18, 2012, at 22:35, Glenn L. Austin <email@hidden> wrote:
>>
>>> Just one of the (multiple) reasons I despise the "afterDelay" version.
>>>
>>> Almost every crash I see is directly (or indirectly) caused by using performSelector:withObject:afterDelay: to insert some kind of "pause" in the application, and that pause isn't cancelable (AFAIK) -- the selector WILL be called after the delay time, even if the user has moved to another part of the program.
>>
>> Glenn,
>>
>> Can you elaborate on the last part?
>
>
> Sure. I often see people use performSelector:withObject:afterDelay: as a way to implement a "state machine" where they move from method to method using performSelector:withObject:afterDelay: as a way to "not block" the main thread.
>
> Now, imagine that the user leaves that view to go back to the main view and in order to do this you popped the navigator stack (or otherwise modified it), that view is gone when the selector is performed, and BOOM!
>
> A far better way is to either use a pre-defined queue of operations, or now use GCD. Whatever you do should be easily cancelable. If you're using a queue, cancel the queue contents -- otherwise set a flag that your code can check before moving to the next state.
>
> These kinds of crashes are hard to diagnose and track down, but in every case of non-deterministic crashes I've seen have been related to using some kind of timer. For pre-4.0, I switched code out to either use a queue and performSelectorOnMainThread:withObject:, or a thread that slept for the designated time and checked the "cancelled" flag before calling the selector. Yes, it does mean keeping track of an additional object, but rock-solid stability (one product I worked on went from something like 100 distinct reported crash types to zero) was worth the little bit of extra care.
I see what you mean. Well, I'm not trying to recreate a state machine. For example, I have a bunch of UITableViewCells that download content from a server, including images. When they are done, I want to refresh the table view because the pictures will not display. However, I don't want to reload the table view each time a cell has got its content, so, they send a message to the UITableViewController which then cancel any previous performAfterDelay that could be pending and then issue a performAfterDelay to reload the table view. So, if there is a delay of more than 3 seconds, the table view will reload, otherwise, it will keep pushing out the reload until most cells have received their contents. Of course, the content of the cells is partially visible as the text portion is quick to setup. It's the images attached to the cells that can take a variable amount of time.
-Laurent.
--
Laurent Daudelin
AIM/iChat/Skype:LaurentDaudelin http://www.nemesys-soft.com/
Logiciels Nemesys Software email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden