04 نوفمبر 2025·7 دقيقة
استراتيجيات الكاش في Flutter: التخزين المحلي، البيانات القديمة، قواعد التحديث
استراتيجيات كاش في Flutter للتخزين المحلي، البيانات القديمة، وقواعد التحديث: ماذا تخزن، متى تُبطّل، وكيف تحافظ على اتساق الشاشات.
استراتيجيات كاش في Flutter للتخزين المحلي، البيانات القديمة، وقواعد التحديث: ماذا تخزن، متى تُبطّل، وكيف تحافظ على اتساق الشاشات.
التخزين المؤقت في تطبيق الجوال يعني الاحتفاظ بنسخة من البيانات قريبة (في الذاكرة أو على الجهاز) حتى تعرض الشاشة التالية فورًا بدلًا من الانتظار للشبكة. قد تكون هذه البيانات قائمة عناصر، ملف مستخدم، أو نتائج بحث.
المشكلة أن البيانات المخبأة غالبًا ما تكون قديمة قليلًا. يلاحظ المستخدمون ذلك بسرعة: سعر لا يتحدث، عداد إشعارات يبدو ثابتًا، أو شاشة تفاصيل تعرض معلومات قديمة بعد تعديلها مباشرةً. ما يجعل هذا صعب التصحيح هو التوقيت. نفس النداء الشبكي يمكن أن يبدو سليمًا بعد سحب للتحديث، لكنه خطأ بعد الرجوع للخلف، استئناف التطبيق، أو تبديل الحساب.
هناك مقايضة حقيقية. إذا جلبت بيانات جديدة دائمًا، ستشعر الشاشات بالبطء والتقطّع، وستهدر بطارية وبيانات. إذا خزنت بشكل مفرط، يصبح التطبيق سريعًا لكن الناس يتوقفون عن الثقة بما يرونه.
هدف بسيط يساعد: اجعل النضارة متوقعة. قرر ما الذي يمكن لكل شاشة أن تعرضه (طازج، قديم قليلًا، أو دون اتصال)، كم مدة صلاحية البيانات قبل التحديث، وما الأحداث التي يجب أن تُبطلها.
تخيل تدفقًا شائعًا: يفتح المستخدم طلبًا ثم يعود إلى قائمة الطلبات. إذا جاءت القائمة من الكاش فقد تعرض حالة قديمة. إذا حدثت في كل مرة، قد تومض القائمة وتشعر بالبطء. قواعد واضحة مثل "عرض المخزن فورًا، التحديث في الخلفية، وتحديث الشاشتين عند وصول الاستجابة" تجعل التجربة متسقة عبر التنقل.
الكاش ليس مجرد "بيانات محفوظة". إنه نسخة محفوظة زائد قاعدة لتحديد متى لا تزال هذه النسخة صالحة. إذا خزنت الحمولة بدون القاعدة، ستحصل على واقعين مختلفين: شاشة تظهر معلومات جديدة، وأخرى تظهر معلومات الأمس.
نموذج عملي هو وضع كل عنصر مخبأ في واحد من ثلاث حالات:
هذا الإطار يجعل واجهة المستخدم متوقعة لأنها تستطيع أن تتصرف بنفس الطريقة في كل مرة ترى فيها حالة معينة.
قواعد النضارة يجب أن تُبنى على إشارات يمكنك شرحها لزميل. الخيارات الشائعة هي انتهاء بالزمن (مثل 5 دقائق)، تغيير في الإصدار (المخطط أو نسخة التطبيق)، إجراء مستخدم (سحب للتحديث، إرسال، حذف)، أو تلميح من الخادم (ETag، last-updated، أو استجابة "إبطال الكاش").
مثال: شاشة الملف الشخصي تحمل بيانات المستخدم المخبأة فورًا. إذا كانت قديمة لكن قابلة للاستخدام، تعرض الاسم والصورة المخبأة ثم تُحدّث بهدوء. إذا عدّل المستخدم ملفه، فهذه لحظة يجب التحديث فيها. يجب أن يُحدث التطبيق الكاش فورًا حتى تبقى كل الشاشات متسقة.
قرر من يملك هذه القواعد. في معظم التطبيقات، الافتراض الأفضل هو: طبقة البيانات هي من يملك النضارة والإبطال، والواجهة تتفاعل فقط (عرض المخزن، عرض التحميل، عرض الخطأ)، والخادم يعطي تلميحات عندما يستطيع. هذا يمنع كل شاشة من اختراع قواعدها.
الكاش الجيد يبدأ بسؤال واحد: إذا كانت هذه البيانات قديمة قليلًا، هل سيؤذي ذلك المستخدم؟ إذا كانت الإجابة "على الأرجح لا"، فغالبًا تستحق التخزين المحلي.
البيانات التي تُقرَأ كثيرًا وتتحرك ببطء جديرة بالتخزين: الخلاصات والقوائم التي يتصفحها الناس كثيرًا، محتوى الكتالوج (منتجات، مقالات)، وبيانات مرجعية مثل الفئات أو الدول. الإعدادات والتفضيلات تنتمي هنا أيضًا، مع معلومات ملف شخصي أساسية مثل الاسم وعنوان صورة العرض.
الجانب الخطير هو أي شيء متعلق بالمال أو الحساسية الزمنية. الأرصدة، حالة الدفع، توفر المخزون، مواعيد الحجز، تقديرات التسليم، و"آخر ظهور" يمكن أن يسبّب مشاكل حقيقية إذا كانت قديمة. يمكنك تخزينها للتسريع، لكن عامل الكاش كمؤقت وأجبر التحديث في نقاط القرار (مثلاً قبل تأكيد الطلب).
حالة واجهة المستخدم المشتقّة لها فئة خاصة. حفظ التبويب المختار، الفلاتر، استعلامات البحث، ترتيب العرض، أو موضع التمرير يجعل التنقل سلسًا. لكنه قد يربك المستخدمين عندما تعود اختيارات قديمة دون قصد. قاعدة بسيطة مفيدة: احتفظ بحالة الواجهة في الذاكرة طالما ظل المستخدم في التدفق، لكن أعدها عندما يبدأ المستخدم "من جديد" (مثل العودة إلى الشاشة الرئيسية).
تجنّب تخزين ما يخلق خطرًا أمنيًا أو خصوصية: الأسرار (كلمات المرور، مفاتيح API)، رموز الاستخدام لمرة واحدة (OTP)، والبيانات الشخصية الحساسة ما لم تكن تحتاجها فعلاً للوضع دون اتصال. لا تخزن تفاصيل البطاقات كاملة أو أي شيء يزيد خطر الاحتيال.
في تطبيق تسوق، تخزين قائمة المنتجات محليًا فائدة كبيرة. شاشة الدفع، مع ذلك، يجب أن تحدث الأرصدة والتوافر مباشرةً قبل الشراء.
معظم تطبيقات Flutter تحتاج كاش محليًا حتى تحمل الشاشات بسرعة ولا تعرض فراغًا أثناء استيقاظ الشبكة. القرار الأساسي هو مكان حفظ الكاش لأن كل طبقة لها سرعة وحدود حجم وسلوك تنظيف مختلف.
كاش الذاكرة الأسرع. ممتاز للبيانات التي جلبتها للتو وستعيد استخدامها أثناء بقاء التطبيق مفتوحًا، مثل الملف الشخصي الحالي، نتائج البحث الأخيرة، أو منتج عُرض للتو. المقايضة بسيطة: تختفي عند قتل التطبيق، فلا يساعد في البداية الباردة أو الاستخدام دون اتصال.
تخزين مفتاح-قيمة على القرص يناسب العناصر الصغيرة التي تريدها عبر إعادة التشغيل. فكر في الإعدادات والبلوب الصغيرة: أعلام الوظائف، "آخر تبويب مختار"، وردود JSON الصغيرة النادر تغييرها. اجعلها صغيرة عمدًا. حالما تبدأ بوضع قوائم كبيرة في تخزين مفتاح-قيمة، تصبح التحديثات فوضوية والانتفاخ سهلًا.
قاعدة بيانات محلية الأفضل عندما تكون بياناتك أكبر، منظمة، أو تحتاج سلوكًا دون اتصال. تساعد عند الحاجة إلى استعلامات ("كل الرسائل غير المقروءة"، "العناصر في السلة"، "الطلبات من الشهر الماضي") بدلًا من تحميل بلوب ضخم ثم التصفية في الذاكرة.
للحفاظ على توقعية الكاش، اختر مخزنًا أساسيًا واحدًا لكل نوع بيانات وتجنب الاحتفاظ بنفس المجموعة في ثلاث أماكن.
قاعدة إرشادية سريعة:
خطط أيضًا للحجم. قرر ماذا يعني "كبير جدًا"، كم تبقي العناصر، وكيف تنظفها. مثلاً: حدّ نتائج البحث المخبأة لآخر 20 استعلامًا، وأزل سجلات أقدم من 30 يومًا بانتظام حتى لا يكبر الكاش بصمت.
قواعد التحديث يجب أن تكون بسيطة بما يكفي لشرحها في جملة واحدة لكل شاشة. هنا يثمر الكاش المعقول: شاشات سريعة، وتطبيق موثوق.
أبسط قاعدة هي TTL (وقت الحياة). احفظ البيانات مع طابع زمني واعتبرها طازجة، مثلاً، 5 دقائق. بعد ذلك تصبح قديمة. TTL يعمل جيدًا للبيانات "المفيدة" مثل الخلاصات، الفئات، أو التوصيات.
تحسين مفيد هو تقسيم TTL إلى soft TTL و hard TTL.
مع soft TTL تعرض البيانات المخبأة فورًا ثم تحدّث في الخلفية وتعيد رسم الواجهة إذا تغيّرت. مع hard TTL، تتوقف عن عرض البيانات القديمة عند انتهاء وقتها. إما أن تحجب العرض بمؤشر تحميل أو تعرض حالة "دون اتصال/أعد المحاولة". hard TTL يناسب الحالات التي يكون فيها الخطأ أسوأ من البطء، مثل الأرصدة، حالة الطلب، أو الأذونات.
إذا دعم الخادم ذلك، فضّل "التحديث فقط عند التغيير" باستخدام ETag أو updatedAt أو حقل نسخة. يمكن لتطبيقك سؤال "هل تغيّر؟" وتخطي تحميل الحمولة الكاملة عند عدم وجود جديد.
افتراض ودود للمستخدم لكثير من الشاشات هو stale-while-revalidate: عرض الآن، تحديث بهدوء، وإعادة الرسم فقط إذا اختلفت النتيجة. يعطي سرعة بدون وميض عشوائي.
نضارة كل شاشة غالبًا ما تنتهي مثل هذا:
اختر القواعد بناءً على كلفة الخطأ، ليس فقط كلفة الجلب.
إبطال الكاش يبدأ بسؤال: أي حدث يجعل البيانات المخبأة أقل موثوقية من تكلفة إعادة الجلب؟ إذا اخترت مجموعة صغيرة من المحفزات والتزمت بها، يبقى السلوك متوقعًا والواجهة ثابتة.
المحفزات التي تهم معظم التطبيقات:
مثال: يغيّر المستخدم صورة ملفه الشخصي ثم يعود. إذا اعتمدت فقط على التحديث بالزمن، قد تعرض الشاشة السابقة الصورة القديمة حتى الجلب التالي. بدلًا من ذلك، اعتبر التعديل بمثابة محرك: حدّث كائن الملف الشخصي المخبأ فورًا وضع له طابع نضارة جديد.
احتفظ بقواعد إبطال صغيرة وصريحة. إذا لم تستطع الإشارة إلى الحدث الدقيق الذي يبطل إدخال الكاش، فستحدث كثيرًا (واجهة بطيئة ومتوترة) أو لا تحدث بما فيه الكفاية (شاشات قديمة).
ابدأ بسرد شاشاتك الرئيسية والبيانات التي تحتاجها كل واحدة. لا تفكر في النهايات. فكر في الكيانات المرئية للمستخدم: ملف، سلة، قائمة الطلبات، عنصر كتالوج، عداد غير مقروء.
بعدها، اختر مصدر حقيقة واحد لكل نوع بيانات. في Flutter، هذا عادة مستودع (repository) يخفي مكان قدوم البيانات (ذاكرة، قرص، شبكة). لا ينبغي لكل شاشة أن تقرر متى تضرب الشبكة. تطلب الشاشة البيانات من المستودع وتستجيب للحالة الراجعة.
قِدْر عملي:
البيانات الوصفية هي ما يجعل القواعد قابلة للتنفيذ. إذا تغيّر ownerUserId (تسجيل خروج/دخول)، يمكنك إسقاط الصفوف المخبأة القديمة فورًا بدلًا من عرض بيانات المستخدم السابق لبرهة.
لسلوك الواجهة، قرر مسبقًا ماذا يعني "قديم". قاعدة شائعة: اعرض البيانات القديمة فورًا حتى لا تكون الشاشة فارغة، اشعل تحديثًا في الخلفية، وحدّث عند وصول بيانات جديدة. إذا فشل التحديث، احتفظ بالبيانات القديمة وأعرض خطأً صغيرًا وواضحًا.
بعدها اجعل القواعد ثابتة مع بعض الاختبارات المملة:
هذا هو الفرق بين "لدينا كاش" و"تطبيقنا يتصرف بنفس الطريقة في كل مرة".
لا شيء يكسر الثقة أسرع من رؤية قيمة في شاشة القائمة، الضغط للدخول للتفاصيل، تعديلها، ثم العودة لرؤية القيمة القديمة مرة أخرى. الاتساق عبر التنقل يأتي من جعل كل شاشة تقرأ من نفس المصدر.
قاعدة متينة: اجلب مرة، خزّن مرة، اعرض مرات متعددة. لا يجب على الشاشات استدعاء نفس الواجهة بشكل مستقل والاحتفاظ بنسخ خاصة. ضع البيانات المخبأة في مخزن مشترك (طبقة إدارة الحالة)، ودع كل من القائمة والتفاصيل تراقبان نفس البيانات.
احتفظ بمكان واحد يملك القيمة الحالية والنضارة. يمكن للشاشات طلب تحديث، لكن لا يجب أن تدير كل شاشة مؤقتاتها وتجارب إعادة المحاولة وتحليلها.
عادات عملية تمنع "نسختين من الواقع":
حتى مع قواعد جيدة، سيرى المستخدمون أحيانًا بيانات قديمة (دون اتصال، شبكة بطيئة، تطبيق في الخلفية). اجعل ذلك واضحًا بإشارات صغيرة وهادئة: "تم التحديث منذ قليل"، مؤشر "جارٍ التحديث..." خفيف، أو شارة "دون اتصال".
للتعديلات، التحديثات المتفائلة غالبًا ما تعطي أفضل إحساس. مثال: يغيّر المستخدم سعر منتج في شاشة التفاصيل. حدّث المخزن المشترك فورًا حتى تظهر القائمة السعر الجديد عند العودة. إذا فشل الحفظ، ارجع للقيمة السابقة وأعرض خطأ قصيرًا.
معظم إخفاقات الكاش مملة: الكاش يعمل لكن لا أحد يستطيع شرح متى يُستخدم، متى ينتهي، ومن يملكه.
الفخ الأول هو التخزين بدون بيانات وصفية. إذا خزنت فقط الحمولة، لا يمكنك معرفة ما إذا كانت قديمة، أي نسخة من التطبيق أنشأتها، أو لأي مستخدم تخص. خزّن على الأقل savedAt، رقم نسخة بسيط، و userId. هذه العادة الواحدة تمنع الكثير من أخطاء "لماذا الشاشة خاطئة؟".
مشكلة شائعة أخرى هي وجود عدة كاشات لنفس البيانات بدون مالك. شاشة قائمة تحافظ على قائمة في الذاكرة، المستودع يكتب على القرص، وشاشة التفاصيل تجلب وتخزن في مكان آخر. اختر مصدر حقيقة واحد (غالبًا طبقة المستودع) واجعل كل الشاشات تقرأ منه.
تبديلات الحساب كثيرًا ما تكون فخًا. إذا سجّل أحدهم الخروج أو غيّر الحساب، امسح جداول ومفاتيح النطاق الخاص بالمستخدم. وإلا قد تعرض صورة ملف المستخدم السابق أو طلباته لبرهة، مما يبدو كخرق خصوصية.
إصلاحات عملية تغطي المشكلات أعلاه:
مثال: قائمة المنتجات لديك تُحمّل فورًا من الكاش ثم تُحدّث بهدوء. إذا فشل التحديث، استمر في عرض الكاش لكن أظهر أنها قديمة ووفِّر زر إعادة المحاولة. لا تحجب الواجهة على التحديث عندما تكون البيانات المخبأة كافية.
قبل الإصدار، حوّل الكاش من "يبدو جيدًا" إلى قواعد يمكنك اختبارها. يجب أن يرى المستخدم بيانات منطقية حتى بعد التنقل ذهابًا وإيابًا، الانقطاع، أو تسجيل الدخول بحساب مختلف.
لكل شاشة، قرر كم من الوقت تعتبر البيانات طازجة. قد تكون دقائق للبيانات سريعة الحركة (رسائل، أرصدة) أو ساعات للبيانات البطيئة (الإعدادات، فئات المنتجات). ثم أكد ماذا يحدث عندما لا تكون طازجة: تحديث في الخلفية، تحديث عند الفتح، أم سحب يدوي للتحديث.
لكل نوع بيانات، قرر أي الأحداث يجب أن تمسح أو تتجاوز الكاش. المحفزات الشائعة تشمل تسجيل الخروج، تعديل العنصر، تبديل الحساب، وتحديث التطبيق الذي يغيّر شكل البيانات.
تأكد من أن إدخالات الكاش تخزن مجموعة صغيرة من البيانات الوصفية بجانب الحمولة:
حافظ على وضوح الملكية: استخدم مستودعًا واحدًا لكل نوع بيانات (مثلاً ProductsRepository)، لا لكل ودجت. يجب أن تطلب الودجتس البيانات ولا تقرر قواعد الكاش.
قرر واختبر سلوك دون الاتصال. أكد ما الذي تعرضه الشاشات من الكاش، أي إجراءات معطلة، وما النص المعروض ("عرض بيانات مخزنة"، مع عنصر تحكم تحديث مرئي). يجب أن يوجد تحديث يدوي في كل شاشة تعتمد على الكاش ويكون سهل الوصول.
تخيل تطبيق متجر بسيط بثلاث شاشات: كتالوج المنتجات (قائمة)، تفاصيل المنتج، وتبويب المفضلات. يتصفح المستخدم الكتالوج، يفتح منتجًا، ويضغط على قلب لتفضيله. الهدف أن يشعر التطبيق بالسرعة حتى على شبكات بطيئة دون جعل القيم متضاربة.
خزن محليًا ما يساعد على العرض الفوري: صفحات الكتالوج (المعرّفات، العنوان، السعر، رابط الصورة المصغرة، علم المفضلة)، تفاصيل المنتج (الوصف، المواصفات، التوفر، lastUpdated)، بيانات الصور (عناوين، أحجام، مفاتيح الكاش)، ومجموعة المفضلات (معرّفات المنتجات، اختياريًا مع طوابع زمنية).
عند فتح الكتالوج، اعرض النتائج المخزنة فورًا ثم أعِد التحقق في الخلفية. إذا وصلت بيانات طازجة، حدّث فقط ما تغيّر وحافظ على موضع التمرير.
لتبديل المفضلة، اعتبرها إجراء "يجب أن يكون متسقًا". حدّث مجموعة المفضلات المحلية فورًا (تحديث متفائل)، ثم حدّث أي صفوف مخزنة للمنتجات وتفاصيل المنتج لذلك المعرف. إذا فشل النداء الشبكي، تراجع وأعرض رسالة صغيرة.
للحفاظ على الاتساق عبر التنقل، اعمل على أن تُشغّل شارات القائمة وأيقونات القلب من نفس مصدر الحقيقة (الكاش المحلي أو المخزن)، لا من حالة شاشة منفصلة. تتحدّث أيقونة القلب في القائمة فور العودة من التفاصيل، وتعكس شاشة التفاصيل التغييرات من القائمة، وعد المفضلات يتطابق دون انتظار إعادة جلب.
أضف قواعد تحديث بسيطة: تنتهي صلاحية كاش الكتالوج بسرعة (دقائق)، تفاصيل المنتج أطول قليلًا، والمفضلات لا تنتهي أبدًا لكنها تتصالح دائمًا بعد تسجيل الدخول/الخروج.
يتوقف الكاش عن كونه غامضًا عندما يمكن لفريقك الإشارة إلى صفحة واحدة من القواعد والاتفاق على ما يجب أن يحدث. الهدف ليس الكمال، بل سلوك متوقع يظل نفسه عبر الإصدارات.
اكتب جدولًا صغيرًا لكل شاشة واحتفظ به مختصرًا بما يكفي للمراجعة عند التغييرات: اسم الشاشة والبيانات الرئيسية، مكان الكاش والمفتاح، قاعدة النضارة (TTL، حدثية، أو يدوي)، محفزات الإبطال، وماذا يرى المستخدم أثناء التحديث.
أضف تسجيلًا خفيفًا أثناء الضبط. سجّل نجاحات وفشلات الكاش وسبب التحديث (انتهاء TTL، سحب المستخدم للتحديث، استئناف التطبيق، إتمام تغيير). عندما يبلغ أحدهم أن "هذه القائمة تبدو خاطئة"، تجعل هذه السجلات الخطأ قابلاً للحل.
ابدأ ب TTLs بسيطة، ثم حسّن بناءً على ما يلاحظه المستخدمون. ربما تقبل خلاصات الأخبار 5 إلى 10 دقائق من القدامة، بينما شاشة حالة الطلب قد تحتاج تحديثًا عند الاستئناف وبعد أي إجراء دفع.
إذا كنت تبني تطبيق Flutter بسرعة، فقد يساعدك تنظيم طبقة البيانات وقواعد الكاش قبل التنفيذ. للفرق التي تستخدم Koder.ai (koder.ai)، وضع التخطيط مكان مناسب لكتابة قواعد الشاشة أولًا ثم البناء وفقها.
عند ضبط سلوك التحديث، احمِ الشاشات المستقرة أثناء التجربة. لقطات واسترجاع يمكن أن يوفر وقتًا عندما تُدخل قاعدة جديدة ومفاجئة وتسبب وميضًا أو حالات فارغة أو عدادات غير متناسقة عبر التنقل.
ابدأ بقاعدة واحدة واضحة لكل شاشة: ما الذي يمكن أن تعرضه فورًا (مخزن مؤقت)، متى يجب أن تحدثه، وماذا يرى المستخدم أثناء التحديث. إذا لم تستطع شرح القاعدة في جملة واحدة، سيتصرف التطبيق بشكل غير متسق في النهاية.
عامل البيانات المخبأة كأن لها حالة نضارة. إذا كانت طازجة، عرضها. إذا كانت قديمة لكن صالحة، عرضها الآن وتحديثها بهدوء. إذا كانت تتطلب تحديثًا، اجلب البيانات قبل العرض (أو اعرض حالة تحميل/بدون اتصال). هذا يحافظ على سلوك واجهة المستخدم متسقًا بدلًا من "أحيانًا يتحدث، أحيانًا لا".
خزن ما يُقرأ كثيرًا ويتغير ببطء تقريبًا: الخلاصات، الكتالوجات، بيانات المرجع، والمعلومات الأساسية في الملف الشخصي. تجنّب وضع الثقة في البيانات الحرجة زمنياً أو ماليًا (أرصدة، توفر منتجات، مواعيد، تقديرات التسليم) إلا إذا قمت بتحديثها عند لحظات القرار أو التأكيد.
استخدم الذاكرة لجلب وإعادة استخدام سريع داخل الجلسة الحالية، مثل الملف الشخصي الحالي أو العناصر التي عُرضت مؤخرًا. استخدم تخزين مفتاح-قيمة على القرص للعناصر الصغيرة التي يجب أن تبقى عبر إعادة التشغيل، مثل الإعدادات. استخدم قاعدة بيانات محلية عندما تكون البيانات كبيرة، منظمة، وتحتاج إلى استعلامات أو عمل دون اتصال.
قاعدة TTL بسيطة جيدة كبداية: اعتبر البيانات طازجة لفترة محددة ثم قم بتحديثها. لكن تجربة أفضل غالبًا هي “عرض مخزن الآن، إعادة التحقق في الخلفية، ثم التحديث إذا تغيرت” لأن هذا يتجنب الشاشات الفارغة والوميض العرضي.
إبطال الكاش عند الأحداث التي تغيّر ثقتك بالبيانات: تعديلات المستخدم (إنشاء/تحديث/حذف)، تسجيل الدخول/الخروج أو تبديل الحساب، استئناف التطبيق إذا كانت البيانات أقدم من TTL الخاص بك، والتحديث الصريح من المستخدم. اجعل المشغلات قليلة وصريحة حتى لا تنعش دائمًا أو لا تنعش مطلقًا عندما يكون ذلك مهمًا.
اجعل كل الشاشات تقرأ من مصدر حقيقة واحد، لا من نسخ خاصة. عندما يُعدّل المستخدم شيء ما في شاشة التفاصيل، حدّث الكائن المشترك المخزن محليًا فورًا حتى تعرض القائمة القيمة الجديدة عند العودة، ثمزامن مع الخادم وتراجع فقط في حال فشل الحفظ.
خزن بيانات وصفية بجانب الحمولة، وخصوصًا ختم زمني ومُعرّف المستخدم. عند تسجيل الخروج أو تبديل الحساب، امسح أو عزل إدخالات الكاش الخاصة بالمستخدم فورًا وألغِ الطلبات الجارية المرتبطة بالمستخدم السابق حتى لا تعرض بياناته لفترة قصيرة.
افترض أن تبقى البيانات القديمة مرئية، وعرِض خطأً صغيرًا وواضحًا مع خيار المحاولة مرة أخرى، بدلًا من إفراغ الشاشة. إذا كانت الشاشة لا تستطيع عرض بيانات قديمة بأمان، استخدم قاعدة "تتطلب تحديثًا" وأظهر رسالة تحميل أو حالة عدم اتصال بدلاً من التظاهر بأن القيمة القديمة موثوقة.
ضع قواعد الكاش في طبقة البيانات (مثل المستودعات) حتى تتبع كل الشاشة نفس السلوك. إذا كنت تبني بسرعة في Koder.ai، اكتب قواعد النضارة والإبطال لكل شاشة في وضع التخطيط أولًا، ثم نفّذ بحيث تتفاعل الواجهة ببساطة مع الحالات بدلًا من اختراع منطق التحديث الخاص بها.