Forgot to send to list: > Perhaps, instead of timers, you use objects that represent one of these > set-top boxes and the time at which they should be shutdown. And instead of > scheduling and managing timer, you manage the domain objects instead. Then, > you have one timer, that checks all of your objects and sees if they should > be shut down.
But when re-reading the thread I see this is exactly what John suggested: > Could you use a single, repeating timer with sufficient resolution for your > purposes and an array or dictionary storing the needed timing state? Then > update state appropriately at each fire of the single timer?" On Sep 29, 2011, at 7:48 PM, 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. > > Tom > > > On Sep 29, 2011, at 5:15 PM, David Duncan wrote: > >> I think you need to backup and explain exactly what your requirements are. >> If you really do need to track these timers, you will probably need an array >> or dictionary, but if these timers are all one-shot and they configure the >> next timer to execute, there seems little reason to maintain your own owning >> reference to them... >> >> On Sep 29, 2011, at 3:06 PM, Tom Hohensee wrote: >> >>> Yes. What I have worked on is using an array of timers fired sequentially. >>> Each firing of the timer sets up the next one in the array. Each new >>> addition to the array requires invalidating of the active timer and >>> reordering of the array according to times. But i have run into problems >>> when two or more timers are set to fire at the same time. >>> >>> Tom >>> >>> On Sep 29, 2011, at 4:51 PM, David Duncan wrote: >>> >>>> On Sep 29, 2011, at 2:47 PM, Tom Hohensee wrote: >>>> >>>>> However, I do not know wether the user will have 1 device or 100 devices. >>>>> Do I have to setup a finite amount of timers (ultimately having a limit >>>>> on the number of devices that can be added) or is there a better way? I >>>>> have googled for a while now trying to find example code but have come up >>>>> empty (plenty of finite examples). I see there are timer applications >>>>> out there that seem to handle an infinite number of timers. >>>> >>>> >>>> Have you looked into NSMutableArray? >>>> -- >>>> David Duncan >>>> >>>> _______________________________________________ >>>> >>>> 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 >>> >> >> -- >> David Duncan >> > > _______________________________________________ > > 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/jamiepinkham%40me.com > > This email sent to jamiepink...@me.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
