Bingo! Thanks. This is where I was going wrong. I saw John and Jamie's responses earlier and got me thinking in objects again. But still wasn't putting it together. I had a mental block and was not thinking of the timers as properties of the boxes. Just kept getting stuck on the NSTimer object being the object. Man it is hard to get off of a train of though sometimes. Ultimately each facility has between 20 and 30 boxes. I really did not want to poll.
Thanks again Tom On Sep 29, 2011, at 7:27 PM, Graham Cox wrote: > Timers are objects, and can be retained like any other independently of > whether they are scheduled on a run loop or not. The run loop will > additionally retain the timer, but that's its business. > > In the object that represents the set-top box, just add a 'timer' property > (retained), so that you can get the timer associated with the box. Then you > are free to invalidate it, reschedule it, add it or remove it from the run > loop at will. While leaving the run loop to manage its timers is the usual > M.O., if you need more control, then all you need to do is take it. > > Depending on how many set-top boxes there are likely to be (I'm guessing tens > rather than thousands), then a separate timer per box is probably a good idea > rather than have one timer which is repeatedly compared against a list of > schedule times, which amounts to polling and hence will mean waking up the > thread more often than necessary. > > --Graham > > > On 30/09/2011, at 9:48 AM, Tom Hohensee wrote: > >> Sorry, I started this out wrong. I am probably over thinking this to the >> point of confusion. Here is where I am. >> I have an application for a facility that uses a number of ip enabled set >> top boxes to drive TV's throughout the place. Each box is to be shutdown >> at certain times of the day depending on what part of the facility is closed >> for the day. In my app the user sets up a configuration in an NSTable >> whereby each device is set to shut down at a certain time each day. From >> this configuration, I setup timers to correspond to the shutdown time and >> have them repeat each 24 hours. I originally thought I would simply load >> each into the runloop using NSTimers class method >> +scheduledTimerWithTimeInterval:target:selector:userinfo:repeats. without >> retaining a reference to it. But I ran into the problem of the user >> changing a device's shutdown time while the app is running. I needed to >> retain a reference to the timer to invalidate it . In other words, if the >> user comes along and wants to change the configuration (a shut down time) of >> one device while the app is running I need to be able to stop the timer that >> is currently in the run loop and use the new configuration. Without >> invalidating that timer would I not have an active timer in the run loop on >> top of what is created by new configuration? I then moved on the creating >> timers and instead of loading them into the run loop I would load them into >> an array and and sort them according to time. I then loop through the array >> loading only the first timer of the array into the run loop and retain a >> reference to it. Each firing of the timer loads the next timer into the run >> loop and retains a reference to it. But this has other issues particularly >> when firing times are real close together. >> >> At this point I need a fresh prospective on this. Any thoughts would be >> greatly appreciated. > > _______________________________________________ > > 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.apple.com > > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/cocoa-dev/tomhoh%40mac.com > > This email sent to tom...@mac.com _______________________________________________ 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.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
