Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?
share|improve this question

1 Answer 1

up vote 0 down vote accepted
  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.

share|improve this answer
Very good points re. Q1: separating out the filtering/sorting behaviour has made things much more manageable. I may repost Q2 as a separate question in future, in the hopes of it getting more attention. –  Baqueta Jan 29 '13 at 10:04

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.