လက်တွေ့ လေ့ကျင့်ခန်း အစုံ ၂

စိတ်လျှော့ပါ။ ဒီခန်းကို စာအုပ်လိုမဟုတ်ဘဲ စကားပြောသလိုပဲ၊ နားလည်လွယ်အောင် ရှင်းပါမယ်။

ခဏလေး ဒီလိုပဲ စဉ်းစားကြည့်

ဒီ round က round ၁ ထက် အဆင့်မြင့်ပါတယ် — skill တစ်ခုချင်းစီကို ခွဲစမ်းမယ့်အစား တစ်ခါတည်း ပေါင်းသုံးရမှာပါ။ App တစ်ခုအတွက် MVVM layer ဘယ်လို ခွဲသင့်လဲ ဆုံးဖြတ်ခြင်း, `suspend fun` (တစ်ကြိမ်တည်း result) vs `Flow` (data stream) ကို scenario အလိုက် ရွေးချယ်ခြင်း, Play Store publish ကို production document အနေနဲ့ ရေးဆွဲခြင်း — ဒါတွေ ပါဝင်ပါတယ်။ Task တစ်ခုကို ၁၀ မိနစ်ခန့် ယူပါ.

လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်

Task 1: Note-taking app (offline-first, cloud sync optional) တစ်ခုအတွက် MVVM layer (Data/ViewModel/UI) ကို ဒီဇိုင်းရေးပြီး, layer တစ်ခုစီရဲ့ responsibility ဘာတွေဖြစ်သင့်လဲ ရေးပါ။ Task 2: 'User profile data ကို တစ်ကြိမ်ပဲ fetch ချင်တယ်' vs 'chat message list ကို real-time update ချင်တယ်' ဆိုတဲ့ scenario ၂ ခုအတွက် `suspend fun` သုံးမလား `Flow` သုံးမလား ဆုံးဖြတ်ပြီး ဘာကြောင့်လဲ ရှင်းပါ။ Task 3: App တစ်ခု Play Store မှာ publish လုပ်ပြီးနောက် crash report (Firebase Crashlytics) မှာ error rate ရုတ်တရက် တက်လာရင် ဘယ် step အစီအစဉ်နဲ့ investigate/response လုပ်မလဲ ရေးပါ။ Task 4: 'App ရဲ့ location permission ကို feature တစ်ခုတည်းအတွက်ပဲ (nearby store finder) သုံးချင်တယ်, background location မလိုချင်ဘူး' ဆိုတဲ့ requirement အတွက် permission declaration/request flow ကို ဒီဇိုင်းရေးဆွဲပါ။

MVVM layer responsibility ကို app requirement အလိုက် ဒီဇိုင်းရေးတတ်ပြီ
suspend fun vs Flow ကို scenario အလိုက် မှန်ကန်စွာ ရွေးချယ်တတ်ပြီ
Crash-rate incident response plan နှင့် scoped permission flow ရေးဆွဲထားပြီ

အတူတူ ကြည့်မယ်

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

MVVM layer design, suspend-vs-Flow ဆုံးဖြတ်ချက်, crash-rate incident response plan နှင့် scoped permission flow ရရှိလာမည်။

၅ မိနစ် စမ်းကြည့်

Task 4 ရဲ့ permission flow ကို `CameraScreen` (Intermediate chapter) ရဲ့ pattern အတိုင်း location permission (`ACCESS_FINE_LOCATION`) အတွက် ကိုယ်တိုင် ရေးကြည့်ပါ။

သတိလေးတစ်ချက်

Background location permission (`ACCESS_BACKGROUND_LOCATION`) ကို Google Play က အထူး strict review လုပ်ပါတယ် — app ရဲ့ core feature အတွက် တကယ်လိုအပ်မှသာ တောင်းဆိုပါ၊ justification document ပါ ပြင်ဆင်ထားရပါမယ်။