3 ms·

There's nothing really magical about this – don't cause retain cycles, everyone knows __block semantics changed with ARC, keep the returned value from the block

There's nothing really magical about this – don't cause retain cycles, everyone knows __block semantics changed with ARC, keep the returned value from the block-based NSNotificationCenter method, etc. Standard stuff. The only thing that surprised me was the reference cycle in NSAssert. Then again, given Apple's poor regard for TDD, that shouldn't surprise me.

AshFurrow 13y ago
By the way, you can prevent the retain cycle in NSAssert using libextobjc's @weakify and @strongify macros.
- dcaunt 13y ago
  Indeed, the NSAssert cycle surprised me too. libextobj is great.
deleted 13y ago
[deleted]
seivan 13y ago
Pretty much my take on it as well. Nothing out of the ordinary here except the NSAssert, but I got that before the summer. A hack to get around the self inside the macro https://github.com/seivan/SHAlertViewBlocks/blob/develop/Example/Example/Example-Prefix.pch#L9-L23 https://github.com/seivan/SHAlertViewBlocks/blob/develop/Exa...
stigi 13y ago
I'd recommend looking at @weakify and @strongify that come with libextobjc (https://github.com/jspahrsummers/libextobjc/ https://github.com/jspahrsummers/libextobjc/). Handy little helpers to avoid retain cycles with all kind of blocks.
drewcrawford 13y ago
> everyone knows __block semantics changed Everyone except the authors of the "Blocks Programming Topics" and the authors of the AVCamCaptureManager sample code. Maybe. FYI the reason I included the digression about the __block change specifically is that I was recently fixing bugs on a project that uses AVCamCaptureManager, and Apple's mis-use of __block in that class, this is not a joke, through a series of corner cases, caused the status bar to unexpectedly and nondeterminisitically change color about 5% of the time on an unrelated screen. Saying "everybody should already know how to do weak references" is great in theory. But if you are fielding weird reports for unreproducible status bar issues and it occurs to you at any time in the first hour that maybe Jim from the next cubicle used buggy sample code for a video recording feature on another screen you are a WAY better software developer than I am. Of course this is standard stuff. But unlike a lot of standard stuff, this one can go undetected for long periods, and crop up in very unexpected places. That's the problem.
- matwood 13y ago
  Apple's sample code is terrible. I've always assumed it is written by interns because it is generally bug ridden and often not the right way to do something.
  - chc 13y ago
    Do you mean the code examples in articles or the projects that you can download? Because I haven't looked at their downloadable samples in quite some time, but their docs always seem alright to me.
    - seandougall 13y ago
      Both, in my experience. The downloadable code is usually a rush job and has all sorts of sloppiness and missed edge cases. The code in the docs is usually cleaner (because it's just excerpts), but doesn't always get updated when APIs change.
    - matwood 13y ago
      The code samples are just bad and many are very outdated. I generally just read the header comments now and hit SO if I need more.
- lukeredpath 13y ago
  > Everyone except the authors of the "Blocks Programming Topics" and the authors of the AVCamCaptureManager sample code. Maybe. No - it's just that these documents/samples haven't been updated when they should have been. Have you filed a Radar?
  - drewcrawford 13y ago
    > have you filed a radar I have radars open on both of these issues (and a large quantity of other things referenced in this post). They remain open for long periods of time without acknowledgment, as is tradition.
terhechte 13y ago
Same here. Nothing special. Everything he mentions is not specific to NSNotificationCenter with block. One has to look out for these issues whenever one uses blocks. The NSAssert macro caught me by surprise too.
chrisdevereux 13y ago
Another issue with NSAssert is that it's #ifdef-ed out in release mode. So it can introduce reference cycles that only exist in debug mode, that prevent you from spotting premature deallocations that only become apparent in release mode. (Of course, you QA in release mode. But it's annoying not catching that stuff early)
mackey 13y ago
I agree and disagree. For me, I agree this is standard stuff. If you are writing this stuff everyday, this block song and dance is basically taken care of with muscle memory. Part of my job involves working with people from other companies who aren't as strong with objective-c. There are a lot of people that have trouble blocks for whatever reasons. I recently had a guy from another company act almost surprised that we were using "advanced features like blocks". We were a little shocked. But it just shows that not everyone is comfortable with them. BUT, I think a better approach from the author wouldn't be to tell people not to use blocks w/ NSNotificationCenter but to make sure they know the in and outs of blocks, because blocks are amazingly powerful tools and they aren't going anywhere.

AshFurrow 13y ago

By the way, you can prevent the retain cycle in NSAssert using libextobjc's @weakify and @strongify macros.

dcaunt 13y ago
Indeed, the NSAssert cycle surprised me too. libextobj is great.

deleted 13y ago

[deleted]

seivan 13y ago

Pretty much my take on it as well. Nothing out of the ordinary here except the NSAssert, but I got that before the summer. A hack to get around the self inside the macro https://github.com/seivan/SHAlertViewBlocks/blob/develop/Example/Example/Example-Prefix.pch#L9-L23 https://github.com/seivan/SHAlertViewBlocks/blob/develop/Exa...

stigi 13y ago

I'd recommend looking at @weakify and @strongify that come with libextobjc (https://github.com/jspahrsummers/libextobjc/ https://github.com/jspahrsummers/libextobjc/). Handy little helpers to avoid retain cycles with all kind of blocks.

drewcrawford 13y ago

> everyone knows __block semantics changed Everyone except the authors of the "Blocks Programming Topics" and the authors of the AVCamCaptureManager sample code. Maybe. FYI the reason I included the digression about the __block change specifically is that I was recently fixing bugs on a project that uses AVCamCaptureManager, and Apple's mis-use of __block in that class, this is not a joke, through a series of corner cases, caused the status bar to unexpectedly and nondeterminisitically change color about 5% of the time on an unrelated screen. Saying "everybody should already know how to do weak references" is great in theory. But if you are fielding weird reports for unreproducible status bar issues and it occurs to you at any time in the first hour that maybe Jim from the next cubicle used buggy sample code for a video recording feature on another screen you are a WAY better software developer than I am. Of course this is standard stuff. But unlike a lot of standard stuff, this one can go undetected for long periods, and crop up in very unexpected places. That's the problem.

matwood 13y ago
Apple's sample code is terrible. I've always assumed it is written by interns because it is generally bug ridden and often not the right way to do something.
- chc 13y ago
  Do you mean the code examples in articles or the projects that you can download? Because I haven't looked at their downloadable samples in quite some time, but their docs always seem alright to me.
  - seandougall 13y ago
    Both, in my experience. The downloadable code is usually a rush job and has all sorts of sloppiness and missed edge cases. The code in the docs is usually cleaner (because it's just excerpts), but doesn't always get updated when APIs change.
  - matwood 13y ago
    The code samples are just bad and many are very outdated. I generally just read the header comments now and hit SO if I need more.
lukeredpath 13y ago
> Everyone except the authors of the "Blocks Programming Topics" and the authors of the AVCamCaptureManager sample code. Maybe. No - it's just that these documents/samples haven't been updated when they should have been. Have you filed a Radar?
- drewcrawford 13y ago
  > have you filed a radar I have radars open on both of these issues (and a large quantity of other things referenced in this post). They remain open for long periods of time without acknowledgment, as is tradition.

terhechte 13y ago

Same here. Nothing special. Everything he mentions is not specific to NSNotificationCenter with block. One has to look out for these issues whenever one uses blocks. The NSAssert macro caught me by surprise too.

chrisdevereux 13y ago

Another issue with NSAssert is that it's #ifdef-ed out in release mode. So it can introduce reference cycles that only exist in debug mode, that prevent you from spotting premature deallocations that only become apparent in release mode. (Of course, you QA in release mode. But it's annoying not catching that stuff early)

mackey 13y ago

I agree and disagree. For me, I agree this is standard stuff. If you are writing this stuff everyday, this block song and dance is basically taken care of with muscle memory. Part of my job involves working with people from other companies who aren't as strong with objective-c. There are a lot of people that have trouble blocks for whatever reasons. I recently had a guy from another company act almost surprised that we were using "advanced features like blocks". We were a little shocked. But it just shows that not everyone is comfortable with them. BUT, I think a better approach from the author wouldn't be to tell people not to use blocks w/ NSNotificationCenter but to make sure they know the in and outs of blocks, because blocks are amazingly powerful tools and they aren't going anywhere.