How does not to Crash #3: nsnotification notification-induced crash

<title>How does not to Crash #3: nsnotification notification-induced crash</title>

How does not to Crash #3: nsnotification notification-induced crash cause of the crash caused by the one-to-crash How does the Big rule avoid crashing? Blanket unregistering Not a good way to remove a notification Remove the drawbacks of a specified notification the correct way to remove notifications Beware Double Registrations note multiple registrations for the same notification Register in Init, unregister in dealloc correct registration notification method Avoid Addobserverforname Avoid using this method original link and translation reference

How does not to Crash #3: nsnotification notification-induced crash

In general, I prefer Nsnotification to KVO and (especially) to bindings. I do use KVO sometimes-there is times when it's the most sensible thing. but nsnotification, like many older APIs, are easier to use without crashing. (Overall, using nsnotification is less prone to crashes than using KVO)

But you still need to be careful.

Cause of the crash caused by the one-to-crash

When an object registers to a notification, and then was deallocated without Unregistering, then the app would crash if That's notification is posted. That's the thing you need to avoid. The rest of this article describes how-to does that.

How does the Big rule avoid crashing?

I have one simple, hard-and-fast rule: nsnotifications is posted on the main thread is only. (Notifications are always sent on the main thread) No exceptions. If Some code is running in another thread and it needs to post a notification, it does so on the main thread.

This avoids all problems with notifications coming and on threads you don ' t expect. It avoids race conditions with unregistering for notifications. (avoids the crash caused by notifications on different threads, avoiding problems caused by resource contention)

Almost all of an app ' s code should is written to run on the main thread. Code that runs in an nsoperation or GCD queue should is isolated from everything else, and should use a delegate pattern ( With or without blocks) while multiple objects work together.

Ensuring that notifications is always posted on the main thread ought to being easy. (I ' ll do another How-not-to-crash article on threading and queues that goes into more detail.)

Blanket unregistering not good way to remove notifications

Some people like the extra housekeeping work of unregistering for each nsnotification explicitly in Dealloc. You get the things like this:

[[Nsnotificationcenter Defaultcenter] removeobserver:self name:ksomenotificationname Object:someObject];

[[Nsnotificationcenter Defaultcenter] removeobserver:self name:ksomeothernotificationname Object:someOtherObject];

etc...

Remove the drawbacks of a specified notification

You can prove if you write this, it ' s correct. But it's not enough to think of a snapshot of the your code-you had to think about your code as it moves through time.< /c1>

and future you or the future somebody else might add another notification, and not remember to call removeobserver for that SP ECIFIC notification. And then there ' s a crash.

The other problem was that future coder may has to go through your code and does an audit to make sure each registered Obser Vation is removed. This is a pain:it ' s manual and Error-prone.

The correct way to remove notifications

Instead, always does this:

[[Nsnotificationcenter Defaultcenter] removeobserver:self];

It's What Indiana Jones (film, the protagonist of Indiana) would do.

Beware Double registrations note multiple registrations for the same notification

If An object registers to a notification, and then registers for it again, the notification handler would get called T Wice. (If the same notification is registered more than once, the notification's processing method is called multiple times) There ' s no automatic coalescing.

(This used to happen in the old days on IOS a lot with viewdidload. People would put registration code There-but Remember that views could get unloaded and reloaded, which meant multiple R Egistrations for the same notification.)

Your notification handlers should is written so, they can deal with getting called twice. And it should is impossible for a given object to register twice for the same notification. Both.

Register in Init, unregister in dealloc correct registration notification method

In almost every a single case, I register for observations in a Init method and remove observations in Dealloc. If I find a object needs to add and remove observations during the lifetime of the object, then I consider it a Stro ng code smell.

There ' s a good chance that 1) either it doesn ' t really need to does that, or 2) the object should is split into smaller obje Cts.

You know this an Init method would be called just once for a given object. You know that Dealloc would be called just once when there is no other references to that object. can use this knowledge to balance out registering and unregistering without have to think about it or keep track of It. So easy.

Avoid Addobserverforname Avoid using this method

Some people like-[nsnotificationcenter Addobserverforname:?object:?queue:?usingblock:]. It feels modern because it ' s block-based, and we all love blocks. (I sure do.)

But it's a bad idea. Your may has saved yourself writing a notification handler method, but you ' ve made your housekeeping worse because now The extra object to keep around and do a removeobserver:on later. That means no blanket unregistering; It means you "re back to doing audits; It means another thing to get right.

You might the block-based version means you can keep the registration and the notification handler Together-bu T the cost was too high in housekeeping and potential crashes.

Original link and translation reference

• http://ifujun.com/yi-wen-ru-he-cai-neng-bu-beng-kui-3-nsnotification/
• Http://inessential.com/2015/05/21/how_not_to_crash_3_nsnotification

How does not to Crash #3: nsnotification notification-induced crash