So far I have collected, stored and displayed the first level data. It is for students who have finished the first level of the Self-Pulse Reading technique learning.
Subsequently, the students will access the second level (from Home page) where they will collect the new, more advanced data and will have to display them in the same table.
These second level data must not be mixed with the first level data. So it must be stored separately.
It probably means that the time to dive into the dictionary ocean has come, doesn't it?
Should I further differentiate the names of Namespaces?
Because you are dealing with two separate populations of users, this is a good opportunity to do a Project->SaveAs to lock in your success with your first version and start your expansion in a separate larger project.
This will have the side benefit of giving you a new set of TinyDB storage areas where you can start fresh with new data organizations.
There is a question I have for you regarding second level data:
Is it tied to the same timestamp (tag) used to access your level 1 data?
Will you continue to have only one Submit button but have it now cover both level1 and level2 data?
Also, Can you really fit both levels of data into a single row in your onscreen display table on a phone?
Those need to be answered before data storage design can proceed.
Yes, the tags will be formed the same way as now. Only informations / buttons to click will change.
I could use the same "Save" button, or, if it is necessary, I can replace it with a new "Save" button for level 2.
In the same way I will use the already existing pages, changing their titles, buttons, etc., ...but I will also add the new pages.
I will use the same table structure, but the data will not be mixed. At the time of display, only the data of level 1 will appear (when one is on level 1 of the app) or only the data of level 2 (when one is on level 2 of the app).
Yes ...actually it is
Although for now I use android as a Companion, so theoretically it could be done, but I hope that soon there will be the possibility to build apps for iOS. At what point are you?
Can anyone on the MIT development team answer my question please?
...also, when the build apps for iOS will be available, will the dictionary be included?
This approach only stores the Millis of each days' activities as tags under a new NameSpace for each day. The values are just filler. We need the tags to get to the NameSpaces where we store the named values for the parts of each Activity, one Activity per NameSpace.
This stores each part of an Activity separately under its name, like in a dictionary.
To reverse the process, you would need to walk the TagList of the desired day's NameSpace to get a list of millis, like you do now.
Instead of looking up a table row from that NameSpace, you would have to decide which parts of that Activity you want (Middle, Index,...) and look them up in the NameSpace for that Activity's millis.
This gives you total flexibility to add new parts to Activities, or to leave them out.
You pay a price later if you want to build a table for display, building up each table row piece by piece with separate TinyDB lookups.
Yes, this could be a great solution, but I'm alarmed by the price.
It means much more work, not just for me changing the whole display organization, I guess, but especially for the app that already has a lot to do when displaying, ...it might slow it down further.
So I have to find another solution.
...and why not just add another TinyDB component?
But if there is really a need to separate the data of the various levels later, I would still like to know: what are the pros and cons of adding another TinyDB component?
I would have to see your exported .aia file to know how much rubber stamping you have done in your blocks. Procedures and generic blocks are very helpful for reducing block counts and for shielding your blocks from implementation details like TinyDB vs dictionaries vs lists.
Don't worry about speed at this level. I would love to see any example you could provide where your app is slowed at run time, with such infrequently updated small quantities of data.
It is important to separate the storage organization of data from its organization on a display.
The storage component only needs to keep the data accessible and addressable for use by the display components, and should not meddle with display considerations.
In my pantry, I don't keep flavored ground coffee. I leave that job to breakfast add-ons, which I add to the black coffee in my cup.
This is important for dealing with the added complexity of managing multiple views of the same data, which is what you are getting into now that you want to add Level2 data to your app and want to manage the complexity better.
Though you probably won't be using SQL in your app, you should learn some of the ideas and terminology of SQL, namely Tables and Views, and the difference between them.
Ok, I got the concept.
It's about organizing data in virtual tables already in the database and then calling them for viewing, isn't it?
I wanted to point out two things.
My data is organized more like a list. Right now I don't see the need to group data into columns. I need to manage just rows (and not a single data in the row).
Also, I still have to add 30 or 40 rows to my table, but I will do it as the last thing because my Companion is very slow to load the project and update it after every change (especially in the "Design" section) and it often crashes.
