Re: ARC [was Protecting against "app nap"]

If that wasn’t called out clearly in that non-ARC class’s documentation/header, then that non-ARC class was Doing It Wrong(tm). > On May 13, 2016, at 2:55 AM, Dave wrote: > > Hi, > > The other thing to watch out for is if you have non ARC Classes in your > project,

Re: ARC [was Protecting against "app nap"]

Hi, The other thing to watch out for is if you have non ARC Classes in your project, you can forget that they are using assign rather than weak for properties (so the reference doesn’t get zeroed) that can lead to sending message to objects that have been destroyed if you are not careful. You

Re: ARC [was Protecting against "app nap"]

> On May 12, 2016, at 1:16 AM, Jonathan Taylor > wrote: > > you would definitely recommend ARC then, would you? Totally. As Roland said, I would never go back. > I've been a bit put off by what seems like regular questions on the list(s) > about debugging and

Re: ARC [was Protecting against "app nap"]

I can’t imagine going back to manual retain release. ARC lifted hours of work away from writing code because you just use objects and they stay when they need to stay go away when you’re done with them. I see hardly any questions about ARC at all, there were some at the very start, but they

Re: ARC [was Protecting against "app nap"]

Hi Jens, Thanks again for your reply. I'm sure this has been done to death over the years on the list, but... you would definitely recommend ARC then, would you? I've been a bit put off by what seems like regular questions on the list(s) about debugging and fixing edge cases where ARC doesn't

Re: Protecting against "app nap"

> On May 11, 2016, at 2:31 AM, Jonathan Taylor > wrote: > > I guess I just found method naming a bit odd (not really referring to an > object at all), and might have expected it to have an ‘alloc/new’ naming > since I’d have thought the API would be almost

Re: Protecting against "app nap"

Thankyou both for your replies - a couple of replies below: On 10 May 2016, at 23:33, Jens Alfke wrote: >> However, I was a bit surprised to find that I seem to need to explicitly >> retain the object I get back [this is non-ARC code…] if I want my request to >> remain in

Re: Protecting against "app nap"

> On May 10, 2016, at 10:26 AM, Jonathan Taylor > wrote: > > However, I was a bit surprised to find that I seem to need to explicitly > retain the object I get back [this is non-ARC code…] if I want my request to > remain in effect or even for the object to

Re: Protecting against "app nap"

Did you try clicking “Prevent app nap” in the “Info” inspector for the app? Paul > On May 10, 2016, at 10:26 AM, Jonathan Taylor > wrote: > > Hi all, > > I’m hoping somebody can help me work out how to protect my code against the > effects of “app nap”. This

Protecting against "app nap"

Hi all, I’m hoping somebody can help me work out how to protect my code against the effects of “app nap”. This code is driving a scientific experiment, unattended, and it is catastrophic when the OS decides that my timers running at 10Hz should only be fired every 10 seconds or so… which it