mVoter 2020 Backstage #2: App Update Mechanism

ကျွန်တော်ဒီ Blog Post Series လေးမှာ ကျွန်တော်တို့ မြန်မာနိုင်ငံရဲ့ ၂၀၂၀ အထွေထွေရွေးကောက်ပွဲအတွက် တိကျမှန်ကန်တဲ့အချက်အလက်တွေပေးနိုင်ဖို့ ဖန်တီးခဲ့တဲ့ mVoter 2020 Android App လေးထဲက Tech Stack တွေ အကြောင်းရယ်၊ ဘာလို့ဒီ Tech Stack တွေကိုရွေးချယ်ခဲ့တယ်ဆိုတာကို စာဖတ်သူတွေလည်း ဗဟုသုတရအောင် မျှဝေပေးသွားပါမယ်။ ဒီအပိုင်းမှာ App က အသစ်ထွက်ထားတယ်ဆို update ရှိကြောင်း ပြောလို့ရအောင် လုပ်ထားတဲ့ နည်းလမ်းလေးကို ရှင်းပြပေးမယ်။

တစ်ခြားအပိုင်းတွေဖတ်ချင်တယ်ဆို

#1- Conductors

#3- Test of Time

ကျွန်တော်တို့လိုချင်တဲ့ ပုံစံက

• Update ထွက်တိုင်း အသစ်ရှိကြောင်း User ကို ပြောပေးရမယ်
• ပြတဲ့ပုံစံက မဖြစ်မနေလုပ်ရမဲ့ forced update (ဉပမာ breaking changes တွေ critical bug တွေပြင်ထားတာမျိုး)၊ နဲ့ မလုပ်လည်း ကျော်သွားလို့ရတဲ့ flexible update (ဉပမာ စာလုံးပေါင်းလေးမှားလို့ ပြင်ထားတာမျိုး) ဆိုပြီး နှစ်မျိုးရှိမယ်

ဒီတော့ Android App ဆိုတဲ့အတိုင်း Google Play ရဲ့ In-App Update API ကိုသုံးဖို့ကြည့်ကြတယ်။ ကျွန်တော်တို့လိုချင်တာလည်း ဒါမျိုးပဲ၊ သူ့မှာလည်း forced update နဲ့ flexible update ဆိုပြီးရှိမယ်။ Functionality အရကြည့်ရင် ကွက်တိပဲ၊ ဒါပေမဲ့ ပြဿနာက ဘယ်မှာဖြစ်လဲဆိုတော့ တစ်ချို့ တရုတ်ဖုန်းတွေမှာ Play Store မရှိဘူး။ ဒီ user တွေက update ရှိတာသိမှာမဟုတ်တော့ဘူး။ ပိုဆိုးတာက vendor lock-in မဖြစ်ချင်ဘူး။ vendor lock-in ဆိုတာက Play Store ကိုအရမ်းမှီခိုထားတော့ Play Store က ကျွန်တော်တို့ App ကို ban လိုက်တယ်ဆို အဲမှာပြီးသွားပြီ၊ ဘာမှ ဆက်လုပ်လို့မရတော့ဘူး။ ဒီတော့နောက်တစ်မျိုး ကြံကြည့်ရအောင်။

Firebase Remote Config ဆိုရင်ကော? Config မှာ ကျွန်တော်တို့ နောက်ဆုံး version_code လေးကို မှတ်ထားပြီး၊ force ဟုတ်မဟုတ် boolean လေးသိမ်းထားရင်ကော? ဒါဆိုရင် များသာအားဖြင့် အဆင်ပြေတယ်။ ဒါပေမဲ့ ပြဿနာ တစ်ခုရှိနေပြန်ကော၊ အဲဒါကဘာလဲဆိုတော့ ကျွန်တော်တို့ Version 1,2,3 ရှိမယ်ဆိုပါဆို့

• 1က User ရဲ့ဖုန်းထဲမှာရှိတယ်။
• 2 က forced update လုပ်ထားတယ်
• 3 က flexible update ဆိုပါဆို့

ကျွန်တော်တို့က latest_code ကိုပဲသိမ်းတော့ 2 ရောက်နေတဲ့သူအဖို့ 3 က flexible ဆိုတာမှန်ပေမဲ့ 1 ရောက်နေတဲ့သူကျ နောက်ဆုံး version 3 က flexible ဆိုတာမှားနေတယ်။ သူက အလယ်မှာရှိတဲ့ forced update တွေအကုန်လုံးကို ကျော်သွားသလိုဖြစ်နေတယ်။ ကျွန်တော်တို့ စစ်ချင်တဲ့ update လုပ်သင့်မလုပ်သင့် logic က pesudocode နဲ့ဆိုဒီလိုဖြစ်မယ်။

step 1 : let user_version= user's app version
step 2 : let all_newer_versions = list of all versions that's greater than x
step 3: let require_forced = false
step 4: for all version in all_newer_version, do step 5
step 5: if version has forced_update set to true, then go to step 6, else do nothing
step 6: return property of latest version in all_newer_version togetherwith required_forced value

Remote Config ကဒီလိုမျိုးရေးလို့မရဘူး။ ဆိုတော့ အဲဒါကလည်း အဆင်မပြေပြန်ဘူး။

ဒါနဲ့ ကျွန်တော်တို့ Firebase Cloud functions ကိုကြည့်ဖြစ်တယ်။ သူက function လေးကိုရေးပြီး API endpoint ထုတ်ထားပေးလို့ရတယ်။ ဒါနဲ့ဆိုရင် ကျွန်တော်တို့လိုသချင်သလို Logic ရေးလို့ရပြီ။ ချဲ့ချင်ရင်လည်းချဲ့လို့ရတယ်။ အပေါ်က pesudocode ကို ပိုချဲ့ချင်တယ်ဆို version အလိုက်ထွက်တဲ့ timestamp လေးမှတ်၊ ဘယ်နရက် ကြာသွားတဲ့ version ဆိုရင်တော့ update လုပ်ကိုလုပ်ကမယ်သတ်မှတ်လို့ရတယ်။ update တစ်ခုနဲ့တစ်ခုကြား ဘယ်လောက်ပဲ flexible ဖြစ်ပါစေ၊ version သုံးဆင့်ထက်ပိုခြားခွင့်မပေးဘူးစသဖြင့် ကြိုက်သလိုကို ပြောင်းနေလို့ရတယ်။ ဒီတော့ extensible လည်းဖြစ်တယ်၊ ကိုယ့် logic ကိုယ်တိုင် ကြိုက်သလို စီစဉ်လို့ရတယ်။ Cloud function ကိုတော့ Kaung Myat Lwin က တာဝန်ယူပြီးရေးထားပေးတယ်။

PopStackHack/mvoter-cloud-funcs

This repo contains code for updating and deploying mechanism for mVoter 2020 mobile applications. This is open sourced…

github.com

Client side မှာ ကျွန်တော်တို့က data ကိုဒီလိုလေးယူလိုက်တယ်။

version_code: integer
is_force_update: boolean
playstore_link: string
self_host_link: string

အရင်ဆုံး server ပေါ်ကပြန်လာတဲ့ version_code က ဖုန်းပေါ်က version_code က ထက်ကြီးသလား စစ်လိုက်တယ်။ မကြီးဘူး ဆိုရင် ဒါဘာမှလုပ်စရာမလိုဘူး။ ကြီးနေတယ်ဆိုရင် update ပြဖို့ play store ရှိမရှိကိုကြည့်ပြီး ရှိရင် playstore_link ကိုသုံးတယ်။ မရှိရင် self_host_link ကိုသုံးထားတယ်။ တကယ်လို့ အပေါ်ကပြောခဲ့သလို play store ကြီးက ban လိုက်ပါတယ်ဆိုရင်တောင် cloud function ပေါ်မှာ playstore_link နေရာမှာ self_host_link ကိုပြောင်းလိုက်လို့ရတယ်။ ဒါဆိုရင် ရှိပြီးသား user တွေကိုလည်း ဆက်ပြီး update တွေပေးနေလို့ရမယ်။ Play store မှာလည်း vendor lock-in မဖြစ်တော့ဘူး။ force_update ဆိုရင်တော့ မဖြစ်မနေကို လုပ်ခိုင်းတယ်၊ flexible ဆိုရင် Bottom Sheet လေးနဲ့ပြမယ်။ အဆင်မပြေတာကတော့ Play Store In-App Update API လိုမျိုးတော့ App ထဲကမထွက်သွားပဲ update တော့ပေးလုပ်လို့မရတော့ဘူးပေါ့။

နောက်တစ်ဆင့်အနေနဲ့ ကျွန်တော်တို့ အသစ်ထွက်ထိုင်း ကိုယ်တိုင် Firebase ထဲ ဒေတာသွားထည့်နေရရင် အဆင်မပြေဘူး။ ဒီတော့ ပိုမြန်အောင် deploy ဆိုတဲ့ cloud function နောက်တစ်ခုထပ်ရေးလိုက်တယ်။ APK file လေးရယ်၊ သူ့ version code ရယ်၊ forced လုပ်သင့်မလုပ်သင့်ဆိုတာလေးကို လက်ခံထားတယ်။ ပြီးတော့ အလွယ်တကူတင်လို့ရအောင် gradle script ရေးလိုက်တယ်။ (ဘာမှမဟုတ်ဘူး curl command ထဲ parameter တွေဖြည့်ပေးတာပဲ)။ ပြီးတော့ github pipeline မှာ master ကို merge တိုင်း auto တင်နေအောင်လုပ်ထားပေးလိုက်တယ်။ ဒါဆိုရင် ကျွန်တော်တို့ကိုယ်တိုင် ဒေတာပြင်စရာလည်း လုံးဝမလိုတော့ဘူး။

ဒီလောက်ဆိုရင်တော့ ကိုယ်ရေးနေတဲ့ product တွေမှာလည်း vendor-lock in မဖြစ်အောင်၊ user တွေကို update ပေးလို့ရတဲ့ နည်းလေးတစ်ခုတော့ရသွားပြီလို့ ထင်ပါတယ်။ Code တွေက Github မှာ Open Source ပေးထားပါတယ်။ mVoter 2020 ကို Download လုပ်မယ်ဆိုရင်တော့ ကျွန်တော်တို့ mvoterapp.com မှာ အခမဲ့ရယူလိုရပါတယ်။

ကျွန်တော်ရေးတဲ့၊ ပြောတဲ့ အကြောင်းတွေသဘာကြတယ်ဆို ကျွန်တော်နဲ့ ကိုလင်းဖြိုးပေါင်းလုပ်နေတဲ့ ပထမဆုံး ဗမာလိုပြောတဲ့ နည်းပညာ Podcast ဖြစ်တဲ့ Techshaw Podcast လေးရှိပါတယ်။ ကျွန်တော်တို့တွေ နည်းပညာအကြောင်းတွေ အစုံအလင် ပြောဖြစ်ပါတယ်။ Follow မလုပ်ရသေးရင် လုပ်လိုက်ဦးနော်။