الانتقال إلى المحتوى الرئيسي
مكوّن إضافي متعدد المنصات لـ Flutter يغلّف حزمتي SDK الأصليتين لنظامي iOS وAndroid، ويوفّر واجهة Dart موحّدة للتحقق من الهوية.

مستودع GitHub

اطّلع على الشيفرة المصدرية والأمثلة على GitHub

حزمة pub.dev

didit_sdk

SDK الأصلي: هذا هو النهج الموصى به لتطبيقات Flutter. يغلّف الـ SDK حزمتي SDK الأصليتين لنظامي iOS وAndroid عبر قنوات المنصة، لتوفير أفضل تجربة للمستخدم، ومعالجة محسّنة للكاميرا، ودعم كامل لـ NFC.


المتطلبات

متطلبات المنصة

الموافقة البيومترية تتطلب SDK الأصلي 4.10.0 أو أحدث. بالنسبة للأشخاص الخاضعين لقوانين Illinois أو Texas أو Colorado، يمكن لـ Didit أن تطلب الموافقة البيومترية الصريحة قبل أول التقاط للوجه. يعرض إصدار Flutter SDK الذي يثبّت SDK الأصلي لـ iOS وAndroid بالإصدار 4.10.0 أو أحدث هذه الخطوة. الإصدارات الأقدم لا تستطيع عرض هذه الخطوة: تعمل جلساتها كما كانت من قبل، ويسجّل القرار الموافقة على أنها لم تُجمع، مع biometric_consent.reason: "BIOMETRIC_CONSENT_UNSUPPORTED_SDK". قم بالترقية إذا كنت تتحقق من أشخاص في تلك الولايات.

التثبيت

أو أضفه يدويًا إلى ملف pubspec.yaml:
ثم شغّل:

متغيرات حزمة SDK الأصلية

تتضمن حزمة didit_sdk حزمة SDK الأصلية كاملة. لتقليل حجم الملف الثنائي، استخدم بدلًا من ذلك إحدى حزم المتغيرات، فهي تعرض واجهة Dart نفسها بالضبط، وتثبّت إصدار SDK الأصلي المطابق على المنصتين:
أضف حزمة واحدة فقط من هذه الحزم، واستورد من الحزمة التي اخترتها، على سبيل المثال package:didit_sdk_core/sdk_flutter.dart.

إعداد iOS

تدعم الإضافة مديري تبعيات iOS في Flutter كليهما: Swift Package Manager وCocoaPods.

Swift Package Manager

إذا كان دعم Swift Package Manager مفعّلًا في إصدار Flutter لديك (فعّله باستخدام flutter config --enable-swift-package-manager في Flutter 3.24+)، تُستخدم الإضافة كحزمة Swift تلقائيًا. لا حاجة إلى أي إعداد في Podfile، إذ تُحل تبعية DiditSDK الأصلية من GitHub تلقائيًا. اضبط الحد الأدنى لإصدار النشر في iOS لتطبيقك في Xcode (الهدف Runner والمشروع) على الحد الأدنى للحزمة التي اخترتها: 15.0 لـ didit_sdk وdidit_sdk_nfc، و13.0 لـ didit_sdk_core وdidit_sdk_autodetection.

CocoaPods

مع didit_sdk، تختار الإضافة متغير SDK الأصلي لـ iOS من $DiditSdkIosVariant، وهو متغير عام في Ruby تضبطه في ملف ios/Podfile الخاص بتطبيقك (لا توجد حزمة DiditSDK في CocoaPods trunk):
إذا استخدمت حزمة متغير (didit_sdk_core أو didit_sdk_autodetection أو didit_sdk_nfc)، فهي تثبّت الوحدة الفرعية الأصلية الخاصة بها مباشرة وتتجاهل $DiditSdkIosVariant. اجعل سطر pod في Podfile وإصدار النشر متطابقين مع تلك الحزمة، على سبيل المثال pod 'DiditSDK/Core', :podspec => ... مع platform :ios, '13.0'.
المتغيران all وnfc يتطلبان هدف نشر iOS 15.0+، بينما يمكن للمتغيرين core وautodetection استهداف iOS 13.0. عند التبديل بين المتغيرات، نظّف CocoaPods أولًا (rm -rf Pods Podfile.lock) حتى لا يُعاد استخدام متغير SDK السابق.
يجب أن يطابق الوسم في رابط podspec إصدار SDK الأصلي لـ iOS الذي يثبّته إصدار didit_sdk لديك (الإصدار 4.13.2 يثبّت SDK الأصلي 4.13.2). إذا كان الرابط يشير إلى وسم أقدم، يفشل pod install في حل التبعية، لأن CocoaPods يجد podspec يعلن ذلك الإصدار الأقدم، بينما تتطلب الإضافة تطابقًا تامًا. عند ترقية didit_sdk، حدّث الوسم في هذا الرابط إلى الإصدار نفسه.

إعداد Android

تعتمد الإضافة افتراضيًا على حزمة SDK الكاملة لـ Android مع NFC. لبناء التطبيق بدون NFC، أضف هذا إلى android/gradle.properties:
يغيّر هذه التبعية من me.didit:didit-sdk إلى me.didit:didit-sdk-core، فتُزال وحدة قارئ NFC وتبعياتها JMRTD وSCUBA وBouncyCastle. عند تفعيل NFC (الافتراضي)، أضف قاعدة التجميع هذه إلى android/app/build.gradle.kts لحل ملف بيانات وصفية مكرر من BouncyCastle:
بدون هذه القاعدة يفشل البناء بخطأ mergeDebugJavaResource. لا تلزم القاعدة عندما يكون diditSdkAndroidNfcEnabled=false.
تُحل حزمة SDK الأصلية لـ Android من مستودع Maven بعيد على GitHub (منذ الإضافة 3.4.0)، ولا حاجة إلى أي إعداد Maven يدوي في تطبيقك.

الأذونات

iOS

أضف المفاتيح التالية إلى ملف Info.plist الخاص بالتطبيق:
إذا كان أي مفتاح خصوصية مطلوب في iOS مفقودًا، فإن iOS ينهي التطبيق فور محاولة الحزمة الوصول إلى ذلك المورد المحمي. على سبيل المثال، يؤدي غياب NSCameraUsageDescription إلى تعطل التطبيق عندما يضغط المستخدم زر التقاط الصورة في كاميرا المستندات.

إعدادات NFC

لتفعيل قراءة NFC لجوازات السفر وبطاقات الهوية التي تحتوي على شرائح:
  1. أضف إمكانية NFC في Xcode:
    • حدّد الهدف (target) الخاص بك > Signing & Capabilities > + Capability > Near Field Communication Tag Reading
  2. أضف معرّفات ISO7816 إلى Info.plist:
يتيح D392F000260100000001 للحزمة قراءة Japan My Number Card عبر JPKI، فبدونه لا يُبلّغ iOS الحزمة بوجود البطاقة. قراءة My Number Card غير مفعّلة في بيئة الإنتاج بعد، ولا يغيّر هذا المعرّف شيئًا بالنسبة إلى المستندات الأخرى، لذا يمكنك إضافته الآن.
  1. أضف ملف الاستحقاقات (entitlements) مع تفعيل قراءة وسوم NFC:
تأكد من أن ملف توصيف التوفير (provisioning profile) الخاص بالتطبيق يتضمن إمكانية NFC Tag Reading. إذا لم يكن معرّف الحزمة (bundle ID) مهيأً لـ NFC في حساب Apple Developer الخاص بك، فسيفشل Xcode في التوقيع بسبب غياب الاستحقاق com.apple.developer.nfc.readersession.formats. إعدادات NFC هذه غير لازمة للمتغيرين core أو autodetection ($DiditSdkIosVariant)، ولا للحزمتين didit_sdk_core / didit_sdk_autodetection، إذ لا يقرأ أيٌّ منها الشرائح.

Android

تُعلن الحزمة الأذونات التالية في ملف AndroidManifest.xml الخاص بها، وتُدمج تلقائيًا: تُعلن ميزتا الكاميرا وNFC في الجهاز كميزتين اختياريتين (android:required="false")، فيمكن تثبيت التطبيق على أجهزة لا تملك هذه الميزات. عندما تكون diditSdkAndroidNfcEnabled=false، لا تضيف الحزمة إذن NFC ولا الميزة الخاصة به على Android.

أذونات وقت التشغيل

تتولى الحزمة طلبات أذونات وقت التشغيل في Android تلقائيًا. عندما يصل المستخدم إلى خطوة تتطلب الوصول إلى الكاميرا:
  1. تطلب الحزمة إذن الكاميرا إذا لم يكن ممنوحًا من قبل
  2. إذا رفض المستخدم الإذن، تظهر رسالة خطأ مع زر Try Again
  3. إذا منح المستخدم الإذن، يتابع مسار التحقق
لست بحاجة إلى طلب إذن الكاميرا في كود التطبيق قبل استدعاء startVerification()، فالحزمة تدير ذلك داخليًا.

البدء السريع


طرق التكامل

تدعم الحزمة طريقتين للتكامل:

الطريقة 1: token الجلسة (موصى به للإنتاج)

أنشئ جلسة على الخادم الخلفي باستخدام واجهة برمجة تطبيقات إنشاء جلسة التحقق، ثم مرّر token إلى الحزمة:
يمنحك هذا النهج تحكمًا كاملًا في:
  • ربط الجلسات بمستخدميك (vendor_data)
  • ضبط البيانات الوصفية المخصصة
  • ضبط عمليات الاستدعاء لكل جلسة

الطريقة 2: معرّف سير العمل (تكامل أبسط)

للتكاملات الأبسط، يمكن للحزمة إنشاء الجلسات مباشرة باستخدام معرّف سير العمل الخاص بك، دون الحاجة إلى خادم خلفي:
معاملات الجلسة المتقدمة (contact_details وexpected_details وmetadata) مدعومة فقط عبر طريقة token الجلسة، حيث يستدعي خادمك واجهة برمجة تطبيقات إنشاء الجلسة بدعم كامل لهذه المعاملات. مرّر session_token المُعاد إلى DiditSdk.startVerification().

الإعدادات

خصّص سلوك SDK بتمرير كائن DiditConfig:
مع startVerificationWithWorkflow، مرّر config كمعامل مسمّى:

خيارات الإعداد

خيارات الكاميرا

تتطابق خيارات الكاميرا مع خيارات كاميرا Web SDK. كل عدسة هي CameraLens.front أو CameraLens.back. إذا لم يكن الجهاز يحتوي على العدسة المطلوبة، يستخدم SDK أول كاميرا متوفرة لديه. يُخفى مبدّل الكاميرا أيضاً على الأجهزة التي تحتوي على كاميرا واحدة فقط. اضبط خيار المبدّل على false لتثبيت المستخدم على العدسة الافتراضية لتلك الخطوة.
السمات والألوان: تُضبط الألوان والخلفيات وإعدادات شاشة المقدمة من خلال إعدادات العلامة البيضاء في Didit Console، وليس في إعدادات SDK. وهذا يضمن هوية بصرية متسقة عبر جميع المنصات.

دعم اللغات

يدعم SDK 54 لغة. إذا لم تحدد أي لغة، يستخدم SDK لغة الجهاز مع الإنجليزية كلغة احتياطية.
عرض جميع اللغات المدعومة ←

معاملات الجلسة المتقدمة

لا تُدعم المعاملات مثل contact_details وexpected_details وmetadata إلا من خلال طريقة Session Token. يستدعي الخادم الخاص بك POST /v3/session/ مع دعم كامل للمعاملات، ثم يمرر session_token المُرجَع إلى SDK.
لا تقبل طريقة Dart startVerificationWithWorkflow سوى workflowId وvendorData وconfig. كانت الإصدارات السابقة للإصدار 3.4.0 تعرض المعاملات contactDetails وexpectedDetails وmetadata، لكن أُزيلت لأن endpoint الخاص بـ Unilink لا يلتزم بها.

معالجة النتائج

تُعيد كلتا الطريقتين startVerification وstartVerificationWithWorkflow قيمة Future<VerificationResult>. النتيجة فئة مغلقة (sealed class)، فاستخدم مطابقة الأنماط لتحديد النتيجة.

حالات النتيجة

خصائص SessionData

أنواع الأخطاء

يعرض التعداد VerificationErrorType الحالات التالية:

انقطاع الاتصال

إذا فقد الجهاز اتصاله أثناء التحقق، يعرض SDK شاشة “No internet connection” فوق التدفق بدلاً من ترك خطوة في حالة تحميل. يستمر SDK في التحقق في الخلفية، ويغلق الشاشة تلقائياً بمجرد إمكانية الوصول إلى Didit مرة أخرى، ويتابع المستخدم من الخطوة التي كان عليها. تعرض الشاشة Try Again و، ما لم يكن زر الإغلاق معطلاً، Exit Verification. يؤدي الخروج إلى إنهاء التحقق بنتيجة VerificationFailed يكون نوع الخطأ فيها networkError، لكي يعرف تطبيقك أن المستخدم خرج بسبب الاتصال.

مثال كامل لمعالجة النتائج


مثال شامل من البداية إلى النهاية (الخادم الخلفي → Flutter SDK → webhook)

التكامل الجاهز للإنتاج: ينشئ الخادم الخاص بك الجلسة، ويستقبل تطبيق Flutter الخاص بك session_token، ويُشغّل التدفق عبر SDK. يُرسَل القرار النهائي إلى الخادم عبر webhook، ولا تعتمد أبداً على نتيجة جانب العميل وحدها.

1. الخادم الخلفي: إنشاء الجلسة

2. Flutter: تبادل token وتشغيل SDK

3. الخادم الخلفي: استقبال القرار النهائي عبر webhook

راجع دليل webhook لمعرفة تفاصيل التحقق من توقيع HMAC.

مثال كامل


آخر تعديل في ٧ نوفمبر ٢٠٢٦