Closed inbalzukerman closed 7 years ago
FYI about listeners definition - the AppTeam wants them to receive whole table (or in this case, list) :)
@EliaTraore thanks 😊
@EliaTraore & the app team - I think its incorrect to return the whole list when listening to it. When you listen to something, you get notified about objects that change in the container. I think the correct design would be to give apps the object that was inserted (in our case, the String
) and let them decide whether or not they want the whole table.
I have to admit this is actually how I saw the implementation at first (and therefore the methods initially implemented in the Table
class were allowing mainly this functionality)
But for my understanding the current requirement (for the entire list) is for data analyzing and GUI purposes. For them more than only one "record" is necessary
@RonGatenio @roy-shchory @EliaTraore would naturally know better about that 😅
They still have the ability to get the whole table or the last k entries from other API calls. I simply think that a listener should receive objects, and not the whole container
IDRGAF... its up to the AppTeam :sweat_smile:
I really don't mind either I though it would work the way @SharonKL described but apps team didn't like it before that's all 😕
After discussion we all agreed that the listeners should receive the last update 👍
From the application's side, it should look something like this: Subscribing to a sensor
This class should have functionalities similar to
ListenableTable
- it should save a list of listeners to a list and inform them on any addition