ARC uses the analyzers rules. I was told that if you trust the analyzer (and
follow it's rules), ARC will be fine.
I have a few pieces of code that the analyzer was unhappy with, bugs had been
submitted, but they were primarily with C++ code wrapping CF objects.
--
Glenn L. Austin, Computer Wi
Hi,
I’d try this:
Make a method called setupTimer with the code below.
Then in applicationDidFinishLaunching call performSelector: setupTimer with a
delay of (say 5 seconds).
Just to see if it changes anything….
Cheers
Dave
> On 29 Apr 2020, at 23:35, Carl Hoefs via Cocoa-dev
> wrote:
>
Yes, that’s correct, nothing wrong with a method beginning with new as long as
it follows the rules, I use it all the time.
I’m not sure if it matters at all with ARC, but I stick by the rules anyway.
Cheers
Dave
> On 30 Apr 2020, at 00:27, Sandor Szatmari via Cocoa-dev
> wrote:
>
> Alex,
>
prefix new one must ensure
>> that the method followed memory management conventions, and would return an
>> object with a +1 retain count. Am I mistaken about this?
>>
>> Sandor
>>
>>>
>>>>> On Apr 29, 2020, at 4:07 PM, Carl Hoefs via Co
Cosmic rays? Disk corruption? Tired bits? Embedded escapes? Xcode cruft?
Whatever the bug-a-boo was, with a freshly reinstalled Xcode (11.2.1) and
command line tools, it's gone! I blew everything away and rebuilt the project
and It Just Works™️.
Thanks for all the support. Sorry for the noise!
)applicationDidFinishLaunching:(NSNotification *)aNotification {
// Insert code here to initialize your application
NSTimer *newTimer = [NSTimer timerWithTimeInterval:1.0 // should be 1/sec
target:self selector:@selector(newData:) userInfo:nil repeats:YES];
CFTimeInterval newTimerIntervalFromCF
followed memory management conventions, and would return an
> object with a +1 retain count. Am I mistaken about this?
>
> Sandor
>
>>
>>>> On Apr 29, 2020, at 4:07 PM, Carl Hoefs via Cocoa-dev
>>>>
dded a
>> newData: method. This is with Xcode 11.2.1 on Mojave, 10.4.6. Works fine
>> for me. Weird!
>>
>> @implementation AppDelegate
>>
>> - (void)applicationDidFinishLaunching:(NSNotification *)aNotification {
>>NSTimer *newTimer = [N
and instrument its creation (NSLog
or equiv.) which might help debug whether its the timer or how it's added or
perhaps how the caller is threaded...
@property (nonatomic, assign) NSTimer *myOneSecondTimer;
[self.myOneSecondTimer invalidate];
self.myOneSecondTimer = [NSTimer s
On Apr 29, 2020, at 5:27 PM, Sandor Szatmari via Cocoa-dev
wrote:
>
>> On Apr 29, 2020, at 17:12, Alex Zavatone via Cocoa-dev
>> wrote:
>>
>> Not sure about this, but in Objective-C, you’re not supposed to start
>> methods with new.
>
> I’ve always operated under the premise that using a r
r, if one chose the prefix new one must ensure
that the method followed memory management conventions, and would return an
object with a +1 retain count. Am I mistaken about this?
Sandor
>
>>> On Apr 29, 2020, at 4:07 PM, Carl Hoefs via Cocoa-dev
>>> wrote
added a
>> newData: method. This is with Xcode 11.2.1 on Mojave, 10.4.6. Works fine
>> for me. Weird!
>>
>> @implementation AppDelegate
>>
>> - (void)applicationDidFinishLaunching:(NSNotification *)aNotification {
>>NSTimer *new
For giggles, comment out the current code and replace it with exactly the same
code. Or put it in a new class and call the new class.
> On Apr 29, 2020, at 4:45 PM, Carl Hoefs via Cocoa-dev
> wrote:
>
> When everything goes wonky... it's time to reinstall all of Xcode...!
>
> *sigh*
> -Car
I thought when everything goes wonky you zap the PRAM and rebuild the Desktop?
—Rob
> On Apr 29, 2020, at 3:45 PM, Carl Hoefs via Cocoa-dev
> wrote:
>
> When everything goes wonky... it's time to reinstall all of Xcode...!
>
> *sigh*
> -Carl
>
>
> __
When everything goes wonky... it's time to reinstall all of Xcode...!
*sigh*
-Carl
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(
Xcode 11.2.1 on Mojave, 10.4.6. Works fine
> for me. Weird!
>
> @implementation AppDelegate
>
> - (void)applicationDidFinishLaunching:(NSNotification *)aNotification {
> NSTimer *newTimer = [NSTimer timerWithTimeIn
Just ot be safe, reboot your Mac to make sure that things aren’t completely
borked. I’ve had to do this many times.
> On Apr 29, 2020, at 4:26 PM, Carl Hoefs
> wrote:
>
> I accept that NSTimer works as documented! But I allege there must be
> something odd about my (inh
I accept that NSTimer works as documented! But I allege there must be something
odd about my (inherited) project that I can't quite put my finger on.
Perhaps the +timerWithTimeInterval: method is overridden...
-Carl
> On Apr 29, 2020, at 2:15 PM, Alex Zavatone wrote:
>
> I use
t;>>> times/sec.
>>>> ∙ If I specify 20.0 for the time interval, my method gets called 1
>>>> time/sec.
>>>> ∙ If I specify 100.0 for the time interval, my method gets called 5
>>>> times/sec.
>>>> ...etc.
>>>>
Not sure about this, but in Objective-C, you’re not supposed to start methods
with new.
> On Apr 29, 2020, at 4:07 PM, Carl Hoefs via Cocoa-dev
> wrote:
>
>>>> NSTimer *newTimer = [NSTimer timerWithTimeInterval:1.
pecify 20.0 for the time interval, my method gets called 1 time/sec.
>>> ∙ If I specify 100.0 for the time interval, my method gets called 5
>>> times/sec.
>>> ...etc.
>>>
>>> Here is my only invocation, called once and nevermore:
>>
times/sec.
>> ...etc.
>>
>> Here is my only invocation, called once and nevermore:
>>
>> NSTimer *newTimer = [NSTimer timerWithTimeInterval:1.0 // should be
>> 1/sec
>>
d 20 times/sec.
> ∙ If I specify 20.0 for the time interval, my method gets called 1 time/sec.
> ∙ If I specify 100.0 for the time interval, my method gets called 5 times/sec.
> ...etc.
>
> Here is my only invocation, called once and nevermore:
>
>NSTimer *newTimer = [N
...etc.
>
> Here is my only invocation, called once and nevermore:
>
>NSTimer *newTimer = [NSTimer timerWithTimeInterval:1.0 // should be
> 1/sec
>target:self
>
ec.
∙ If I specify 100.0 for the time interval, my method gets called 5 times/sec.
...etc.
Here is my only invocation, called once and nevermore:
NSTimer *newTimer = [NSTimer timerWithTimeInterval:1.0 // should be
1/sec
t
> On Nov 14, 2017, at 4:43 PM, Nathan Day wrote:
>
> The background app is kept alive by launchd as a User Agent and looks for new
> resources to be downloaded periodically
If this is a launchd agent, you can configure its plist so it gets launched
periodically. That way it won’t have to kee
On Nov 14, 2017, at 16:57 , Quincey Morris
wrote:
>
> I would suggest you try setting the QoS to at least “utility”, perhaps even
> “user initiated”.
To clarify: *what* you set to a different QoS depends on the nature of the
thing you described as a “background process”. For example, if you’r
On Nov 14, 2017, at 16:43 , Nathan Day wrote:
>
> I have a background process that uses an NSTimer that is set to fire every
> minute, but when the computer is inactive for a while it will stop firing
My guess is that it’s not a problem with the timer, but with the quality of
service
I should make it clear, this is a Mac OS X application.
Nathan Day
On 14 Nov, 2017, at 01:43 PM, Nathan Day wrote:
I have a background process that uses an NSTimer that is set to fire every
minute, but when the computer is inactive for a while it will stop firing, its
not until someone
I have a background process that uses an NSTimer that is set to fire every
minute, but when the computer is inactive for a while it will stop firing, its
not until someone interacts with the computer the timer will start firing
again. The timer is added to the main NSRunLoop, maybe the
On 19. Oct 2017, at 18:04, Mark Allan wrote:
> So I tried refactoring the block into a separate method and using an older
> NSTimer method:
> [NSTimer timerWithTimeInterval:0.2 target:self
> selector:@selector(updateTheDelegateForRunID:) userInfo:runID repeats:YES];
>
>
> Le 20 oct. 2017 à 18:56, Quincey Morris
> a écrit :
>
> On Oct 20, 2017, at 03:23 , Mark Allan wrote:
>>
>> That worked with the block-based NSTimer API but not the selector-based API.
>> I tried changing it to 'currentRunLoop' which got rid of
> On Oct 20, 2017, at 9:56 AM, Quincey Morris
> wrote:
>
> — When you scheduled the timer on the main run loop, it was actually being
> scheduled on the main app’s run loop. When it was block based, only the block
> had to be passed across the XPC interface (which somehow works), but when it
On Oct 20, 2017, at 03:23 , Mark Allan wrote:
>
> That worked with the block-based NSTimer API but not the selector-based API.
> I tried changing it to 'currentRunLoop' which got rid of the crash, but the
> timer never fired.
This is pure guesswork, but I suspect thi
ly, I thought this meant my own class needed to conform to
>> NSSecureCoding, but after some failed attempts, it think it's trying to tell
>> me that it can't do it because *NSTimer* doesn't conform to NSSecureCoding.
>> Is that correct, and if so does anyone kn
interface to
> the main app. What does the backtrace look like? Ideally there would be
> something there that tells you what it’s trying to do at that time.
>
> I don’t know, but I suspect that the block-based NSTimer methods might differ
> from the selector-based ones in t
at that time.
I don’t know, but I suspect that the block-based NSTimer methods might differ
from the selector-based ones in that they use GCD rather than the run loop. If
you look at the documentation, the old methods say "schedules it on the current
run loop”. The new methods
unicates these back to the main app.
>
> The main app communicates with the helper tool via NSXPCConnection.
>
> I'm using an NSTimer to send the update messages to the delegate with the
> following incantation:
>
>[NSTimer timerWithTimeInterval:0.2 repeats:YES block:^(N
o the main app.
The main app communicates with the helper tool via NSXPCConnection.
I'm using an NSTimer to send the update messages to the delegate with the
following incantation:
[NSTimer timerWithTimeInterval:0.2 repeats:YES block:^(NSTimer * _Nonnull
timer) { ... }];
This works
> On 20 Jun 2017, at 16:24, Alastair Houghton
> wrote:
>
> On 20 Jun 2017, at 04:04, Gerriet M. Denkmann wrote:
>>
>
>> 2. some other thing repeatedly about every 0.1 second.
>
> Personally, I’d choose an API that directly supports repeating ti
use so much as whether you want to be able
> to cancel the operation. If you need to be able to cancel it before it
> fires, you’ll want to use NSTimer or a CFRunLoopTimer.
I indeed need the things to cancel: The app might schedule a thing to be done
in 5 seconds, then decides after 2 seco
before it fires,
you’ll want to use NSTimer or a CFRunLoopTimer. Energy wise, the fact this is
to happen “a few seconds later” would seem to imply that it isn’t going to
happen often, so it’s probably irrelevant and which you choose is a matter of
taste.
> 2. some other thing repeatedly abou
On Jun 19, 2017, at 20:04 , Gerriet M. Denkmann wrote:
>
> What is the most efficient (energy-wise) way to do this:
>
> NSTimer (with tolerance)
> NSRunLoop performSelector:target:argument:order:modes:
> NSObject performSelector:withObject
macOS 11+
Some Cocoa app which has to do:
1. something a few seconds later
2. some other thing repeatedly about every 0.1 second.
What is the most efficient (energy-wise) way to do this:
NSTimer (with tolerance)
NSRunLoop performSelector:target:argument:order:modes:
NSObject
).
> On Apr 29, 2016, at 3:23 AM, Gerriet M. Denkmann wrote:
>
> OS X 10.11.4; Xcode Version 7.3 (7D175).
>
> self.timer = [ NSTimer scheduledTimerWithTimeInterval: 900 … repeats: YES ];
> self.timer.fireDate = [ NSDate dateWithTimeIntervalSinceNow: ];
>
> works fine
OS X 10.11.4; Xcode Version 7.3 (7D175).
self.timer = [ NSTimer scheduledTimerWithTimeInterval: 900 … repeats: YES ];
self.timer.fireDate = [ NSDate dateWithTimeIntervalSinceNow: ];
works fine without sleep.
But:
fireDate: Fri 29 Apr 2016 15:06:14 +0700 in 37.03 min +900 sec
Fri 29 Apr
14, at 12:21 PM, William Squires wrote:
> What would be the best way to make an NSTimer that could pause/un-pause its
> timing? Subclassing? Containment? Just roll my own with
> performWithSelector:afterDelay:? That is, if I (my code) creates a (smart)
> NSTimer with a duration of 5
It seems like he wants a set of expire events where certain events will fire
independent of whether the timer is paused or not.
It might be possible to have a global timer for these decorations and each
object has a durationUntilExpiration, which is the global timer + the object's
duration of e
On Jul 1, 2014, at 11:21 , William Squires wrote:
> Use-case:
> I have a (fictitious) FPS game in which the players or bots can "damage" the
> scenery by leaving blast marks. A timer should remove these "decorations"
> after a given delay, but I want the timers to pause if any players/bots are
way to make an NSTimer that could pause/un-pause its
> timing? Subclassing? Containment? Just roll my own with
> performWithSelector:afterDelay:? That is, if I (my code) creates a (smart)
> NSTimer with a duration of 5 seconds, then three seconds later I need to
> pause the timer, t
would be the best way to make an NSTimer that could pause/un-pause its
> timing? Subclassing? Containment? Just roll my own with
> performWithSelector:afterDelay:? That is, if I (my code) creates a (smart)
> NSTimer with a duration of 5 seconds, then three seconds later I need to
>
What would be the best way to make an NSTimer that could pause/un-pause its
timing? Subclassing? Containment? Just roll my own with
performWithSelector:afterDelay:? That is, if I (my code) creates a (smart)
NSTimer with a duration of 5 seconds, then three seconds later I need to pause
the
On 10 Jun 2014, at 8:01 am, Peters, Brandon wrote:
> Is it safe to invalidate a timer from within the timer callback function?
Yes.
--Graham
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator co
Is it safe to invalidate a timer from within the timer callback function?
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.ap
In case anybody is interested, the following wrapper for NSTimer solves the
problem. (You can add the other methods yourself, if needed.)
#import
@interface RTPTimer : NSObject
@property(nonatomic, weak) id target;
@property(nonatomic) SEL sel;
+ (RTPTimer *)scheduledTimerWithTimeInterval
s that point at objects in other parts of his app that
>>> know nothing of the timers' existence, this sounds like a fragility
>>> nightmare.
>>>
>>> The NSTimer ship has sailed.
>>
>> I don't really see it. All you'd need woul
f the timers' existence, this sounds like a fragility
>> nightmare.
>>
>> The NSTimer ship has sailed.
>
> I don't really see it. All you'd need would be a special initializer or
> convenience constructor, like +[NSMapTable strongToWeakObjectsMapTable]
On Jan 14, 2013, at 5:45 PM, Charles Srstka wrote:
> Make versions of the +timerWithTimeInterval:etc:etc: classes
That obviously should be methods, not classes. Sorry; I've had a long day.
Charles
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.co
On Jan 14, 2013, at 2:38 PM, Kyle Sluder wrote:
> Given that Gordon's explicit use case involves one part of his app
> setting up timers that point at objects in other parts of his app that
> know nothing of the timers' existence, this sounds like a fragility
> nightmare.
On Jan 14, 2013, at 12:38 , Kyle Sluder wrote:
> Given that Gordon's explicit use case involves one part of his app
> setting up timers that point at objects in other parts of his app that
> know nothing of the timers' existence, this sounds like a fragility
> nightmare.
that are compiled under different settings — most likely, a system
>> framework compiled under MRR and an executable compiled under ARC. Indeed,
>> the *same* NSTimer can be used from different places, which should
>> presumably agree on how strongly the timer holds its target.
>
e involves one part of his app
setting up timers that point at objects in other parts of his app that
know nothing of the timers' existence, this sounds like a fragility
nightmare.
The NSTimer ship has sailed.
--Kyle Sluder
___
Cocoa-dev mail
On Jan 14, 2013, at 1:23 PM, John McCall wrote:
> On Jan 14, 2013, at 10:07 AM, David Duncan wrote:
>> On Jan 12, 2013, at 10:49 AM, Gordon Apple wrote:
>>
>>> When compiled under ARC, NSTimer should have a weak, not strong, reference
>>> to its target.
&g
On Jan 14, 2013, at 10:07 AM, David Duncan wrote:
> On Jan 12, 2013, at 10:49 AM, Gordon Apple wrote:
>
>> When compiled under ARC, NSTimer should have a weak, not strong, reference
>> to its target.
>
> If you want this, file a bug. Posting on the mailing list isn
On Jan 12, 2013, at 10:49 AM, Gordon Apple wrote:
> When compiled under ARC, NSTimer should have a weak, not strong, reference to
> its target.
If you want this, file a bug. Posting on the mailing list isn't guaranteed to
get your request anywhere close to the persons resp
Uh, that¹s where I¹m calling the wakeup methods for the other controllers in
the nib. Then, I was suggesting calling ³shutDown² in windowWillClose. I
guess I wasn¹t very specific. My window nibs generally have a variety of
other controllers. I try my best to partition and encapsulate
functional
On Sun, Jan 13, 2013, at 03:44 PM, Gordon Apple wrote:
> It may be ancient but, IMHO, it should be fixed, at least for ARC. It
> is a
> major source of unnecessary retain cycles and the fix is simple. I went
> ahead and created a simple wrapper for NSTimer, as I originally
> desc
It may be ancient but, IMHO, it should be fixed, at least for ARC. It is a
major source of unnecessary retain cycles and the fix is simple. I went
ahead and created a simple wrapper for NSTimer, as I originally described,
and it works perfectly. I am going to file an enhancement request.
You
lement it
yourself, or use one of the other existing implementations the framework
provides for you: -viewDidMoveToSuperview, -windowWillClose, etc.
> From the literature, it appears that NSTimer is the main offender in this
> regard.
NSTimer is something like twenty years old, but it i
And just how does one go about doing that? The only way I can see is to use
an owner’s dealloc to call something like “wouldLikeToDealloc” on the owned
object. From the literature, it appears that NSTimer is the main offender
in this regard. I frequently use generic NSViewControllers and
2, 2013 10:49 AM
Subject: Could somebody please fix NSTimer?
When compiled under ARC, NSTimer should have a weak, not strong, reference
to its target. When the timer starts to fire, check the reference for nil
and invalidate itself. Come on guys, how hard is that? You wouldn¹t even
have to keep a
On Jan 12, 2013, at 2:05 PM, Kyle Sluder wrote:
> On Jan 12, 2013, at 10:49 AM, Gordon Apple wrote:
>
>> When compiled under ARC, NSTimer should have a weak, not strong, reference
>> to its target. When the timer starts to fire, check the reference for nil
>> and inv
On Jan 12, 2013, at 10:49 AM, Gordon Apple wrote:
> When compiled under ARC, NSTimer should have a weak, not strong, reference
> to its target. When the timer starts to fire, check the reference for nil
> and invalidate itself. Come on guys, how hard is that? You wouldn¹t even
>
When compiled under ARC, NSTimer should have a weak, not strong, reference
to its target. When the timer starts to fire, check the reference for nil
and invalidate itself. Come on guys, how hard is that? You wouldn¹t even
have to keep a reference to it, unless you want to invalidate it before
I am not at all sure about the details but I think your app is receiving some
sort of notification that power sleep is occurring in order to allow it to do
what it needs to do in that situation. My guess is that all timers are caused
to expire because when asleep they will not and then, when wak
> When our software is running and the Mac goes into Power Nap, our NSTimers
> (which are fire-once and set to 3 hour periods) are firing immediately, so
> the software does the timer work and installed a new fire-once timer for 3
> hours later.
>
> Except that one of course fires immediately and
When our software is running and the Mac goes into Power Nap, our NSTimers
(which are fire-once and set to 3 hour periods) are firing immediately, so
the software does the timer work and installed a new fire-once timer for 3
hours later.
Except that one of course fires immediately and it just keep
7;invalidate'
will prevent from "ever firing", according to the class documentation.
Otherwise it's harmless.
You don't care (and the documentation tells you not to care) when it's actually
removed from the run loop. All you care about is that it won't fire.
&
> You must use the 2nd way. If you don't you could get a memory exception if the
> timer has fired and, therefore, been invalidated.
>
> On Aug 3, 2012, at 4:19 PM, Trygve Inda wrote:
My code looks like this:
-(void)awakeFromNib
{
[self setUpd
ory exception if
> the timer has fired and, therefore, been invalidated.
>
> On Aug 3, 2012, at 4:19 PM, Trygve Inda wrote:
>
>> NSTimer* myTimer = [NSTimer scheduledTimerWithTimeInterval:60 target:self
>> selector:@selector(wantsUpdate:) userInfo:nil repeats:NO]
>>
&g
You must use the 2nd way. If you don't you could get a memory exception if the
timer has fired and, therefore, been invalidated.
On Aug 3, 2012, at 4:19 PM, Trygve Inda wrote:
> NSTimer* myTimer = [NSTimer scheduledTimerWithTimeInterval:60 target:self
> selector:@selector(
NSTimer* myTimer = [NSTimer scheduledTimerWithTimeInterval:60 target:self
selector:@selector(wantsUpdate:) userInfo:nil repeats:NO]
Sometime after it fires (and occasionally before), I call
if ( myTimer )
{
[myTimer invalidate];
[myTimer release];
myTimer = nil;
}
Should I really be
NSTime docs say:
--
The date at which the receiver will fire. If the timer is no longer valid,
this method returns the last date at which the timer fired.
--
For an invalidated timer I am seeing a fireDate of: 2001-01-01 00:00:00
But I know it fired at 2012-08-03 19:39:12
Is this a known bug?
screenTimer = [NSTimer timerWithTimeInterval:2 target:self selector:
> > @selector(turnOffScreen:) userInfo:nil repeats:NO];
>
> You need scheduledTimerWithTimeInterval:... (as opposed to just
> timerWithTimeInterval:...), in order for the timer to actually get posted.
> The same
On 10 Jan 2012, at 12:03 pm, Eric E. Dolecki wrote:
>screenTimer = [NSTimer timerWithTimeInterval:2 target:self selector:
> @selector(turnOffScreen:) userInfo:nil repeats:NO];
You need scheduledTimerWithTimeInterval:... (as opposed to just
timerWithTimeInterval:...), in order for the
This is odd. Perhaps I need coffee. I have an app where I hide something by
default (UIView). touchesBegan will make it visible. touchesMoved keeps
visible. touchesEnded after 2 seconds. My method is never getting called.
In my .h
NSTimer *screenTimer;
...
@property(nonatomic,retain) NSTimer
Hi,
I am playing around with CVDisplayLink, I have it set up and running
properly.
I also have another method called update, which I am trying to run using a
timer set to 60.0 frames per second.
When I run the application without starting the CVDisplayLink, the update
function runs very near to
see no evidence of it either in the console or
> the data.
>
Check out Mr Noodle with regard to sleepy timers:
http://www.noodlesoft.com/blog/2010/07/01/playing-with-nstimer/
Regards
Jonathan___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.
g Parker wrote:
On Nov 17, 2010, at 2:12 PM, Kyle Sluder wrote:
On Wed, Nov 17, 2010 at 2:07 PM, Dave DeLong davedel...@me.com> wrote:
Here's what I got from that documentation:
- An NSTimer is a run loop source.
Ah, I think this is where my brain went all funny, because the NS
On Nov 17, 2010, at 2:12 PM, Kyle Sluder wrote:
> On Wed, Nov 17, 2010 at 2:07 PM, Dave DeLong wrote:
> Here's what I got from that documentation:
>
> - An NSTimer is a run loop source.
>
> Ah, I think this is where my brain went all funny, because the NSRunLoop
&
On Wed, Nov 17, 2010 at 2:07 PM, Dave DeLong wrote:
> Here's what I got from that documentation:
>
> - An NSTimer is a run loop source.
>
Ah, I think this is where my brain went all funny, because the NSRunLoop
documentation mentions multiple times that "A timer is n
Here's what I got from that documentation:
- An NSTimer is a run loop source.
- NSRunLoop monitors its sources for events, provided that the run loop is
running in the mode that the source is scheduled in.
- If the run loop is processing an event from a different source and a timer
On 17 Nov 2010, at 1:54 PM, Kyle Sluder wrote:
> Okay, that's two people who have corrected me on this now. What am I
> misinterpreting about this documentation:
>
> http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Multithreading/RunLoopManagement/RunLoopManagement.html
Whi
On Wed, Nov 17, 2010 at 1:54 PM, Kyle Sluder wrote:
> On Wed, Nov 17, 2010 at 1:54 PM, Greg Parker wrote:
>
>> On Nov 17, 2010, at 1:35 PM, Kyle Sluder wrote:
>> > That's not how timers work. They only fire if something wakes the runloop
>> > after their time has expired. Usually this is an event
Pool alloc] init];
[NSTimer scheduledTimerWithTimeInterval:5.0
target:self
selector:@selector(timerFired:)
userInfo:nil
repeats:YES];
[[NSRunLoop curr
On Wed, Nov 17, 2010 at 1:54 PM, Greg Parker wrote:
> On Nov 17, 2010, at 1:35 PM, Kyle Sluder wrote:
> > That's not how timers work. They only fire if something wakes the runloop
> > after their time has expired. Usually this is an event.
>
> Not true. A timer may fire some time after its fire d
On Nov 17, 2010, at 1:35 PM, Kyle Sluder wrote:
> That's not how timers work. They only fire if something wakes the runloop
> after their time has expired. Usually this is an event.
Not true. A timer may fire some time after its fire date for any number of
reasons, but "no event to wake the run l
t; there is no code that resets the full fetch timer; no need, it should run
> every 4 hours.
>
That's not how timers work. They only fire if something wakes the runloop
after their time has expired. Usually this is an event.
Read the Overview section of the NSTimer reference:
http:
ize the mini timer:
miniTimer = [[NSTimer scheduledTimerWithTimeInterval:[[self fetchInterval]
floatValue] * 60.0
target:self selector:@selector(myMethod) userInfo:nil repeats:NO] retain];
This code gets called after every mini fetch to ensure the timer is set
The full fetch timer is set
On 10/18/2010 9:45 AM, Keary Suska wrote:
On Oct 18, 2010, at 9:00 AM, JongAm Park wrote:
Is there any benefit in using it? My guess is that an NSInvocation instance is used
repeatedly, but using the "selector" based method is not inconvenient for the
most of cases.
Is there any other benefi
1 - 100 of 314 matches
Mail list logo
