URL Scheme: คืออะไร ทำงานอย่างไร และใช้งานในการพัฒนาอย่างไร

URL Scheme คืออะไร?

URL Scheme — เป็นตัวระบุโปรโตคอลที่ไม่ซ้ำกันที่แอปลงทะเบียนในระบบปฏิบัติการเพื่อรับการเรียกผ่านลิงก์แบบกำหนดเอง เมื่อผู้ใช้คลิกลิงก์เช่น myapp://profile/123 ระบบจะระบุแอปที่ลงทะเบียนสกีมา myapp และส่งต่อการควบคุมให้กับแอปพร้อม URI เต็ม กลไกนี้ช่วยให้แอปสามารถแลกเปลี่ยนข้อมูลและเปิดซึ่งกันและกันได้โดยไม่ต้องใช้โครงสร้างพื้นฐานเซิร์ฟเวอร์

แนวคิดของ URL Scheme ยืมมาจากมาตรฐานเว็บ RFC 3986 โดยตรง โดยที่สกีมา URI เป็นส่วนประกอบแรกของตัวระบุทรัพยากรสากลใดๆ ในการพัฒนามือถือ แนวคิดนี้ถูกปรับให้เข้ากับการสื่อสารระหว่างแอป โดยที่ตัวแอปเองทำหน้าที่เป็นตัวจัดการลิงก์แทนเซิร์ฟเวอร์ HTTP

ตัวอย่าง URL Schemes ที่รู้จัก

แอปยอดนิยมหลายแห่งลงทะเบียน URL Schemes ของตนเองเพื่อการรวมเข้ากับบริการของบุคคลที่สาม ตัวอย่างเช่น Spotify ใช้สกีมา spotify://, Telegram ใช้ tg:// และ Instagram ใช้ instagram:// นักพัฒนามักสร้างสกีมาแบบ appname:// สำหรับการนำทางภายในและการทดสอบหน้าจอแบบครบวงจร

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

ไวยากรณ์ URL Scheme: สกีมา โฮสต์และเส้นทาง

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

ไวยากรณ์เต็มรูปแบบคือ scheme://host/path?key=value#fragment สกีมาเป็นองค์ประกอบบังคับเพียงอย่างเดียว ส่วนที่เหลือถูกกำหนดโดยความต้องการของการนำไปใช้งานเฉพาะ เครื่องหมายทับคู่หลังจากสกีมานั้นยืมมาจาก HTTP ในอดีตและไม่บังคับตามข้อกำหนดอย่างเคร่งครัด แต่ใช้กันทั่วไปเป็นธรรมเนียมปฏิบัติ

ส่วนประกอบ URI

สำหรับการแสดงโครงสร้าง URI ด้วยภาพ จะใช้ตารางส่วนประกอบ แต่ละองค์ประกอบมีวัตถุประสงค์และระดับความบังคับของตนเอง

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

URL Scheme ทำงานอย่างไรใน iOS

iOS ต้องการการลงทะเบียนอย่างชัดเจนของแต่ละ URL Scheme ในไฟล์ Info.plist ของโปรเจกต์ นักพัฒนาเพิ่มอาร์เรย์ CFBundleURLTypes ซึ่งแต่ละองค์ประกอบประกอบด้วยตัวระบุ (CFBundleURLName) และรายการสกีมาที่รองรับ (CFBundleURLSchemes) หลังจากลงทะเบียน ระบบจะส่งต่อการเรียกที่เข้ามาทั้งหมดบนสกีมาที่ลงทะเบียนไปยังแอปโดยอัตโนมัติ

การจัดการ URL Scheme ที่เข้ามาเกิดขึ้นในตัวแทนแอปผ่านเมธอด application(_:open:options:) เมธอดนี้รับออบเจกต์ URL ซึ่งเส้นทางและพารามิเตอร์คิวรีถูกแยกออกเพื่อตัดสินใจนำทาง ตัวจัดการต้องคืนค่า Bool ที่ระบุความสำเร็จของการดำเนินการ

การจัดการใน AppDelegate

ด้านล่างนี้คือตัวอย่างการใช้งานตัวจัดการ URL Scheme ในภาษา Swift โค้ดสาธิตการแยกโฮสต์และพารามิเตอร์คิวรีจาก URI ที่เข้ามาโดยใช้ URLComponents

func application(
    _ app: UIApplication,
    open url: URL,
    options: [UIApplication.OpenURLOptionsKey: Any]
) -> Bool {
    let host = url.host
    let params = URLComponents(
        url: url,
        resolvingAgainstBaseURL: false
    )?.queryItems
    if host == "profile" {
        navigateToProfile(params)
    }
    return true
}

เมธอดใช้ URLComponents สำหรับการแยกวิเคราะห์พารามิเตอร์คิวรีอย่างปลอดภัย วิธีการนี้ดีกว่าการแยกวิเคราะห์สตริงด้วยตนเองเนื่องจากจัดการกับการเข้ารหัสเปอร์เซ็นต์และการถอดรหัสอักขระพิเศษในค่าพารามิเตอร์โดยอัตโนมัติ

URL Scheme ทำงานอย่างไรใน Android

Android ใช้ระบบ Intent Filter เพื่อกำหนดเส้นทางดีพลิงก์ตาม URL Scheme นักพัฒนาประกาศตัวกรองใน AndroidManifest.xml ภายในแท็ก Activity ที่ควรจัดการลิงก์ ตัวกรองประกอบด้วยแอคชัน VIEW หมวดหมู่ BROWSABLE และ DEFAULT และแท็ก data ที่ระบุสกีมา โฮสต์และ pathPrefix

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

การกำหนดค่า Intent Filter

ตัวอย่างการประกาศ Intent Filter ใน AndroidManifest.xml เพื่อจัดการสกีมา myapp บน Activity การรวมกันของ action และ category เป็นสิ่งจำเป็นสำหรับการกำหนดเส้นทางดีพลิงก์ที่ถูกต้อง

<activity android:name=".MainActivity">
    <intent-filter>
        <action android:name="android.intent.action.VIEW" />
        <category
            android:name="android.intent.category.DEFAULT" />
        <category
            android:name="android.intent.category.BROWSABLE" />
        <data
            android:scheme="myapp"
            android:host="profile"
            android:pathPrefix="/user" />
    </intent-filter>
</activity>

หลังจากกำหนดค่าตัวกรองใน Activity แล้ว ต้องเรียก intent.getData() เพื่อรับ URI สิ่งสำคัญคือต้องตรวจสอบ intent และข้อมูลว่าเป็น null หรือไม่ เนื่องจาก Activity อาจถูกเริ่มต้นโดยไม่มีดีพลิงก์ขาเข้า เช่น ระหว่างการเริ่มต้นมาตรฐานจากตัวเรียกใช้

การส่งพารามิเตอร์ผ่าน URL Scheme

พารามิเตอร์คิวรีใน URL Scheme จะถูกส่งหลังเครื่องหมายคำถามในรูปแบบ คีย์=ค่า คั่นด้วยเครื่องหมายและ รูปแบบนี้เหมือนกับคำขอ HTTP และประมวลผลได้ง่ายโดยเครื่องมือมาตรฐานของแพลตฟอร์ม พารามิเตอร์ต้องถูกเข้ารหัสโดยใช้การเข้ารหัสเปอร์เซ็นต์สำหรับอักขระทั้งหมดที่ไม่อยู่ในชุดอักขระ URI ที่อนุญาต

ตัวอย่างลิงก์แบบเต็มพร้อมพารามิเตอร์: myapp://profile?userId=42&source=email&ref=abc123 หลังจากแยก URL แล้ว แอปจะแยกวิเคราะห์รายการคิวรีทั้งหมดตามลำดับและตัดสินใจนำทางไปยังหน้าจอเป้าหมายตามค่าของพารามิเตอร์

ข้อจำกัดความยาว URI

เมื่อส่งข้อมูลที่ซับซ้อน สิ่งสำคัญคือต้องพิจารณาข้อจำกัดความยาวของ URI บน iOS ความยาวสูงสุดของ URL Scheme ถูกจำกัดไว้ที่ 2 KB หลังจากนั้นระบบจะตัดลิงก์ บน Android ขีดจำกัดอยู่ที่ประมาณ 8 KB แต่ค่าที่แน่นอนขึ้นอยู่กับเวอร์ชันของระบบปฏิบัติการและผู้ผลิตอุปกรณ์ สำหรับข้อมูลปริมาณมาก ขอแนะนำให้ส่งเฉพาะตัวระบุเซสชันผ่าน URL Scheme และโหลดข้อมูลที่เหลือจากเซิร์ฟเวอร์

ข้อจำกัดและทางเลือกของ URL Scheme

ข้อเสียหลักของ URL Scheme คือไม่สามารถจัดการลิงก์ได้หากไม่ได้ติดตั้งแอปบนอุปกรณ์ เบราว์เซอร์แสดงข้อผิดพลาดและผู้ใช้สูญเสียบริบทการนำทาง เพื่อแก้ปัญหานี้ Apple เปิดตัว Universal Links ใน iOS 9 และ Google เปิดตัว App Links ใน Android 6 ทั้งสองกลไกลงทะเบียนผ่านโดเมนเว็บที่เชื่อมโยงกับแอป

Universal Links และ App Links ทำงานเหมือนลิงก์ HTTPS ทั่วไป แต่เมื่อติดตั้งแอปแล้ว ลิงก์จะเปิดแอปโดยไม่มีกล่องโต้ตอบเลือก หากไม่ได้ติดตั้งแอป ลิงก์จะเปิดหน้าเว็บบนโดเมนเดียวกัน รักษาประสบการณ์ผู้ใช้ไว้ ทำให้เป็นทางเลือกที่ต้องการสำหรับสภาพแวดล้อมการผลิต

กลไกสำรอง

สำหรับ URL Scheme บน iOS และ Android ไม่มีกลไกสำรองในตัว นักพัฒนาใช้โซลูชันเซิร์ฟเวอร์ตัวกลาง: ลิงก์นำไปสู่หน้าเว็บที่ตรวจสอบการติดตั้งแอปผ่าน JavaScript และเปลี่ยนเส้นทางไปยังสกีมาหรือร้านค้าแอป Firebase Dynamic Links และ Branch.io นำเสนอโซลูชันสำเร็จรูปสำหรับปัญหานี้พร้อมรองรับดีพลิงก์แบบรอการตัดบัญชีที่กำหนดสถานะการติดตั้งโดยอัตโนมัติและกำหนดเส้นทางผู้ใช้โดยไม่ต้องพัฒนาไปป์ไลน์เซิร์ฟเวอร์แบบกำหนดเอง

ความซับซ้อนเพิ่มเติมเกิดขึ้นเมื่อใช้ URL Scheme บน iOS 15+ และ Android 12+ ซึ่งกฎความเป็นส่วนตัวถูกทำให้เข้มงวดขึ้น Safari บล็อกความพยายามเปิดสกีมาที่ยังไม่ได้ลงทะเบียนโดยไม่มีการยืนยันล่วงหน้า และ Android 12 จำกัดการมองเห็นแอปที่ติดตั้งผ่าน PackageManager การเปลี่ยนแปลงเหล่านี้ทำให้การใช้ URL Scheme สำหรับการสื่อสารระหว่างแอปมีความน่าเชื่อถือน้อยกว่าในเวอร์ชันก่อนหน้าของแพลตฟอร์ม