I think this is a very worthy Project because all App Inventor Users will benefit from it.
The ability to define one’s own constants, perhaps an enumeration of related constants, would be of interest to many Users too - especially those who have experience of other languages.
I think I bit off more than I could conceptualize here.
Here is a more limitted but more practical idea, copied from the code generators of old that grew code from data base schemas. (I haven't heard much of these lately. Maybe they weren't such a great ides after all.)
This need not even be part of AI2. A separate tool could generate draggable PNG files from a schema, given enough reverse engineering of AI2 PNG files.
This samples is based on the sample at JSON Schema - What is a schema?
to represent a person ...
{
"type": "object",
"properties": {
"first_name": { "type": "string" },
"last_name": { "type": "string" },
"birthday": { "type": "string", "format": "date" },
"address": {
"type": "object",
"properties": {
"street_address": { "type": "string" },
"city": { "type": "string" },
"state": { "type": "string" },
"country": { "type" : "string" }
}
}
}
}
Given such a schema, it could be automatic to create generators, getters, and setters as AI2 procedures for such objects as person and address ...
Here are sample .PNG outputs for such a schema (I'm throwing in my project too, for safe keeping.) ...
schema_enums_samples.aia (4.6 KB) Uploading: set_address_country.png... Uploading: set_address_state.png... Uploading: set_address_street_address.png... Uploading: set_person_address.png... Uploading: set_person_birthday.png... Uploading: set_person_first_name.png... Uploading: set_person_last_name.png...(Some of the uploads did not arrive, 21 files was too much. You get the idea, right?)
The value of a schema to procedure blocks tool comes from avoiding the opportunity for tag string typoes in dict lookup and setter blocks, if one wants to do object oriented programming with dict blocks. Once these boiler plate setter and getter procedure blocks have been dragged into the blocks workspace, they become available for typeblocking. On the other hand, I have cluttered up the procedure branch of the Blocks pallette.
At this point, AI2 starts to look like Java.
As I said at the top of this post, I have bitten off more than I can conceptualize.
Wow that seems really cool!
So the idea is that you create a schema for an object in json. Then a separate tool uses that data to create draggable png files that represent procedures for accessing properties. Then you can add those pngs to your workspace to give you an easy way of working with your object (which is a dictionary under the hood)?
-- Or alternatively AI could take the json schema directly and convert it into blocks.
That's a really cool idea. And I like how you talk about using dictionaries as a kind of "glue" to form more complex data structures. Not something I had thought about before!
I don't think this necessarily falls under my project, but I do think it's really interesting! I'll be thinking about this for a while haha. Thank you for sharing 
@BeksOmega Yes, I agree that supporting more complex structures isn’t part of the scope of your project.
@ABG We have explored using GraphQL with dictionaries to provide a schema-like constraint when working with remote services. Longer term I’d like to see some object support (e.g., structs or classes) since it is such a common CS topic to cover. Dictionaries was a first step in that direction and a more formal set of blocks for defining objects and their behaviors with the corresponding autogenerated blocks could be valuable. Also, as part of the PUNYA (http://punya.mit.edu) project we explored the use of Semantic Web ontologies to drive the app UI.
Thanks all for the great material in this thread.
Hi! I just wanted to let everyone know there have been a few changes to the doc based on feedback I've gotten. Rest assured, all of the information is still there! And the User and Component Developer sections remained basically unchanged.
Changes include:
I am also working on creating a data structure diagram to make that section of the "Implementation Details" more clear.
So tomorrow is the last day we will be actively soliciting feedback! If you have any final thoughts be sure to get them in
Hello! I'm here to give a one-month update on my project. There has been a lot of work done and almost everything is working. But... I haven't gotten any feedback on my project yet, so by next month everything may change!
Here is a short video demoing how the system currently works (with some info for extension developers at the end!)
For those of you that are more text-oriented:
@Options Java annotation or by using the type directly. So it's easy to upgrade components in a backwards compatible way, but future components can maintain a clean design.Bounce function demoed in the video) you can still use the number blocks just like you have in the past.Remember all of the above could change! ^^^
If anyone has questions or comments I would be delighted to chat
excellent! keep up the good work!
Taifun
It looks great!
unbelievable 
I have a question.
Which emulator are you using? 
It is indeed! It might be tricky to get working if you aren't used to working in the sources though. What I did is:
MIT AI Companion.apk you get from building the sources (build/buildserver/MIT AI Companion.apk) into the emulator.But people that are more experienced using emulators may know an easier way to get this working.
Thank you for your question! =)
This is basically what we do here as well for testing App Inventor on different versions of Android when we don't have devices available (especially common due to the pandemic as we're all stuck at home).
One optimization you can make though is if you've installed the aiStarter package is to edit the run-emulator script in commands-for-Appinventor to start the emulator from the Android SDK rather than the prepackaged emulator. Then you can just use the Connect > Emulator menu option without having to separately start the emulator.
Thanks @BeksOmega, this is great. A couple questions that you may want to think about:
Great work @BeksOmega. Really looking good and helpful.
Currently "Do It" looks like this:
3. Note: I didn't add that on purpose, this is just what the default behavior results in.
Nope Dropdown blocks actually return an instance of the enum type. So if the comparison block has two enum instances, it compares those. If it has one enum and one more primitive type, it gets the underlying value of the enum and then compares that against the other primitive value.
Here's an example where both ScreenAnimation:Default and MapFeature:Circle have an underlying value of "Circle":
Yep i18n is working Here is the direction dropdown in (hopefully correct) Spanish:
The OdeMessages file looks like this:
directionOptionList = Dirección
directionNorthOption = Norte
directionNortheastOption = Noreste
directionEastOption = Este
directionSoutheastOption = Sureste
directionSouthOption = Sur
directionSouthwestOption = Sur oeste
directionWestOption = Oeste
directionNorthwestOption = Noroeste
But the suffixes can be easily changed to whatever you like.
Thank you for your questions!
Hello! I'm back again, this time with a two-month update on the project. There was a lot of exciting discussion this month about trade offs of different implementation of these blocks, but the main visible output has been adding dropdown blocks to a bunch of different components.
I would also like to announce that I've created a test domain so that you guys can try out these blocks =) Here is a complete list of the new dropdown types, and the components they are associated with:
I would really appreciate people testing these blocks out if anyone is interested 
In particular if anyone has an Ev3 or a Nxt (and some time to burn 
) I would really appreciate you giving them a look.
But all testing and feedback is very much appreciated!
A few notes:
I also have a preliminary document describing how extension developers can add these blocks to their extensions. Note that in the last post I mentioned:
Dropdown blocks can be added to components using an
@OptionsJava annotation or by using the type directly.
But this has been temporarily removed due to the afformentioned tradeoff discussions 
I hope to add it back in by the end of the summer if time allows!
You should be able to upgrade your components as described in the doc and upload them to the test server to test them.
I'm looking forward to a good third month! If anyone has issues with testing feel free to comment here or shoot me a message =)
Congratulations, incredible work! Saves time and makes the App Inventor much more didactic.
I have three little updates to the test server this week!
The asset blocks are associated with an annotation (like the @Options annotation, except in this case it is @Asset). There is documentation about this for extension developers, and they should be able to test it out on the test server. Also note that I'm not sure if file type filtering will make it into the final version.
Please tell me how you guys feel about the limited flyout width! With the added helper blocks, the flyout was starting to get huge and I didn't want it to start taking over the workspace. Personally I think the limited width still allows you to get enough information about the blocks, but I want to hear what you guys think!
Again, if anyone has questions or opinions I'm always available =)
Will the new features also work in the iOS version?
Is Screen1 worthy of inclusion in the Open Other Screen option list?
I have yet to see that work out well.
As far as I know, yes! One particularly nice thing is that the new "Permission" block means you don't need to to type android.permission.WHATEVER, which will make the apps more compatible with iOS =)
@ABG Hmm.. would you give me some more details about this? As you know, I'm not a very experienced App Inventor user hehe.
I assume there is an issue with people trying to navigate back to Screen1 from a different screen, but in doing so they keep pushing screens to the stack? That may actually need to be fixed at a deeper level, and I'm wondering if anyone has looked into it before.
Now I'm also wondering if it might be nice to remove the current screen from the dropdown... any thoughts?
Thank you both for your feedback! I really appreciate both of you taking the time to respond =)
