Theory
How the app gets its events
FestConnect Mobile does not invent its events: it FETCHES them from a server, which sends them as text in a specific format. That format is almost always JSON, the lightweight data language you studied deeply in BCA405-01 and generated server-side in BCA504.
Now you meet it from the MOBILE side: the app requests JSON from an API, PARSES it into Kotlin objects, and displays them. This lesson recaps JSON's structure and its contrast with XML, then focuses on how an Android app actually consumes it. JSON is the bridge between FestConnect Mobile and its data.
Theory
JSON structure, recapped
JSON (JavaScript Object Notation) is a lightweight, text-based, language-independent data format:
- objects:
{ "key": value }with DOUBLE-QUOTED keys - arrays:
[ value, value ] - values: string (double quotes), number (bare), boolean, null, or nested object/array
And one rule worth repeating: JSON has NO comments (unlike XML). It is deliberately minimal.
Everything you learned in BCA405-01 applies. The key point for mobile: a server sends a JSON string, and the app turns that string into usable objects. An events endpoint might return an ARRAY of event OBJECTS, exactly the shape FestConnect Mobile needs to build its list.
Practical
Events JSON, and parsing it in Android
// The server sends this JSON (an array of event objects):
// [
// { "name": "Garba Night", "seats": 350 },
// { "name": "Coding Contest", "seats": 60 }
// ]
import org.json.JSONArray
fun parseEvents(jsonText: String): List<String> {
val names = mutableListOf<String>()
val arr = JSONArray(jsonText) // parse the JSON array
for (i in 0 until arr.length()) {
val obj = arr.getJSONObject(i) // each event object
names.add(obj.getString("name")) // read the name field
}
return names
}
// Android also offers Gson/Moshi to map JSON directly to Kotlin classes.
At a glance
JSON vs XML (recap)
| Aspect | JSON | XML |
|---|---|---|
| Weight | Lighter (no closing tags) | Heavier (open/close tags) |
| Arrays | Native [ ] | Repeated elements |
| Comments | None | Yes (<!-- -->) |
| Parsing in apps | Easy, maps to objects | Needs tree walking |
Quiz
Which statement about JSON is correct?
- JSON supports comments with // like code
- JSON is a lightweight data format with objects {} and arrays []; it has NO comments and is lighter than XML
- JSON can only store text, not numbers
- JSON is heavier than XML
Show the answer
JSON is a lightweight data format with objects {} and arrays []; it has NO comments and is lighter than XML
JSON is a lightweight, text-based data format using objects {} (double-quoted keys) and arrays [], with NO comment syntax, and it is lighter than XML (no closing tags, native arrays). Option A is a common myth: standard JSON has NO comments (a whole BCA405-01 lesson). Option C is false: JSON stores strings, numbers, booleans, null, and nested structures. Option D reverses the weight comparison: JSON is lighter than XML, which is why mobile apps and APIs prefer it (less data over the network, easier parsing). For FestConnect Mobile, JSON is the compact, easy-to-parse format the server uses to deliver events.
Think first
Why mobile apps love JSON
Mobile apps run on phones with limited data and battery. Why does that make JSON, rather than XML, the natural choice for talking to servers? Then tap.
Show the answer
Because JSON is LIGHTER. Over a mobile network, every byte costs data and battery, and JSON carries the same information as XML in far fewer bytes (no repeated closing tags, compact syntax). Smaller responses mean faster downloads, less data usage, and less battery drain, all precious on a phone. JSON also PARSES more easily and maps cleanly to objects (a JSON object becomes a Kotlin object), so the app spends less effort turning the response into usable data. And since mobile apps overwhelmingly talk to REST APIs that return JSON, using it fits the ecosystem. XML still has its place (Android LAYOUTS are XML, and some enterprise systems use it), but for app-to-server DATA exchange, JSON's lightness and ease win. The general principle: on constrained devices, prefer the format that moves and parses with the least overhead.
Watch out
JSON-in-Android traps
Expecting JSON comments: there are none; do not put // in JSON.
Not handling parse errors: malformed JSON throws; wrap parsing in try/catch.
Blocking the UI thread: fetching and parsing should be off the main thread (coroutines/background), or the app freezes.
Assuming fields exist: a missing key throws with getString; check or use opt methods / nullable mapping.
Confusing JSON (data) with XML layouts: Android uses XML for layouts but JSON for API data; different jobs.
Theory
Data format known; now move between screens
FestConnect Mobile can parse the events JSON the server sends. A real app has MULTIPLE screens: an event list, an event detail, a registration form. Moving between them, and passing data along, is done with INTENTS, Android's mechanism for launching and communicating between activities. The next lesson covers multi-screen apps and intents, the backbone of Android navigation you first met in BCA305-02.
Summary
Key takeaways
- JSON is a lightweight, text-based, language-independent data format: objects {"key": value}, arrays [value, value].
- Values: string (double quotes), number (bare), boolean, null, nested; keys are double-quoted; JSON has NO comments.
- JSON vs XML: JSON is lighter (no closing tags), has native arrays, parses easily; XML has tags, attributes, comments.
- Mobile apps fetch JSON from a server (REST API) and PARSE it into objects to display.
- Android parses JSON with org.json (JSONObject/JSONArray) or libraries like Gson/Moshi (map to Kotlin classes).
- JSON's lightness suits phones (less data, battery, easier parsing); XML is used for Android layouts, not API data.
- Memory hook: JSON is the light data format apps fetch and parse; no comments, lighter than XML.