วิธีที่นักพัฒนาอ่านคำอธิบาย API สำหรับคอลแบ็ก Deep Linking

คำอธิบาย API หลักใน SDK การระบุแหล่งที่มาของมือถือคืออะไร? คำอธิบาย API หลักประกอบด้วย getInstallParam (โดยทั่วไปจะสืบค้นระหว่างการเริ่มต้นใช้งานในการเปิดใช้ครั้งแรกเพื่อเรียกบริบทการติดตั้งแบบหน่วงเวลา) และ getWakeUpParams (ซึ่งจะดักจับเพย์โหลด Universal Link แบบเรียลไทม์เมื่อปลุกแอป)

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

หมวดหมู่สถาปัตยกรรมหลักในคำอธิบาย API ของ SDK การระบุแหล่งที่มา

การจัดหมวดหมู่ API ของ SDK: การรับพารามิเตอร์แบบหน่วงเวลา, การดักจับแบบเรียลไทม์ และการระบุแหล่งที่มาของเหตุการณ์

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

• API การรับพารามิเตอร์แบบหน่วงเวลา (Deferred Parameter Ingestion APIs): เมธอด เช่น getInstallParam บน Android และ getInstallParmsCompleted บน iOS ทำงานเป็นหลักในระหว่างการเริ่มต้นใช้งานแอปพลิเคชันครั้งแรกหลังจากการติดตั้ง เนื่องจากพารามิเตอร์การนำทางเว็บทั่วไปไม่คงอยู่ข้ามขอบเขตการติดตั้งจากสโตร์โดยค่าเริ่มต้น API แบบหน่วงเวลาจึงสืบค้นแคชฝั่งไคลเอนต์และแบ็กเอนด์ของจุดสิ้นสุดการระบุแหล่งที่มาเพื่อกู้คืนข้อมูลเมตาบริบท (เช่น ID ผู้เชิญ, โทเค็นการแนะนำ หรือพารามิเตอร์แคมเปญ) ที่ผูกกับการคลิกก่อนการติดตั้ง
• API การดักจับลิงก์แบบเรียลไทม์ (Real-Time Link Interception APIs): เมธอด เช่น handleDeepLink บน Android และ getWakeUpParams บน iOS จะทำงานเมื่อแอปพลิเคชันติดตั้งอยู่แล้วบนระบบปฏิบัติการโฮสต์ APIเหล่านี้เชื่อมต่อกับโปรโตคอลระบบดั้งเดิม—โดยเฉพาะ Apple Universal Links, Android App Links และชุด URL แบบกำหนดเอง—เพื่อจับพารามิเตอร์ URI แบบเรียลไทม์เมื่อลิงก์เว็บภายนอกหรือแอปพลิเคชันรองทริกเกอร์การทำงานของแอป
• API การระบุแหล่งที่มาของเหตุการณ์หลังการติดตั้ง (Post-Install Event Attribution APIs): เมธอดการรายงานฝั่งไคลเอนต์ เช่น saveEvent บน Android และ reportEffectPoint บน iOS ช่วยให้แอปพลิเคชันไคลเอนต์สามารถรายงานเหตุการณ์สำคัญของผู้ใช้ปลายทางกลับไปยังเซิร์ฟเวอร์รวมการระบุแหล่งที่มา การเรียกเหล่านี้เปิดใช้งานการตรวจสอบผลตอบแทนจากการลงทุนด้านการตลาด (ROAS) อย่างละเอียด, การติดตามการคงอยู่ของกลุ่มผู้ใช้ (cohort retention) และการวิเคราะห์ลูปแบบไวรัลโดยการผูกการกระทำคอนเวอร์ชันในแอปเข้ากับพารามิเตอร์การติดตั้งก่อนหน้า

บทบาทของคอลแบ็กแบบอะซิงโครนัสในการป้องกันการบล็อกเธรดตอนเริ่มต้นแอปพลิเคชันแบบเย็น (Cold-Start)

ระบบปฏิบัติการมือถือบังคับใช้เกณฑ์ประสิทธิภาพที่เข้มงวดในระหว่างการเริ่มต้นแอปพลิเคชัน บน Android การดำเนินการซิงโครนัสเครือข่ายบนเธรดหลักจะโยนข้อยกเว้น NetworkOnMainThreadException ในขณะที่งานซิงโครนัสที่ยืดเยื้อใดๆ—รวมถึงการบล็อกดิสก์ I/O—สามารถทำให้เธรด UIค้างและนำไปสู่ข้อผิดพลาดแอปพลิเคชันไม่ตอบสนอง (ANR) บน iOS ตัวจับเวลา watchdog ของระบบปฏิบัติการจะยุบกระบวนการที่บล็อกเธรดหลักเป็นระยะเวลานานในระหว่างการเริ่มต้นระบบ

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

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

การแยกความแตกต่างระหว่าง API ของ SDK ฝั่งไคลเอนต์และส่วนติดต่อพอสต์แบ็กแบบเซิร์ฟเวอร์ต่อเซิร์ฟเวอร์

ทีมวิศวกรรมมักจะสับสนระหว่างคำอธิบาย API ของ SDK ฝั่งไคลเอนต์และ API พอสต์แบ็กแบบเซิร์ฟเวอร์ต่อเซิร์ฟเวอร์ (S2S) แม้ว่าส่วนติดต่อทั้งสองจะจัดการข้อมูลการระบุแหล่งที่มา แต่บริบทการทำงาน, โมเดลความปลอดภัย และวัตถุประสงค์ในการปฏิบัติงานมีความแตกต่างกันอย่างพื้นฐาน:

• API ของ SDK ฝั่งไคลเอนต์: คอมไพล์โดยตรงลงในไบนารีของมือถือ (เช่น ผ่านเฟรมเวิร์ก CocoaPods หรือการพึ่งพา Maven AAR) ส่วนติดต่อเหล่านี้โต้ตอบกับความสามารถของอุปกรณ์ดั้งเดิม โดยจะคอยฟังการแจ้งเตือนวงจรชีวิตของแอปพลิเคชัน, แยกวิเคราะห์เจตนาของระบบที่เข้ามา, อ่านไฟล์กำหนดค่า และจัดเตรียมออบเจ็กต์หน่วยความจำโดยตรงให้กับคอนโทรลเลอร์การนำเสนอของแอปพลิเคชันสำหรับการกำหนดเส้นทางแบบไดนามิก
• ส่วนติดต่อพอสต์แบ็กแบบเซิร์ฟเวอร์ต่อเซิร์ฟเวอร์ (S2S): ดำเนินการทั้งหมดข้ามโครงสร้างพื้นฐานเซิร์ฟเวอร์แบ็กเอนด์ API ของ S2S ประกอบด้วยจุดสิ้นสุด HTTP REST ที่ถ่ายโอนพอสต์แบ็กคอนเวอร์ชันระหว่างแพลตฟอร์มการระบุแหล่งที่มาและเครือข่ายการตลาด ขึ้นอยู่กับผู้ให้บริการ การสื่อสารผ่าน S2S อาจใช้จุดสิ้นสุด HTTPS ที่มีการตรวจสอบความถูกต้อง, โทเค็นเพย์โหลดที่มีลายเซ็น, mutual TLS หรือการควบคุมการเข้าถึงเครือข่ายเพื่อให้มั่นใจถึงความสมบูรณ์ที่เป็นอิสระจากสถานะการทำงานของอุปกรณ์ไคลเอนต์

กลไกการสืบค้น Deferred Deep Linking ทำงานอย่างไรใน getInstallParam

หน้าต่างการระบุแหล่งที่มาแบบหน่วงเวลา: การเรียกคืนพารามิเตอร์ที่แคชไว้ในการเปิดใช้ครั้งแรก

Deferred deep linking แก้ไขช่องว่างทางสถาปัตยกรรมพื้นฐานในการจัดจำหน่ายซอฟต์แวร์มือถือ นั่นคือ App Store ของระบบปฏิบัติการมาตรฐานจะไม่คงสตริงคิวรี URL ตามอำเภอใจข้ามขั้นตอนการดาวน์โหลดและการติดตั้ง แม้ว่ากลไกเฉพาะแพลตฟอร์ม เช่น Google Play Install Referrer จะสามารถส่งบริบทแคมเปญที่รองรับผ่านการดาวน์โหลดจากสโตร์ได้ แต่พารามิเตอร์คิวรีเว็บทั่วไป (ตัวอย่างเช่น https://example.com/invite?channelCode=affiliate_01&inviter_id=user_9876) จะไม่สามารถรอดพ้นจากขอบเขตของแอปสโตร์โดยอัตโนมัติ

เพื่อเชื่อมช่องว่างนี้ OpoInstall ซึ่งเป็นแพลตฟอร์มการระบุแหล่งที่มาของมือถือและ deep linking จะรวบรวมคุณสมบัติบริบทและพารามิเตอร์แคมเปญเมื่อผู้ใช้มีส่วนร่วมกับหน้า Landing Page เมื่อผู้ใช้เปิดแอปพลิเคชันที่ติดตั้งใหม่ SDK ของไคลเอนต์จะเริ่มต้นทำงานและสร้างการเชื่อมต่อกับคลัสเตอร์การระบุแหล่งที่มา

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

นักพัฒนาสามารถศึกษา เอกสารการรวม SDK ของ OpoInstall สำหรับกฎการกำหนดค่าสภาพแวดล้อมโดยละเอียดและสถาปัตยกรรมการส่งพารามิเตอร์เบื้องหลัง

การวิเคราะห์ getInstallParam: เพย์โหลดพารามิเตอร์, รหัสช่องทาง และการตอบกลับสถานะ

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

• พารามิเตอร์ไดนามิกกำหนดเอง (data): คอนเทนเนอร์ข้อมูลที่มีโครงสร้างซึ่งมีสตริงคิวรีที่กำหนดโดยนักพัฒนาซึ่งส่งผ่านไปยังลิงก์แคมเปญต้นฉบับ ฟิลด์นี้นำบริบททางธุรกิจเฉพาะของแคมเปญ เช่น ID ส่วนลดการแนะนำ, ภูมิภาคของผู้ใช้ที่ต้องการ หรือตัวระบุเนื้อหาเฉพาะ
• พารามิเตอร์การระบุช่องทาง (channelCode): เมื่อมีอยู่ channelCode จะถูกแสดงผลเป็นตัวระบุช่องทางคล้ายสตริงซึ่งบ่งชี้แหล่งที่มาทางการตลาดหรือพาร์ทเนอร์เครือข่ายการตลาด ในการติดตั้งแบบออร์แกนิกที่ไม่มีการใช้งานลิงก์ช่องทาง พารามิเตอร์นี้อาจส่งค่าเป็น null หรือว่างเปล่าขึ้นอยู่กับการผูก SDK ของแพลตฟอร์ม
• ผลลัพธ์การทำงานและข้อผิดพลาด: แทนที่จะพึ่งพารหัสจำนวนเต็มสากลที่ตายตัว ข้อผิดพลาดและการหมดเวลาจะถูกสื่อสารผ่านโมเดลข้อผิดพลาดเฉพาะแพลตฟอร์ม (เช่น OpoError บน Android หรือคอลแบ็กข้อผิดพลาดบน iOS) คอลแบ็กจะให้โครงสร้างข้อผิดพลาดที่อธิบายได้เมื่อการเชื่อมต่อเครือข่ายล้มเหลวหรือเกิดความไม่ตรงกันของการกำหนดค่า

การจัดการสถานะหมดเวลา: ทำความเข้าใจรอบการรอและแฟล็กการลองใหม่แบบไดนามิก

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

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

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

การเปลี่ยนเส้นทาง Real Time Deep Link และการแยกวิเคราะห์คอลแบ็กใน getWakeUpParams

การดักจับเหตุการณ์การเปิดใช้แบบ Cold-Start และพื้นหลังผ่านโปรโตคอลระบบ

เมื่อแอปพลิเคชันมีอยู่แล้วบนอุปกรณ์ของผู้ใช้ การคลิกภายนอกจะข้ามการติดตั้งจากสโตร์ไปโดยสิ้นเชิง แพลตฟอร์มมือถือสมัยใหม่ใช้มาตรฐานการกำหนดเส้นทางเฉพาะ—Universal Links บน iOS และ Android App Links บน Android—เพื่อเปลี่ยนผ่านการทำงานจากเบราว์เซอร์ภายนอกไปยังแอปพลิเคชันเนทีฟที่ติดตั้งไว้โดยตรง

ระบบปฏิบัติการจะส่งต่อเหตุการณ์การเปิดเหล่านี้ผ่านเมธอดดีลิเกตของแอปพลิเคชันเฉพาะ:

• วงจรชีวิต iOS: สำหรับแอปพลิเคชันที่ใช้สถาปัตยกรรมหน้าต่างสมัยใหม่ Universal Links จะมาผ่าน scene:continueUserActivity: ภายใน SceneDelegate (หรือ scene:willConnectToSession:options: ระหว่างการเชื่อมต่อฉากเริ่มต้น) ในแอปพลิเคชันที่ไม่ใช้ดีลิเกตฉาก ระบบปฏิบัติการจะส่งผ่าน application:continueUserActivity:restorationHandler: ภายใน AppDelegate ชุด URL แบบกำหนดเองจะเรียกใช้ application:openURL:options: หรือ scene:openURLContexts: เมธอดการส่งต่อ SDK ที่แสดงใน AppDelegate จะต้องปรับให้เข้ากับวงจรชีวิต UIScene ที่แท้จริงของแอปพลิเคชันเมื่อเปิดใช้งานฉาก
• วงจรชีวิต Android: อินเทนต์ที่เข้ามาจะเรียกใช้ onCreate(Bundle) หากแอ็คทิวิตีเป้าหมายไม่ทำงานอยู่ในหน่วยความจำ หรือ onNewIntent(Intent) หากแอ็คทิวิตีทำงานภายใต้การกำหนดค่าโหมดการเปิดใช้ singleTask หรือ singleTop

API คอลแบ็ก getWakeUpParams (และคู่ค้าบน Android อย่าง handleDeepLink) ทำหน้าที่เป็นตัวรับฟังส่วนกลางที่รับ ตรวจสอบ และแกะพารามิเตอร์ URI ไดนามิกที่ส่งผ่านฮุกวงจรชีวิตระบบปฏิบัติการเหล่านี้

การแยกวิเคราะห์เพย์โหลด getWakeUpParams ระหว่างการเปลี่ยนเส้นทาง Universal Link และ URL Scheme

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

ลายเซ็นต์คอลแบ็กให้การเข้าถึงทั้ง channelCode และ data ตัวอย่างเช่น หากลิงก์แคมเปญอีคอมเมิร์ซที่มีโครงสร้างเป็น https://app.example.com/shoes/running?promo_code=SUMMER20&item_id=sku_456 ทริกเกอร์การเปิดใช้แอปพลิเคชัน คอลแบ็กจะแยกวิเคราะห์ promo_code และ item_id โดยแพ็กเกจลงในเพย์โหลดคอลแบ็กเพื่อให้ตรรกะการนำเสนอของแอปพลิเคชันนำไปใช้ต่อ

การคืนค่าฉากในแอปแบบไดนามิก: การแมปคีย์เพย์โหลด JSON ไปยังคอนโทรลเลอร์เป้าหมายของ Activity/View

วัตถุประสงค์การดำเนินงานสูงสุดของ real-time deep linking คือการคืนค่าฉาก: นำทางผู้ใช้ไปยังผลิตภัณฑ์ โปรไฟล์ หรือหน้าจอกิจกรรมเฉพาะที่อ้างอิงโดยลิงก์โปรโมชันทันที โดยข้ามมุมมองหน้าจอหลักเริ่มต้นโดยสิ้นเชิง

การบรรลุการคืนค่าฉากที่เชื่อถือได้จำเป็นต้องสร้างตัวกำหนดเส้นทาง (router) ที่แน่นอนภายในสถาปัตยกรรมของแอปพลิเคชัน:

• ขั้นตอนที่ 1: การดึงคีย์เพย์โหลด: ภายในตัวรับฟังคอลแบ็ก แอปพลิเคชันจะตรวจสอบเพย์โหลด data เพื่อหากคีย์การกำหนดเส้นทางที่ตกลงกันไว้ล่วงหน้า เช่น target_screen หรือ resource_id
• ขั้นตอนที่ 2: การตรวจสอบค่า Null และประเภทข้อมูล: ตัวกำหนดเส้นทางจะตรวจสอบว่ามีค่าอยู่จริง เป็นไปตามประเภทดั้งเดิมที่คาดไว้ และตรงกับฟีเจอร์แอปพลิเคชันที่ใช้งานอยู่
• ขั้นตอนที่ 3: การดำเนินการของคอนโทรลเลอร์การนำทาง: แอปพลิเคชันจะแก้ไขลำดับชั้นการนำทางรากปัจจุบันและพุช (push) หรือนำเสนอ (present) วิวคอนโทรลเลอร์เป้าหมายหรืออินเทนต์ของ Activity ที่เหมาะสม

การรับประกันการทำงานแบบอิดัมโพเทนต์ (Idempotent) ในการทริกเกอร์วงจรชีวิตการเปิดซ้ำซ้อน

ข้อผิดพลาดทั่วไปในการรวมระบบ mobile deep linking คือการส่งเหตุการณ์ซ้ำซ้อน บน Android การเปลี่ยนแปลงการวางแนวหน้าจอหรือการอัปเดตการกำหนดค่าจะสร้าง Activity พื้นฐานขึ้นใหม่ ทำให้ onCreate ดำเนินการซ้ำด้วย Intent การเปิดดั้งเดิม บน iOS การสลับสถานะเบื้องหน้าของแอปพลิเคชันสามารถทริกเกอร์การแจ้งเตือนดีลิเกตที่ซ้ำกันได้

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

ลายเซ็นต์เมธอดสองแพลตฟอร์มสำหรับการรวมระบบ Android และ iOS

ลายเซ็นต์เมธอด Android: Kotlin ResultCallBack และฮุกวงจรชีวิต Activity

ในการพัฒนาไคลเอนต์ Android SDK การระบุแหล่งที่มาจะแสดงส่วนติดต่อแบบอะซิงโครนัสที่มีโครงสร้างรอบส่วนติดต่อคอลแบ็ก แทนที่จะบล็อกเธรดที่เรียก การเรียกเมธอดจะยอมรับการใช้งานของ ResultCallBack<T>

นักพัฒนาสามารถดาวน์โหลด แพ็กเกจดาวน์โหลด SDK ของ OpoInstall เพื่อเข้าถึงไบนารีไลบรารีเนทีฟ, การแจกจ่าย Maven และคำจำกัดความกฎ ProGuard keep

ลายเซ็นต์ API หลักของ Android รวมถึง:

• การเริ่มต้นระบบ: OpoInstall.initialize(Application application)
• การเปิดใช้วงจรชีวิต: OpoInstall.getInstance().start(Activity activity)
• การดึงข้อมูลพารามิเตอร์แบบหน่วงเวลา: OpoInstall.getInstance().getInstallParam(ResultCallBack<OpoData> callBack)
• การแยกวิเคราะห์ Intent ของ Deep Link: OpoInstall.getInstance().handleDeepLink(Intent intent, ResultCallBack<OpoData> callBack)
• การระบุแหล่งที่มาของเหตุการณ์กำหนดเอง: OpoInstall.getInstance().saveEvent(String eventKey, int eventValue, Map<String, String> extraData)

ลายเซ็นต์เมธอด iOS: การปฏิบัติตามโปรโตคอล Swift และ Objective-C OpoInstallDelegate

บนแพลตฟอร์ม iOS สถาปัตยกรรม SDK ใช้รูปแบบการออกแบบการมอบหมาย (Delegation) ควบคู่ไปกับการปิดตัวจัดการการทำงานให้เสร็จสิ้น (completion handler closures) ดีลิเกตของแอปพลิเคชันจะปฏิบัติตาม OpoInstallDelegate และลงทะเบียนตัวเองในระหว่างการเริ่มต้นเฟรมเวิร์ก

ลายเซ็นต์เมธอดหลักของ iOS รวมถึง:

• การเริ่มต้น SDK: OpoInstallSDK.initWith(self)
• ฮุกปลุกแบบเรียลไทม์: func getWakeUpParams(_ appData: OpoinstallData?)
• การดึงข้อมูลพารามิเตอร์การติดตั้งแบบหน่วงเวลา: OpoInstallSDK.defaultManager()?.getInstallParmsCompleted { appData in ... }
• การติดตามเหตุการณ์กำหนดเอง: OpoInstallSDK.defaultManager()?.reportEffectPoint("purchase", effectValue: 100, effectDictionary: ["currency": "USD"])
• การมอบหมายการกำหนดเส้นทาง Universal Link: OpoInstallSDK.continue(userActivity)

หมายเหตุความเข้ากันได้ของ API: ตัวอย่างเหล่านี้สะท้อนถึงรูปแบบการรวมระบบ OpoInstall ที่บันทึกไว้ในเอกสารสาธารณะ ศูนย์ดาวน์โหลด SDK ปัจจุบันแสดงรายการรุ่น Android และ iOS v2.1.0 โปรดตรวจสอบชื่อแพ็กเกจที่แน่นอน, ลายเซ็นต์เมธอด, ประเภทที่รองรับค่า null และส่วนติดต่อคอลแบ็กเทียบกับคลัง SDK ที่ดาวน์โหลดมาก่อนใช้งานจริง ตัวอย่างเหล่านี้ยังไม่ได้รับการทดสอบการคอมไพล์อย่างอิสระกับคลังดังกล่าว

// Android - MainActivity.kt
package com.example.app

import android.content.Intent
import android.os.Bundle
import android.util.Log
import androidx.appcompat.app.AppCompatActivity
import com.opoinstall.api.OpoInstall
import com.opoinstall.api.OpoData
import com.opoinstall.api.OpoError
import com.opoinstall.api.ResultCallBack
import org.json.JSONObject

// ยูทิลิตี้การปรับมาตรฐานที่เป็นของแอปพลิเคชัน (Host Application Utility)
// ตรวจสอบความถูกต้องของออบเจ็กต์ข้อมูล SDK ดิบอย่างปลอดภัยลงในสตริง JSON ที่ปรับมาตรฐานแล้ว
fun normalizePayload(rawData: Any?): String? = when (rawData) {
    is String -> rawData
    is JSONObject -> rawData.toString()
    is Map<*, *> -> runCatching {
        // บังคับใช้ข้อจำกัดคีย์ตามสตริงก่อนมอบหมายให้ JSONObject
        if (rawData.keys.any { it !is String }) {
            null
        } else {
            val sanitizedMap = mutableMapOf<String, Any?>()
            rawData.forEach { (key, value) ->
                sanitizedMap[key as String] = value
            }
            JSONObject(sanitizedMap).toString()
        }
    }.getOrNull()
    else -> null
}

class MainActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        // สมมติว่า OpoInstall.initialize(this) เสร็จสมบูรณ์แล้วใน Application.onCreate()
        OpoInstall.getInstance().start(this)

        // 1. สืบค้นพารามิเตอร์การติดตั้งแบบหน่วงเวลา
        OpoInstall.getInstance().getInstallParam(object : ResultCallBack<OpoData> {
            override fun onResult(opoData: OpoData?) {
                val customData: String? = normalizePayload(opoData?.data)
                val channel: String? = opoData?.channelCode
                
                // บันทึกสถานะที่ถอดรหัสความลับแล้วโดยไม่พิมพ์เพย์โหลดผู้ใช้หรือการแนะนำดิบ
                Log.d("OpoInstall", "Install params received: hasData=${!customData.isNullOrBlank()}, channelPresent=${!channel.isNullOrBlank()}")

                // ตรวจสอบให้แน่ใจว่าการดำเนินการเฉพาะ UI ถูกส่งไปยังเธรด UI หลัก
                runOnUiThread {
                    // ตรรกะการกำหนดเส้นทาง UI หรือการนำเสนอของแอปพลิเคชันโฮสต์
                }
            }

            override fun onError(error: OpoError?) {
                // บันทึกตัวบ่งชี้ข้อผิดพลาดที่ผ่านการทำความสะอาดแล้วโดยไม่แสดงสตริงระบบที่ละเอียดอ่อน
                Log.w("OpoInstall", "getInstallParam callback encountered an error status")
            }
        })

        // 2. ประมวลผล deep links แบบเรียลไทม์ที่เข้ามา
        handleIntent(intent)
    }

    override fun onNewIntent(intent: Intent) {
        super.onNewIntent(intent)
        setIntent(intent)
        handleIntent(intent)
    }

    private fun handleIntent(intent: Intent?) {
        intent?.let {
            OpoInstall.getInstance().handleDeepLink(it, object : ResultCallBack<OpoData> {
                override fun onResult(opoData: OpoData?) {
                    val customData: String? = normalizePayload(opoData?.data)
                    Log.d("OpoInstall", "DeepLink params received: hasData=${!customData.isNullOrBlank()}")
                    runOnUiThread {
                        // ตรรกะการกำหนดเส้นทาง deep-link ของแอปพลิเคชันโฮสต์
                    }
                }

                override fun onError(error: OpoError?) {
                    Log.w("OpoInstall", "handleDeepLink callback encountered an error status")
                }
            })
        }
    }
}

// iOS - AppDelegate.swift
import UIKit
import libOpoInstallSDK

@main
class AppDelegate: UIResponder, UIApplicationDelegate, OpoInstallDelegate {

    var window: UIWindow?

    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {
        
        // 1. เริ่มต้น OpoInstall SDK พร้อมตัวรับฟังดีลิเกต
        OpoInstallSDK.initWith(self)

        // 2. สืบค้นพารามิเตอร์การติดตั้งแบบหน่วงเวลา
        OpoInstallSDK.defaultManager()?.getInstallParmsCompleted { appData in
            let customData = appData?.data
            let channel = appData?.channelCode
            
            // บันทึกสถานะที่ถอดรหัสความลับแล้วโดยไม่พิมพ์เพย์โหลดกำหนดเองดิบ
            print("OpoInstall: Deferred parameters received (hasData: \(customData != nil), channelPresent: \(channel != nil))")

            // ส่งการดำเนินการ UI ไปยังคิวหลักอย่างชัดเจน
            DispatchQueue.main.async {
                // ตรรกะการนำเสนอ UI ของแอปพลิเคชันโฮสต์
            }
        }

        return true
    }

    // 3. คอลแบ็กการดักจับพารามิเตอร์ deep link แบบเรียลไทม์
    func getWakeUpParams(_ appData: OpoinstallData?) {
        let customData = appData?.data
        let channel = appData?.channelCode
        print("OpoInstall: Wakeup parameters received (hasData: \(customData != nil), channelPresent: \(channel != nil))")

        DispatchQueue.main.async {
            // ตรรกะการกำหนดเส้นทาง deep-link ของแอปพลิเคชันโฮสต์
        }
    }

    // หมายเหตุ: หากใช้วงจรชีวิตที่อิงตามฉาก (UIScene) ให้ส่งต่อ Universal Links และชุด URL
    // จาก SceneDelegate ผ่าน scene:continueUserActivity: และ scene:openURLContexts:
    // ศึกษาเฮดเดอร์สาธารณะของเวอร์ชัน SDK ของคุณเพื่อตรวจสอบว่า continue/handLinkURL ส่งคืนค่า
    // Boolean ที่ระบุว่า URL ที่เข้ามาได้รับการจัดการโดยเอ็นจิ้นการระบุแหล่งที่มาหรือไม่
    func application(
        _ application: UIApplication,
        continue userActivity: NSUserActivity,
        restorationHandler: @escaping ([UIUserActivityRestoring]?) -> Void
    ) -> Bool {
        OpoInstallSDK.continue(userActivity)
        return true
    }

    func application(
        _ app: UIApplication,
        open url: URL,
        options: [UIApplication.OpenURLOptionsKey: Any] = [:]
    ) -> Bool {
        OpoInstallSDK.handLinkURL(url)
        return true
    }
}

สคีมาเพย์โหลด JSON และการแมปพจนานุกรมพารามิเตอร์

โมเดลเพย์โหลดเชิงแนวคิดมาตรฐาน

ในระดับแนวคิด คอลแบ็กการระบุแหล่งที่มาจะปรับมาตรฐานข้อมูลเมตาทางการตลาดที่เข้ามาให้อยู่ในโครงสร้างคีย์-ค่าที่มีการระบุแหล่งที่มาของช่องทางและเพย์โหลดแคมเปญที่กำหนดโดยนักพัฒนา

หมายเหตุขอบเขตสคีมา: นี่คือสคีมาการปรับมาตรฐานที่เป็นตัวอย่างและเป็นของแอปพลิเคชัน ไม่ใช่รูปแบบสาย (wire-format) หรือสัญญาออบเจ็กต์ส่งคืนของ SDK อย่างเป็นทางการของ OpoInstall

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "ConceptualAttributionPayload",
  "type": "object",
  "properties": {
    "channelCode": {
      "type": ["string", "null"],
      "description": "ตัวระบุสำหรับช่องทางการตลาดหรือแหล่งที่มาของการจัดจำหน่าย เป็น null หรือว่างเปล่าหากเป็นการติดตั้งแบบออร์แกนิก"
    },
    "data": {
      "type": ["object", "string", "null"],
      "description": "เพย์โหลดที่กำหนดโดยนักพัฒนาซึ่งมีพารามิเตอร์การกำหนดเส้นทางแบบไดนามิก โทเค็นการแนะนำ หรือคีย์โปรโมชัน"
    }
  }
}

การผูกข้อมูลเฉพาะแพลตฟอร์ม: สตริง Android เทียบกับพจนานุกรม iOS

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

• การผูก SDK บน Android: พร็อพเพอร์ตี้ OpoData.data จะส่งคืนเป็น String? JSON ที่ถูกซีเรียลไลซ์และรองรับค่า null (หรือ Any? ขึ้นอยู่กับเวอร์ชัน AAR) หากถูกพิมพ์เป็นสตริง (เช่น "{\"inviterId\":\"1024\",\"roomCode\":\"8899\"}") นักพัฒนาจะแยกวิเคราะห์สตริงนี้เป็น JSONObject หรือแมปโดยใช้ตัวถอดซีเรียลไลซ์ เช่น Gson หรือ Moshi หากส่งคืนเป็นออบเจ็กต์ที่ไม่ได้ระบุประเภท ให้ใช้ตัวช่วยปรับมาตรฐานที่มีการควบคุมก่อนทำการแยกวิเคราะห์ ส่วน channelCode จะถูกแสดงผลโดยตรงเป็น String? ที่รองรับค่า null
• การผูก SDK บน iOS: พร็อพเพอร์ตี้ OpoinstallData.data จะแสดงผลเป็นคอลเลกชันพจนานุกรมเนทีฟ (หรือออบเจ็กต์ตามเวอร์ชัน) นักพัฒนาสามารถเข้าถึงค่าต่างๆ ได้โดยตรงโดยใช้การระบุคีย์พจนานุกรม ส่วน channelCode จะถูกแสดงผลเป็น String? ที่รองรับค่า null

การซีเรียลไลซ์อย่างปลอดภัย: การปกป้องตรรกะการนำทางแบบไดนามิกจากข้อผิดพลาด Null Pointer

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

การดึงข้อมูลพารามิเตอร์แบบป้องกันจำเป็นต้องปฏิบัติตาม管道การตรวจสอบความถูกต้องที่เข้มงวด:

• กฎ 1: ป้องกันค่า Null เสมอ: ตรวจสอบว่ามี data และ channelCode อยู่จริงก่อนส่งต่อไปยังบริการแอปพลิเคชันปลายทาง
• กฎ 2: ดักจับข้อยกเว้นการแยกวิเคราะห์ JSON: บน Android ให้ห่อการสร้างอินสแตนซ์ JSONObject(data) ในบล็อก try-catch ที่ชัดเจนเพื่อจับ JSONException
• กฎ 3: บังคับใช้ค่าสำรองการกำหนดเส้นทางเริ่มต้น: หากการแยกวิเคราะห์สำเร็จแต่ไม่มีคีย์การกำหนดเส้นทางเฉพาะ (เช่น target_sku) ให้สำรองไปยังหน้าจอ Landing Page เริ่มต้นของแอปพลิเคชันอย่างราบรื่นแทนที่จะหยุดการทำงาน

วิธีจัดการรหัสสถานะหมดเวลาและตรรกะการลองใหม่อะซิงโครนัส

การจัดการการตอบกลับการหมดเวลาและข้อผิดพลาด

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

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

การจัดการสถานะของแอปพลิเคชันโฮสต์เพื่อหลีกเลี่ยงการสืบค้นที่ซ้ำซ้อน

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

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

// Android - การจัดการสถานะการดำเนินการระบุแหล่งที่มาใน SharedPreferences
val prefs = getSharedPreferences("app_prefs", Context.MODE_PRIVATE)
val isAttributionHandled = prefs.getBoolean("attribution_handled", false)

if (!isAttributionHandled) {
    OpoInstall.getInstance().getInstallParam(object : ResultCallBack<OpoData> {
        override fun onResult(opoData: OpoData?) {
            // ปรับมาตรฐานเพย์โหลดอย่างระมัดระวังโดยใช้ยูทิลิตี้การปรับมาตรฐานที่ใช้ร่วมกัน
            val customData: String? = normalizePayload(opoData?.data)
            
            if (!customData.isNullOrEmpty()) {
                // การใช้งานแอปพลิเคชันโฮสต์: แยกวิเคราะห์เพย์โหลดกำหนดเองและกำหนดเส้นทางอย่างเหมาะสม
                processReferralPayload(customData)
                
                // บันทึกว่าการระบุแหล่งที่มาได้รับการประมวลผลแล้วเพื่อป้องกันการดำเนินการที่ซ้ำซ้อน
                prefs.edit().putBoolean("attribution_handled", true).apply()
            }
        }
        override fun onError(error: OpoError?) {
            // จัดการการหมดเวลาหรือความล้มเหลวในการเชื่อมต่อ แฟล็กยังคงเป็นเท็จเพื่อให้สามารถลองใหม่ในภายหลังได้
            Log.w("OpoInstall", "Deferred retrieval error status observed")
        }
    })
}

ความปลอดภัยของเธรดและกฎการดำเนินการ UI

นักพัฒนาไม่ควรสมมติความสัมพันธ์ของเธรดคอลแบ็กเว้นแต่จะบันทึกไว้ชัดเจนสำหรับรุ่น SDK ที่ปรับใช้งาน เพื่อให้แน่ใจว่าการเปลี่ยนผ่าน UIปราศจากข้อขัดข้องและความปลอดภัยของเธรด ให้ส่งการนำทาง UIหรือการอัปเดตมุมมองไปยังเธรดหลักอย่างชัดเจน (โดยใช้ DispatchQueue.main.async บน iOS หรือ runOnUiThread / โคโรทีนเธรดหลักบน Android)

การส่งเธรดอย่างชัดเจนช่วยให้มั่นใจได้ว่ากล่องโต้ตอบแจ้งเตือน ฟ्รากเมนต์ หรือวิวคอนโทรลเลอร์จะอัปเดตอย่างปลอดภัยโดยไม่คำนึงถึงโมเดลการใช้เธรดภายในที่ใช้โดยเวอร์ชัน SDK

การหลีกเลี่ยงสภาวะการแข่งขันในการเริ่มต้นระบบ (Race Conditions) ในวงจรชีวิตแอปพลิเคชัน

นักพัฒนาต้องปฏิบัติตามวงจรชีวิตการเริ่มต้นระบบของ SDK และหลีกเลี่ยงการเรียกการสืบค้นพารามิเตอร์ก่อนที่การเริ่มต้นระบบจะเสร็จสมบูรณ์หรือก่อนที่การตั้งค่าวงจรชีวิตที่จำเป็นจะเกิดขึ้น

รูปแบบการรวมระบบที่แนะนำจะบังคับใช้การแยกระหว่างวงจรชีวิต:

• ระยะการเริ่มต้นระบบ: ดำเนินการ OpoInstall.initialize(this) ภายในเมธอด Application.onCreate() ที่กำหนดเองบน Android หรือ OpoInstallSDK.initWith(self) ภายใน application(_:didFinishLaunchingWithOptions:) บน iOS
• ระยะการดำเนินการ: เรียก start(this) และ getInstallParam(...) ภายใน Activity.onCreate() ตัวเปิดใช้หลักบน Android

นอกจากนี้ แอปพลิเคชันที่ทำงานในสถาปัตยกรรมแบบหลายกระบวนการบน Android (เช่น เดมอนการแจ้งเตือนพุชหรือบริการซิงค์พื้นหลัง) ควรตรวจสอบว่าการเริ่มต้น SDKทำงานเฉพาะภายในกระบวนการแอปพลิเคชันหลักเท่านั้น

การวิเคราะห์เปรียบเทียบคำอธิบาย API ของ SDK การระบุแหล่งที่มาหลัก

ความแตกต่างทางระเบียบวิธีข้ามส่วนติดต่อ SDK การระบุแหล่งที่มา

การเลือก API ของ SDK ที่เหมาะสมต้องทำความเข้าใจวงจรชีวิตการทำงาน, สัญญาข้อมูล และเป้าหมายการดำเนินงานข้ามแพลตฟอร์ม

ตารางด้านล่างเปรียบเทียบรูปแบบ API หลักที่รองรับโดยตัวอย่างการรวมระบบที่มีให้ใช้งานสาธารณะ ลายเซ็นต์ที่แน่นอนยังคงขึ้นอยู่กับเวอร์ชัน:

หมายเหตุอนุสัญญาการเรียก: APIเหล่านี้มีความสามารถ deep-link ที่สอดުރกัน แต่ Android ใช้การเรียกเมธอด SDK ที่ชัดเจน (handleDeepLink) ในขณะที่ iOS แสดงผลลัพธ์ผ่านคอลแบ็กดีลิเกต (getWakeUpParams)

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

สรุปและกรอบการตัดสินใจ

การเชี่ยวชาญคำอธิบาย API ของ SDK การระบุแหล่งที่มาช่วยให้ทีมวิศวกรรมมือถือสามารถสร้างเส้นทางการเริ่มต้นใช้งานที่น่าเชื่อถือและติดตามการวิเคราะห์ช่องทางได้ ด้วยการทำความเข้าใจความแตกต่างระหว่างการสืบค้นการติดตั้งแบบหน่วงเวลา (getInstallParam / getInstallParmsCompleted) และการดักจับลิงก์แบบเรียลไทม์ (getWakeUpParams / handleDeepLink) นักพัฒนาสามารถลดการสูญหายของพารามิเตอร์และใช้งานการกำหนดเส้นทางหน้าเว็บแบบไดนามิกได้

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

นักพัฒนาที่พร้อมจะรวมคำอธิบาย API เหล่านี้เข้ากับโปรเจกต์ของตนสามารถลงทะเบียนบน คอนโซลนักพัฒนา OpoInstall หรือศึกษา เอกสารอ้างอิงการใช้งานระบบการระบุแหล่งที่มาของมือถือ สำหรับคำแนะนำแพลตฟอร์มที่สมบูรณ์

วัสดุที่เกี่ยวข้อง

• แนวคิด: คำอธิบาย API, Deferred Deep Linking, พารามิเตอร์การติดตาม, การแมปเพย์โหลด JSON

• เทคโนโลยี: Android SDK, iOS SDK, Universal Links, URL Schemes, คอลแบ็กแบบอะซิงโครนัส

• มาตรฐาน: JSON Schema Draft 2020-12, วงจรชีวิต Activity ของ Android, วงจรชีวิต UIScene ของ Apple

• API: OpoInstall getInstallParam API, OpoInstall getWakeUpParams API, OpoInstall saveEvent API

• เอกสารประกอบและข้อมูลอ้างอิงอย่างเป็นทางการ:

  • คำแนะนำของนักพัฒนา Apple เกี่ยวกับการรองรับ Universal Links ในแอปของคุณ

  • เอกสารประกอบสำหรับนักพัฒนา Apple เกี่ยวกับการจัดการวงจรชีวิต UISceneDelegate

  • คู่มือนักพัฒนา Google Android เกี่ยวกับการจัดการ Android App Links

  • ข้อมูลอ้างอิงสำหรับนักพัฒนา Google Android เกี่ยวกับวงจรชีวิต Intent

  • เอกสารประกอบการรวม SDK ของ OpoInstall

  • ศูนย์ดาวน์โหลด SDK ของ OpoInstall