iOS နှင့် Android အတွက် React Native ဖြင့် cross-platform မိုဘိုင်းအက်ပ်ကို ကျွန်ုပ်တည်ဆောက်ပေးပါမည်။

၎င်းတွင် အဘယ်အရာများ ပါဝင်သနည်း။

React Native codebase တစ်ခု၊ store နှစ်ခု၊ ပြင်ဆင်ရန် bug တစ်ခု။ Navigation၊ authentication၊ push notifications၊ offline handling နှင့် cross-platform framework တစ်ခုတည်းဖြင့် ပျောက်ကွယ်မသွားနိုင်သော platform ကွဲပြားမှုများ။

ကျွန်ုပ်၏ ချဉ်းကပ်ပုံ

အက်ပ်ကို ပထမဆုံးနေ့မှစ၍ သင်၏စစ်မှန်သော API နှင့် တည်ဆောက်ထားသည်၊ ထုတ်လုပ်မှုထက် ပိုမိုကောင်းမွန်စွာ လုပ်ဆောင်နိုင်သော mock data ဖြင့် မဟုတ်ပါ။ Authentication သည် device ပေါ်ရှိ လုံခြုံသော storage နှင့် refresh tokens များကို နေရာတစ်နေရာတည်းတွင် ကိုင်တွယ်သည်။ အဘယ်ကြောင့်ဆိုသော် screens များတစ်လျှောက် ပြန့်ကျဲနေသော token bugs များသည် မိုဘိုင်းအက်ပ်များ ပျက်စီးစေသော အဖြစ်အများဆုံးနည်းလမ်းဖြစ်သည်။ Lists များကို virtualised နှင့် paginated လုပ်ထားသည်။ ပုံများကို full resolution ဖြင့် download လုပ်မည့်အစား device အတွက် cache လုပ်ပြီး အရွယ်အစား သတ်မှတ်ထားသည်။

Platform လုပ်ငန်းကို မှတ်စုတစ်ခုအဖြစ် မဟုတ်ဘဲ လုပ်ငန်းအဖြစ် သတ်မှတ်သည်။ iOS သည် ၎င်း၏ကိုယ်ပိုင် permission strings နှင့် provisioning လိုအပ်သည်။ Android သည် ၎င်း၏ notification channels နှင့် back-button behaviour လိုအပ်သည်။ နှစ်ခုလုံးသည် cold start တွင် အလုပ်လုပ်နိုင်သော deep links များ လိုအပ်သည်။

ပေးပို့နိုင်သောပစ္စည်းများ

• TypeScript တွင် React Native project၊ သင်လိုအပ်သော native modules များသာ ပါဝင်ပြီး အခြားမပါဝင်ပါ။
• TestFlight နှင့် Play internal-track builds များကြောင့် သင်သည် ၎င်းကို စောစီးစွာ ကိုင်တွယ်နိုင်သည်။
• backend trigger အပါအဝင် end-to-end ချိတ်ဆက်ထားသော Push notifications များ။
• Release builds၊ store listing text နှင့် screenshots နှင့် တင်သွင်းရန် လိုအပ်သော မှတ်စုများ။
• ၎င်းကို သင်ကိုယ်တိုင် run ရန်၊ build လုပ်ရန်နှင့် release လုပ်ရန်အတွက် အတိုချုပ်လမ်းညွှန်။

ကျွန်ုပ်လိုအပ်သောအရာ

API တစ်ခု သို့မဟုတ် ၎င်းအတွက် specification တစ်ခု၊ အရေးအကြီးဆုံး screens သုံးခုနှင့် သင့်တွင်ရှိပြီးသားဖြစ်ပါက Apple နှင့် Google developer accounts များ။ သင့်တွင်မရှိပါက မည်သည့်အရာကို မည်သည့်အချိန်တွင် ဖန်တီးရမည်ကို ကျွန်ုပ်အတိအကျ ပြောပြပါမည်။

Scope မှတ်စု

အက်ပ်တစ်ခု၊ ပရိသတ်တစ်ခု။ ထုတ်ကုန်သည် အလွန်ကွဲပြားခြားနားသော အတွေ့အကြုံနှစ်ခု လိုအပ်ပါက — ဥပမာအားဖြင့် customer အက်ပ်နှင့် driver အက်ပ် — ၎င်းတို့သည် builds နှစ်ခုဖြစ်ပြီး ကိုးကားပြီးမှ မဟုတ်ဘဲ ကိုးကားခြင်းမပြုမီ ကျွန်ုပ်ပြောပြပါမည်။

အလှည့်ကျနှင့် ဆက်သွယ်ရေး

ပထမဆုံး TestFlight သို့မဟုတ် internal-track build ကို ပုံမှန်အားဖြင့် နှစ်ပတ်အတွင်း ရရှိသောကြောင့် သင်သည် အက်ပ်ကို ကိုင်တွယ်ပြီး screenshots များပေါ်တွင် မဟုတ်ဘဲ အရာဝတ္ထုကိုယ်တိုင်ပေါ်တွင် တုံ့ပြန်ချက်ပေးနေပါသည်။ ကျွန်ုပ်သည် release checklist ကို ရှင်းလင်းစွာ ထားရှိသည် — permissions၊ deep links၊ offline behaviour၊ store metadata — အဘယ်ကြောင့်ဆိုသော် ၎င်းတို့သည် အလုပ်လုပ်နေသော အက်ပ်ကို ပယ်ချခံရသော တင်သွင်းမှုအဖြစ် ပြောင်းလဲစေသော အရာများဖြစ်သည်။ သင်လက်ခံရရှိသော build တိုင်းသည် သင်တင်ပို့နိုင်သော build တစ်ခုဖြစ်သည်။