المعنى ببساطة: ما الذي يحسبه كل رقم؟

Total Messages هو عدد الرسائل الموجودة في صندوق بريد معيّن أو محادثة معيّنة أو “عنوان بريد” معيّن، حسب تصميم التطبيق. هو عدّاد “الوجود”: كم رسالة مخزّنة أو معروفة للنظام داخل ذلك الصندوق.

Unread هو عدد الرسائل التي لم تُسجَّل كـ “مقروءة” بعد. هذا ليس مجرد “أنا قرأتها بعيني”، بل حالة منطقية تتغير عندما يقرر التطبيق أو الخادم أن الرسالة تم الاطلاع عليها، عادةً عبر حدث يسمى read receipt أو “علامة القراءة”.

باختصار: الإجمالي يسأل “كم رسالة عندي؟” وغير المقروء يسأل “كم رسالة تحتاج انتباهك؟”. لذلك من الطبيعي أن يكون الإجمالي كبيرًا بينما غير المقروء صغير جدًا.

كيف تتولد “حالة القراءة” أصلاً؟

معظم الأنظمة تعتمد على حقول أو أعلام (flags) لكل رسالة، مثل: is_read، read_at، أو status. عندما تصل رسالة جديدة تُسجّل كغير مقروءة. ثم عندما تفتحها (أو أحيانًا بمجرد أن تظهر داخل نافذة المعاينة)، يرسل التطبيق طلبًا إلى الخادم يقول: “هذه الرسالة قُرئت الآن”.

هنا تظهر التفاصيل المهمة: من الذي يقرر أنها قُرئت؟ بعض التطبيقات تعتبر الرسالة مقروءة بمجرد فتح “قائمة الرسائل” إذا كانت الرسالة ظهرت على الشاشة. تطبيقات أخرى لا تغير الحالة إلا عند فتح الرسالة نفسها. وتطبيقات تعتمد على البريد المؤقت قد تضع سياسة أكثر تحفظًا حتى لا يحدث تلاعب في العدادات.

لماذا يحدث تأخير أو اختلاف في الأرقام؟

1) التزامن (Sync) ليس دائمًا لحظيًا

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

2) الكاش (Cache) داخل التطبيق

كثير من التطبيقات تحفظ النتائج محليًا لتكون الواجهة سريعة. لذلك قد ترى رقم غير مقروء قديم حتى يحصل “refresh”. في بيئات مثل الإمارات، حيث الشبكات غالبًا ممتازة لكن قد تتغير بين Wi-Fi و5G أثناء الحركة، يحصل أحيانًا تذبذب بسيط ينعكس على التحديثات.

3) ترتيب الأحداث (Race Conditions)

تخيل السيناريو التالي: وصلت رسالة، ثم فتحت الشاشة بسرعة، ثم جاءت إشارة “تمت القراءة” قبل ما تستقبل “وصول الرسالة” في الواجهة. عندها قد ترى لحظة قصيرة يكون فيها الإجمالي ثابت بينما غير المقروء يتغير، أو العكس. هذه ليست بالضرورة مشكلة؛ هي نتيجة تداخل الأحداث في الزمن.

4) سياسات الإشعارات والخصوصية

بعض الأنظمة لا ترسل محتوى الرسالة في الإشعار لأسباب خصوصية، وتكتفي بإشارة “Message arrived”. في هذه الحالة، قد ترى شارة غير مقروء تزيد، لكن التفاصيل لا تظهر إلا بعد فتح التطبيق. هذا شائع في تطبيقات تركز على الخصوصية أو عند تعطيل “Background refresh”.

أمثلة واقعية توضح الفرق

مثال 1: OTP وصل… لكن غير المقروء لم يتغير

أنت تسجل في خدمة، وتنتظر كود التفعيل. فجأة تلاحظ أن Total زاد من 12 إلى 13، لكن Unread بقي 0. هذا يحدث إذا كانت الرسالة وصلت بالفعل لكن تم وضعها “مقروءة” تلقائيًا بسبب إعدادات العرض، أو لأن التطبيق اعتبر أن صندوق الوارد مفتوح وبالتالي “أي رسالة جديدة تُعدّ مقروءة عند ظهورها”. بعض التطبيقات تفضل هذا السلوك لتجنب تراكم “غير المقروء” في واجهات سريعة.

مثال 2: Unread يظهر 1 ثم يصبح 0 بدون ما تفتح الرسالة

قد يكون السبب أن الرسالة ظهرت في معاينة داخل القائمة (Preview Pane) أو تم فتحها تلقائيًا عند تحديدها أو تمرير الشاشة، أو لأن الخادم سجّل حدث قراءة بسبب جلسة مفتوحة تُحدّث “آخر رسالة تمت رؤيتها”. هذا شائع في تطبيقات تعرض محتوى مختصر للرسالة داخل السطر نفسه.

مثال 3: الإجمالي لا يزيد فورًا بينما غير المقروء يزيد

أحيانًا يصل إشعار سريع “لديك رسالة جديدة” فيزيد عداد غير المقروء، لكن قائمة الرسائل تحتاج عملية جلب (fetch) لتحديث الإجمالي. عند أول تحديث كامل، سيقفز الإجمالي، ويصبح الرقمان متناسقين.

كيف تُنفّذ الأنظمة عدّادات Unread وTotal من الناحية التقنية؟

غالبًا هناك طريقتان: الحساب في الخادم (Server-side counters) أو الحساب في الجهاز (Client-side). في الحساب على الخادم، تكون هناك استعلامات وقيم مخزّنة تتحدث مع كل وصول أو قراءة. في الحساب على الجهاز، التطبيق يجلب قائمة الرسائل ثم يحسب بنفسه كم رسالة is_read=false.

أنظمة الخادم عادةً أدق في البيئات متعددة الأجهزة (مثلاً: فتحت نفس الحساب في جوالين)، لأن الخادم يملك “الحقيقة” ويُوحّد الحالة. لكن حساب الجهاز قد يكون أسرع في الواجهة وأقل تكلفة على الخادم، خصوصًا لو عدد الرسائل محدود.

كثير من التطبيقات تستخدم مزيجًا: الخادم يرسل “ملخص counts”، والتطبيق يعيد التحقق عند فتح الشاشة. هذا يعطي تجربة سلسة، لكنه يعني أن الرقم قد يتغير بعد ثوانٍ من دخولك، وهذا طبيعي.

لماذا قد ترى اختلافًا بين شاشة “القائمة” وشاشة “داخل الرسائل”؟

لأن كل شاشة قد تعتمد على مصدر بيانات مختلف: شاشة القائمة قد تستخدم “counts cached” أو ملخص سريع، بينما شاشة التفاصيل قد تجلب البيانات مباشرة من API أو من مزود البريد. لهذا، قد ترى في القائمة Unread=2، ثم تدخل فتجد في التفاصيل Unread=1 بعد تحديث فعلي.

هذا يظهر أكثر عندما تكون الرسائل قصيرة العمر أو سريعة الوصول (مثل رسائل التفعيل)، أو عندما يكون هناك تحديث متكرر كل عدة ثوانٍ بدلًا من اتصال مستمر.

هل هذه الفروقات تعني أن النظام “فيه مشكلة”؟

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

• Unread عالق دائمًا: الرقم لا يتغير حتى بعد فتح الرسائل أو عمل تحديث يدوي. قد يعني أن حدث “mark as read” لا يصل للخادم أو أن هناك خطأ في الصلاحيات.
• Total لا يتغير رغم وصول رسائل جديدة: قد يكون هناك مشكلة في جلب الرسائل أو في التصفية (filter).
• عدم التناسق بين أجهزة متعددة لفترة طويلة: قد يدل على أن التزامن لا يعمل أو أن الحسابات مختلفة.

أفضل ممارسات لتحديث الحالة بشكل موثوق (من منظور المستخدم)

1. اعمل Refresh عند الحاجة: إذا كنت تنتظر OTP أو رسالة حساسة، التحديث اليدوي يقلل الاعتماد على الكاش.
2. لا تعتمد على رقم Unread وحده: أحيانًا الرسالة موجودة لكن تم وسمها كمقروءة تلقائيًا. راقب الإجمالي أو ابحث عن أحدث رسالة.
3. انتبه لفلترة الرسائل: بعض التطبيقات تعرض “غير المقروء فقط” أو “الأحدث فقط”. تغيير الفلتر قد يغير أرقامك فورًا.
4. أعطِ النظام ثواني في الشبكات المتغيرة: التنقل بين Wi-Fi وبيانات الهاتف قد يؤخر تحديثًا صغيرًا.
5. للحسابات المهمة استخدم بريدًا ثابتًا: البريد المؤقت ممتاز للخصوصية، لكنه ليس مناسبًا لتدفق رسائل طويل يعتمد على استرجاع كلمة المرور والرسائل المتتابعة.

FAQ: أسئلة شائعة

الخلاصة

الفرق بين Unread وTotal Messages ليس مجرد رقمين للزينة: هو انعكاس لطريقة النظام في إدارة وصول الرسائل، وحالة القراءة، والتزامن بين الجهاز والخادم. في الاستخدام اليومي داخل الإمارات—خصوصًا مع رسائل التفعيل والتنبيهات السريعة—من الطبيعي أن ترى تغيّرًا سريعًا أو تأخيرًا بسيطًا. عندما تفهم منطق التحديث، ستعرف متى تنتظر تحديثًا طبيعيًا، ومتى تحتاج Refresh، ومتى يكون هناك خلل فعلي يستحق المعالجة.