تحدثنا حتى الآن عن الوصول إلى واجهات Google APIs التي تستخدم الحسابات والمستخدمين الذين تحدّدهم Google. إذا كانت لديك خدمة خاصة بك على الإنترنت، فلن يكون لها حسابات أو مستخدمين على Google، فماذا تفعل؟ لقد اتضح أن تثبيت أنواع حسابات جديدة على جهاز المستخدم أمر بسيط نسبيًا. يشرح هذا الدرس كيفية إنشاء نوع حساب مخصّص يعمل بالطريقة نفسها التي تعمل بها الحسابات المضمّنة.
تنفيذ رمز حسابك المخصّص
ستحتاج أولاً إلى طريقة للحصول على بيانات الاعتماد من المستخدم. قد يكون ذلك بسيطًا مثل مربع حوار يطلب منك إدخال اسم وكلمة مرور. أو قد يكون إجراءً أكثر غرابة مثل كلمة المرور التي تُستخدم مرة واحدة أو المسح الضوئي للمقاييس الحيوية. في كلتا الحالتين، تقع على عاتقك مسئولية تنفيذ التعليمة البرمجية التي:
- يجمع بيانات الاعتماد من المستخدم
- يعمل على مصادقة بيانات الاعتماد مع الخادم.
- تخزين بيانات الاعتماد على الجهاز
عادةً ما يمكن معالجة جميع هذه المتطلبات الثلاثة من خلال نشاط واحد. سنطلق على هذا نشاط المصادقة.
وبسبب ضرورة التفاعل مع نظام AccountManager،
لأنشطة المصادقة متطلبات معيّنة لا تراعيها الأنشطة العادية. لتسهيل إجراء ما سبق، يوفّر إطار عمل Android فئة أساسية، AccountAuthenticatorActivity، يمكنك توسيعها لإنشاء برنامج مصادقة مخصّص.
والأمر متروك لك تمامًا في كيفية تلبية الشرطين الأولين من نشاط برنامج المصادقة وجمع بيانات الاعتماد والمصادقة عليها. (إذا لم تكن هناك سوى طريقة واحدة لإجراء ذلك، فلن تكون هناك حاجة إلى أنواع الحسابات "المخصصة" في النهاية.) يتضمن المطلب الثالث تنفيذًا أساسيًا وبسيطًا إلى حد ما:
Kotlin
Account(username, your_account_type).also { account ->
accountManager.addAccountExplicitly(account, password, null)
}
Java
final Account account = new Account(username, your_account_type); accountManager.addAccountExplicitly(account, password, null);
كن ذكيًا بشأن الأمان!
من المهم أن تفهم أنّ AccountManager ليست خدمة تشفير
أو سلسلة مفاتيح. وهو يخزِّن بيانات اعتماد الحساب بنص عادي تمامًا كما تُدخِلها. في معظم الأجهزة، لا يمثل هذا مصدر قلق خاص، لأنه يخزنها في
قاعدة بيانات لا يمكن الوصول إليها إلا من خلال الجذر. أما على الجهاز الجذر، فستكون بيانات الاعتماد
قابلة للقراءة بواسطة أي شخص لديه إذن وصول adb إلى الجهاز.
من هذا المنطلق، يجب عدم إدخال كلمة المرور الفعلية للمستخدم إلى AccountManager.addAccountExplicitly(). بدلاً من ذلك، يجب عليك تخزين رمز مميّز آمن من ناحية التشفير والذي سيكون ذا استخدام محدود للمهاجم. إذا كانت بيانات اعتماد المستخدم تحمي شيئًا ذا قيمة، فيجب أن تفكر بعناية في فعل شيء مشابه.
تذكير: عندما يتعلق الأمر برمز الأمان، عليك اتّباع قاعدة "Mythbusters" (الخرافات): لا تجرِّب هذا الإجراء في المنزل. استشِر متخصصًا في مجال الأمان قبل تنفيذ أي رمز حساب مخصص.
والآن بعد أن تم عرض بيانات إخلاء المسؤولية المتعلقة بالأمان، حان الوقت للعودة إلى العمل. لقد نفذت بالفعل جزء من رمز حسابك المخصص؛ وما يتبقى هو السباكة.
Extend AbstractAccountAuthenticator
لكي يعمل AccountManager مع رمز حسابك المخصّص،
تحتاج إلى فئة تنفّذ الواجهات التي يتوقعها AccountManager.
هذا الصف هو فئة المصادقة.
إنّ أسهل طريقة لإنشاء فئة المصادقة هي من خلال توسيع
AbstractAccountAuthenticator وتنفيذ أساليبه المجرّدة. إذا كنت قد درست الدروس السابقة، يجب أن تبدو الطرق المجرّدة لـ AbstractAccountAuthenticator مألوفة لك، فهي عكس الطرق التي استعنت بها في الدرس السابق للحصول على معلومات الحساب والرموز المميزة للتفويض.
يتطلب تنفيذ فئة المصادقة بشكلٍ صحيح عددًا من أجزاء التعليمات البرمجية المنفصلة. أولاً، يتضمن AbstractAccountAuthenticator سبع طرق
تجريدية يجب تجاوزها. ثانيًا، يجب إضافة
فلتر نية الشراء لـ
"android.accounts.AccountAuthenticator" إلى بيان التطبيق (الذي يظهر في القسم التالي). أخيرًا، يجب توفير موردَي XML يحدّدان، من بين أمور أخرى، اسم نوع حسابك المخصّص والرمز الذي سيعرضه النظام بجانب حسابات من هذا النوع.
يمكنك العثور على دليل مفصّل حول تنفيذ دورة مصادقة ناجحة
وملفات XML في المستند
AbstractAccountAuthenticator.
إذا كان نشاط أداة المصادقة بحاجة إلى أي معلَمات إعداد خاصة، يمكنك إرفاقها بالهدف باستخدام Intent.putExtra().
إنشاء خدمة مصادقة
بما أنّه أصبح لديك الآن دورة تدريبية في مجال المصادقة، عليك توفير مكان للإقامة.
يجب أن تكون برامج مصادقة الحسابات متاحة لتطبيقات متعددة وتعمل في
الخلفية، ولذلك يجب بطبيعة الحال تشغيلها داخل Service. سنطلق على
هذا اسم خدمة المصادقة.
يمكن أن تكون خدمة المصادقة بسيطة للغاية. كل ما عليك فعله هو إنشاء
مثال لفئة المصادقة في
onCreate()
واستدعاء
getIBinder()
في onBind().
لا تنسَ إضافة علامة <service> إلى ملف البيان
وإضافة فلتر أهداف من أجل غرض AccountAuthenticator وتوضيح
أداة المصادقة على الحساب:
<service ...>
<intent-filter>
<action android:name="android.accounts.AccountAuthenticator" />
</intent-filter>
<meta-data android:name="android.accounts.AccountAuthenticator"
android:resource="@xml/authenticator" />
</service>
توزيع الخدمة
إنتهى! يتعرف النظام الآن على نوع حسابك، جنبًا إلى جنب مع جميع أنواع الحسابات الشهيرة مثل "Google" و "الشركة". يمكنك استخدام صفحة إعدادات الحسابات والمزامنة لإضافة حساب، وسيكون بإمكان التطبيقات التي تطلب حسابات من نوعك المخصص تعدادها والمصادقة عليها تمامًا كما تفعل مع أي نوع حساب آخر.
وبالطبع، يفترض كل ذلك أن خدمة حسابك مثبته بالفعل على الجهاز. إذا كان بإمكان تطبيق واحد فقط الوصول إلى الخدمة، فلن يكون ذلك بالأمر الهين، فما عليك سوى تجميع الخدمة في التطبيق. ولكن إذا كنت تريد أن يستخدم أكثر من تطبيق خدمة حسابك، فستصبح الأمور أكثر تعقيدًا. لست بحاجة إلى تجميع الخدمة مع جميع تطبيقاتك، والحصول على نُسخ متعددة منها تستهلك مساحة على جهاز المستخدم.
يتمثل أحد الحلول في وضع الخدمة في حزمة APK صغيرة ذات غرضٍ خاص. عندما يريد أحد التطبيقات استخدام نوع حسابك المخصّص، يمكنه التحقّق من الجهاز لمعرفة ما إذا كانت خدمة الحساب المخصّص متاحة لك. وإذا لم يكن متوفّرًا، يمكن توجيه المستخدم إلى Google Play لتنزيل الخدمة. قد يبدو ذلك مصدرًا للمشاكل الكبيرة في البداية، ولكن بالمقارنة مع بديل إعادة إدخال بيانات الاعتماد لكل تطبيق يستخدم حسابك المخصّص، ما عليك سوى تنفيذ هذا الإجراء بسهولة.