...ah, ok, no problem.
I will post all the blocks once I have finished working on my calendar, so then we'll see it.
Is this question related to the topic? Else either search in forum or create new topic regarding this. Before that dont forget to hit the properly reply as solutiin which gives you an idea
Hi Spicy, You are right.
So I can correct the topic title in: "How can I create data storage using clock component and display it in a table using calendar?"
They are all related subjects as I explained in my first post. The calendar is just following that thread, until my storing and displaying work together optimally.
Or I can break this thread and create a new topic. However, in this topic there is already the Abraham's suggestion I am working on and I am collecting the questions to ask.
So tell me what you prefer and what is most comfortable for readers 
1 Like
better split the topic.. Thats always healthy conversation betwenn one and all..
also chek up whether this calendar apps suits for you or not
...so my calendar has been fixed in the separate topic: Fixing my customized calendar
If the Community allows, I continue this topic.
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?
...or maybe just add a new TinyDB?
I await your suggestions
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).
I'm curious to understand your idea better.
Dictionaries are like little in-memory TinyDBs, good for keeping data separate by name.
They allow in-place update, and can deal well with missing data.
You can remove a key/value from a dictionary without affecting the other keys/values.
Here is your starter reading...
http://ai2.appinventor.mit.edu/reference/blocks/dictionaries.html
Ok, done.
What's next?
I forgot to mention that iOS AI2 currently has no dictionary support.
Is that a problem for you?
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?
I am not on the MIT development team, and I personally have no iOS devices or any urge to develop for them or support them.
So do you want to use dictionaries?
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?
I need the answers to decide how to proceed.
Can anyone answer my questions please?
Please state your query clearly again
When it is ready, that is all we know
probably...
Here is an alternative to dictionaries, using only TinyDB Namespaces:
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.
Ok, I understand.
Thanks Tim for answers
I hope you will make a big announcement when iOS for AppInventor is ready 
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?
So, for now, I have decided to keep the data of all the levels together but I have differentiated them by adding to Tag: "L1" or "L2"...
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.
There is a famous warning in Computer Science:
1 Like