حل مشكلة فقدان بيانات المستخدم عند تغيير الجهاز (تسجيل الدخول بجوجل + المزامنة السحابية)

 

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

ليه المشكلة دي بتحصل أصلاً؟

أي تطبيق بيحفظ بيانات المستخدم (تقدم، نقاط، مصروفات، إعدادات) بيبدأ غالباً بأبسط حل ممكن: تخزين محلي على الجهاز (زي localStorage في تطبيقات الويب، أو SharedPreferences/قاعدة بيانات محلية في أندرويد). الحل ده سريع ومباشر، لكنه بيحمل عيب جوهري: البيانات مربوطة بالجهاز، مش بالمستخدم نفسه.

يعني لو المستخدم:

مسح التطبيق وأعاد تثبيته.

غيّر موبايله.

أراد يستخدم نفس حسابه على جهازين مختلفين.

في كل الحالات دي، البيانات مش هتلاقيه، لأنها أصلاً محفوظة في مكان مرتبط بالجهاز القديم بس.

علامة التعرف على المشكلة دي في مشروعك: لو التطبيق بيحفظ بيانات مهمة (مش إعدادات بسيطة) باستخدام تخزين محلي فقط، من غير أي حساب مستخدم مرتبط بيها، يبقى التطبيق عرضة للمشكلة دي أكيد عاجلاً أو آجلاً.

الحل الصحيح: ربط البيانات بحساب مستخدم + مزامنة سحابية

الحل مش "إصلاح" للتخزين المحلي، لكنه تغيير في المفهوم: البيانات المفروض تتبع المستخدم أينما راح، مش الجهاز. وده بيتطلب خطوتين أساسيتين: نظام تسجيل دخول، وقاعدة بيانات سحابية تتزامن معاه.

هنستخدم في الشرح جوجل كمزوّد لتسجيل الدخول (لأنه الأسهل والأكثر أماناً، ومعظم مستخدمي أندرويد أصلاً عندهم حساب جوجل جاهز)، مع Firebase Authentication وFirestore كقاعدة بيانات سحابية، لكن نفس المبدأ ينطبق مع أي مزوّد أو قاعدة بيانات تانية.

الخطوة الأولى: إعداد المشروع على Firebase

أنشئ مشروع على Firebase Console وفعّل خدمتين: Authentication (وفعّل مزوّد Google تحديداً)، وFirestore Database.

لازم تضيف بصمة SHA-1 وSHA-256 بتاعة تطبيقك في إعدادات المشروع على Firebase. النقطة دي كتير مطورين بينسوها، وهي سبب شائع جداً لفشل تسجيل الدخول بجوجل حتى لو الكود كله سليم — لأن جوجل بيتحقق من هوية التطبيق عن طريق البصمة دي قبل ما يسمح بتسجيل الدخول.

bash

# استخراج بصمة SHA للتوقيع Debug (للتجربة)

keytool -list -v -keystore ~/.android/debug.keystore -alias androiddebugkey -storepass android -keypass android

حمّل ملف google-services.json وضيفه في مسار المشروع الصحيح (app/ في مشاريع أندرويد الأصلية).

الخطوة الثانية: تنفيذ تسجيل الدخول بجوجل

مثال مبسط لتطبيق ويب (React) مغلّف بـ Capacitor:

javascript

import { GoogleAuthProvider, signInWithPopup, getAuth } from "firebase/auth";

async function signInWithGoogle() {

const provider = new GoogleAuthProvider();

const auth = getAuth();

try {

const result = await signInWithPopup(auth, provider);

const user = result.user; // uid, email, displayName متاحين هنا

return user;

} catch (error) {

    console.error("فشل تسجيل الدخول:", error.code);

}

}

الخطوة الثالثة: المزامنة الفعلية — رفع البيانات وتنزيلها

الجزء ده هو قلب الحل. المطلوب: لما المستخدم يسجل دخول، البيانات المحلية تترفع لحسابه، ولما يدخل من جهاز جديد، بياناته تنزل تلقائياً.

javascript

import { doc, setDoc, getDoc } from "firebase/firestore";

// رفع البيانات المحلية إلى حساب المستخدم بعد تسجيل الدخول

async function syncLocalDataToCloud(userId, localData) {

const userDocRef = doc(db, "users", userId);

await setDoc(userDocRef, localData, { merge: true });

}

// استرجاع البيانات عند الدخول من جهاز جديد

async function restoreDataFromCloud(userId) {

const userDocRef = doc(db, "users", userId);

const snapshot = await getDoc(userDocRef);

if (snapshot.exists()) {

return snapshot.data(); // استخدمها لتحديث التخزين المحلي والواجهة

}

return null; // مستخدم جديد، مفيش بيانات سابقة

}

نقطة مهمة غالباً بتتنسى: لازم تحدد إيه بيحصل لو المستخدم عنده بيانات محلية على الجهاز وفي نفس الوقت عنده بيانات سحابية مختلفة (مثلاً سجّل دخول لأول مرة على جهاز كان بيستخدمه من غير حساب). الحل الشائع هو مقارنة بالتاريخ (آخر تعديل)، والاعتماد على النسخة الأحدث، أو دمج البيانات لو طبيعة التطبيق تسمح بده (زي دمج قوائم مصروفات من مصدرين).

الخطوة الرابعة: تأمين البيانات بقواعد Firestore

من غير قواعد أمان صحيحة، أي مستخدم ممكن يقرأ أو يعدّل بيانات مستخدم تاني. لازم تتأكد إن كل مستخدم بيوصل لبياناته هو بس:

javascript

// Firestore Security Rules

rules_version = '2';

service cloud.firestore {

  match /databases/{database}/documents {

    match /users/{userId} {

      allow read, write: if request.auth != null && request.auth.uid == userId;

}

}

}

القاعدة دي بتضمن إن المستخدم لازم يكون مسجل دخول (request.auth != null)، وإنه بس اللي يقدر يوصل للمستند اللي فيه نفس الـ uid بتاعه.

الخطوة الخامسة (إلزامية مش اختيارية): زر حذف الحساب

لو تطبيقك فيه تسجيل دخول وبيحفظ بيانات مستخدمين، جوجل بلاي بيشترط وجود طريقة واضحة وسهلة يقدر بيها المستخدم يحذف حسابه وبياناته من داخل التطبيق نفسه (مش بس من خلال طلب بالإيميل). تجاهل الشرط ده ممكن يعرّض تطبيقك لرفض أو تعليق من المتجر.

javascript

async function deleteUserAccount(userId) {

// 1. حذف بيانات المستخدم من Firestore

await deleteDoc(doc(db, "users", userId));

// 2. حذف حساب المصادقة نفسه

await auth.currentUser.delete();

}

خطوات اختبار الحل قبل ما تعتبره مكتمل

سجّل دخول بحساب، سجّل بعض البيانات، بعدين امسح التطبيق ونزّله تاني وسجّل بنفس الحساب — تأكد إن البيانات رجعت كاملة.

جرّب تسجيل الدخول من جهازين مختلفين بنفس الحساب في نفس الوقت، وشوف هل البيانات بتتعارض ولا بتتزامن صح.

تأكد إن مستخدم مش مسجل دخول أصلاً مايقدرش يوصل لبيانات أي حساب تاني (اختبر قواعد الأمان فعلياً مش بس نظرياً).

جرّب زر حذف الحساب وتأكد إن البيانات فعلاً بتتمسح من القاعدة، مش بس الواجهة بتختفي.

الخلاصة

مشكلة فقدان البيانات عند تغيير الجهاز مش مشكلة تقنية معقدة في حد ذاتها، لكنها نتيجة قرار تصميم مبكر (ربط البيانات بالجهاز بدل المستخدم). الحل المستقر بيعتمد على ثلاثة أركان: تسجيل دخول موثوق، مزامنة واضحة القواعد (مين بياناته بتاخد الأولوية)، وتأمين صارم لقواعد قاعدة البيانات. تجاهل أي ركن من التلاتة ديه بيرجّع نفس المشكلة تاني بشكل مختلف.