Ela, I dont think so, here it is very straightforward code, DB-> UserProfiles-> reading fram.
Here, in your code it seems to be one user will be owner of the db or one user control. And you are seems to be done Great, as you have sucessfully save the namespace for one day and under that namespace you have saved the one reading of pulse oximeter sensor for different fingers ( I just visually verified ).
But in the ABG's code example there was a logic to have namespaces for profil(s), but here you are just saving multiple readings for one day, and perhaps for one user only. Why don't you have a dictionary, day as Key and list of lists as value for multiple readings. Your app will be having two options in main page one for having new reaidng and one options of read old readings.
Go to a sepcific namespace and populate the underling tag using get all tags and enumarate them all to render them.
The way you had saved the data, the same way you will be using to retrive them, millis or a specific date-format.
and maximum querey/concerns have already been answered here
...interesting, but it is sufficient that I give the user only one option: all readings by clicking the List button.
The user can save his data without looking at the table every time the reading session ends. He looks at the table mainly when he wants to compare various readings.
But maybe this solution can be useful when I will need to recall namespaces with datepicker? I don't know how to do it yet.
Now I think it's time to build the table, ...without extensions.
I could assume a maximum of readings per day: 50
What is best to do:
use Table Arrangement with 50 rows
(ABG: "Table Arr. is susceptible to copy/paste errors", ...can it be a problem for me?)
use 50 Horrizontal Arrangements with the fixed length of Labels?
Here, you can have multiple keys for multiple days, and day will be refreing to specifc table - list of lists for the multiple readings. Your current approach is correct but for me it looks Scattered not united. In a day user can save multiple readings, just clicking New-Reading, that will open a form to enter corresponding reading data and save. That reading will be saved along with the existing reading of that day only.
TinyDB creates its NameSpacename.XML files automatically when you save to a new NameSpaceName
The NameSpaqceName.XML sit there behind the scenes until you uninstall the app.
Because they are separate files, they don't take up any RAM until you need to read them for export or display.
Performance-wise, this allows for fast update at constant speed, eliminating ever longer packing/unpacking delays from TinyDB that would occur if all the data stayed in a single TinyDB nameSpace file.
I personally favor using a small screen-sized fixed window of Horizontal Arrangements stacked in a Vertical Arrangement, with a thin vertical Canvas on the side for scrolling, and a global variable OFFSET (default 0) to hold how far down the aforesaid table is the section you are showing in the window.
I need sample data to make a demo of how to do this.
Can you gather a table of your readings (12 should be enough) and upload a csv file?
Oh, nice idea, but I have a feeling that it is not suitable for using my app.
What happens here is:
The user feels his pulse with his three fingers and detects various perceptions. Then he starts the app and selects the buttons that correspond to his perceptions (he collects one-reading data). Finally he saves the data and can close the app or go to see the table.
Some time later, he sits down again to feel his pulse, again collects the data (perceptions) by clicking the buttons and saves the next reading session.
In one day he can do from 0 to 20 readings, or more. It depends on how much he wants to practice in order to become an expert in the pulse-reading technique.
Data collection must be very fast and intuitive, that's why I use buttons instead of the form.
However your idea can be useful for something else. Every contribution is precious
When the user goes to the table by clicking List button, he must see the current day in the Datepicker calendar and all the readings done on that day displayed in the table.
I have already tried to apply that Dynamic Table with Javascript and prefer to avoid it.
My appetite goes for the Arrangements
This is a possible quantity and distribution of data:
I have merged Time and Activity display to optimize space on the screen.
Even though we have the date appearing in the Datepicker, initially I kept the date in Day&Time column thinking about export, but for now we can try this solution.
Anyway I would like to keep the storage with Date and Time and also separate it from the Activity. Only in the visualization I would do as in the attached table.
In anticipation of your (and others) future need to scroll through a display of customized table rows, I created this sample:
This sample lets you scroll through hundreds of rows.
Regarding your blocks, I see a big red triangle of text replacement blocks where you steamroll a table into a text then try to pick out the resultant markup (",) characters by text replacement. For more customized control over table cell formatting, consider using the JOIN With Separator (\n or "," or " " or \t) block for your list to text conversion.
A table to text conversion might require 2 passes, building rows then piling them up with \n.
There is a table to csv conversion block that's even simpler.