Why network calls fetch remote data in Android Kotlin - Challenge Your Understanding

Challenge - 5 Problems

🧠 Conceptual

intermediate

Why do network calls fetch remote data?

Which statement best explains why mobile apps use network calls to fetch remote data?

A Network calls are only used to send data, not to receive it.

B Network calls are used to speed up the app by storing data locally.

C Network calls help apps run without internet by using cached data only.

D Network calls allow apps to get updated information from servers located elsewhere.

💡 Hint

Think about where the latest data lives and how apps get it.

Mobile apps use network calls to connect to remote servers to get the latest data that is not stored locally. This keeps the app's information fresh and up to date.

❓ ui_behavior

intermediate

What happens when a network call fetches data?

When a mobile app makes a network call to fetch remote data, what is the expected behavior in the app's UI?

A The app shows a loading indicator until data arrives, then updates the display.

B The app immediately shows old data without any change.

C The app crashes if the network call takes longer than 1 second.

D The app closes automatically after the network call.

💡 Hint

Think about how apps keep users informed during data loading.

Apps usually show a loading spinner or message while waiting for data, then update the UI once the data is received.

❓ lifecycle

advanced

When should network calls be made in an Android app lifecycle?

In Android development with Kotlin, at which lifecycle event is it best to start a network call to fetch remote data for a screen?

A Inside onCreate() to start loading data as soon as the screen is created.

B Inside onStop() to fetch data after the screen is hidden.

C Inside onPause() to load data when the app is not visible.

D Inside onDestroy() to fetch data before the screen closes.

💡 Hint

Consider when the UI is ready to show new data.

onCreate() is called when the screen is created, so starting network calls here ensures data loads early for display.

❓ navigation

advanced

How does fetching remote data affect navigation flow?

If a screen depends on remote data fetched via network call, what is a good practice for navigation?

A Skip fetching data and navigate to a different screen.

B Navigate immediately and show empty UI without waiting for data.

C Show a loading screen or placeholder until data is ready before navigating fully.

D Block navigation until the user manually refreshes data.

💡 Hint

Think about user experience when data is not yet loaded.

Showing a loading screen or placeholder prevents showing empty or broken UI and improves user experience.

🔧 Debug

expert

What error occurs if network call is made on main thread?

In Android Kotlin, what error or behavior happens if you make a network call directly on the main UI thread?

Android Kotlin

val url = URL("https://example.com/data.json")
val connection = url.openConnection() as HttpURLConnection
val data = connection.inputStream.bufferedReader().readText()

A The network call succeeds instantly without any error.

B android.os.NetworkOnMainThreadException is thrown, blocking UI.

C The app silently ignores the network call and returns empty data.

D The app crashes with NullPointerException.

💡 Hint

Android prevents long tasks on the main thread to keep UI responsive.

Android throws NetworkOnMainThreadException to prevent freezing the UI by blocking network calls on the main thread.

Practice

1. Why do mobile apps use network calls to fetch data from the internet?

easy

A. To get the most up-to-date information that changes frequently

B. To save battery by avoiding local storage

C. To make the app run faster without internet

D. To store data permanently on the device

Solution

1. Step 1: Understand the purpose of network calls

   Network calls are used to get fresh data from the internet, especially when data changes often.

2. Step 2: Compare options with this purpose

   Only To get the most up-to-date information that changes frequently matches this reason; others are incorrect because network calls do not save battery or store data locally.

3. Final Answer:

   To get the most up-to-date information that changes frequently -> Option A

4. Quick Check:

   Network calls fetch fresh data = A [OK]

Hint: Network calls get fresh data from internet, not local storage [OK]

Common Mistakes:

• Thinking network calls save battery
• Assuming network calls store data locally
• Believing network calls make app work offline

2. Which Kotlin code snippet correctly starts a network call on a background thread?

easy

A. fetchDataFromNetwork()

B. Thread.sleep(1000); fetchDataFromNetwork()

C. runOnUiThread { fetchDataFromNetwork() }

D. GlobalScope.launch { fetchDataFromNetwork() }

Solution

1. Step 1: Identify correct background thread usage in Kotlin

   Using GlobalScope.launch starts a coroutine on a background thread for network calls.

2. Step 2: Check other options for thread usage

   fetchDataFromNetwork() runs on main thread, runOnUiThread { fetchDataFromNetwork() } forces main thread, Thread.sleep(1000); fetchDataFromNetwork() just delays but runs on main thread.

3. Final Answer:

   GlobalScope.launch { fetchDataFromNetwork() } -> Option D

4. Quick Check:

   Background thread with coroutine = B [OK]

Hint: Use coroutines (launch) for background network calls in Kotlin [OK]

Common Mistakes:

• Calling network on main thread causing app freeze
• Using runOnUiThread for network calls
• Using Thread.sleep to delay network calls

3. What will this Kotlin code print if the network call returns "Hello" asynchronously?

GlobalScope.launch {
  val result = fetchDataFromNetwork()
  println(result)
}
println("Done")

medium

A. Hello\nDone

B. Done\nHello

C. HelloHello

D. DoneDone

Solution

1. Step 1: Understand coroutine asynchronous behavior

   The println("Done") runs immediately on main thread before coroutine finishes.

2. Step 2: Determine print order

   Coroutine prints "Hello" after network call completes, so output is "Done" then "Hello".

3. Final Answer:

   Done\nHello -> Option B

4. Quick Check:

   Async coroutine prints after main thread = A [OK]

Hint: Main thread prints first, coroutine prints after network call [OK]

Common Mistakes:

• Assuming coroutine blocks main thread
• Expecting prints in code order
• Ignoring asynchronous nature of network calls

4. Identify the error in this Kotlin code that fetches data from network:

fun fetch() {
  val data = fetchDataFromNetwork()
  println(data)
}

fun fetchDataFromNetwork(): String {
  Thread.sleep(2000)
  return "Data"
}

medium

A. Thread.sleep is not allowed in Kotlin

B. fetchDataFromNetwork() returns wrong data type

C. Network call is blocking main thread causing app freeze

D. println cannot print strings

Solution

1. Step 1: Analyze fetchDataFromNetwork() behavior

   Thread.sleep(2000) blocks the thread it runs on, here main thread, freezing UI.

2. Step 2: Understand impact on app

   Blocking main thread causes app to freeze, so network calls must run on background thread.

3. Final Answer:

   Network call is blocking main thread causing app freeze -> Option C

4. Quick Check:

   Blocking main thread with sleep = C [OK]

Hint: Never block main thread with network calls or sleep [OK]

Common Mistakes:

• Ignoring UI freeze caused by blocking calls
• Thinking Thread.sleep is forbidden syntax
• Assuming println cannot print strings

5. You want to fetch a large list of user data from a server that updates every minute. Which approach is best to keep your Android app smooth and up-to-date?

hard

A. Use background network calls with caching and refresh every minute

B. Fetch data on main thread every time user opens screen

C. Avoid network calls and use static data bundled in app

D. Fetch data once at app start and store locally forever

Solution

1. Step 1: Consider data freshness and app performance

   Data updates every minute, so app needs fresh data regularly without freezing UI.

2. Step 2: Evaluate options for smoothness and freshness

   Use background network calls with caching and refresh every minute uses background calls with caching and periodic refresh, balancing smooth UI and fresh data.

3. Final Answer:

   Use background network calls with caching and refresh every minute -> Option A

4. Quick Check:

   Background fetch + caching = D [OK]

Hint: Combine background fetch with caching for smooth, fresh data [OK]

Common Mistakes:

• Fetching on main thread causing freezes
• Not refreshing data causing stale info
• Using static data ignoring updates