It is now running the latest version of our master and “ucr” branches along with code from three pull requests that haven’t been merged.
An important (and still being tested) change is the addition of a new “dictionary” block type. Check it out!
This is a Components release, so a new Companion is needed (version 2.56t1u). More information as well as the feedback document is at:
The feedback document seems to have been trashed, with lines through all the text.
(Never mind, it’s been fixed.)
By the way, are the if/then blocks supposed to include pre-mutations?
Yes (I added them 
)
New users may not be immediately aware of the mutator, so adding the blocks with pre-defined mutations makes the blocks easier to find.
Yes, and thank you! We'll make sure that you get credited in the final release notes. Original issue for reference:
Could you please share the proposed documentation that relates to the new json and xml blocks? I wish to understand their relevance and requirement (why we need them and what they do). Does it describe what a json/xml dictionary is, if it exists - I have found python dictionaries…
Difficult to test otherwise
Of course. JSON/JavaScript style dictionaries and Python dictionaries have a lot in common. JSON puts some additional constraints by restricting the types of valid elements. We relax that a bit and allow for components and numbers to be keys in the dictionary (JSON allows only strings, and Python allows any hashable object).
The Dictionaries blocks documentation includes all of the blocks and also includes an example of using the list by walking key path block to walk the new XML structure.
The Web component documentation includes the three new functions JsonObjectEncode, JsonTextDecodeWithDictionaries, and XMLTextDecodeAsDictionary with some discussion of the output they produce.
This document in the Technical and other guides reference materials describes how to use the dictionary blocks in conjunction with JSON-based Web APIs.
I also wrote this memo (which I think I had shared with the power users) that discusses specifically the redesign of the XML parser output.
With all of the documentation, I'm happy to incorporate any suggestions to improve the materials with clarifications or examples. Where possible, I've tried to put links between documentation pages to aid with follow-up research. If you think that there should be links someplace in the docs, please let me know.
Thank you, that makes a lot more sense 
it might be more consistent if the JsonDecodeWithDictionaries function would be renamed as JsonTextDecodeAsDictionary
Taifun
Wouldn't As Dictionary imply the output is always a Dictionary?
But if the outer layer of the input is [ ...] then the output should be a list.
So I would stick with JsonDecodeWithDictionaries.
@ABG’s reasoning here is correct. In the case of the XML block, the output is always guaranteed to be a dictionary by design. For the JSON block, it will use dictionaries at the App Inventor version of Objects (versus lists-of-lists in the JsonTextDecode method). However, there’s no guarantee that the output will be a dictionary. For example, calling JsonTextDecodeWithDictionaries on the string "Foo" will return a string. Calling it on ["Foo"] will return a 1-element list with the string "Foo". Because there’s the opportunity to get “not a dictionary”, I didn’t want the name to imply that it always returned one (e.g., what does it mean to return the parse as a dictionary of "foo"). I also contemplated UsingDictionaries instead of WithDictionaries for the JSON version. I guess that’s still an option before we finalize this.
The how-to-use document is well written, but it is burdensome to have to jump out into the JSON generator site to see the raw JSON that is being traversed in the various examples.
I recommend inserting a small sample directly into the doc, to avoid having to leave the doc to understand the searches and their results:
[
{
"userId": 1,
"id": 1,
"title": "sunt aut facere repellat provident occaecati excepturi optio reprehenderit",
"body": "quia et suscipit\nsuscipit recusandae consequuntur expedita et cum\nreprehenderit molestiae ut ut quas totam\nnostrum rerum est autem sunt rem eveniet architecto"
},
{
"userId": 1,
"id": 2,
"title": "qui est esse",
"body": "est rerum tempore vitae\nsequi sint nihil reprehenderit dolor beatae ea dolores neque\nfugiat blanditiis voluptate porro vel nihil molestiae ut reiciendis\nqui aperiam non debitis possimus qui neque nisi nulla"
},
{
"userId": 1,
"id": 3,
"title": "ea molestias quasi exercitationem repellat qui ipsa sit aut",
"body": "et iusto sed quo iure\nvoluptatem occaecati omnis eligendi aut ad\nvoluptatem doloribus vel accusantium quis pariatur\nmolestiae porro eius odio et labore et velit aut"
},
{
"userId": 1,
"id": 4,
"title": "eum et est occaecati",
"body": "ullam et saepe reiciendis voluptatem adipisci\nsit amet autem assumenda provident rerum culpa\nquis hic commodi nesciunt rem tenetur doloremque ipsam iure\nquis sunt voluptatem rerum illo velit"
},
{
"userId": 1,
"id": 5,
"title": "nesciunt quas odio",
"body": "repudiandae veniam quaerat sunt sed\nalias aut fugiat sit autem sed est\nvoluptatem omnis possimus esse voluptatibus quis\nest aut tenetur dolor neque"
}
]
Some spoon feeding is needed regarding the use of "$attributes" in a path walk through decoded XML in MIT App Inventor Dictionary Blocks
based on this XML:
<schedule>
<day>
<room name="Hewlitt" />
<room name="Bleil" />
</day>
<day>
<room name="Kiva" />
<room name="Star" />
</day>
</schedule>
If we go back to Connectivity to look for $attributes, we are told
The
$tagkey is the full tag name, e.g., foo:bar. The$localNameis the local portion of the name (everything after the colon:character). If a namespace is given (everything before the colon:character), it is provided in$namespaceand the corresponding URI is given in$namespaceUri. The attributes are stored in a dictionary in$attributesand the child nodes are given as a list under$content.
So there is a dictionary hiding among the literals in the key path list. What to make of it? Maybe it feeds the walk at all level block preceding it in the key path list?
I smell the need for a mutator or a socket for that walk at all level block?
There's a bunch more explaining needed here for those $ variables.
this is actually what I naively expected... 
Taifun
@ABG Thanks for the feedback. I’ll expand on the meaning of the different $ fields in the next update.
After sleeping on the key path complications,
I came up with some alternative mental models
and terminology for how they might work.
I’m going to throw them against the wall to see if they stick …
A Key Path is actually a regex (regular expression)
or Query By Example against the set of possible
traversals from the root of a dictionary however deeply into
its thicket of branches.
A Key Path is a Tour Set generator.
A Key Path is like a SQL SELECT with WHERE clauses, GROUP BY clauses, and HAVING clauses across the set of tours through a dictionary.
(end of speculations)
2 posts were split to a new topic: Error: There is no method named JsonTextDecodeWithDictionaries in class Web