မင်္ဂလာပါ!

လှိုက်လှဲစွာကြိုဆိုပါသည်။ ယခု ပထမဆုံးအကြိမ် ရောက်ဖူးခြင်းဖြစ်ပါသလား? ဝင်ရောက် ဆွေးနွေး မေးမြန်းလိုပါလျှင် အောက်တွင်ဖော်ပြထားသော button များမှတဆင့် ဝင်ရောက် ဆွေးနွေးနိုင်သကဲ့သို့ အဖွဲ့ဝင်အသစ်အနေဖြင့်လည်း လျှောက်ထားနိုင်ပါတယ်။

MYSTERY ZILLION တွင် English သို့မဟုတ် Unicode ဖြင့်သာ အသုံးပြုခွင့်ရှိသည်။ ဇော်ဂျီ ၊ ဧရာ စသည်တို့ကို အသုံးပြုခွင့် မရှိ။ Unicode fonts များမှာ Mon3,Yunghkio, Myanamr3 စသည်များ အသုံးပြုနိုင်သည်။ Unicode Guide ကို ဒီမှာ Download ချပါ။ Zawgyi to Unicode Converter
Don't share ebook or software if nobody request. You can find free book websites on here. We are welcome for discussion or asking question instead.

Mobile Development အတွက် Actual Coding အပြင် မဖြစ်မနေလိုအပ်သော Development အဆာပလာများ

ဒီ Thread မှာ Mobile Development နဲ့ပတ်သတ်ြပီး Feature တစ်ခုအတွက် လုပ်ရတဲ့ Actual Coding အပြင် Project တစ်ခုလုံးစာအတွက် ဆို မဖြစ်မနေလိုအပ်တဲ့ အဆာပလာ တွေအကြ​ောင်း ဆွေးနွေးလိုပါတယ်

ပထမတစ်ခုက Project Structure ပါ။ Project တစ်ခု Maintainable ဖြစ်နေဖို့ Memory Profiling / Processing Profiling စတာတွေ လွယ်လွယ်ကူကူ Integrate လုပ်နိုင်ဖို့နောက်ြပီး Automated Testing တွေ Inject လုပ်ရတာ သက်တောင်သက်သာ ရှိနေစေဖို့က Project Structuring (Android - iOS) အတွက်တော်တော်လေး အရေးပါတယ်လို့မြင်ပါတယ်။

ဒုတိယတစ်ခု Unit Testing ပါ။ ဘယ်လို တည်ဆောက်တယ်။ ဘယ် Test Case တွေ မဖြစ်မနေ လိုအပ်တယ်။ Automated Testing တွေအတွက်ဆို ဘယ်လို Tool တွေကို သုံးလို့ရတယ် .. စသည်ြဖင့်ပေါ့။

တတိယတစ်ခုက Code Repository Management ပါ။ ဘယ်လို Choice တွေရှိတယ် ။ Daily Routine တွေကို ဘယ်လို Handle လုပ်တယ်။ ဘယ်အချက်တွေကို သတိထားရမယ် စသည်ဖြင့်ပေါ့ ။

နံပါတ် လေး ဆွေးနွေးချင်တာက Build Management ပါ။ Debug Build / Production Build စတာတွေကို ဘယ်လို Handle လုပ်လဲ .. Android နဲ့ပတ်သတ်တာဆိုရင် Gradle Build / Ant Build စသည်ြဖင့် .. ။ နောက်ပြီး Continuous Integration နဲ့ပတ်သတ်တာတွေဆိုရင် Jenkin လိုဟာမျိုးတွေ .. ဒါတွေ ဆွေးနွေးလိုပါတယ်။

နံပါတ် ၅ က Mobile Development အတွက် ဒိြပင့်အြခားသိထားသင့်တဲ့အချက်တွေ ..

ဒီမှာ တကယ့် International Quality Mobile Project တွေကို ၄ ၅ နှစ်လုပ်နေကြတဲ့ Senior ကြီးတွေ ရှိပါတယ် ။ အတွေ့အကြုံလေးတွေ တစ်ချက် Share ပေးပါ။ ဘာတွေက ဘယ်လို ရှိတယ် ဘယ်လိုလုပ်လို့ ရတယ်ဆိုတဲ့ Tutorial တွေထက်စာရင် တကယ် Daily Basic မှာ ြကုံရတာတွေ ကိုယ်ရွေးချယ်လိုက်တာတွေ လုပ်မိတဲ့ အမှားလေးတွေ .. Thumbs Up Rule လေးတွေ .. ဒါတွေကို အဓိက ဆွေးနွေးလိုပါတယ် ။

မေးခွန်းတစ်ခုတည်းကို မေးလို့ ဖြေလိုက်တာထပ်စာရင် အခုလို Suit လိုက် ကိုယ်ြကုံဖူးတာလေးတွေ​ေပြာရင်း သိချင်တဲ့လူကလဲ ဝင်မေးရင်းဆိုရင် ပိုြပီးတော့စုစုစီးစီး နဲ့ နားလည်သဘောပေါက်လွယ်မယ် ယူဆလို့ပါ .. ။

မှတ်ချက်များ

  • Administrators

    memory management အတွက် iOS 5.0 မတိုင်ခင်က အတော်ကို အရေးပါပါတယ်။ ARC ပေါ်လာပြီးနောက် ရေးရတာ တော်တော်သက်သာသွားတယ်။ သို့ပေမယ့် ARC မတိုင်ခင်က memory mangament အတွေ့အကြုံက အခု အချိန်အထိ အထောက်အကူပေးပါတယ်။

    Project Structure ပိုင်းကိုတော့ ကျွန်တော်ကတော့ အစကတည်းကနေ အခုအချိန်ထိ Controller , Model folder ၂ ခု နဲ့ ခွဲပြီး ဆောက်လာတာ အခုအချိန်ထိပဲ။ နောက်ပိုင်း ကိုယ်ပိုင် library တွေကို prefix ပေးတတ်တယ်။ Project name ပေါ်မှာ မူတည်ပြီး class တွေကို prefix ပေးပြီး သုံးတတ်ပါတယ်။

    Unit Testing ပိုင်းကတော့ project ပေါ်မှာ မူတည်တယ်။ အချို့ UI ပိုင်းတွေက Unit Testing နဲ့ စစ်လို့ အဆင်မပြေတာ တွေရှိတယ်။ ပုံမှန် class ပိုင်းမှာဆိုရင်လည်း key chain access တွေပါလာရင် unit testing က အဆင်မပြေတော့ဘူး။ Unit Test က key chain မှာ store လုပ်ရင် အမြဲ ပြဿနာ ဖြစ်နေတတ်တော့ key chain ပိုင်းကို unit test မရေးဖြစ်တာ များတယ်။

    iOS မှာ ကျွန်တော်ကတော့ xcode မှာ ပါတဲ့ Unit test ပဲ သုံးဖြစ်တယ်။ သီးသန့် library ထည့်ပြီး မသုံးဖြစ်ဘူး။

    Code Repo ကတော့ git ပဲ သုံးပြီးတော့ A Successful Git Branching ကို အတတ်နိုင်ဆုံး follow လုပ်ပါတယ်။

    Continuous Integration တော့ တစ်ခါမှ မသုံးဖြစ်ဘူး။ Build ကတော့ project ပေါ်မှာ မူတည်တယ်။

    Mobile Development ပိုင်းမှာ iOS ရဲ့ Android က အဓိက ပါ။ ကျွန်တော်ကတော iOS ပဲ ရေးဖြစ်တယ်။ Android ကို သေသေချာချာ မလေ့လာဖြစ်ဘူး။ ရေးချင်တဲ့ project ရှိမှ Android ကို ကောက်ရေးဖြစ်တာ များတယ်။ သေသေချာချာ လေ့လာထားတာ မရှိတဲ့ အတွက် မပြောနိုင်ဘူး။

    iOS Dev ပဲ ဖြစ်ဖြစ် Android Dev ပဲ ဖြစ်ဖြစ် အရေးကြီးတဲ့ တစ်ခုကတော့ UI Guideline ကို လိုက်နာဖို့ လိုတယ်။ iOS မှာ ဆိုရင် Human Interface Guideline နဲ့ Android မှာ ဆိုရင် လည်း Guideline ရှိပါတယ်။

    iOS guide line ကို android မှာ သုံးထားတဲ့ app တော်တော်များများ တွေ့ဖူးတယ်။ တချို့ iOS app တွေမှာလည်း mobile web UI/UX တွေ သုံးထားတာတွေ တွေ့ရတယ်။ ဒါဟာ မှားနေတယ်လို့ မြင်တယ်။ UI/UX တစ်ခု ကို ဖန်တီး ရင် သက်ဆိုင် ရာ platform ရဲ့ guide line ကို လေ့လာထားဖို့လိုတယ်။

    iOS အတွက် http://www.pttrns.com/ ကို အမြဲ ကြည့်နေဖို့လိုတယ်။ တခြားသူတွေ ဖန်တီးထားတဲ့ UI/UX အသစ်တွေကို တွေ့နိုင်တယ်။

    Code ပိုင်းကတော့ နောက်ပိုင်း Apple Developer Guide နဲ့ WWDC video ကိုပဲ ကြည့်ဖြစ် ဖတ်ဖြစ်တာ များတယ်။ Swift မှာ ဆိုရင် WWDC videos , Swift အပိုင်း ၃ ပိုင်းလုံးဟာ swift langauge ကို တော်တော်လေး သိသွားစေပါတယ်။ စာအုပ်ဖတ်တာ ထက် ပိုမြန်တယ်။

  • Administrators

    Unit Testing က Developer လုပ်လို့ရတဲ့ အပိုင်းဖြစ်နေတယ် Tools တွေကတော့ တယောက်နဲ့ တယောက် မတူဘူးဖြစ်မယ် အလေ့အကျင့်နဲ့လည်း ဆိုင်လိမ့်မယ် တချို့ကလည်းဘာ Tools မှမသုံးဘူး ဒါပေမယ့် TDD အလေ့အကျင့်အရ Manual Test လုပ်ပြီးသွားလို့ မလိုတာလည်းရှိမယ်။ Unit Test က လုပ်နိုင်သလောက် လုပ်ထားတာက ကောင်းပါတယ် Development Bug အတတ်နိုင်ဆုံး နည်းသွားတာပေါ့။

    ဒါပေမယ့် တကယ်တမ်း အရေးအကြီးတဲ့ Functionality & Usability Testing ကျတော့ Developer မလုပ်သင့်ဘူး Developer Test လုပ်နေသမျှ ဘယ်တော့မှ အရေးကြီးတဲ့ အမှားမတွေ့ဘူး။ Functionality Testing အတွက်က Testing Team တခုရှိရတယ် အဲဒီမှာပါတဲ့ Members တွေဟာ Development မှာပါခဲ့တဲ့လူတွေ မဟုတ်ရဘူး အဲဒါဆိုရင် အတော်လေး အဆင်ပြေလိမ့်မယ် Specification နဲ့ Software ကို Test လုပ်လိမ့်မယ်။ Qualified Tester မဟုတ်ရင်တောင် Developer Test လုပ်တာထက် အများကြီး ကောင်းပါလိမ့်မယ်။

    Usability Testing ကျတော့ In-House Testing Team အတွက်က အတိုင်းအတာ တခုအထိပဲရှိတယ် သုံးမယ့်လူတွေနဲ့ Pilot Test လိုပါတယ် မဟုတ်ရင်တော့ Deliver လုပ်လိုက်ပြီးမှ Usability Fail ဖြစ်တာ ဖြစ်နိုင်ပါတယ်။ Usability အတွက်ကျတော့ စဉ်းစားရမှာတွေ အများကြီးရှိတယ် လူတွေနဲ့ တိုက်ရိုက် ပါတ်သက်တဲ့အတွက် Age, Gender, Culture, Disability စသည်ဖြင့် အခြေအနေ အများကြီးကို အခြေခံစဉ်းစားရမယ် တကယ်ကတော့ Developer ရဲ့ အလုပ်ရယ်တော့ မဟုတ်ပါဘူး User Interface ဟာ broad subject ဖြစ်ပါတယ်။ Design လုပ်ကတည်းက သင့်လျော်တဲ့လူတွေ ပါဖို့လိုသလို Design လုပ်တဲ့လူကလည်း ဒီအကြောင်းကို နားလည်တဲ့လူ ဖြစ်ဖို့လိုတယ်။

    သက်ဆိုင်ရာ Platform ရဲ့ UI Guideline က ယေဘုယျအားဖြင့် တော့အသုံးကျနိုင်ပါတယ် လိုက်နာတိုင်း မှန်တယ်လို့တော့ မဟုတ်ပါဘူး မလိုက်နာတိုင်း မှားတယ်လည်း မဟုတ်ပါဘူး တကယ်တမ်း လိုက်နာရမယ့် UI Guideline က User Oriented ဖြစ်ဖို့ပါ Platform Oriented မဟုတ်ဘူး။ ဘာကြောင့်ဆိုတဲ့ Justification ရှိမယ်ဆိုရင် မလိုက်နာချင်ရင် မလိုက်နာလို့ရပါတယ် ကိုယ့်ရဲ့ Software ကို ကိုယ်အမြင်မှာ သုံးလို့လွယ်ဖို့ထက် တကယ်သုံးမယ့် User တွေ သုံးရလွယ်တယ်လို့ တကယ်လက်ခံဖို့က အရေးကြီးဆုံး အချက်ဆိုတာ သတိထားရင် အဆင်ပြေပါတယ်။

  • Registered Users

    ကိုCalmHill‌ ကိုရော ကိုsaturngod ကိုရောအခုလို ဝင်ဆွေးနွေးပေးတဲ့အတွက် ကျေးဇူးတင်ပါတယ်။

    ကျွန်တော်ကတော့ Android နဲ့ပတ်သတ်ြပီး Project Structure လေးနည်းနည်းပြောချင်တယ်။ များသောအားဖြင့် Android နဲ့ပတ်သတ်ပြီး စလုပ်ပြီဆိုရင် Activity တစ်ခုဆောက်လိုက်တယ်။ ပြီးတော့ အဲဒီ Activity မှာ UI Widget တွေ ထည့်ပြီး UI Widget တွေကို (ဥပမာ TextView ၊ ListView) Activity ကနေတဆင့် တာရိုက် Control လုပ်လိုက်တာပဲ ။ သေးတုန်းမှာမသိသာပေမဲ့ Project က တဖြည်းဖြည်း ကြိးလာတဲ့အခါ File တစ်ခုက ဘယ်နေရာမှာထားတယ် ၊ ဒါမှမဟုတ် ထားသင့်တယ်ဆိုတာကို ကိုယ်ကလွဲရင် ကျန်တဲ့လူနားမလည်တော့ဘူး ။ ပြောရရင် စနစ်မကျဘူးဆိုပါတော့ ။

    ဒါမျိုးတစ်ခါလောက်ြဖစ်ပြီးတဲ့အခါ Project Structure နဲ့ပတ်သတ်ပြီး Project တွေအကုန်လုံးအတွက် Common ဖြစ်မဲ့ဟာ တစ်ခုလောက်ထားနိုင်ရင်ကောင်းမှာပဲလို့ စဉ်းစားမိပြီးရှာကြည့်တော့ Strict MVC ပုံစံမျိုးနဲ့ Android Project တစ်ခုကို Structure ဘယ်လိုချနိုင်မလဲ ဆိုတာကို သွားတွေ့မိတယ်။

    ပထမ Package Structure နဲ့ပတ်သတ်ပြီးပြောရရင် ဒီနေရာမှာ ၂ ဖွဲ့ကွဲနေတာက တစ်ချို့ Android Developer တွေက Package Structure ကို Functionality အပေါ်မူတည်ပြီး ခွဲတာကို သဘောကျကြသလို တစ်ချို့Android Developer တွေက Component Type အပေါ်မူတည်ပြီး ခွဲကြတယ် ။ ကျွန်တော်ကတော့ Component Type အပေါ်မူတည်ပြီး ခွဲတဲ့ပုံစံနဲ့ပဲနောက်ပိုင်း Project တွေကို ရေးဖြစ်ပါတော့တယ် ။ Functionality အပေါ်မူတည်ပြီးခွဲတာက Project ၁ခုချင်းစီမှာ ပို Understandability ကိုတိုးတက်စေပေမဲ့ Project 4 5 ခုခွကိုင်ရတဲ့အခါ Component Type နဲ့ချတာက ပို Smooth ဖြစ်တယ်လို့မြင်မိပါတယ်။

    ခုနက Strict MVC ရဲ့ Project Structure ကိုဆက်ပြောရမယ်ဆိုရင် Android Project တစ်ခုအနေနဲ့ UI Level မှာ ၃ ပိုင်းရှိတယ်လို့မြင်မိပါတယ်။ Activity အပိုင်းရယ် Fragment အပိုင်းရယ် Modular ဖြစ်နေတဲ့ View Group အပိုင်းရယ်လို့ ခွဲပါတယ်။ UI ရဲ့ Depth နဲ့ Complexity အပေါ်မူတည်ပြီး သိပ်Complex မဖြစ်ရင် Activity / Fragment ကိုပဲ View နေရာမှာရော Controller ထားလိုက်ပါတယ်။ တကယ်လို့ အောက်က ပုံလိုအရမ်း Complexity တွေများလာပြီဆိုရင်တော့ View Group တွေခွဲထုတ်လိုက်ပါတယ်။ ခွဲထုတ်ပြီး View Group တွေကို View နေရာမှာ ထားပါတယ်။ Activity / Fragment တွေကိုတော့ Controller နေရာမှာထားပါတယ် ။

    တကယ်တော့ Fragment တွေ Activity တွေဟာ hooker methods (Application အပေါ်မှာအများကြီးသက်ရောက်မှုရှိတဲ့ Life Cycle Methods) တွေအများကြီး ပါန​ေ ပြီးသား Controller စစ်စစ်တွေပါ ။ သူတို့ကို View နေရာမှာထားပြီး သက်သက် Controller တွေတည်ဆောက်ထားတဲ့ Project တွေ တွေ့နေရမပါတယ်။ တကယ်တော့အဲဒါတော်တော်လေးမှားပါတယ် ။ Development မှာမလိုအပ်တဲ့ Complexity တွေတိုးတက်လာစေပါတယ်။

    နောက်ပြီး DataManager အတွက် Persistence Layer ကို Support ပေးမဲ့ Wrapper Class တစ်ခုရေးပါတယ်၊ ဒါက Application Logic အရ SharedPreference မှာပဲ သိမ်းသိမ်း SQLite မှာပဲ သိမ်းသိမ်း I/O နဲ့ပဲ သိမ်းသိမ်း ကျန်တဲ့အစိတ်အပိုင်းတွေနဲ့ သိသိသာသာ ခွဲထုတ်လိုက်နိုင်အောင် လို့ပါ။

    Network Manager class တစ်ခုကတော့ ဘယ် App မဆိုသုံးနိုင်အောင် Lib ထုတ်ထားပါတယ်။ အဲဒီမှာ Async / Sync Call တွေအကုန် GET / POST / PUT / DELETE method အကုန် Support ပေးနိုင်အောင် ထားထားပါတယ်။ Cookie နဲ့ပတ်သတ်တာတွေ Retry Count တွေ ResposeHandler တွေအကုန်ထည့်ထားပါတယ် ။

    Social Medai နဲ့ပတ်သတ်တာလဲ အဲလိုပါပဲ ။ Lib ခွဲထုတ်ထားမှပါ။ App 10 မှာ 9 ခုက Social Media တစ်ခုမဟုတ်တစ်ခုနဲ့ ချိတ်ခိုင်းကြပါတယ်။

    နောက်အရေးကြီးတာက ImageLoader ပါ။ အပေါ်ကဟာတွေက ကိုယ့်ဘာသာ ရေးတာပိုအဆင်ပြေပါတယ်။ တစ်ခုခု ဖြစ်လာရင် ဘယ်နေရာက ဘာက ဖြစ်နိုင်တယ်ဆိုတာတန်းသိပါတယ်။ ImageLoader က မလိုပါဘူး ။ ရှိပြီးသားတစ်ခုခု သုံးလိုက်ရင် လုံလောက်ပါတယ်။ အရင်က UniversalImageLoader ကိုသုံးပါတယ် ။ အဆင်ပြေတယ်ဆိုပေမဲ့ ဖောင်းပွလွန်းလို့ အခုတော့ Picasso Library ကိုသုံးပါတယ် ။

    ဒါက အခြေခံ Android Project တစ်ခုအတွက် သိထားသင့်တာလေးပါ။ UI နဲ့ပတ်သတ်ပြီး Structure ချတာမှာ ဖြစ်ခဲ့တဲ့ အတွေ့အကြုံလေးတွေ အဆင်ပြေရင် ပြောပါဉီးမယ် ။

    တစ်ခု Request လုပ်ချင်တာက Android Project မှာ Multiple Build create လုပ်တဲ့အပိုင်း (ANT / Gradle) ကို နည်းနည်း အတွေ့အကြုံလေးတွေ Share ပေးကြပါလား ။ Preview / Publish config logic ခွဲပုံတွေ ProGuard အတွက် ထည့်တဲ့ Settings ခွဲပုံတ​ွေ ။ နောက် Google Play Service နဲ့ပတ်သတ်တဲ့ အတွေ့အကြုံလေးတွေ .. ဒါလေးတွေလဲ Discuss လုပ်ချင်ပါတယ် ။ ကို သားထက် တို့ဆိုအများကြီး အတွေ့အကြုံရှိမှာပါ ။

  • Administrators

    I think you should change the title to Android Development rather than Mobile Development. You are talking about physical source code structure and design pattern, it might be different according to your underlying technology even you are using the same design pattern. I don't see Ko Thar Thar online here for many years. If you want to discuss with him, you will need to contact him directly.

  • Registered Users

    ကျွန်တော်လဲပထမတော့ Android Development လို့ခေါင်းစဉ်တပ်မလားလို့စဉ်းစားပါသေးတယ်။ ဒါပေမဲ့ ကျွန်တော်က Android နဲ့ပတ်သတ်တာတွေကို ပဲဆွေးနွေးချင်တာမဟုတ်ဘူးလေ။ Mobile Development မှာရှိတဲ့ Structure တွေ Aspect တွေကို အပေါ်မှာ ကျွန်တော်ပြောထားတဲ့ အချက် ငါးချက် ဘောင်ထဲကဟာတွေ အကုန်လုံးကို သိလဲသိချင်တယ်။ ကိုယ်သိတာ အထောက်အကူဖြစ်တာလေးတွေဆိုရင်လဲ ဆွေးနွေးချင်တယ်။ ဒါကြောင့် Mobile Development အောင်မှာပဲထားလိုက်တာ ။

    ကျွန်တော်ပြောသွားတဲ့ အချက် ၅ ချက်ထဲက နံပါတ်တစ်ချက် Project Structure ဆိုတာ Project တစ်ခုကိုတည်ဆောက်တဲ့ Concept Logic နဲ့ အဲဒီ Logic ကို Real World မှာ ဘယ်လိုပြန်အကောင်အထည် ဖေါ်တယ် ဆိုတာကို ပြောချင်တာ ။ ဉပမာ ကိုCalmHill က Strict MVC ကို Web နဲ့ပတ်သတ်တဲ့ Project တွေမှာ ဘယ်လို Structure ချတယ်ဆိုတာကို ပြောရင်လဲ ကျွန်တော်မသိတာဆိုရင် ဗဟုသုတရတာပဲ ။ ကို စေတန်က iOS Project တစ်ခုအတွက် ဘယ်လို Concept မျိုးကို Backbone ထားပြီး Strucutre ချတယ်ဆိုတာကို ပြောမယ်ဆိုရင် ကျွန်တော်အနေနဲ့ ဖတ်မဲ့လူတွေအနေနဲ့ ကိုယ်သိတာနဲ့ပြန်ပြန်နိုင်း ယဉ်ပြီး မှတ်သားလို့ရပါတယ် ။ Project ရဲ့ Nature အပေါ်မူတည်ပြီး ကွဲမယ် ဆိုပေမဲ့ တကယ် Real World က ဉပမာတစ်ခုဆိုရင်တောင်မှ ကိုယ့် Experience နဲ့ယှဉ်ပြိး ဗဟုသုတရပါတယ်။

    အဓိကကတော့ ဒီ Category ၅ ခုအတွင်းမှာ ဘယ် Mobile Platform အတွက်ဆို ဘယ်လိုလေး လုပ်ရတယ် ။ လုပ်ကြတယ်ဆိုတာကို ယှဉ်ဖတ်ရင်း လေ့လာကြည့်ချင်တာပါ။ ဒါဘောင်ကျယ်ကျယ်ထားထားတဲ့ Discussion ပါ။ မေးခွန်းတစ်ခု မဟုတ်သလို သိတာပြောပြတဲ့ Post တစ်ခုလဲ မဟုတ်ပါဘူး ။

    ဘယ်မေးခွန်းကိုမှ ကိုသားထက်ရယ် ဘယ်သူရယ် ဘယ်ဝါရယ်ကို နံမည်တပ်မမ​ေးလိုပါဘူး ။ ဉပမာအနေနဲ့ mention လုပ်လိုက်တာပဲ ရှိတာပါ ။ အကုန်လုံးအလုပ်ကိုယ်စီနဲ့ ဆိုတော့ ။ တကယ်လို့ ဒီကိုရောက်လာမိလို့ ဒါကိုဖတ်မိရင်း ကိုယ်သိတဲ့ Know-How တစ်ခုက ကျန်တဲ့လူတွေအတွက် အနည်းဆုံး ဗဟုသုတအနေနဲ့ဖြစ်ဖြစ် အသုံးဝင်မှာပဲဆိုပြီး Share ခဲ့တယ်ဆိုရင်အကုန်လုံးအတွက် အကျိုးရှိတယ်လို့ယူဆတယ်လေ ။ ဒါကြောင့်ပါ ။

  • edited July 2014 Registered Users

    ပြောမယ်ဆိုလည်း ပြည့်ပြည့်စုံစုံပြောကြဗျာ။
    စိတ်၀င်စားတယ်။အားလုံးကိုအားပေးတယ်။
    ကျွှန်တော်လည်းအဲဒါကို အသေးစိတ်စိတ်၀င်စားတယ် :)

  • Administrators

    iOS မှာ objective-c နဲ့ ပတ်သက်ပြီးတော့ https://github.com/saturngod/objective-c-style-guide ကို အတတ်နိုင်ဆုံး လိုက်နာပါတယ်။

    Android Java အတွက်ကတော့ https://source.android.com/source/code-style.html ရှိပေမယ့် တစ်ခါမှ မဖတ်ဖြစ်ဘူး။

    @lynlyndrupal‌ ဘယ်အပိုင်းကို သိချင်လဲ။ iOS ပိုင်းမှာ ဆိုရင်တော့ ကျွန်တော် ရှင်းပြပေးနိုင်တယ်။ သို့ပေမယ့် overall အကုန် ဆိုရင်တော့ ကျွန်တော်လည်း မပြောပြတတ်ဘူး။

    Project Structure , Build Management , Unit Test စတာတွေကတော့ တစ်ယောက်နဲ့ တစ်ယောက် တူမှာမဟုတ်သလို company တစ်ခုနဲ့ တစ်ခု policy လည်း တူတာ မဟုတ်ဘူးဗျ။

    ကိုယ့် company က ချမှတ်ထားတဲ့ guide line ရှိတဲ့ အဲဒီ guide line ကို လိုက်နာရတာပဲ။ guide line မရှိသေးဘူး လူကလည်း တစ်ယောက်တည်းမဟုတ်ဘူးဆိုရင်တော့ team နဲ့ ညှိပြီး guide line တစ်ခု ဖန်တီး ရတာပဲ။

  • Registered Users

    ခုကတော့ iOS ကို Newsstand app ပါအစ်ကို :)

  • Administrators

    @lynlyndrupal‌ newstand အတွက် http://www.viggiosoft.com/blog/blog/2011/10/17/ios-newsstand-tutorial/ ကို ဖတ်ကြည့်ပါ။ ပြည့်ပြည့်စုံစုံ ပါပါတယ်။

  • Registered Users

    May I know the tutorial about Newstand for android ...plz

  • Registered Users

    wow...so much cool,thanks you so much u guys for sharing knowledge.I wanna let u guys keep discuss about these topic :D

Sign In or Register to comment.