Event Aggregation

The main achievement of the last few days was the implementation of the event aggregation. Let’s see how it works:

All the different source providers make their content (list of events) accessible via a Cursor that contains all the columns defined in .data.providers.Events, ordered by the PUBLISHED_TIME field.  The EventAggregator’s responsibility is to turn these different event lists into a single sequence of events and pass it to the TimeLineAdapter to convert them into View objects.

The method that realizes this functionality is based on the MergedCursor class. MergedCursor is basically a wrapper around an array of the different cursors. It is derived from AbstractCursor, so it could be integrated into the existing architecture seamlessly. It emulates a virtual cursor that contains the union of the rows of the aggregated cursors, while its content is sorted by a certain numerical field (in our case Events.PUBLISHED_TIME). Sorting is accomplished by a modified version of the Merge sort algorithm.

Aggregation is tested with the already implemented internal providers, and special provider added for test purposes. This provider (called FactoryTest) generates a certain number of events for every contact:

The first version of the sorting algorithm turned out to be surprisingly fast in practice, however, further improvements necessary for a scalable solution (for users with may providers and thousands of aggregated events).