مستودع 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 السابق.إعداد 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 الخاص بالتطبيق:
إعدادات NFC
لتفعيل قراءة NFC لجوازات السفر وبطاقات الهوية التي تحتوي على شرائح:-
أضف إمكانية NFC في Xcode:
- حدّد الهدف (target) الخاص بك > Signing & Capabilities > + Capability > Near Field Communication Tag Reading
-
أضف معرّفات ISO7816 إلى
Info.plist:
D392F000260100000001 للحزمة قراءة Japan My Number Card عبر JPKI، فبدونه لا يُبلّغ iOS الحزمة بوجود البطاقة. قراءة My Number Card غير مفعّلة في بيئة الإنتاج بعد، ولا يغيّر هذا المعرّف شيئًا بالنسبة إلى المستندات الأخرى، لذا يمكنك إضافته الآن.
- أضف ملف الاستحقاقات (entitlements) مع تفعيل قراءة وسوم NFC:
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 تلقائيًا. عندما يصل المستخدم إلى خطوة تتطلب الوصول إلى الكاميرا:- تطلب الحزمة إذن الكاميرا إذا لم يكن ممنوحًا من قبل
- إذا رفض المستخدم الإذن، تظهر رسالة خطأ مع زر Try Again
- إذا منح المستخدم الإذن، يتابع مسار التحقق
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، ولا تعتمد أبداً على نتيجة جانب العميل وحدها.