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

Refactoring: Cleanup dependencies around envControlDataService #141

Open
klues opened this issue May 9, 2018 · 0 comments
Open

Refactoring: Cleanup dependencies around envControlDataService #141

klues opened this issue May 9, 2018 · 0 comments

Comments

@klues
Copy link
Contributor

klues commented May 9, 2018

With commit 1ce80fa I implemented a callback system in order to be able to:

  1. automatically get data (also on updates) from envControlDataService to module hardwareIrTrans
  2. be able to update data from hardwareIrTrans to envControlDataService which eventually saves the data to file via ARE.

So in the end a two-way communication between envControlDataService and hardwareIrTrans is needed.
However it is not possible to just include the modules with angularJS dependency injection because it will result in a circular dependency circle, which leads to an angularJS error.

The current implementation is not the prettiest and in the end the architecture should be refactored in this way:

  • there is one dataService which is responsible only for storing data to ARE and notify other modules about updated data.
  • retrieving and saving data to this service will be done with public service methods
  • notifications about changes of the saved data will be done by a subscriber system. So all modules that want to be updated about data updates have to register to updates with a callback. Maybe the observer pattern would fit for this purpose: https://en.wikipedia.org/wiki/Observer_pattern

Currently the dependencies look about like this:
dsc00031

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant