Mobile/Frontend Developer တစ်ယောက်အနေနဲ့ မေးသင့်သောမေးခွန်းများ

Introduction

ကျွန်တော် ဒီအကြောင်းအရာလေးကို ဒီနှစ် VarCamp မှာ ပြောမယ်လို့ စာရင်းပေးခဲ့ပါတယ်။ ဒါပေမယ့်လည်း အကြောင်းအမျိုးမျိုးကြောင့် ဒီနှစ်မပြောဖြစ်ခဲ့ပါဘူး။ ပြောမယ့်အကြောင်းအရာတွေအများကြီးထဲကမှ ဒီအကြောင်းအရာလေးကို မပြောဖြစ်ပေမယ့်လည်း article လေးတစ်ပုဒ်လောက်ရေးပြီး မျှဝေလိုက်ရပါတယ်။ ဒီ topic က မြန်မာ developer တွေအတွက်ရည်ရွယ်တာကြောင့်မို့လို့ မြန်မာလိုပဲဆက်ရေးသွားပါမယ်။

Input Field

Design မှာ text box ပဲဖြစ်ဖြစ် user ရိုက်ထည့်လို့ရတဲ့ input field တစ်ခုပါပြီဆိုတာနဲ့ အနည်းဆုံးခေါင်းထဲမှာ အခြေအနေ လေးမျိုး တွေးဖို့လိုတယ်။

Input မထည့်ရသေးခင် neutral state
Input ရိုက်ထည့်ဖို့ cursor ချလိုက်တဲ့အချိန် active state
Input ထည့်ပြီး validate တော့မှ မှားသွားလို့ပြရမယ့် error state
တစ်ချို့သောအခြေအနေတွေမှာ hit testing ပိတ်ထားရမယ့် disable state

ဆိုပြီး အခြေအနေ အနည်းဆုံးတော့လေးမျိုးရှိတယ်။ အဲ့တော့ ပေးထားတဲ့ design file မှာ အဲ့လေးမျိုးပါပြီလား မပါဘူးဆိုရင် ပြန်မေးဖို့လိုတယ် အမြန်ဆုံး ပေးဖို့လိုတယ် app တစ်ခုလုံးကို ဒီ state တွေနဲ့ UI က share သုံးသွားရဖို့ရှိတဲ့အတွက် ဖြစ်နိုင်ခြေရှိတဲ့ state တွေ၊ ပုံမှန်ဆိုရင်တော့ လေးခုပေါ့နော် အဲ့တာတွေကို ရှင်းရှင်းလင်းလင်းသိပြီးမှ နောက်ပြန်သုံးရလွယ်အောင် အချိန်ယူရေးသွားရင် နောက်ကျ အချိန်ကုန်သက်သာပါတယ်။

Form Validation

Input field တွေပါလာပြီဆိုကတည်းက user ကိုဖြည့်ခိုင်းတဲ့ form တစ်ခုရှိလာပြီလို့ ယူဆရမှာပေါ့။ အဲ့တော့ form ရှိပြီဆိုရင် အဲ့ form က အမြဲ valid ဖြစ်နေမှာလား invalid ရောရှိနိုင်သလားပေါ့။ ဆိုကြပါစို့ form က valid နဲ့ invalid ဆိုပြီး အခြေအနေနှစ်မျိုးရှိနိုင်တယ်ပေါ့။ အဲ့အချိန်မှာစဥ်းစားရမှာက

invalid ဖြစ်သွားရင် input field တွေကိုပါ error state နဲ့ပြမှာလား
တစ်ကယ်လို့ invalid ဖြစ်တာနဲ့ input field ကို error state နဲ့ ပြမယ်ဆိုရင် ဘယ်အချိန်မှာ validate လုပ်မလဲ? Key stroke တစ်ခုစီတိုင်းလိုက် validate မှာလား CTA (call to action) button လို့ခေါ်တဲ့ နောက်တစ်ဆင့်ကိုဆက်ခေါ်သွားမယ့် button ကိုနှိပ်မှ validate လုပ်မှာလား စသဖြင့်
ဒါမှမဟုတ် valid ဖြစ်တော့မှ CTA button ကို enable လုပ်ပြီး invalid ဖြစ်ရင် disable လုပ်မလား (ဒါဆို input state က error ပြစရာမလိုဘူး များသောအားဖြင့်)

အဲ့သုံးချက်ကို design ပေးထားတာမှာပါသလား မပါရင် ပြန်မေးရမယ်။ ပြောချင်တာက form မြင်ပြီဆိုရင် validation ဘယ်အချိန်စစ်မလဲ valid ဖြစ်ရင်ဘာလုပ်မလဲ invalid ဖြစ်ရင်ဘာလုပ်မလဲ ဘယ် field က optional လည်း ဘယ်ကောင်က mandatory လဲ စသဖြင့် ဆန်းစစ်ပြီး မေးခွန်းထုတ်တတ်ရမယ်။

Listing

App တိုင်းက list နဲ့မကင်းဘူး။ Horizontal list တွေလည်းရှိတယ်။ Vertical list တွေလည်းရှိတယ်။ List မြင်ပြီဆိုရင် စစ်ရမယ့် ဂရုပြုရမယ့်အရာ ၄ ခု ရှိတယ်။

List ထဲမှာ item တစ်ခုမှမရှိရင် ဒါမှမဟုတ် API fail ခဲ့ရင် ဘာပြမလဲ? Empty state အတွက် UI ရှိပြီလား? ဒါမှမဟုတ် cache ထဲကဆွဲပြမှာလား?
အဲ့ list က see more ရှိလား? ရှိခဲ့ရင် အများဆုံး ဘယ်နှစ်ခုပြမှာလဲ?
See more မရှိခဲ့ရင် ဒီ list က pagination ရှိမှာလား? Pagination UI ကရော ဘယ်လိုဖြစ်မှာလဲ?
List ကို pull to refresh (mobile မှာတော့ ပိုတွင်ကျယ်တာပေါ့) လုပ်လို့ရမှာလား?

ဒါက ကျွန်တော်မှတ်မိသလောက်ပြောတာ။ ကိုယ့် app ရဲ့ business logic အပေါ်မူတည်ပြီး ဒီထက်ပိုများဖို့သာရှိတယ်။ ပိုနည်းဖို့မရှိဘူး။

Loading style

API call တွေ ခေါ်ရပြီဆိုရင် user ကို loading ပြရမယ်။ ကောင်းပြီ။ ဒီလိုဆိုရင် ဘယ်လို loading ပြမှာလဲ?

App-wide overlay နဲ့ loading spinner ပြမလား?
ဒါမှမဟုတ် shimmering view (skeleton view) နဲ့ပြမှာလား?
ဒါမှမဟုတ် တစ်ချို့ view တွေကို loading ပြပြီး တစ်ချို့ view တွေကို shimmer view ပြမှာလား?
Loading ကို button တစ်ခုခုနဲ့ user ကို cancel ခွင့်ပေးမှာလား?

အဲ့လို loading ပြမယ့် style အပေါ်မူတည်ပြီး mobile သမားတွေအတွက် ဆင့်ပွားစဥ်းစားစရာ နှစ်ခုရှိလာပြန်တယ်။ Interactive နဲ့ non-interactive loading လို့ခေါ်ကြစို့။ Interactive ဆိုတာဘာလဲဆိုတော့ loading ပြနေချိန်မှာ user က app ကို interact လုပ်နေလို့ရတယ် tab selection change တာ back ပြန်ထွက်တာ လုပ်လို့ရတယ်။။ App-wide overlay ကြီးနဲ့ UI ကို block ပြီးပြတာမဟုတ်ဘူးပေါ့ဗျာ။ Non-interactive ကျ သူနဲ့ပြောင်းပြန် loading လည်နေတဲ့အချိန် app ကို quit တာမှတစ်ပါး တစ်ခြား UI element တွေကို ဘာမှ interact လုပ်လို့မရဘူး။ Android မှာ back indicator ပါသေးတဲ့ဖုန်းတွေဆိုရင် back stack ကို pop လို့တော့ရဦးမယ်ပေါ့။ အဲ့လို interactive နဲ့ non-interactive ပေါ်မူတည်ပြီး ထိန်းရမယ့် state တွေလည်းများတယ်။ Non-interactive ဆိုရင် user က တစ်ခြား screen ကိုသွားတာပဲဖြစ်ဖြစ် back ပြန်ထွက်တာပဲဖြစ်ဖြစ် လက်ရှိ in flight ဖြစ်နေတဲ့ asynchronous operation တွေအကုန်လုံးကို cancel လုပ်ပစ်ဖို့လိုတယ် မဟုတ်ရင် background မှာ မလိုအပ်ပဲ computing resource တွေကုန်သလို တစ်ခါတလေ bug တွေပါတက်တတ်တယ်။

Error alert

App တိုင်းကတော့ error ဖြစ်တဲ့ အခြေအနေရှိိနိုင်တာပဲ။ User ရဲ့ အမှားကြောင့် error ပြရနိုင်သလို API fail လို့လည်း error ပြရနိုင်တယ်။ အဲ့တော့ ကြိုမေးထားဖို့လိုတာက

App အစကနေအဆုံး error style က တစ်မျိုး တည်းပြမှာလား (native alert/modal ဆိုလည်းဖြစ်တယ် ဒါမှမဟုတ် Toast လိုကောင်မျိုးလား)
ဒါမှမဟုတ် တစ်ချို့နေရာတွေမှာ toast တစ်ချို့နေရာတွေမှာ native modal dialog နဲ့ပြ အဲ့လိုမျိုးလား
Error state ကို ပုံစံတစ်မျိုးထက်ပိုပြီးပြမယ်ဆိုရင် ထပ်စဥ်းစားရမှာက ဒီ error သည် server ဘက်ကလာတာကို ပြန်ပြရတာမျိုးဖြစ်နိုင်တယ်။ ဒါဆိုရင် server ဘက်ကလာတဲ့ response မှာ error style ကိုပါ ပြန်လာပေးရတော့မယ်။ အဲ့တစ်ချက်လည်းထည့်တွက်ရမယ်။ Error style စဥ်းစားရာမှာလည်း ထားပါတော့ အခုလက်ရှိက error UI style က နှစ်ခုပဲရှိလို့ true/false ပဲပြန်မယ် မလုပ်ရဘူး နောက်တစ်မျိုးထပ်ပိုလာရင် true/false အပြင် ထပ်မရှိတော့ဘူး အဲ့တော့ ပိုသေချာအောင် enum/const သုံးသင့်တယ်။

Scrollable container

Mobile သမားတွေအတွက် ပိုပြီး relevant ဖြစ်တယ်။ Login screen လေးပဲဖြစ်ဖြစ် onboarding screen ပဲဖြစ်ဖြစ် ဘယ် screen မဆို screen တစ်ခုကိုမြင်တာနဲ့ ဒီကောင်က scrollable ဖြစ်သလား မဖြစ်ဘူးလား တစ်နည်းပြောရရင် သူ့ content က device အမျိုးမျိုးရဲ့ size အပေါ်မူတည်ပြီး scroll လို့ ရမှာလား မရဘူးလား စဥ်းစားဖို့လိုတယ်။ UI က scroll စရာမလိုတဲ့ပုံစံ ဆွဲထားရင်တောင် ကိုယ့်ဘက်ကချင့်ချိန်ပြီး မေးသင့် မေးရမယ်။ တစ်ကယ်လို့ content က user generated ဖြစ်ရင် (CMS ဘက်ကလာတဲ့ long description မျိုး) ဆိုရင် အရှည်ကြီးလည်းလာနိုင်တာမို့ scroll ရဖို့များတယ်။ အဲ့လိုဆိုရင် scroll ဆွဲတဲ့အခါ လက်ရှိ navigation bar က ဘယ်လိုဖြစ်မှာလဲ အရောင်တစ်မျိုးပြောင်းမှာလား ဘာအရောင်မှမပြောင်းဘူးလား စသဖြင့် မေးခွန်းထုတ်ရမယ်။

Text formatting

Text ဆိုတာမှာတော့ အမျိုးမျိးရှိတယ်။ ဒီမှာတော့ plain text, price, decimal points, duration, date ဆိုပြီး ခွဲပြောသွားမယ်။

Plain text

ခေါင်းစဥ်ပဲ ဖြစ်ဖြစ် စာသားပဲဖြစ်ဖြစ် မေးစရာလေးတွေရှိတယ်။

ခေါင်းစဥ်က design မှာဆွဲပေးထားတုန်းကတော့ တစ်ကြောင်းတည်း။ နောက်ပိုင်း text က ရှည်သွားလို့ တစ်ကြောင်းထက်ပိုလာရင်ရော wrap မှာလား trim မှာလား? Trim မယ်ဆို ဘယ်နှစ်ကြောင်းကနေစပြီးတော့ trim မှာလဲပေါ့။
Body text ဆိုရင် read more/read less ရှိနိုင်လား? ရှိခဲ့ရင်တော့ max ဘယ်နှစ်ကြောင်းက စပြီး ဖြတ်မလဲ trim မလဲပေါ့
နောက် multiple language support လုပ်ရတဲ့ app တွေ (ဘာသာစကား ပြောင်းလို့ရတဲ့ app) မှာဆိုရင် design ကတော့ english နဲ့ပေးမှာပေမယ့်လို့ ဘာသာစကားပြောင်းလိုက်တဲ့အခါ မလှတော့တာတွေ layout ပျက်သွားတာတွေဖြစ်နိုင်လို့ ကြိုသတိပေးဖို့လိုမယ်။ တစ်ခါတလေကျ “Back” လို တိုတိုတုတ်တုတ်ကလည်း ဘာသာပြန်လိုက်လို့ အရှည်ကြီးဖြစ်သွားတဲ့အခါ ပြသနာတက်နိုင်တာမျိုးကိုး

Price

စျေးနှုန်းတွေကို format နဲ့ပြမယ်ဆိုရင် တအားဂရုစိုက်ရမယ်။

မြန်မာနိုင်ငံမှာ ဒဿမကိန်း ကျပ် ပြား စျေးနှုန်းမရှိပေမယ့် နိုင်ငံတကာမှာ ဒဿမနောက်က ဂဏန်းတွေကလည်း ဂရုစိုက်ရတယ်။ ဘယ်တော့မှ ကိုယ့်သဘောနဲ့ကိုယ် ဒဿမတစ်နေရာယူပြတာတို့ နှစ်နေရာယူပြတာတို့ round တာတို့ ceiling up/down လုံးဝမလုပ်ရဘူး တအားထိလွယ်ရှလွယ်ကိစ္စမျိုး ဒါမျိုးဆို app တစ်ခုလုံးမှာ ဘယ်လိုပြမလဲ ဒါမှမဟုတ် အဲ့လို format ဘယ်နှစ်ခုရှိနိုင်သလဲ တစ်ခါတည်း ဟိုးအစကတည်းက မေးထားရမယ် မမေးရင် ပြသနာတွေအများကြီး ရှင်းရဖို့ရှိတယ်။
နောက် price ရဲ့နောက်က currency symbol ကို long form လား short form လား ရှေ့မှာပြမလား နောက်မှာပြမလား ဘယ်အချိန်ဆိုရှေ့မှာပြပြီး ဘယ်အချိန်ဆိုနောက်မှာပြမလဲ ကြိုမေးထားသင့်တယ် ဒါဆို component တွေကို အဲ့တာတွေနဲ့ကိုက်ပြီးရေးသွားရင် နောက်မှားစရာနေရာမရှိတော့ဘူးပေါ့။

Decimal Points

ဒါကတော့ user ရဲ့ progress လိုကောင်မျိုးတွေ သူ့ redeem point လိုကောင်မျိုးတွေ ဒါတွေကိုရော ဒဿမရှိသလား ရှိခဲ့ရင်ရော ဘယ်လို format နဲ့ပြမှာလဲ မေးကြဖို့ပေါ့။

Duration

တစ်ခါတလေ ကိုယ့် app မှာ ကြာချိန် duration ကို ပြဖို့လိုလာတယ်။ အဲ့လိုအခါကျလည်း app ရဲ့ nature အပေါ်မူတည်ပြီး ကွဲပြားတာလေးတွေရှိတယ်။ ဥပမာ ကိုယ်က video app ဆို နာရီနဲ့ချီတာရှိတယ်။ အဲ့တာဆို ၁ နာရီ၊ ၁၅ မိနစ်၊ ၃၀ စက္ကန့် ဆိုတာမျိုးက make sense ဖြစ်တယ်။ အဲ့တော့ duration ကို hour:minute:second နဲ့အမြဲပြမှာလား ဒါမှမဟုတ် second ပဲရှိရင် second ပဲပြ minute ရှိမှ minute:second ပြ အဲ့လို တိုးသွားတဲ့ပုံစံမျိုးလား စသဖြင့် ဘယ်လိုတွက်ပြီး ဘယ်လိုပြမလဲ ထုံးစံအတိုင်း အဲ့လိုတွက်တာ/ပြတာကရော app မှာ ပုံစံဘယ်နှစ်မျိုးရှိနိုင်မလဲ ကြိုပြီး သိထားဖို့လိုအပ်တယ်။ ဒါမှ ကြိုပြီး ပြင်ဆင်ထားရင် နောက်လူက ကိုယ့် code ယူသုံးတာနဲ့ မှန်သွားတာမျိုး ဖြစ်မှာ။

Date

Date ဆိုတာကလည်း သိတဲ့အတိုင်း

12 hr format နဲ့ပြမှာလား 24 hr format နဲ့ပြမှာလား
ဒါမှမဟုတ် UTC time တစ်ခါတည်းပြမလား ဒါမှမဟုတ် user ရဲ့ ဒေသစံတော်ချိန်အပေါ်မူတည်ပြီးပြမလား
နောက်တစ်ခါ API ဘက်ကလာရင် ဘယ် format နဲ့လာမလဲ? server ကိုပြန်ပို့ရရင်ရော ဘယ် format နဲ့ပြန်ပို့ရမလဲ? ဒါတွေပေါ့။

ဒါလည်း mobile ရဲ့ ပြသနာတစ်ခုပဲ။ Screen တစ်ခုကနေ နောက်တစ်ခုကိုပြောင်းတဲ့အခါ ဘယ်လို transition နဲ့ပြောင်းမလဲပေါ့

Drill down လား (Screen အသစ်က ညာဘက်ကနေ ဘယ်ဘက်ကို slide in ဖြစ်ပြီး ဝင်လာတာမျိုး)
Sheet လား (Screen အသစ်က အောက်ကနေ အပေါက်ို တက်လာပြီး အပြည့်မတက်ဘဲ float နေတာမျိုး) အဲ့တာမျိုးဆို swipe down လုပ်လိုက်ရင် dismiss ဖြစ်သွားတယ်
Full screen sheet လား (sheet အတိုင်းပဲ၊ ဒါပေမယ့် float မဖြစ်ဘဲ screen အပြည့်ကိုဖုံးသွားတာမျိုး swipe down လုပ်ပြီးလည်း dismiss လို့မရဘူး)
Modal dialog လား (ဒါကတော့ ရှင်းပါတယ်။ Overlay နဲ့ dialog လေးတစ်ခုတက်လာတာမျိုးပေါ့) ဥပမာ Delete လုပ်လိုက်လို့ confirmation dialog တက်လာတာမျိုး

ထပ်စဥ်းစားရမှာက ဒီ screen တစ်ခုက အပေါ်ကပြောခဲ့တဲ့ transition တွေထဲက တစ်ခုနဲ့ပဲ အမြဲလာနိုင်လား ဒါမှမဟုတ် context (အခြေအနေ) အပေါ်မူတည်ပြီး drill down လည်းဖြစ်နိုင်သလို sheet လည်းဖြစ်နိုင်တာမျိုးလား?

Search bar

Search bar ပါရင် အခြေအနေတွေက အမျိုးမျိုးရှိနိုင်တယ်။

Search bar ကို nav မှာထားရင် scroll up လုပ်တဲ့အခါ ဘယ်လိုဖြစ်မလဲ? Scroll down လုပ်တဲ့အခါ ဘယ်လိုဖြစ်မလဲ?
Search bar က fold ဖြစ်နေတာဆိုရင် သူ့ကို နှိပ်လိုက်လို့ expand ဖြစ်သွားရင်ဘယ်လိုဖြစ်မလဲ? အဲ့ state က အပေါ်က scroll up/down အပေါ်မူတည်ပြီးရောပြောင်းနိုင်လား?
Search bar က active ဖြစ်သွားရင် search result ကိုဘယ်လိုပြမှာလဲ? နောက် screen တစ်ခုကိုသွားပြီးပြမှာလား? ဥပမာ Grab mobile app မှာဆို home screen က search bar က button သာသာပဲ သူ့ကိုနှိပ်ရင်နောက် screen ကို drill down လုပ်သွားပြီး အဲ့မှာမှ search လို့ရတာ။
Search result က no result ဆို ဘယ်လိုပြမလဲ? Search bar ထဲမှာ query text တစ်ခုမှရိုက်မထည့်ရသေးခင် empty ဖြစ်နေတဲ့အချိန် default state မှာ ဘာတွေပြမှာလဲ?

State Management in Large Flow

State management ဆိုတာတော့ FE dev တိုင်းရဲ့ ပြသနာတစ်ခုပါပဲ။ တစ်ကယ်လို့ app heavy flow တစ်ခုကို လုပ်နေတယ်ဆိုပါစို့။ Step 1, 2, 3 ဆိုပြီး screen သုံးခုရှိမယ်ဗျာ။ ထားပါတော့ user က step 2 လောက်ကနေ ဆက်မဖြည့်တော့ဘဲနဲ့ ဟိုးရှေ့ဆုံးကိုပြန်ထွက်မယ်ပေါ့။ အဲ့တာဆိုရင်

Step 2 အထိ data က cache ထားမှာလား? ဖျက်ပစ်မှာလား?

User က Step 2 ကိုဖြည့်ပြီး back ပြန်ထွက်တယ် Step 1 ကိုသွားတယ်ဗျာ။ ဟိုးရှေ့ကိုမထွက်သေးဘူး။ အဲ့တာဆိုရင်ရော Step 1 ကနေ 2 ကိုပြန်သွားရင်ရော

Step 2 data က cache ထားမှာလား? ဖျက်ပစ်မှာလား?

တစ်ကယ်လို့အဖြေက cache မယ်ဆိုရင်

ဘယ်အချိန်မှာဖျက်မှာလဲ? အမြဲမှတ်ထားမှာလား?

ထားပါတော့ အဲ့ step 3 အထိပြီးသွားလို့ summary screen မှာ edit ထပ်လုပ်ခွင့်ပေးထားတယ်ဆိုပါစို့။ အဲ့တာဆိုရင်ရော

edit လုပ်လိုက်တဲ့ state က source of truth ဖြစ်နေမှာလား? ဆိုလိုတာက summary screen မှာ step 2 ကို update လုပ်လိုက်တယ်ဆိုပါစို့။ အဲ့တာဆို back ပြန်ထွက်ပြီး step 2 ကိုသွားတဲ့အချိန်မှာ summary က update လုပ်လိုက်တာကိုပြမလား? step 2 ရဲ့ မူလ data ကိုပြမလား?
Summary screen ကနေ back ပြန်ထွက်ရင်ရော step 1, 2, 3 က data တွေကို မှတ်ထားမှာလား ဖျက်မှာလား?

Logout flow

App တစ်ခုကို logout ထွက်ပြီဆိုတာနဲ့ ဘယ် data တွေမှတ်ထားမလဲ ဘယ် data တွေ ဖျက်ပစ်ရမလဲ စဥ်းစားထားရမယ်။ ဥပမာ access token လို refresh token လိုကောင်မျိုးတွေ ထားရမလား ဖျက်ပစ်ရမလားပေါ့။

Others

App orientation က portrait mode တစ်ခုတည်းလား landscape mode ရော support ပေးမှာလား?
UI က light mode တစ်ခုတည်းလား dark mode ရော support လုပ်ရမှာလား?
Dynamic text scaling ရော support လုပ်မှာလား? ဆိုလိုတာက user က phone settings မှာ font ကို increase/decrease လုပ်ထားရင် ကိုယ့် app က အဲ့တာကို respect ဖြစ်ပြီး လိုက် scale လုပ်ပေးတာမျိုး

API call

UI နဲ့မဆိုင်ပေမယ့် api call နဲ့ပတ်သက်ပြီး နည်းနည်း တွေးစရာလေးတွေ ပြောပြဦးမယ်။

Api call ကို တစ်ခေါက်ပဲခေါ်မှာလား ဒီ screen ကိုဖွင့်တိုင်း ခေါ်နေမှာလား?
Screen တစ်ခုမှာ api သုံးကြောင်း လေးကြောင်းခေါ်ဆို parallel ခေါ်မလား တစ်ခုပြီးမှတစ်ခုခေါ်မလား?
User action တွေကို api ခေါ်တဲ့အခါ optimistic UI update သုံးသင့်/မသင်? ဥပမာ +/- button ရှိတယ် + နှိပ်ရင် API ခေါ် api က +1 ပေါင်းပြီး result ပြန်ပေါ့ အဲ့တာမျိုးဆိုရင် API ခေါ်တဲ့ loading စောင့်မနေဘဲနဲ့ + နှိပ်တာနဲ့ UI မှာ ကိုယ့်ဘာသာတစ်တိုးပြီး API ကိုနောက်ကွယ်ကခေါ် API success ဖြစ်ရင် ဘာမှမလုပ်နဲ့ fail သွားရင် previous value ကို fall back ပြန်လုပ်တာမျိုးပေါ့။ မလိုအပ်ဘဲ user ကို loading မပြဘူး user exprience ကောင်းအောင်လုပ်တဲ့ဟာမျိုး အဲ့တာကို optimistic rebound/ui update လို့ခေါ်သဗျ။
API တွေကို frontend ဘက်က rate limit ထိန်းတာ။ Server ဘက်ကလည်း ထိန်းတာပေမယ့် တစ်ခါတလေ ကိုယ်က စျေးကြီးတဲ့ 3rd party SDK တွေသုံးနေရတယ် ဟို SDK ဘက်ကလည်းထိန်းမထားဘူးဆို ကိုယ့်ဘက်က network တစ်ကြောင်းလွှတ် တစ်ခါ ပိုက်ဆံကုန်မယ်။ အဲ့တာမျိုးဆို exponential back off တို့ circuit breaker တို့ကို ကိုယ့်ဘက်က လုပ်သင့်လုပ်ရမယ်။
Circuit breaker နဲ့တစ်ဆက်တည်းပြောချင်တာက retry strategy လည်းစဥ်းစားရမယ်။ ဘယ်နှစ်ခါ retry မှာလည်း။ တစ်ခါနဲ့တစ်ခါကြား ဘယ်လောက် interval တိုးမှာလဲ။ ဒါမှမဟုတ် user က retry လုပ်ခိုင်းမှထပ်ခေါ်မှာလားပေါ့။
API fail ပြီဆိုရင် fallback UI ရှိရမယ်။ Home screen လိုကောင်မျိုးမှာ မတော်တဆ API fail လို့ ဘာမှပြစရာမရှိရင်လည်း ကြည့်ရဆိုးတယ်။ ဒါမျိုးဆို ဘယ်လိုတွေပြမလဲ ကြိုတိုင်ပင်ထားသင့်တယ်။ ဟိုဘက်က UI မထုတ်ပေးတောင် ကိုယ့်ဘက်ကတော့ issue raised ခဲ့တယ်ဆိုတာမျိုး record ကျန်ရင် ကောင်းတာပေါ့။
နောက်တစ်ခါ poor network connection မျိုးတွေ offline တွေမှာ ဘာလုပ်မလဲဆိုတာလည်းစဥ်းစားရမယ်။ ကိုယ့် app က offline support လိုလား network ရှိမှ လုပ်လို့ရမှာမျိုးလား လိုင်းမရမချင်း ဆက်တိုက် refresh လုပ်နေမှာလားပေါ့။ နောက်တစ်ခါ လိုင်းကျနေတဲ့အခါမျိုးမှာ download task ရှိရင် resume/cancel ဘယ်လိုလုပ်မလဲ တွေးဖို့လည်းလိုသေးတယ်။ iOS မှာတော့ အခုနောက်ပိုင်း resume/cancel လုပ်ရတာ တအားလွယ်သွားပြီ။

Outro

ဒါတွေကတော့ ကျွန်တော်ကြုံရ ပြသနာတက်ရတဲ့ frontend issue တွေကို နောက်လူတွေအချိန်မကုန်စေဖို့ စောစော identify လုပ်ပြီး စောစောရှင်းနိုင်အောင် စုပေးထားတာပါ။ ကျွန်တော်ကျန်ခဲ့တာလည်းရှိနိုင်တာပေါ့။ တစ်ချို့က common sense လို့ပြောပေမယ့် ကျွန်တော်ကတော့ တစ်ချို့အရာတွေက domain knowledge လည်းလိုတယ်လို့ ထင်ပါတယ်။