Introduction
Activity repositories are used by rows to store and lookup activities. Each row by default owns an IntervalTreeActivityRepository. This default repository can be replaced with a custom one, for example if your application requires a lazy loading strategy.
Queries
The most important functionality of any repository is the ability to query the repository for activities within a given time interval. For this purpose the ActivityRepository interface defines the getActivities() method with these parameters:
Parameter | Description |
---|---|
Layer layer |
Whenever the user scrolls left or right the row will query the repository several times. Once for each layer. |
Instant startTime |
The start time of the time interval for which the row is querying activities. |
Instant endTime |
The end time of the time interval for which the row is querying activities. |
TemporalUnit unit |
The current value of the primary temporal unit currently displayed by the dateline. This is the unit shown at the bottom of the dateline, e.g. days. This parameter can be used to control how fine-grained the result will be. If we know that the user is currently looking at months then it might make sense to aggregate daily activities. |
ZomeId zoneId |
The timezone shown by the row. |
Earliest / Latest Time Used
Each repository implementation needs to be able to answer the question for the earliest and latest times used (earliest start time / latest end time of any activity stored in the repository). This allows the UI to provide controls for easy navigation: "show earliest", "show latest". For this purpose repositories need to implement the getEarliestTimeUsed() and getLatestTimeUsed() methods.
Updating Activities
Activities need to be removed (ActivityRef.detachFromRow()) from their repository before they are being changed and added back (ActivityRef.attachToRow()) after they have been changed. This is the only way to ensure that a repository will always have its underlying data structure in synch with the activities. Example: the interval tree data structure only works properly if all its nodes are in their correct location. This can only be guaranteed if the nodes are removed from the tree before they are being changed (otherwise the tree will not find them) and then reinserted with their new value.
Event Handling
Activitiy repositories implement listener support so that the UI can update itself if the content of the repository changes. Interested parties can attach handlers by calling addEventHandler() or remove handlers by calling removeEventHandler(). The event class is called RepositoryEvent and it has three event types:
Event Type | Description |
---|---|
ACTIVITY_ADDED |
An activity was added to the repository. |
ACTIVITY_REMOVED |
An activity was removed from the repository. |
REPOSITORY_CHANGED |
Something has changed the state of the repository. |
Each one of these event types will normally trigger a redraw of the row to which the repository belongs.