Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider benefits/drawbacks of Google Guava Event Bus for communication between controllers #4

Open
lemon-codes opened this issue Feb 9, 2021 · 1 comment

Comments

@lemon-codes
Copy link
Owner

At current the ModelAdapter provide basic event support to allow all controllers to be notified when the models state is changed. Each controller can then ensure that values shown in it's view are consistent with the state of the model.

This solution allows controllers to be notified of other controllers actions on the model, while maintaining a loose coupling between controllers. This solution is satisfactory for current requirements, however it is limited since it does not allow communication between controllers unless a controller is performing an operation on the model.

Using Guava Event Bus would allow controllers to communicate without the ModelAdapter. The ModelAdapter could use the EventBus to fire Events related to the model, keeping that responsibility away from each controller. Controllers would be able to fire their own events for other events.

Need to consider the benefits and drawbacks, and what the probability is of any benefits being utilised/required in future updates.

@lemon-codes
Copy link
Owner Author

Adding EventBus support could help in implementing "next"/"previous" station buttons in the playback controller.
Ideally the "next" button will select the next channel to play based upon which station tab is open and which row is currently selected in that table whithin the StationBrowser. For this to work, the playback controller will need a way to communicate with the StationBrowser controller.

lemon-codes added a commit that referenced this issue Feb 12, 2021
…ationManager. The Station interface now contains only getters. A MutableStation interface has been added which extends the Station interface, providing access to setters. The RadioStation class now implements MutableStation, however any time the StationManager publishes a station it is cast to immutable type Station. MutableStation is package private to prevent clients altering Station state. Station instances are not entirerly immutable since the StationManeger can still modify it's contents, however to the rest of the application these instances are effectively immutable since they are unmodifiable through the Station interface. By making station instances immutable, and by containing instances in an unmodifiableList when publishing, the StationManager ensures external actors cannot alter the StationManagers state illegaly (by either modifying the list or any Station instances contained in the list).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant