Scheduling

The Scheduling suite contains a group of modules which allow scheduling of events. You can think of a schedulable thing in very broad terms. For example, if you need the microscope to take a picture of a certain location every five minutes, you can schedule this action.

There is only one Scheduler (it implements the Singleton Pattern) The Scheduler runs on a Daemon Thread. The Scheduler juggles all the schedules which it has been asked to deal with. The scheduler can start, pause, and stop schedules.

Schedules are containers which hold together all the timing information.

There are several types of schedules :

• ONCE : this schedule runs only once

• CONTINUOUS : this schedule continues to run until it is stopped

• EPISODIC : this schedule has a certain number of episodes and specifies the delay between them

Schedules can be in several “states”

• paused : the schedule remembers whether it has been paused

• exclusive : an exclusive schedule stops all other schedules from running when it starts, and does not allow other schedules to start while it is running.

• delayed : the schedule can start at some future point that you specify

Schedules can be asked to start, stop or pause themselves with public methods please_start(), please_stop() and please_pause(). These methods allow GUIs or other modules to affect schedules. The please methods should be though of as requests, not orders. The Scheduler is the one who can actually command schedules to start, stop and pause. But the schedules can also pass information to the Scheduler that someone else would like to start them. Schedules are the middle men between the Scheduler and users or program schedulables.

Schedules HAVE Schedulables Schedules are general in the sense that they mostly deal with timing. They don't directly know what activities they are scheduling. The Schedulable part of Schedules knows this. When the Scheduler orders a Schedule to start, the Scheduler calls the startingNow() method of the Schedule, which in turn asks its Schedulable subpart to do its thing.

If you're trying to schedule things, most of your work will consist of writing a new Schedulable class.

The communication between Schedules and Schedulables involves the System Filesystem and Cookies

the Scheduler tells the Schedule to start by calling Schedule.startingNow().

the Schedule gets a file from the System Filesystem which is called “m_schedule”.

the Schedule searches for a DataObject which contains the file called “m_schedule” and obtains a cookie from the DataObject.

The cookie is requested to be of type InstanceCookie.class.

Finally this cookie is asked to produce an instance of the Schedulable class, by calling a cookie.instanceCreate() method. Once the Scheduler has obtained the Schedulable, it can pass orders down from the Scheduler to its private Schedulable subpart.

In essence, this filesystem cookie stuff is a way for the Schedule to not have to have a schedulable unless it is running. Before the Schedule is told to run, it simply knows the name of the Schedulable which it wants.

//part of class Schedule
protected void startingNow() throws ScheduleException {
...
     try {
            propertyChangeSupport.firePropertyChange("starting", 0, 1);
 
            //asks the system filesystem root for a file object called "m_schedulable"
            FileObject fileObj = Repository.getDefault().getDefaultFileSystem().getRoot().getFileObject(m_schedulable);
            displayname = (String) fileObj.getAttribute(ATTR_DISPLAY_NAME);
 
 
            //find the data object associated with this file object
            DataObject ob = DataObject.find(fileObj);
            InstanceCookie ck = ob.getCookie(InstanceCookie.class);
            t_schedulable = (Schedulable) ck.instanceCreate();
            t_schedulable.initialize();
        } catch (Exception ex) {
            throw new ScheduleException(ex);
        }
.....
}

In order for something to be Schedulable, it has to implement the Schedulable interface.

This is a GUI form which allows the user to set the properties of a schedule.

Each ScheduleTopComponent HAS a Schedule

The ScheduleTopComponent displays the name of Schedulable which is run by this schedule (also referred to as a protocol) and its description. ScheduleTopComponent asks its Schedule for the name of the Schedulable, which return the “m_schedulable” described above; then it finds the DataObject in a similar way to the Schedule (except the cookies because here only the name and the description are necessary, not a particular instance of a Schedulable)

A class which implements the Schedulable Interface contributes an XML Layer to the System Filesystem which can be found in the Important Files/XML Layer/<this layer>/yourfolder/Test.settings and looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE settings PUBLIC '-//NetBeans//DTD Session settings 1.0//EN' 'http://www.netbeans.org/dtds/sessionsettings-1_0.dtd'>
<settings>
    <module name="scheduler"/>
    <instanceof class="scheduler.Schedulable"/>
    <instance class="scheduler.TestSchedulable" method="create"/>
</settings>

example of a class which implements the Schedulable Interface

Schedules look up Schedulables by name, by finding a file in the System Filesystem with that given name.

 
public class WaterPlants implements Schedulable{
 
       //you can define some attribute strings
       public static final String ATTRIBUTE_TREES = "trees";
 
       public static WaterPlants create(final FileObject fo) throws DataObjectNotFoundException, IOException, ClassNotFoundException {
               return new WaterPlants(fo);
       }
 
       protected FileObject m_obj;
       protected int num_trees;
 
       protected WaterPlants(FileObject fo){
               m_obj = fo;
               num_trees = (Integer) fo.getAttribute(ATTRIBUTE_TREES);
       }
       public void initialize(){....}
       public void prepare(){...}
       public void arm(){....}
       public void run(){..}
       public void cleanup(){...}
       public void interrupted(){...}
       public void configure(){..}
}