Thuta Learning
Search
ExercisesMobile Developmentintermediate

Practice Round 2

Relax. We'll talk through this in plain words — no textbook voice.

What you'll walk away with

  • Understand Practice Round 2 without any of the intimidation
  • Be able to run Android Studio/Compose code yourself
  • Apply this concept straight away in a real project

Let's think about it this way for a second

This round is a step up from round 1 — instead of practicing each skill in isolation, you'll combine them all at once. That includes deciding how to split MVVM layers for an app, choosing between `suspend fun` (a one-shot result) and `Flow` (a data stream) depending on the scenario, and writing up a Play Store publish plan as a production document. Budget about 10 minutes per task.

Let's connect this to a real scenario

Task 1: Design the MVVM layers (Data/ViewModel/UI) for a note-taking app (offline-first, with optional cloud sync), and write down what each layer's responsibility should be. Task 2: For the two scenarios 'I want to fetch the user profile data just once' vs 'I want the chat message list to update in real time', decide whether to use `suspend fun` or `Flow` and explain why. Task 3: After an app is published on the Play Store, if the crash report (Firebase Crashlytics) suddenly shows a spike in error rate, write out the steps you'd follow to investigate and respond. Task 4: For the requirement 'I want the app's location permission for just one feature (a nearby store finder), and I don't need background location', design the permission declaration/request flow.

Let's look at it together

text
# Task 2 - suspend fun vs Flow
One-time fetch (user profile) -> suspend fun
  (call once, get one result, done — Flow would be overkill)

Real-time updates (chat messages) -> Flow
  (many values over time, UI should auto-update as new
  messages arrive without a manual refresh call)

# Task 3 - crash-rate incident response
1. Check Firebase Crashlytics — which screen/exception type spiked?
2. Check recent release notes — did a new version just roll out?
3. Reproduce locally on the affected Android version/device if possible
4. If severe, consider a staged rollout halt or quick hotfix release
5. Document root cause once fixed, add a regression test
You should see
You'll come away with an MVVM layer design, a suspend-vs-Flow decision, a crash-rate incident response plan, and a scoped permission flow.

Try it in 5 minutes

Write Task 4's permission flow for location permission (`ACCESS_FINE_LOCATION`) yourself, following the same pattern as `CameraScreen` from the Intermediate chapter.

One thing to watch out for

Google Play reviews the background location permission (`ACCESS_BACKGROUND_LOCATION`) especially strictly — only request it when your app's core feature genuinely needs it, and be ready with a justification document.

Easy traps

  • Implementing real-time data (chat, live scores) with `suspend fun` plus manual polling (a timer that fetches repeatedly) — Flow/WebSocket is a much better fit
  • Not realizing that requesting an overly broad permission scope (background location, ACCESS_BACKGROUND_LOCATION) can get your app rejected in Play Store review

Now try it yourself

Write Task 4's permission flow for location permission (`ACCESS_FINE_LOCATION`) yourself, following the same pattern as `CameraScreen` from the Intermediate chapter.

You'll know it worked when: You'll come away with an MVVM layer design, a suspend-vs-Flow decision, a crash-rate incident response plan, and a scoped permission flow.

Practice Round 2 | Thuta Learning