Java List Class – Designing with Filtering and Sorting

class-designfilteringjavalist

The app I'm developing needs to display lists of items. Simple enough, but there are a number of things which can change based on user input:

  • Items can be added to/removed from the list.
  • The items in the list can be updated. Multiple items can be updated simultaneously!
  • The filters can be updated. Multiple filters can be updated simultaneously!
  • The sort order of the items can change.

Possibly relevant info:

  • It's a multiplatform Java app.
  • One of the platforms we distribute on is MIDP, so that limits which language features/libraries/etc we can use.
  • The implementation is currently split into a model class (in the common code) and device-specific view/controller classes.

I've tried a couple of approaches to designing a suitable list implementation, but both have drawbacks:

Approach 1:

The platform-specific controller implementations are responsible for calling a refresh() method whenever anything happens which could change the list.

This approach keeps the list class (model) implementation fairly straightforward, but leaves much of the responsibility up to the platform-specific controller implementations. The more logic there is in these classes, the greater the chance of bugs creeping in. It also encourages the controllers to directly notifying the view of updates, which feels like poor design.

Approach 2:

The model is entirely responsible for raising events to notify the platform-specific views of changes. The list items, filter, and sorters notify the model when they change, which then notifies the views of changes.

This keeps the platform-specific classes much simpler, and feels like a stronger design (less coupling between the classes, etc). However, the list class implementation becomes much more complicated.

My main problem with this approach is dealing with a proliferation of events when multiple items/filters are updated in a single operation.

My questions:

  1. Is there other approaches I could/should be trying?
  2. Is there a recognised way to manage/avoid the explosion of events in approach #2?

Best Answer

  1. As the lists are the model (and the items are only parts of them), I would suggest the following process:

    • When changed, items raise events to the list in which they are placed.
    • When changed (directly or via a change in the items), lists raise events to the depending views.
    • Lists filtering and sorting only concern the views. So the sorters and filters are not longer active elements but just passive elements manipulated by the views.

  2. I don't know. The fact to restrict the filtering and sorting activities to the views themself will reduce the number of events sent. The single other way I can imagine for reducing the number of events sent is to be as specific as possible so that only the concerned receivers receive an event. An alternative could be to gather the events in a "super-event" received by "something" acting consequently, but I fear it is not conceptually a better solution.

Related Topic