Read JSON in MIT App Inventor | How to Decode JSON File | MIT App Inventor File #json #appinventor

TL;DR

JSON is a common, language-independent data format built from key–value pairs, using curly braces for objects and square brackets for lists.

Briefing Cornell Notes

Briefing

JSON—short for JavaScript Object Notation—is a lightweight data format built around key–value pairs. In practice, it lets programs store and exchange structured information in a way that’s easy for humans to read and for software to parse. Curly braces mark an object, square brackets mark a list, and arrays can hold repeated values like strings. That structure is why JSON shows up so often in APIs, where different systems need a common language for sending and receiving data.

A concrete example drives the lesson: a downloaded JSON file containing 1,302 colors, each represented by a dictionary with a hex code and a color name. The file begins with a square bracket, indicating the top-level list. Inside that list sit multiple objects (curly braces), each carrying key–value pairs such as a “hex” field and a corresponding “name” field. The goal in MIT App Inventor is straightforward: let a user enter a color hex code, press a button, and display the matching color name.

The build starts with a new MIT App Inventor project and a simple user interface: a text box for the hex input, a submit button, and a label to show the resulting color name. A File component is added for reading the JSON text from the project’s uploaded media. During the screen’s Initialize event, the app reads the file as raw text (not yet interpreted), using File1’s “read from” procedure with the uploaded filename (colors.Json). When the read completes, the “File1 got text” event fires, storing the entire file content into a global variable.

Next comes the decoding step. The raw JSON text is converted into a usable data structure with Web’s “JSON text decode,” producing a list of dictionary objects—matching the file’s list-of-objects structure. A global empty list is prepared to hold that decoded result.

To find a color name, the lesson adds a procedure called “find color.” It uses a local variable (so it stays scoped to the procedure) and a for-each loop that iterates through the decoded color list. Before searching, the color name is initialized to “color name was not found,” covering cases where a given hex code has no match. Inside the loop, an if condition checks whether the current item’s “hex” value contains the user-provided hex code. To make the search case-insensitive, the user input is converted to uppercase before comparison. When a match is found, the procedure sets the local “name” variable to the matched item’s “name” field, then breaks out of the loop immediately to avoid unnecessary scanning.

Finally, the submit button triggers the “find color” procedure, and the label is updated with either the found color name or the default “not found” message. The workflow ties JSON’s structure directly to app logic: read text, decode into lists/dictionaries, then search through decoded objects by key values.

Cornell Notes

JSON (JavaScript Object Notation) organizes data using key–value pairs, with curly braces for objects and square brackets for lists. In this MIT App Inventor workflow, a colors.Json file containing 1,302 color entries is first read as plain text, then decoded using Web’s “JSON text decode” into a list of dictionary objects. A “find color” procedure loops through that decoded list, initializing the result to “color name was not found.” For each dictionary item, it checks whether the item’s “hex” value contains the user-entered hex code (converted to uppercase for case-insensitive matching). On the first match, it sets the result to the item’s “name” field and breaks the loop, then updates the label when the submit button is pressed.

How does JSON’s structure (objects vs lists) map to what MIT App Inventor needs to work with?

Curly braces in JSON represent an object with key–value pairs, while square brackets represent a list. The colors.Json file starts with a square bracket, meaning the top-level is a list. Inside that list are many objects (curly braces), each acting like a dictionary with keys such as “hex” and “name.” After reading the file as text, Web’s “JSON text decode” turns that list-of-objects JSON into a decoded list where each item is a dictionary, which the app can iterate over with a for-each loop.

Why does the app read the JSON file as text first, and what changes after decoding?

File1 reads the uploaded colors.Json file as raw text, stored in a global variable. That text is still just characters, not a structured list/dictionary. The decoding step—Web’s “JSON text decode”—converts the JSON text into actual data structures: a list (for the outer array) containing dictionary objects (for each color entry). Only after decoding can the app reliably access dictionary values like the “hex” and “name” fields.

What’s the purpose of initializing the result to “color name was not found”?

The procedure “find color” sets a local variable (scoped to the procedure) to “color name was not found” before searching. This ensures the label always gets a meaningful output even when the user enters a hex code that doesn’t exist in the dataset. If no dictionary item matches the hex input, the for-each loop completes and the default value remains.

How does the app make hex-code matching case-insensitive?

User input can be typed in lowercase or uppercase. Before comparison, the procedure converts the user-entered hex text to uppercase using an up-case block. It then checks whether the current dictionary item’s “hex” value contains that uppercase input, so the match works regardless of the user’s letter casing.

Why does the procedure break out of the loop after finding a match?

Once the if condition confirms a match, the procedure sets the local “name” variable to the matched dictionary’s “name” value. It then uses a break block inside the if block to exit the for-each loop immediately. This avoids scanning the remaining 1,302 entries unnecessarily and ensures the first match determines the output.

What triggers the search and how does the result reach the user?

When the submit button is pressed, the app calls the “find color” procedure. After the procedure finishes, it sets the label (color name label) to the local variable holding either the matched color name or the default “color name was not found.” The label update is what the user sees on screen.

Review Questions

What JSON elements (curly braces vs square brackets) correspond to objects and lists, and how does that affect the decoded data structure in MIT App Inventor?
In the “find color” procedure, which dictionary key is used for matching, which key is used for the displayed result, and why is uppercase conversion applied?
Why is the break block placed inside the if condition rather than after the loop?

Key Points

1
JSON is a common, language-independent data format built from key–value pairs, using curly braces for objects and square brackets for lists.
2
To use JSON in MIT App Inventor, the file is first read as raw text via a File component, then converted into usable structures with Web’s “JSON text decode.”
3
A JSON file structured as a list of objects decodes into a list where each item behaves like a dictionary, enabling key-based lookups.
4
Searching for a match is implemented with a for-each loop over the decoded list, with a default result set to “color name was not found.”
5
Hex-code matching is made case-insensitive by converting the user’s input to uppercase before comparing against each item’s “hex” value.
6
When a match is found, the app extracts the corresponding “name” value and breaks out of the loop to stop further scanning.
7
The submit button triggers the lookup procedure, and the label is updated with the final result for the user.

Highlights

The workflow hinges on two steps: read colors.Json as text, then decode it into a list of dictionaries using “JSON text decode.”

The app treats each color entry as a dictionary item, matching on the “hex” key and displaying the “name” key.

A default “color name was not found” value guarantees a sensible output even when no hex code matches.

Uppercasing the user’s hex input makes the lookup robust against letter-case differences.

Breaking out of the loop immediately after the first match improves efficiency and keeps results deterministic.

Topics

JSON Basics
MIT App Inventor
Reading JSON Files
Decoding JSON
Dictionary Lookup