Writing down verbal agreements

[EliaTraore]

Currently, I have 2 assumptions about the code -

• The sensor save json msgs in the Table
• The sensors keep the newest entry at index 0 in their list (the second is a full blown assumption. IDRK how was that implemented...)

Where should such things be written? Are they even correct?

(the issue will be closed when assumptions are corrected/approved and documented in some form)

[inbalzukerman]

• The sensor does not have a Table anymore- its ListenableList now, as we all agreed
• The OLDEST_DATA_INDEX in the ListenableList is index 0 and in order to recieve the most recent record of a sensor you should use get(size()-1)

It is all documented already and can be found in ListenableList and DatabaseHandler I will improve documentation asap 👍

[SharonKL]

@EliaTraore the DBHandler class has a getLastEntry method

[EliaTraore]

• Obviously I meant the list. The sensor DB in whatever name it currently holds.
• Kinda followup question, which json data is(/should be) saved? from what I can understand from SystemSensor team's code (not sure about that tho), they are keeping the whole data (including the sensorId for example). Isn't that redundant? I think that should be explicitly defined somewhere

[EliaTraore]

I know that, but the AppTeam wants the abilitiy to get more then one entry (not in listeners, just as a general functionality)

[inbalzukerman]

The entire message is saved in the DB ( UpdateMessage to be exact ), this is what @RonGatenio asked in the last meeting.. This way, as I understand it, the application can parse the JSon msg back to the Message representation, and retrieve all the necessary data. If we'll change the data we're saving to be "less redundant", we'll have to parse the JSon msg, remove some data and then create another JSon msg to be saved in the DB. This new representation will be parsed by the application then...

[EliaTraore]

Actually, I think the idea was to keep only the data. The whole purpose of initializing objects for the app devs is to simplify the creation of sensor-representing objects, and allow easy access to the information. Whats the point Of that if we force them to work with UpdateMessage? They will still have to initialize the fields and cast them by themselves, which is tedious and not really needed. I don't think that parsing and getting the data itself in the ListenableList is such a hard job, and on the other hand I does come with a great benefit at the apps side.

[inbalzukerman]

I don't mind working this way 😅 It just not the way I understood it on first. Anyway I don't think the right place to do this is in ListenableList, it is supposed to be a generic class. It should be implemented in DatabaseHandler in my opinion.

[SharonKL]

The DBHandler receives a json message, meaning it will have to covnert it back to UpdateMessage to access the data. Considering the handlerUpdateMessage(...) method in SensorsHandler already receives an UpdateMessage, I think it should be implemented there.

[inbalzukerman]

Even better :smile:

[EliaTraore]

Awesome, I think we're almost done then. There's the small issue of where all of that should be written? This issue can't count as official documentation, or can it? I know its internal so it seems less important to keep track of, but this could lead to integration bugs in no time :sweat_smile: As for the ListenableList, @inbalzukerman , can you add getkentries(int k) method? it will surly clear any possible confusions

[inbalzukerman]

Sure, no problem 👍

[inbalzukerman]

Can this issue be closed?

[EliaTraore]

Yeah, any integration bugs are on Kunini anyway :tada:

[SharonKL]

hmm...