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
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.
I have some concept reading for you.
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.
SQL Tables and Views Introduction
Don't dive deep, just inhale the aroma of a few of the posts.
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.
So how can SQL be useful to me?
SQL won't help you as a tool, because there is no native support for it in AI2.
In suggesting you look at it, I was suggesting you learn that your data presentation does not have to exactly match your data storage organization.
I apologize if you learned something unnecessarily.
The Designer and Companion should not be used together once you pass the start of a small Project. Disconnect and reconnect after you are done with the Designer.
I do not recommend that and can't support that.
I posted an example of using a small self-scrolling display window in my Go Scroll Yourself demo, but you stripped out the scrolling part and added more display rows yourself.
I cannot support what you want.
...so, did you see any blocks to improve in my .aia?
Did you also have a slow loading of my project?
Now I would like to fix the last part of TinyDB data management: exporting and clearing data.
...but I'm already hearing Spicy's thoughts, so I'm going to cover it in the separate topic 
1 Like
So the last part of managing data was fixed in: Fixing exporting and clearing my TinyDB data
Thanks to the support of whole App Inventor community, the storing, displaying and clearing data is created now.
I enjoyed a lot assembling the blocks and seeing how everything emerged step by step.
I tested the app and for now everything seems great
These are related blocks:
I hope to build the app in iOS soon
......... 
Thank You All! ............
from the blocks i see too much "make a list" blocks.
maybe next time you can try create the component dynamicly.
Hi Kevin
what would you suggest?
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.