tag:robotlegs.tenderapp.com,2009-10-18:/discussions/questions/494-robotlegs-and-setintervalRobotlegs: Discussion 2018-10-18T16:35:25Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/63741372011-04-01T15:12:37Z2011-04-01T15:12:37ZRobotLegs and setInterval<div><p>I'd say it's pretty certainly a service > event > command
thing. At least that's where I put it.</p></div>creynderstag:robotlegs.tenderapp.com,2009-10-18:Comment/63741372011-04-02T11:35:44Z2011-04-02T11:35:44ZRobotLegs and setInterval<div><p>Ditto. In my mind that's a service - because it dispatches
events in its own sweet time.</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/63741372011-04-02T12:54:50Z2011-04-02T12:54:50ZRobotLegs and setInterval<div><p>Yes OK, a service also seems like the best solution to me.<br>
But where would you instantiate it? In the main context? Since it
doesn't really belong to anyone, I'm a little bit lost...</p></div>Quentintag:robotlegs.tenderapp.com,2009-10-18:Comment/63741372011-04-03T11:07:01Z2011-04-03T11:07:01ZRobotLegs and setInterval<div><p>Yes - well, in a StartTimerCommand. Which would be bootstrapped
to ContexEvent.STARTUP_COMPLETE - or whatever makes sense in your
application.</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/63741372011-04-03T11:09:07Z2011-04-03T11:09:07ZRobotLegs and setInterval<div><p>Depends on when it's needed. If it's something that needs to run
from the very beginning I'd instantiate/run it in the bootstrap
sequence. More often than not I separate the mapping of classes
from concrete instantiation/execution in separate commands, so in
my case it would probably end up in a StartupServicesCommand of
some kind.</p>
<p>On the other hand it could be instantiated/run on a
request-basis: mediator needs file list and requests it >
command checks whether the service is running, if not starts
it.<br>
Another command gets called when the service has done it's thing,
optionally populates a model and dispatches an event with the
requested data, which gets picked up by the data requesting
mediator.</p>
<p>You should try to let as much as possible happen lazily, so
intuitively I'd say nr 2 would be the right solution. But obviously
I don't know the entire use case.</p>
<p>BTW try to avoid automatic, regular remote service calls as much
as possible. 90% of the time it's unneeded overhead that cogs the
connection and strains the CPU. If it CAN be tied to user input
(granted sometimes you need to be creative to find the right user
action to couple it to) then that's a LOT better than having an
automatic update.<br>
If you really can't avoid it, restrict it to a bare minimum.
Instead of retrieving a complete list of files, and having the
client check for any modifications, let the remote service return
the modified/added files together with state modification data
specifically for those files. Maybe that's evident for you, but I
thought I'd just let you know in case it wasn't.</p></div>creynderstag:robotlegs.tenderapp.com,2009-10-18:Comment/63741372011-04-04T08:39:17Z2011-04-04T08:39:17ZRobotLegs and setInterval<div><p>Hey, thanks for all this!</p>
<p>For this specific project I can't really expect any input from
the user. Some folders (chosen in the options) are regularly filled
with photos by PhotoBooth (on Mac), so I have to wait (like every
minute) and check of the number of files has changed...</p>
<p>I think what is the best for me (and this project) is the
StartupServicesCommand!<br>
Thanks a bunch, I think things are clearer in my head now and I've
learned I was not completely wrong.</p></div>Quentin