شرح Flutter Fingerprint Integration لربط أجهزة البصمة الخارجية وبناء نظام حضور متكامل
في عالم تطوير التطبيقات، قد تواجه أحيانًا تحديات لا يمكن حلها باستخدام المكتبات الجاهزة، خاصة عند التعامل مع الأجهزة الخارجية (Hardware). في هذا المقال سنتحدث عن تجربة عملية في تنفيذ Flutter Fingerprint Integration لربط تطبيق Flutter مع جهاز بصمة حقيقي من نوع ZKTeco، وبناء نظام حضور وانصراف متكامل بدون الاعتماد على حلول جاهزة.
الفكرة بدأت أثناء العمل على نظام POS كامل باستخدام Flutter، يشمل الكاشير، إدارة الطلبات، التقارير، وإدارة الجلسات. كان أحد المتطلبات الأساسية هو تسجيل حضور وانصراف الموظفين باستخدام البصمة، وليس بكلمة مرور أو PIN، بل بصمة فعلية من خلال جهاز خارجي.
وهنا ظهرت المشكلة الحقيقية: Flutter لا يوفر دعمًا مباشرًا للتعامل مع هذا النوع من الأجهزة، ولا توجد مكتبات جاهزة على Pub.dev تدعم أجهزة ZKTeco مثل ZK8500R.
المشكلة: عدم وجود دعم مباشر لأجهزة البصمة في Flutter
هذا التحدي كان نقطة تحول، حيث لم يكن الحل هو الانتظار حتى تظهر مكتبة جاهزة، بل التفكير بطريقة مختلفة لبناء حل عملي من الصفر.
الحل: بناء وسيط باستخدام Python وربطه مع Flutter
هذا الـ Agent يقوم بالتواصل مع جهاز البصمة باستخدام مكتبة pyzkfp، ويعرض مجموعة من API endpoints عبر REST API، بحيث يمكن لتطبيق Flutter التواصل معه بسهولة باستخدام HTTP requests.
بمعنى آخر، أصبح Flutter يتعامل مع جهاز البصمة وكأنه Backend عادي.
كيف يعمل النظام بشكل عام؟
Python Agent
يتعامل مباشرة مع جهاز البصمة ويقرأ البيانات ويعالجها.
Flutter App
يرسل طلبات HTTP إلى الـ Agent للحصول على حالة البصمة أو التحقق منها.
يعمل الـ Agent على Localhost باستخدام منفذ (Port) مخصص، ويتم استدعاؤه من Flutter باستخدام مكتبة مثل Dio.
الهيكل المعماري للـ API داخل Python Agent
/connect
يقوم بفتح الاتصال مع جهاز البصمة ويبدأ Thread في الخلفية لقراءة البصمات بشكل مستمر باستخدام AcquireFingerprint().
/load_templates
يستقبل بيانات بصمات الموظفين من Firebase ويقوم بتحميلها في الذاكرة كـ Templates.
/status
يقوم Flutter بالاستعلام عنه بشكل دوري لمعرفة ما إذا تم وضع إصبع على الجهاز.
/identify
يقارن البصمة الحالية مع جميع البصمات المسجلة باستخدام خوارزمية المطابقة الخاصة بـ ZKTeco، ويعيد user_id في حال تطابق النتيجة.
/clear_pending
يمسح البصمة الحالية من الذاكرة لمنع التعرف على نفس الإصبع أكثر من مرة.
دمج Flutter مع نظام البصمة
بدلاً من التعامل مع Hardware، أصبح التطبيق:
– يطلب حالة الجهاز – ينتظر البصمة – يرسل طلب التحقق – يستقبل نتيجة التعرف
وهذا يجعل Flutter Fingerprint Integration أكثر مرونة وقابلية للتطوير.
تطبيق النظام داخل التطبيق
تسجيل الحضور (Check-in)
يقوم الموظف بوضع بصمته، ثم يقوم الأدمن بتأكيد العملية ببصمته، ويتم تسجيل العملية في Firestore.
تسجيل الانصراف (Check-out)
نفس الفكرة، ولكن لتسجيل وقت الخروج.
العمليات المالية
أي تعديل مالي داخل النظام يحتاج إلى موافقة أدمن باستخدام بصمته.
هذا التصميم يضيف طبقة أمان قوية للنظام.
واجهة المستخدم: Fingerprint Dialog
تدعم هذه الواجهة عدة حالات:
– انتظار (Waiting) – قراءة البصمة (Scanning) – نجاح (Success) – فشل (Failed)
كما تحتوي على Animation وانتقال تلقائي بين الحالات، مع إمكانية إعادة المحاولة بدون تدخل المستخدم.
والأهم: كل هذا يتم بدون استخدام لوحة المفاتيح نهائيًا.
أحد التحديات التقنية: مشكلة pythonnet
الخطأ كان:
RuntimeError: Initialize clr before importing
وكان الحل بسيطًا لكنه غير واضح:
import pythonnet
pythonnet.load('netfx')
import clr
هذا السطر يجب أن يكون قبل أي استخدام لـ clr، وهو ما حل المشكلة بالكامل.
نتائج التطبيق على أرض الواقع
هذا أدى إلى:
– تسريع العمليات – تقليل الأخطاء البشرية – رفع مستوى الأمان – تحسين تجربة المستخدم
الدروس المستفادة من التجربة
بل على العكس، يمكن أن يكون فرصة لبناء حل مخصص:
– أكثر مرونة – أكثر توافقًا مع احتياجات المشروع – قابلًا لإعادة الاستخدام لاحقًا
في كثير من الأحيان، أفضل الحلول ليست الجاهزة، بل التي يتم تصميمها خصيصًا للمشكلة.
الخلاصة
من خلال هذا الأسلوب، يمكنك بناء نظام متكامل يعتمد على البصمة بشكل احترافي، مع الحفاظ على بساطة تطبيق Flutter.
إذا كنت تواجه مشكلة مشابهة، تذكر دائمًا:
عدم وجود مكتبة لا يعني التوقف… بل يعني أن لديك فرصة لبناء حل قد يستخدمه الآخرون من بعدك.
لمزيد من المقالات : لماذا زاد حجم تطبيقات Android بعد SDK Version 23؟
