Task #351: Performance refactoring
Rebuild GUI refresh to base on Channel broadcasts instead of polling the channels
|Assignee:||Espen Solbu||% Done:|
|Target version:||2.5 Maintenance|
Eg. Upon model config/channel config or onResume:
- Build Channel List (listenfor id and view id) (or use local channel list)
- register listeners
In listener, update list
Cyclically, iterate the list, update the corresponding view IDs
localChannelList = currentModel.getChannels()
#3 Updated by Hans Cappelle over 6 years ago
Do I get it that this is a proposition to change the GUI from checking the server on an interval towards server broadcasting and GUI listening? If so I agree.
In case the amount of updates is too high for several sensor values we could reduce traffic by putting only unique sensor ids together in a broadcast event. Collect in hashmap on server side and if key is found in map (=second value for this sensor) perform broadcast and empty map to be ready to accept next iteration of sensor values.
If I get this wrong maybe better to create another refactor task for this...
#4 Updated by Espen Solbu over 6 years ago
Yes this is to stop GUI from checking server.
All channel updates are already broadcast, however we would slow down the gui if we update on all of them. I was thinking having the gui "catch" them all, but only update presentation on an interval.
We could add another single broadcast with all the channel values as you state, not sure if this is neccessary though..
#6 Updated by Espen Solbu over 6 years ago
Yes, this to prevent the cyclic server poll.
not really an important refactor though, but would help to keep things ascynchronous.
(the runnable is already in the dashboard, just make it check the collection instead.)
However. it might be messy registering for all the active channels...
(need at least rssi channels as well as the model channels)