คู่มือ Android: ด้านธุรกิจ สถาปัตยกรรม และการพัฒนาวิชาชีพ

หากคุณกำลังก้าวเข้าสู่โลกของ Android ไม่ช้าก็เร็วคุณจะต้องใช้... คู่มือ Android ที่ดีซึ่งอธิบายทั้งด้านธุรกิจและด้านการพัฒนาแอปการรู้วิธีเขียนโปรแกรมแค่สองสามหน้าจอนั้นไม่เพียงพออีกต่อไปแล้ว ในปัจจุบันคุณต้องเข้าใจลักษณะงาน อุปกรณ์ที่ได้รับการจัดการ สถาปัตยกรรมสมัยใหม่ ความปลอดภัย SSO การทดสอบ... และอีกมากมาย

ในคู่มือฉบับสมบูรณ์นี้ คุณจะพบกับ ภาพรวมที่สมบูรณ์และทันสมัยเกี่ยวกับวิธีการพัฒนาแอปพลิเคชัน Android ที่ออกแบบมาสำหรับธุรกิจและใช้งานได้บนอุปกรณ์หลากหลายประเภทหลักสูตรนี้จะช่วยให้คุณพัฒนาแผนผังความคิดที่ชัดเจนเกี่ยวกับทุกสิ่งที่คุณจำเป็นต้องเรียนรู้เพื่อสร้างแอปพลิเคชันระดับมืออาชีพและบำรุงรักษาได้ง่าย ตั้งแต่พื้นฐานของ Android Enterprise และการจัดการอุปกรณ์ ไปจนถึงการจัดโครงสร้างโค้ดด้วยสถาปัตยกรรมที่แข็งแกร่งและปรับขนาดได้

Android Enterprise: วิธีเตรียมแอปของคุณให้พร้อมสำหรับสภาพแวดล้อมในองค์กร

ระบบปฏิบัติการ Android มีฟีเจอร์มาตรฐานอยู่หลายอย่าง คุณสมบัติระดับองค์กรที่ช่วยให้องค์กรสามารถจัดการอุปกรณ์ แอปพลิเคชัน และข้อมูลได้อย่างปลอดภัยข่าวดีก็คือ แอป Android มาตรฐานทุกแอปนั้นรองรับฟีเจอร์เหล่านี้อยู่แล้ว แต่ข่าวร้ายก็คือ หากคุณต้องการให้แอปของคุณโดดเด่นในสภาพแวดล้อมขององค์กร คุณจะต้องก้าวไปอีกขั้นและปรับแต่งแอปของคุณให้เหมาะสม

เพื่อให้ได้ประโยชน์สูงสุดจาก Android Enterprise ควรเริ่มต้นด้วย... แอป Android ที่สร้างเสร็จแล้ว พร้อมสำหรับการแก้ไข และมีเวอร์ชันขั้นต่ำ 5.0 Lollipop (แม้ว่าจะแนะนำให้ใช้ Android 6.0 Marshmallow หรือสูงกว่าก็ตาม) เวอร์ชันที่สูงกว่านี้จะมีคุณสมบัติขั้นสูง โดยเฉพาะอย่างยิ่งสำหรับอุปกรณ์เฉพาะทางและนโยบายการจัดการที่เข้มงวดกว่า

องค์กรต่างๆ ใช้คุณสมบัติเหล่านี้เพื่อเปิดใช้งาน สถานการณ์การใช้งานอุปกรณ์พกพาอย่างมีประสิทธิภาพ: ตั้งแต่โทรศัพท์มือถือของพนักงานที่มีข้อมูลส่วนตัวและข้อมูลการทำงานแยกกัน ไปจนถึงตู้คีออสก์แบบใช้ครั้งเดียวในฐานะนักพัฒนา คุณควรทำความเข้าใจระบบนิเวศนี้เพื่อหลีกเลี่ยงปัญหาความไม่เข้ากัน และที่สำคัญที่สุดคือเพื่อป้องกันไม่ให้ธุรกิจต่างๆ จำกัดการใช้งานแอปของคุณ

โปรไฟล์การทำงานบน Android: การแยกชีวิตส่วนตัวและชีวิตการทำงานออกจากกัน

แนวคิดหลักของ Android Enterprise คือ โปรไฟล์การทำงาน คือคอนเทนเนอร์ขององค์กรที่จัดการอยู่ภายในอุปกรณ์ของผู้ใช้โปรไฟล์นี้เชื่อมโยงกับบัญชีหลักของอุปกรณ์ แต่ยังคงแยกแอปพลิเคชัน ข้อมูลส่วนตัว และข้อมูลการทำงานออกจากกันอย่างชัดเจน

ในทางปฏิบัติ รายละเอียดงานทำหน้าที่เป็น พื้นที่แยกต่างหากซึ่งแอปพลิเคชันระดับองค์กรจะมีตราสัญลักษณ์เฉพาะและได้รับการจัดการด้วยนโยบายของตนเองผู้ใช้ยังคงควบคุมพื้นที่ส่วนตัวของตนเอง ในขณะที่ฝ่ายไอทีจะจัดการเฉพาะข้อมูลทางธุรกิจและแอปพลิเคชันที่ผู้ใช้สนใจ โดยไม่เข้าไปยุ่งเกี่ยวกับส่วนอื่นๆ ของอุปกรณ์

ลักษณะสำคัญที่สุดอย่างหนึ่งของรายละเอียดงาน ได้แก่: การแยกข้อมูลอย่างปลอดภัย การเผยแพร่แอปผ่าน Google Play ที่ได้รับการจัดการ และความสามารถในการจัดการเฉพาะด้าน ควบคุมโดยผู้ดูแลระบบ และมีการเข้ารหัสอุปกรณ์อย่างสมบูรณ์เพื่อสำรองข้อมูล

รายละเอียดสำคัญอย่างหนึ่งคือ เมื่ออุปกรณ์มีทั้งโปรไฟล์ส่วนตัวและโปรไฟล์สำหรับการทำงาน โดยปกติแล้วมักจะถูกใช้งานในลักษณะเดียวกัน ใช้ไฟล์ APK เดียวสำหรับทั้งสองพื้นที่ ในขณะที่ตัวควบคุมนโยบาย (DPC) ถูกจำกัดไว้เฉพาะโปรไฟล์การทำงานเท่านั้นการบริหารจัดการจะดำเนินการผ่านคลาส DevicePolicyManager ซึ่งหมายความว่าคุณต้องคำนึงถึง API เหล่านี้หากคุณพัฒนาโซลูชันระดับองค์กรขั้นสูง

เพื่อหลีกเลี่ยงปัญหา สิ่งสำคัญคือต้อง อย่าคิดว่าความตั้งใจใดๆ จะสามารถถ่ายโอนจากโปรไฟล์หนึ่งไปยังอีกโปรไฟล์หนึ่งได้โดยง่ายบางกิจกรรมถูกบล็อกด้วยเหตุผลด้านความปลอดภัย และคุณจะทราบได้ก็ต่อเมื่อทำการทดสอบเท่านั้น ก่อนเริ่มกิจกรรมใดๆ ควรโทรสอบถามก่อน Intent.resolveActivity()หากฟังก์ชันส่งค่ากลับเป็น null แสดงว่าไม่มีคอมโพเนนต์ใดในโปรไฟล์นั้นที่สามารถจัดการ Intent นั้นได้

เมื่อทำการแลกเปลี่ยนไฟล์ระหว่างโปรไฟล์ Android แนะนำให้ใช้ URI ของเนื้อหาที่มี FileProvider ซึ่งแชร์ผ่าน Intent พร้อมสิทธิ์การเข้าถึงเฉพาะวิธีนี้ช่วยให้มั่นใจได้ว่าการเข้าถึงจะจำกัดเฉพาะโปรไฟล์ที่ถูกต้อง และแอปอื่นๆ จะเห็นเฉพาะสิ่งที่จำเป็นเท่านั้น ซึ่งแตกต่างจากแบบเดิม URI ที่ขึ้นต้นด้วย file:// ซึ่งชี้ไปยังพาธของระบบไฟล์แบบสัมบูรณ์นั้นใช้ไม่ได้กับโปรไฟล์ต่างๆ และอาจทำให้เกิดความล้มเหลวเมื่อพยายามเปิดใช้งานทรัพยากรจากอีกฝั่งหนึ่ง

การกำหนดค่าที่ได้รับการจัดการ: การควบคุมแอปพลิเคชันจากระยะไกลโดยฝ่ายไอที

เสาหลักสำคัญในสภาพแวดล้อมขององค์กรคือ... การกำหนดค่าแบบจัดการ คือชุดพารามิเตอร์ที่ผู้ดูแลระบบสามารถนำไปใช้กับแอปพลิเคชันจากระยะไกลได้ ของผู้ใช้งาน ข้อได้เปรียบที่สำคัญคือสามารถใช้งานได้กับทุกระบบ: สามารถใช้งานร่วมกับโซลูชัน EMM (Enterprise Mobility Management) ใดก็ได้

ด้วยการตั้งค่าเหล่านี้ ฝ่ายไอทีจึงสามารถ ปรับแต่งการทำงานของแอปพลิเคชันจากส่วนกลางในส่วนสำคัญๆ เช่น การเชื่อมต่อ ความปลอดภัย หรือข้อจำกัดในการใช้งานตัวอย่างเช่น คุณสามารถกำหนดได้ว่าแอปจะซิงค์ข้อมูลเฉพาะผ่าน Wi-Fi หรือรวมถึงข้อมูลมือถือด้วย URL ใดบ้างที่อนุญาตให้ใช้ในเบราว์เซอร์ในตัว วิธีการตั้งค่าบัญชีอีเมล การเปิดใช้งานการพิมพ์ หรือรายการโปรดใดบ้างที่โหลดไว้ล่วงหน้า

จากมุมมองของนักพัฒนา สิ่งสำคัญอยู่ที่... ตรวจสอบข้อจำกัดเหล่านี้ในช่วงเวลาที่เหมาะสมตลอดวงจรชีวิตของแอปเมื่อเริ่มต้นระบบ แนะนำให้ตรวจสอบโค้ดก่อน onStart() หรือ onResume() ผลลัพธ์จาก getApplicationRestrictions() เพื่อตรวจสอบว่าแอปได้รับการจัดการหรือไม่ มีข้อจำกัดใด ๆ ที่กำหนดไว้แล้วหรือไม่ หรือมีสถานะการกำหนดค่าที่รอดำเนินการอยู่หรือไม่

ค่าที่ส่งคืนโดย getApplicationRestrictions() อาจเป็น แพ็กเกจที่มีข้อจำกัดเฉพาะ แพ็กเกจว่างเปล่า หรือโครงสร้างที่มีคีย์ KEY_RESTRICTIONS_PENDINGในกรณีสุดท้ายนี้ แอปของคุณทราบว่ากำลังอยู่ภายใต้การควบคุม แต่ DPC ยังไม่ได้นำนโยบายไปใช้อย่างถูกต้อง ดังนั้นสิ่งที่ควรทำคือจำกัดการใช้งานและแนะนำให้ผู้ใช้ติดต่อผู้ดูแลระบบไอที

นอกจากนี้ นโยบายต่างๆ สามารถเปลี่ยนแปลงได้ตลอดเวลา ซึ่งเป็นเหตุผลว่าทำไมแอปของคุณจึงต้อง... ตรวจจับการเปลี่ยนแปลงแบบเรียลไทม์โดยการบันทึกข้อมูลการออกอากาศ ACTION_APPLICATION_RESTRICTIONS_CHANGED แบบไดนามิกตามหลักการแล้ว คุณควรสมัครใช้งานเมื่อกิจกรรมหรือบริการนั้นทำงานอยู่ และยกเลิกการลงทะเบียนโดยใช้ onPause() เพื่อหลีกเลี่ยงการรั่วไหลหรือพฤติกรรมที่ไม่คาดคิด

อุปกรณ์เฉพาะทาง: ตู้คีออสก์ ระบบ POS และป้ายดิจิทัล

อีกหนึ่งแนวปฏิบัติที่แพร่หลายในบริษัทต่างๆ คือการใช้ อุปกรณ์ใช้งานเฉพาะ (อุปกรณ์เฉพาะทาง) เช่น ตู้คีออสก์ ระบบ POS หรือจอแสดงผลป้ายโฆษณาในกรณีเหล่านี้ Android จะถูกตั้งค่าให้แสดงแอปเพียงแอปเดียวหรือชุดแอปที่จำกัดมาก โดยปิดกั้นการเข้าถึงแอปหลักหรือแอปที่ใช้งานล่าสุด

เมื่อตั้งค่าอุปกรณ์เป็นแบบเฉพาะ ผู้ใช้จะเห็นดังนี้ ประสบการณ์เดียวที่ถูกควบคุมไว้ โดยไม่มีวิธีง่ายๆ ในการออกจากแอปหลักนอกจากนี้ คุณยังสามารถกำหนดกลุ่มแอปพลิเคชันที่อนุญาตได้ เช่น ในตู้บริการตนเองของห้องสมุดที่แสดงเฉพาะแคตตาล็อกและเว็บเบราว์เซอร์ขององค์กรเท่านั้น

เพื่อให้บรรลุถึงสถานการณ์เหล่านี้ จำเป็นต้องติดตามกระบวนการต่างๆ การจัดหาอุปกรณ์เฉพาะตามที่ระบุไว้ในเอกสารทางการในสถานการณ์เหล่านี้ DPC จะรับบทบาทเป็นเจ้าของอุปกรณ์ ในฐานะนักพัฒนา คุณต้องตรวจสอบให้แน่ใจว่าแอปของคุณสามารถทำงานในโหมดคีออสก์ได้ โดยไม่มีปุ่มนำทางมาตรฐานหรือการทำงานหลายอย่างพร้อมกัน และตอบสนองได้ดีต่อการเกิดข้อผิดพลาดและการรีสตาร์ทที่ควบคุมได้

การเข้าสู่ระบบครั้งเดียว (SSO) ด้วยแท็บ Chrome แบบกำหนดเอง

ในโลกธุรกิจ เป็นเรื่องปกติมากที่ผู้ใช้จะต้องยืนยันตัวตนในแอปพลิเคชันต่างๆ หลายแอป และหากประสบการณ์การใช้งานไม่ได้รับการจัดการอย่างระมัดระวัง อาจส่งผลเสียได้... การป้อนชื่อผู้ใช้และรหัสผ่านซ้ำแล้วซ้ำเล่าโดยปกติแล้ว WebView ถูกใช้สำหรับการล็อกอิน แต่โซลูชันนี้มีข้อเสียที่ชัดเจน

ในอีกด้านหนึ่ง การใช้งาน WebView หลายๆ รูปแบบไม่ได้ให้คุณสมบัติดังกล่าว SSO ที่แท้จริง เพราะ WebView แต่ละตัวจัดการคุกกี้และเซสชันของตัวเองในทางกลับกัน ก็มีความเสี่ยงด้านความปลอดภัยเช่นกัน เนื่องจากสามารถตรวจสอบคุกกี้หรือแทรกโค้ด JavaScript ที่เป็นอันตรายได้ หากแอปพลิเคชันหรือ SDK ของบุคคลที่สามทำงานผิดปกติ

ทางเลือกที่แนะนำคือการใช้ประโยชน์จาก แท็บแบบกำหนดเอง โดยเฉพาะแท็บแบบกำหนดเองของ Chrome ซึ่งมีมาตั้งแต่ Chrome เวอร์ชัน 45แท็บเหล่านี้ทำหน้าที่เป็นมุมมองเบราว์เซอร์ของระบบแบบบูรณาการ โดยมีบริบทที่ปลอดภัยซึ่งแอปหลักไม่สามารถสอดแนมเนื้อหาได้

เมื่อใช้แท็บแบบกำหนดเองสำหรับการตรวจสอบสิทธิ์ สถานะคุกกี้ทั่วทั้งเบราว์เซอร์ ช่วยให้สามารถเข้าสู่ระบบครั้งเดียวได้ในหลายแอปพลิเคชันผู้ใช้ล็อกอินเพียงครั้งเดียว และแอปพลิเคชันอื่นๆ สามารถใช้ข้อมูลการล็อกอินที่ได้รับการตรวจสอบสิทธิ์แล้วนั้นได้ ซึ่งช่วยเพิ่มความสะดวกในการใช้งานและลดความยุ่งยาก

ในการใช้งาน SSO ร่วมกับแท็บแบบกำหนดเอง คุณสามารถใช้ AppAuth คือไลบรารีไคลเอ็นต์ OAuth แบบโอเพนซอร์สที่ได้รับการสนับสนุนจากกลุ่มทำงาน OpenID Connectไลบรารีนี้ช่วยลดความซับซ้อนในการผสานรวมกับผู้ให้บริการยืนยันตัวตน และจัดการรายละเอียดด้านความปลอดภัยและความเข้ากันได้กับแท็บที่กำหนดเอง

การทดสอบแอปในสภาพแวดล้อมที่มีการจัดการ: การทดสอบ DPC, โปรไฟล์ และอุปกรณ์

เมื่อคุณเพิ่มการรองรับโปรไฟล์การทำงาน การกำหนดค่าแบบจัดการ และอุปกรณ์เฉพาะแล้ว ก็ถึงเวลาสำหรับส่วนที่ไม่น่าดึงดูดใจนัก แต่มีความสำคัญยิ่งกว่า: ทดสอบแอปของคุณทั้งบนโปรไฟล์การทำงานและบนอุปกรณ์ที่ได้รับการจัดการอย่างแท้จริงนี่คือจุดที่แอปพลิเคชัน Test DPC เข้ามามีบทบาท

การทดสอบ DPC คือ แอปพลิเคชันที่ออกแบบมาสำหรับนักพัฒนาเพื่อจำลองพฤติกรรมของ DPC ระดับองค์กรในสภาพแวดล้อมการทดสอบด้วยเครื่องมือนี้ คุณสามารถตั้งค่านโยบาย EMM และค่าการกำหนดค่าที่จัดการได้ราวกับว่าองค์กรกำลังจัดการอุปกรณ์ผ่านคอนโซลของตนเอง

ในการทดสอบแอปของคุณในสภาพแวดล้อมการทำงาน ขั้นตอนการทำงานพื้นฐานมีดังนี้ ติดตั้ง Test DPC เปิดตัวเลือกการกำหนดค่า Test DPC ในตัวเลือก Android และทำตามคำแนะนำเพื่อเตรียมโปรไฟล์การทำงานจากนั้นติดตั้งแอปของคุณและตรวจสอบว่าแอปทำงานอย่างไรในโปรไฟล์ที่มีตราสัญลักษณ์การทำงาน ตรวจสอบสิทธิ์ ความตั้งใจ การเข้าถึงข้อมูล และพฤติกรรมที่ละเอียดอ่อนอื่นๆ

หากคุณต้องการจำลองอุปกรณ์ที่ได้รับการจัดการอย่างสมบูรณ์ คุณต้องดำเนินการดังต่อไปนี้ ตรวจสอบให้แน่ใจว่าเทอร์มินัลนั้นไม่มีผู้ใช้ โปรไฟล์การทำงาน หรือบัญชีอื่นใดที่ตั้งค่าไว้ขั้นตอนต่อไป ติดตั้ง Test DPC แล้วรันคำสั่งต่อไปนี้ใน adb:

adb shell dpm set-device-owner com.afwsamples.testdpc/.DeviceAdminReceiver

เมื่อกระบวนการนี้เสร็จสิ้น อุปกรณ์จะพร้อมใช้งาน อยู่ภายใต้การควบคุมอย่างสมบูรณ์ของ Test DPC ในฐานะเจ้าของอุปกรณ์จากนั้น คุณสามารถทดสอบแอปของคุณในบริบทของการบริหารจัดการอย่างสมบูรณ์ โดยให้ความสำคัญเป็นพิเศษกับวิธีการใช้งานการกำหนดค่าที่ได้รับการจัดการ การตอบสนองของ Intent ที่ถูกจำกัด และสิ่งที่เกิดขึ้นกับแอปในสถานการณ์การบล็อกและนโยบายที่เข้มงวด

เมื่อคุณตรวจสอบพฤติกรรมในการทดสอบภายในเครื่องเรียบร้อยแล้ว สิ่งที่ดีที่สุดคือการก้าวไปอีกขั้นและทำการทดสอบเพิ่มเติม การทดสอบแบบครบวงจรในสภาพแวดล้อมคลาวด์จริง โดยจำลองขั้นตอนที่ลูกค้าจะใช้งานจริงขั้นตอนนี้เกี่ยวข้องกับการมีคอนโซล EMM สำหรับทดสอบ การอ้างสิทธิ์โดเมนที่ได้รับการจัดการจาก Google การเชื่อมโยงโดเมนนั้นกับคอนโซล และการเผยแพร่แอปเวอร์ชันทดสอบ (ด้วย ApplicationId ที่แตกต่างกัน) ในช่อง Google Play ส่วนตัวของโดเมนนั้น

จากคอนโซล EMM คุณจะสามารถ: กำหนดค่าอุปกรณ์ทำงาน แจกจ่ายแอป ตั้งค่าการกำหนดค่าที่จัดการ และตั้งค่านโยบายอุปกรณ์ด้วยวิธีนี้ คุณจะตรวจสอบได้ว่าทุกอย่างทำงานได้เหมือนกับการใช้งานจริง ตั้งแต่การลงทะเบียนเริ่มต้นไปจนถึงการบังคับใช้นโยบายขั้นสูง

คู่มือการเรียนรู้ Android: ตั้งแต่ระดับเริ่มต้นจนถึงระดับขั้นสูง

นอกเหนือจากแง่มุมทางธุรกิจแล้ว หากคุณต้องการเป็นนักพัฒนา Android ที่ดี คุณจำเป็นต้องมี... เส้นทางการเรียนรู้ที่เป็นระบบ ครอบคลุมทุกอย่างตั้งแต่แนวคิดพื้นฐานไปจนถึงหัวข้อขั้นสูง และติดตามข่าวสารล่าสุดอยู่เสมอ ข่าวเทคโนโลยีเกี่ยวกับโทรศัพท์มือถือ แอปพลิเคชัน และวัฒนธรรมดิจิทัลในแง่นี้ คู่มือหรือหลักสูตรที่แบ่งเนื้อหาออกเป็นระดับต่างๆ เช่น ระดับเริ่มต้น ระดับกลาง และระดับสูง จึงมีประโยชน์มาก

ในระยะเริ่มต้นนั้น จะเน้นไปที่... พื้นฐานของ Android, Kotlin หรือ Java, วงจรชีวิตของ Activity, มุมมองพื้นฐาน และการสร้างเลย์เอาต์ปัจจุบันแหล่งข้อมูลสมัยใหม่จำนวนมากมุ่งเน้นไปที่ Kotlin 100% แต่ก็ยังมีหนังสือและเอกสารดีๆ ที่เขียนด้วย Java และสภาพแวดล้อมอย่าง Eclipse ซึ่งแม้จะล้าสมัยไปบ้าง แต่ก็ยังคงมีประโยชน์สำหรับการทำความเข้าใจวิวัฒนาการของแพลตฟอร์มนี้

เมื่อคุณเรียนไปเรื่อย ๆ สิ่งสำคัญคือการแนะนำหัวข้อต่าง ๆ เช่น การคงอยู่ของข้อมูล การเขียนโปรแกรมพร้อมกัน ความปลอดภัย การสื่อสารเครือข่าย และการทดสอบนอกจากนี้ การทำความคุ้นเคยกับ Fragment สถาปัตยกรรมสมัยใหม่ และแนวคิดต่างๆ เช่น การแบ่งส่วนย่อย ก็เป็นความคิดที่ดีเช่นกัน เพื่อที่โครงการของคุณจะไม่เกิดความสับสนวุ่นวายเมื่อมันเติบโตขึ้น

ในระดับขั้นสูง พวกมันจะเข้ามามีบทบาท การเผยแพร่บน Google Play, การจัดการเวอร์ชัน, การสร้างรายได้, การปกป้องแอปแบบเสียเงิน (เช่น ด้วย LVL) และกลไกการอัปเดตหัวข้อต่างๆ เช่น AppWidgets, การเข้าถึงข้อมูลตามตำแหน่งทางภูมิศาสตร์, การเพิ่มประสิทธิภาพการทำงาน, การรองรับ Android หลายเวอร์ชัน และการปรับให้เข้ากับแท็บเล็ตและอุปกรณ์พับได้ ก็เป็นหัวข้อที่กล่าวถึงกันโดยทั่วไปเช่นกัน

ตำราเรียนคลาสสิกบางเล่มครอบคลุมเนื้อหาเหล่านี้ ตั้งแต่การเตรียมสภาพแวดล้อมการพัฒนา การสร้างแอปพลิเคชันตัวแรก การออกแบบส่วนติดต่อผู้ใช้ ไปจนถึงการปรับใช้ในสภาพแวดล้อมการใช้งานจริงในขั้นสุดท้ายนอกจากนี้ หนังสือเหล่านี้มักมีตัวอย่างโปรเจกต์ให้ดาวน์โหลด ซึ่งแสดงให้เห็นถึงทุกสิ่งทุกอย่างที่อธิบายไว้ในเนื้อหาอย่างชัดเจน

สถาปัตยกรรมแอป Android สมัยใหม่: รากฐานสำหรับโครงการที่จริงจัง

หากคุณต้องการให้แอปของคุณไม่ล่มทันทีที่มันเติบโตขึ้นเล็กน้อย คุณจำเป็นต้องมี... โครงสร้างแอปที่ออกแบบมาอย่างดี สามารถปรับขนาดและปรับให้เข้ากับอุปกรณ์ต่างๆ ได้ ไม่ว่าจะเป็นมือถือ แท็บเล็ต อุปกรณ์พับได้ ChromeOS รถยนต์ และอุปกรณ์ XRแนวคิดคือการลดการพึ่งพาองค์ประกอบเฟรมเวิร์กให้น้อยที่สุด และทำให้มั่นใจว่าโค้ดนั้นง่ายต่อการบำรุงรักษาและทดสอบ

แอปพลิเคชัน Android ทั่วไปประกอบด้วย ส่วนประกอบหลายอย่างที่ระบุไว้ในแถลงการณ์ ได้แก่ บริการ ผู้ให้บริการเนื้อหา ผู้รับการออกอากาศ และกิจกรรมต่างๆในอดีต อินเทอร์เฟซผู้ใช้ถูกจัดระเบียบด้วยกิจกรรมหลายอย่าง แต่คำแนะนำในปัจจุบันคือการใช้สถาปัตยกรรมแบบ กิจกรรมที่ไม่เหมือนใครด้วยหน้าจอที่สร้างขึ้นจากส่วนย่อยหรือจุดหมายปลายทางของ Jetpack Compose.

เนื่องจากแอปของคุณสามารถทำงานได้บนอุปกรณ์ที่หลากหลาย คุณจึงไม่สามารถตั้งสมมติฐานได้ล่วงหน้า ไม่ใช่ทั้งการวางแนวคงที่หรือขนาดหน้าจอเดียวการเปลี่ยนแปลงการตั้งค่า (เช่น การหมุนหน้าจอ การเปลี่ยนหน้าต่างใน ChromeOS การพับอุปกรณ์พับได้) จำเป็นต้องสร้างอินเทอร์เฟซใหม่ และอาจทำให้ต้องสร้างส่วนประกอบใหม่ ดังนั้นสถานะที่สำคัญใดๆ ควรเก็บไว้นอก Activity และ Fragment

นอกจากนี้ Android ยังเป็นสภาพแวดล้อมที่มีทรัพยากรจำกัด ซึ่งระบบ... มันสามารถปิดกระบวนการทำงานของแอปที่ทำงานอยู่เบื้องหลังเพื่อเพิ่มพื้นที่ว่างในหน่วยความจำได้นอกจากนี้ยังสามารถเริ่มต้นส่วนประกอบต่างๆ ในลักษณะที่ไม่เป็นระเบียบและทำลายส่วนประกอบเหล่านั้นโดยไม่แจ้งเตือนล่วงหน้า ดังนั้นจึงมีคำแนะนำแบบดั้งเดิมว่า: อย่าเก็บสถานะหรือข้อมูลทางธุรกิจไว้ใน Activity, Service หรือ BroadcastReceiver เพราะข้อมูลเหล่านี้มีลักษณะชั่วคราว

หลักการชี้นำคือ การแบ่งแยกความรับผิดชอบ: ส่วนติดต่อผู้ใช้ (UI) มีหน้าที่แสดงข้อมูลและตอบสนองต่อเหตุการณ์ต่างๆ ในขณะที่ตรรกะทางธุรกิจและการจัดการข้อมูลจะอยู่ในเลเยอร์อื่นๆดังนั้น เมื่อส่วนประกอบอินเทอร์เฟซถูกสร้างขึ้นใหม่ สถานะจะยังคงอยู่ได้ด้วย ViewModel, Repository และ Data Source ที่มีการจัดระเบียบอย่างดี

ชั้นโครงสร้างทางสถาปัตยกรรม: ส่วนติดต่อผู้ใช้ (UI), ข้อมูล และโดเมน

โครงสร้างสถาปัตยกรรมที่แนะนำนั้นแบ่งออกเป็นอย่างน้อยสองชั้น: เลเยอร์ UI (การนำเสนอ) และเลเยอร์ข้อมูลนอกจากนี้ ยังสามารถเพิ่มเลเยอร์โดเมนที่สามเพื่อห่อหุ้มตรรกะทางธุรกิจที่ซับซ้อนหรือสามารถนำกลับมาใช้ซ้ำได้ระหว่าง ViewModel ต่างๆ ได้อีกด้วย

เลเยอร์ UI มีหน้าที่รับผิดชอบในเรื่องต่อไปนี้ แสดงข้อมูลบนหน้าจอและตอบสนองต่อการเปลี่ยนแปลงสิ่งนี้เกิดขึ้นได้ทั้งจากการกระทำของผู้ใช้หรือข้อมูลป้อนเข้าจากภายนอก เช่น การตอบสนองจากเครือข่าย ในกรณีนี้ องค์ประกอบภาพ (วิวหรือส่วนประกอบจาก Jetpack Compose) และตัวจัดการสถานะ (ViewModel) จะเข้ามามีบทบาทในการรักษาและแสดงสถานะของอินเทอร์เฟซ

ในอินเทอร์เฟซแบบปรับเปลี่ยนได้ ViewModel มักจะเป็น แสดงสถานะที่คำนึงถึงคลาสขนาดหน้าต่างแล้วโดยใช้ยูทิลิตี้ต่างๆ เช่น currentWindowAdaptiveInfo() คอมโพเนนต์ต่างๆ เช่น NavigationSuiteScaffold สามารถใช้ข้อมูลนี้เพื่อสลับระหว่าง NavigationBar, NavigationRail หรือ NavigationDrawer โดยอัตโนมัติ ขึ้นอยู่กับพื้นที่ว่างที่มีอยู่

ชั้นข้อมูลจะรวมศูนย์ข้อมูลไว้ด้วยกัน ตรรกะทางธุรกิจและกฎเกณฑ์ที่กำหนดวิธีการสร้าง จัดเก็บ และแก้ไขข้อมูลระบบนี้ใช้พื้นฐานจากคลังข้อมูลที่จัดกลุ่มและสรุปข้อมูลจากแหล่งข้อมูลหนึ่งแหล่งขึ้นไป เช่น ฐานข้อมูลภายในเครื่อง บริการเครือข่าย ไฟล์ ฯลฯ โดยปกติแล้วข้อมูลแต่ละประเภท (เช่น ภาพยนตร์ การชำระเงิน ผู้ใช้ ฯลฯ) จะมีคลังข้อมูลของตนเอง ซึ่งรับผิดชอบในการเปิดเผยข้อมูล รวบรวมการเปลี่ยนแปลง และแก้ไขข้อขัดแย้ง

แหล่งข้อมูลคือคลาสที่ พวกมันสื่อสารโดยตรงกับระบบหรือกับบริการภายนอก เช่น การสอบถามข้อมูลด้วยคำสั่ง SQL การเข้าถึงไฟล์ การร้องขอ HTTP เป็นต้นส่วนที่เหลือของแอปพลิเคชันไม่ควรขึ้นอยู่กับการใช้งานเฉพาะของส่วนนั้น แต่ควรขึ้นอยู่กับอินเทอร์เฟซที่เปิดเผยโดยที่เก็บโค้ดเท่านั้น

เมื่อความซับซ้อนเพิ่มขึ้น จะเป็นประโยชน์ที่จะแนะนำเลเยอร์โดเมนที่ประกอบด้วย กรณีการใช้งานหรือตัวโต้ตอบแต่ละตัว ซึ่งแต่ละตัวมีหน้าที่เฉพาะเจาะจงตัวอย่างเช่น UseCase GetTimeZone ที่ส่งคืนโซนเวลาที่เหมาะสมเพื่อสร้างข้อความที่กำหนดเอง ซึ่งสามารถนำกลับมาใช้ซ้ำได้โดย ViewModel หลายตัว

แบบจำลองข้อมูล, SSOT และการไหลของข้อมูลแบบทิศทางเดียว

หลักการสำคัญอีกประการหนึ่งคือ อินเทอร์เฟซควรมีลักษณะดังนี้ ป้อนข้อมูลด้วยโมเดลข้อมูล โดยเฉพาะโมเดลข้อมูลแบบถาวรโมเดลเหล่านี้แสดงถึงสถานะของแอป และเป็นอิสระอย่างสมบูรณ์จาก UI และวงจรชีวิตของส่วนประกอบเฟรมเวิร์ก ด้วยวิธีนี้ โมเดลเหล่านี้จึงยังคงอยู่แม้ว่าจะมีการสร้าง Activity และ Fragment ขึ้นมาใหม่ และจะหายไปก็ต่อเมื่อระบบยุติกระบวนการเท่านั้น

ในทำนองเดียวกัน การนำรูปแบบของ มาประยุกต์ใช้ ก็เป็นสิ่งที่มีประโยชน์ แหล่งข้อมูลความจริงเดียว (SSOT)ข้อมูลประเภทสำคัญแต่ละประเภทจะมีเจ้าของเพียงรายเดียวที่สามารถแก้ไขได้ ส่วนเลเยอร์อื่นๆ จะทำหน้าที่เพียงสังเกตข้อมูลนั้นผ่านประเภทข้อมูลที่ไม่สามารถเปลี่ยนแปลงได้ การเปลี่ยนแปลงข้อมูลจะดำเนินการผ่านฟังก์ชันที่กำหนดไว้อย่างชัดเจน หรือผ่านเหตุการณ์ที่เข้าถึงแหล่งข้อมูลหลักนั้น

โดยปกติแล้ว SSOT จะถูกรวมเข้ากับ การไหลของข้อมูลแบบทิศทางเดียว (UDF) ซึ่งสถานะไหลจากบนลงล่าง และเหตุการณ์ไหลจากล่างขึ้นบนในระบบ Android หมายความว่าข้อมูลแอปพลิเคชันจะเดินทางจากแหล่งที่มา (เครือข่าย ฐานข้อมูล) ไปยังส่วนติดต่อผู้ใช้ ในขณะที่การกระทำของผู้ใช้จะถูกแปลงเป็นเหตุการณ์ซึ่งจะเดินทางจากส่วนติดต่อผู้ใช้ไปยังโดเมนหรือเลเยอร์ข้อมูล เพื่ออัปเดตสถานะ

การทำตามรูปแบบนี้จะช่วยปรับปรุง ความสอดคล้องของสถานะช่วยลดข้อผิดพลาด ช่วยให้เข้าใจพฤติกรรมของแอปได้ง่ายขึ้น และทำให้การดีบักง่ายขึ้นการมีส่วนประกอบเพียงชิ้นเดียวที่ควบคุมการเปลี่ยนแปลงของข้อมูล ทำให้สามารถระบุแหล่งที่มาของข้อผิดพลาดได้ง่ายขึ้น

การฉีดการพึ่งพาและแนวปฏิบัติที่ดีที่สุดโดยทั่วไป

เพื่อให้คลาสต่างๆ ของแอปสามารถทำงานร่วมกันได้โดยไม่เกิดการเชื่อมโยงที่ไม่จำเป็น ขอแนะนำให้ใช้ รูปแบบการจัดการการพึ่งพา เช่น การฉีดการพึ่งพา (DI) หรือตัวระบุตำแหน่งบริการในระบบ Android โซลูชันที่นิยมใช้คือ Hilt ซึ่งช่วยสร้างอ็อบเจ็กต์โดยอัตโนมัติ ตรวจสอบการพึ่งพาในระหว่างการคอมไพล์ และสร้างคอนเทนเนอร์เฉพาะสำหรับส่วนประกอบของเฟรมเวิร์ก

แนวคิดก็คือว่าชั้นเรียนต่างๆ ระบุสิ่งที่คุณต้องการ แต่ไม่ต้องลงมือสร้างเองวิธีนี้ช่วยให้คุณสลับจากการใช้งานจริงไปยังเวอร์ชันทดสอบ หรือปรับเปลี่ยนพฤติกรรมได้โดยไม่ต้องเขียนโค้ดใหม่ครึ่งหนึ่งของโปรเจ็กต์ นอกจากนี้ยังช่วยลดการทำงานซ้ำซ้อนและแสดงให้เห็นอย่างชัดเจนว่าแต่ละส่วนเชื่อมต่อกันอย่างไรในที่เดียว

ตามหลักสถาปัตยกรรมทั่วไปแล้ว ควรคำนึงถึงว่า จุดเริ่มต้น (กิจกรรม บริการ ผู้รับ) ไม่ใช่แหล่งข้อมูลแต่ในทางกลับกัน พวกมันเป็นเพียงผู้ประสานงานที่ร้องขอข้อมูลที่จำเป็นจากที่เก็บข้อมูลหรือกรณีการใช้งาน นอกจากนี้ยังแนะนำให้ลดการพึ่งพาคลาส Android นอกเหนือจากส่วนประกอบ UI เพื่ออำนวยความสะดวกในการทดสอบ

การกำหนดนิยามนั้นสำคัญ กำหนดขอบเขตความรับผิดชอบระหว่างโมดูลให้ชัดเจน หลีกเลี่ยงการผสมผสานโค้ดเครือข่าย การแคช การผูกมุมมอง และตรรกะทางธุรกิจไว้ในคลาสเดียวกันแต่ละโมดูลควรแสดงเฉพาะสิ่งที่จำเป็นเท่านั้น โดยไม่มีทางลัดที่เปิดเผยรายละเอียดการทำงานภายในและอาจกลายเป็นภาระทางเทคนิคในอนาคต

คำแนะนำที่ได้ยินบ่อยๆ อีกอย่างหนึ่งคือ อย่าสร้างสิ่งที่มีอยู่แล้วขึ้นมาเอง: จงใช้ประโยชน์จากไลบรารีของ Jetpack และโซลูชันที่มีอยู่แล้วสำหรับงานมาตรฐาน (การนำทาง การจัดเก็บข้อมูล การแบ่งหน้า ฯลฯ) ควรใช้เวลาของคุณไปกับสิ่งที่ทำให้แอปของคุณโดดเด่น แทนที่จะเสียเวลาเขียนโค้ดโครงสร้างพื้นฐานเดิมซ้ำแล้วซ้ำเล่า

ในการออกแบบ UI ควรเลือกใช้ ส่วนประกอบที่สามารถนำกลับมาใช้ใหม่ได้และสามารถประกอบเข้าด้วยกันเพื่อปรับให้เข้ากับขนาดและทิศทางต่างๆ ได้คุณควรตรวจสอบให้แน่ใจว่าได้รักษาสถานะของอินเทอร์เฟซไว้ในระหว่างการเปลี่ยนแปลงการตั้งค่า โดยเฉพาะอย่างยิ่งบนอุปกรณ์พับได้และหน้าจอขนาดใหญ่ที่มักมีการปรับขนาดบ่อยครั้ง

ในส่วนของการทำงานพร้อมกัน แต่ละประเภทจะต้อง รับผิดชอบในการดำเนินการภารกิจที่มีค่าใช้จ่ายสูงให้เสร็จสิ้นตามกำหนดเวลาที่ถูกต้องตัวอย่างเช่น ผ่านทาง coroutines และ Flows หลักการสำคัญคือ การเรียกใช้ API ควรปลอดภัยจากเธรดหลัก โดยมอบหมายงานหนักๆ ให้กับเธรดพื้นหลัง

สุดท้ายแล้ว มันคุ้มค่าที่จะอนุรักษ์ไว้ รวบรวมข้อมูลที่เกี่ยวข้องให้ได้มากที่สุดเท่าที่จะเป็นไปได้ในระดับท้องถิ่น โดยให้เป็นข้อมูลที่ทันสมัยอยู่เสมอด้วยวิธีนี้ ผู้ใช้ของคุณจะสามารถใช้งานแอปต่อไปได้แม้ไม่มีการเชื่อมต่อหรือสัญญาณไม่ดี ซึ่งเป็นสิ่งที่พบได้บ่อยโดยเฉพาะในพื้นที่ที่มีผู้คนหนาแน่นหรือเครือข่ายคุณภาพต่ำ

การมีสถาปัตยกรรมที่ดีนำมาซึ่งข้อดีที่จับต้องได้หลายประการ: มันช่วยปรับปรุงการบำรุงรักษา ทำให้หลายทีมสามารถทำงานร่วมกันบนโค้ดเบสเดียวกันได้ง่ายขึ้น เร่งกระบวนการรับนักพัฒนาใหม่ และทำให้แอปทดสอบได้ง่ายขึ้นทั้งหมดนี้ส่งผลให้มีข้อผิดพลาดน้อยลง การอัปเดตเร็วขึ้น และประสบการณ์การใช้งานที่เสถียรยิ่งขึ้นสำหรับผู้ใช้ปลายทาง

โดยรวมแล้ว การเชี่ยวชาญฟังก์ชันการทำงานระดับองค์กรของ Android การเข้าใจวิธีการทำงานของโปรไฟล์การทำงานและอุปกรณ์เฉพาะ การใช้งาน SSO ที่ปลอดภัยด้วยแท็บแบบกำหนดเอง การใช้การกำหนดค่าแบบจัดการ และการนำสถาปัตยกรรมที่ทันสมัยมาใช้ด้วยการแยกเลเยอร์ SSOT และ DI จะช่วยให้คุณสามารถ จากการพัฒนาแอปพลิเคชันง่ายๆ ไปสู่การสร้างโซลูชัน Android ระดับมืออาชีพที่แข็งแกร่ง พร้อมใช้งานสำหรับทุกสภาพแวดล้อม ไม่ว่าจะเป็นองค์กรหรือผู้บริโภค.