طراحی حالت آفلاین در اپلیکیشن موبایل؛ همگام‌سازی و حل تعارض داده

چرا حالت آفلاین اهمیت دارد؟

اپلیکیشن میدانی در انبار، مسیر حمل‌ونقل، زیرزمین یا محل‌هایی با پوشش ضعیف شبکه استفاده می‌شود. اگر هر عملیات به اتصال دائمی وابسته باشد، کاربر نمی‌تواند کار خود را ادامه دهد و احتمال ثبت دوباره یا از دست رفتن اطلاعات افزایش می‌یابد. طراحی آفلاین باید مشخص کند چه داده‌ای در دستگاه در دسترس است، چه عملیاتی قابل ثبت است و چه زمانی باید به سرور ارسال شود. حالت آفلاین صرفاً نمایش آخرین صفحه cacheشده نیست؛ یک مدل عملیاتی با وضعیت و قواعد مشخص است.

انتخاب قابلیت‌های آفلاین

همه قابلیت‌ها برای آفلاین مناسب نیستند. مشاهده فهرست یا ثبت پیش‌نویس ممکن است قابل انجام باشد، اما پرداخت، بررسی اعتبار یا رزرو موجودی به داده لحظه‌ای سرور وابسته است. برای هر عملیات، نیاز به صحت، تازگی داده و اثر تکرار بررسی شود. قابلیت‌های قابل اجرا در حالت آفلاین باید در رابط کاربری مشخص باشند و محدودیت عملیات وابسته به سرور نیز شفاف توضیح داده شود.

تعریف منبع حقیقت

در حالت آنلاین، سرور معمولاً مرجع نهایی داده است؛ دستگاه نسخه محلی و موقت نگهداری می‌کند. این تفاوت باید برای کاربر و منطق برنامه روشن باشد. تغییر محلی تا زمان تأیید سرور در وضعیت pending قرار دارد. اگر داده حساس یا مالی است، نباید نتیجه محلی به‌عنوان تراکنش قطعی نمایش داده شود. مدل داده باید وضعیت محلی، وضعیت سرور و زمان آخرین همگام‌سازی را جدا نگه دارد.

طراحی پایگاه داده محلی

پایگاه داده محلی باید بر اساس حجم داده، نوع پرس‌وجو و نیاز مهاجرت نسخه انتخاب شود. ساختار جدول‌ها، ایندکس و شناسه یکتا باید با مدل Backend سازگار باشند. داده‌های موقت از داده تأییدشده تفکیک شوند. نسخه schema محلی ثبت و مسیر migration برای نسخه‌های جدید برنامه طراحی گردد. اگر تغییر ساختار باعث از دست رفتن داده آفلاین شود، باید پیش از ارتقا آن را همگام یا به شکل امن تبدیل کرد.

شناسه یکتا برای عملیات

هر عملیات آفلاین باید شناسه یکتا داشته باشد تا در زمان ارسال مجدد، سرور بتواند درخواست تکراری را تشخیص دهد. تولید شناسه نباید به اتصال اینترنت وابسته باشد. شناسه عملیات به کاربر، دستگاه، زمان و موجودیت مربوط متصل شود. سرور نیز باید idempotency را بررسی کند؛ اتکا به کلاینت کافی نیست، زیرا درخواست ممکن است از چند مسیر تکرار شود.

صف عملیات و وضعیت‌ها

صف محلی باید عملیات ایجادشده، زمان، payload، تعداد تلاش و وضعیت را نگهداری کند. وضعیت‌هایی مانند در انتظار ارسال، در حال ارسال، تأییدشده، ردشده و نیازمند بررسی به کاربر دید روشنی می‌دهد. صف باید در برابر بسته شدن ناگهانی برنامه مقاوم باشد. عملیات وابسته به هم باید ترتیب مشخص داشته باشند؛ برای مثال ایجاد رکورد پیش از افزودن پیوست آن انجام شود.

همگام‌سازی هنگام بازگشت اینترنت

بازگشت اتصال به معنی ارسال هم‌زمان و بدون محدودیت همه داده‌ها نیست. برنامه باید کیفیت شبکه، باتری و حجم داده را در نظر بگیرد. عملیات کوچک و حیاتی می‌توانند اولویت بالاتر داشته باشند و فایل‌های بزرگ در زمان مناسب منتقل شوند. پاسخ سرور باید برای هر عملیات مستقل ثبت شود. اگر بخشی از batch شکست خورد، وضعیت موفق‌ها نباید دوباره ارسال شود.

حل تعارض داده

تعارض زمانی رخ می‌دهد که یک رکورد در دستگاه و سرور جداگانه تغییر کند. سیاست last-write-wins ساده است اما همیشه درست نیست؛ ساعت دستگاه ممکن است دقیق نباشد و تغییر جدیدتر الزاماً معتبرتر نیست. برای داده‌های حساس، تعارض باید به بررسی کاربر یا قاعده کسب‌وکار منتقل شود. فیلدهای مستقل را می‌توان جداگانه ادغام کرد، اما تغییر هم‌زمان یک فیلد کلیدی نیازمند تصمیم روشن است.

نسخه داده و Timestamp

برای تشخیص تغییر، نسخه رکورد یا شماره revision از timestamp تنها قابل اعتمادتر است. سرور می‌تواند نسخه فعلی را در پاسخ برگرداند و کلاینت هنگام ارسال تغییر، نسخه مورد انتظار را ارائه کند. اگر نسخه تغییر کرده باشد، سرور تعارض را اعلام می‌کند. ساعت دستگاه نباید مرجع قطعی ترتیب تغییرات باشد. زمان محلی برای نمایش مفید است، اما منطق همگام‌سازی باید به شناسه نسخه و قواعد سرور متکی باشد.

حذف رکورد و Tombstone

حذف محلی نباید فوراً رکورد را از همه نسخه‌ها پاک کند؛ ممکن است دستگاه دیگر هنوز نسخه قدیمی را داشته باشد و آن را دوباره ایجاد کند. Tombstone یا نشانگر حذف به سرور و سایر دستگاه‌ها اعلام می‌کند رکورد حذف شده است. دوره نگهداری tombstone باید با حداکثر زمان آفلاین دستگاه‌ها هماهنگ باشد. حذف داده حساس نیز باید سیاست مشخص و قابل ممیزی داشته باشد.

مدیریت فایل و پیوست

عکس، سند و فایل صوتی ممکن است حجم زیادی داشته باشند. فایل باید شناسه، checksum، نوع واقعی، اندازه و وضعیت بارگذاری داشته باشد. بارگذاری ناقص باید قابل ادامه یا تکرار امن باشد. فایل محلی حساس باید رمزگذاری و پس از تأیید سرور طبق سیاست پاک‌سازی شود. مسیر فایل نباید در log عمومی افشا گردد. پیش‌نمایش و فشرده‌سازی باید کیفیت و نیاز عملیاتی را متعادل کند.

امنیت داده محلی

داده آفلاین روی دستگاه خارج از کنترل کامل سازمان قرار دارد. حداقل داده لازم را ذخیره کنید و برای اطلاعات حساس از رمزگذاری و کلید امن سیستم‌عامل استفاده نمایید. خروج از حساب یا ابطال دستگاه باید امکان پاک‌سازی داده محلی را فراهم کند. backup سیستم‌عامل ممکن است داده برنامه را کپی کند؛ سیاست ذخیره‌سازی و استثناهای backup بررسی شوند. رمزگذاری بدون مدیریت صحیح کلید کافی نیست.

احراز هویت در حالت آفلاین

کاربر ممکن است هنگام قطع اینترنت برنامه را باز کند. سیاست باید مشخص کند چه مدت پس از آخرین احراز هویت اجازه مشاهده یا ثبت آفلاین وجود دارد. عملیات حساس باید تا اتصال مجدد و اعتبارسنجی سرور محدود بمانند. توکن منقضی‌شده نباید برای مدت نامحدود دسترسی ایجاد کند. پس از بازگشت اتصال، وضعیت حساب و مجوزها دوباره بررسی شوند و عملیات غیرمجاز به شکل امن متوقف گردد.

تجربه کاربر و نمایش وضعیت

کاربر باید بداند داده فقط روی دستگاه ذخیره شده یا به سرور رسیده است. نشانگر آفلاین، زمان آخرین همگام‌سازی و تعداد عملیات در انتظار کمک می‌کنند انتظار درست شکل گیرد. پیام خطا باید اقدام بعدی را توضیح دهد؛ برای مثال «ارسال ناموفق، دوباره تلاش می‌شود» با «نیازمند بررسی» تفاوت دارد. پنهان کردن وضعیت همگام‌سازی باعث می‌شود کاربر تصور کند عملیات نهایی شده است.

محدودیت عملیات ناسازگار

برخی عملیات در حالت آفلاین باید غیرفعال یا به شکل پیش‌نویس انجام شوند. رزرو موجودی، تأیید پرداخت، تغییر دسترسی و صدور سند رسمی ممکن است نیازمند اعتبارسنجی لحظه‌ای باشند. اگر برنامه اجازه ثبت درخواست موقت می‌دهد، باید وضعیت آن را غیرقطعی نمایش دهد. Backend باید هنگام همگام‌سازی مجدداً مجوز، موجودی و قواعد کسب‌وکار را بررسی کند.

همگام‌سازی افزایشی

دریافت کامل همه داده‌ها در هر اتصال هزینه و زمان زیادی دارد. API می‌تواند تغییرات پس از آخرین cursor یا revision را ارائه کند. cursor باید پایدار و قابل ادامه باشد. حذف‌ها نیز باید در جریان تغییرات دیده شوند. اگر cursor منقضی شد، برنامه باید روش بازسازی کنترل‌شده داشته باشد. همگام‌سازی افزایشی باید با صفحه‌بندی و محدودیت حجم همراه باشد تا دستگاه کم‌حافظه دچار مشکل نشود.

مدیریت خطا و Retry

خطای موقت شبکه می‌تواند retry شود، اما خطای اعتبارسنجی یا تعارض نیازمند اصلاح داده است. retry باید با فاصله افزایشی و سقف تلاش انجام شود. عملیات موفق نباید به دلیل شکست یک عملیات دیگر دوباره ارسال شوند. پیام خطا باید شناسه عملیات و علت قابل فهم داشته باشد. صفی که خطاهای دائمی را بی‌نهایت تکرار می‌کند باتری و منابع را مصرف خواهد کرد.

آزمون قطع و وصل شبکه

سناریوهای آزمون باید شامل قطع اینترنت در میانه ثبت، تغییر شبکه Wi-Fi به موبایل، بسته شدن ناگهانی برنامه، انقضای نشست و بازگشت پس از چند روز باشد. همچنین دو دستگاه باید یک رکورد را هم‌زمان تغییر دهند تا حل تعارض بررسی شود. آزمون روی شبیه‌ساز کافی نیست؛ دستگاه واقعی و شبکه ناپایدار رفتار متفاوتی دارند. نتیجه هر سناریو با وضعیت صف و داده سرور تطبیق داده شود.

مصرف باتری و داده

تلاش مکرر برای همگام‌سازی می‌تواند باتری و بسته اینترنت را مصرف کند. زمان‌بندی باید از قابلیت‌های پس‌زمینه سیستم‌عامل استفاده کند و به تغییر وضعیت شبکه واکنش نشان دهد. فایل‌های بزرگ در اتصال مناسب منتقل شوند و کاربر در صورت نیاز کنترل داشته باشد. درخواست‌های دوره‌ای بی‌هدف حذف شوند. اندازه‌گیری مصرف در شرایط واقعی به تنظیم فاصله retry و حجم batch کمک می‌کند.

نسخه‌بندی API و کلاینت

کاربران ممکن است نسخه قدیمی برنامه را برای مدت طولانی نگه دارند. Backend باید قرارداد نسخه‌های پشتیبانی‌شده را حفظ کند یا مسیر ارتقای اجباری روشن داشته باشد. ساختار صف محلی نیز باید با نسخه جدید سازگار شود. مهاجرت داده آفلاین نباید عملیات در انتظار را حذف کند. قبل از انتشار، سناریوهای همگام‌سازی میان نسخه قدیمی و جدید آزمون شوند.

حریم خصوصی و نگهداری

داده آفلاین ممکن است شامل اطلاعات مشتری یا عملیات سازمان باشد. مدت نگهداری، امکان حذف، رمزگذاری و سطح دسترسی مشخص شود. اگر کاربر دستگاه را گم کرد، امکان ابطال نشست و در صورت اتصال بعدی پاک‌سازی داده لازم است. داده تحلیلی از عملیات آفلاین نیز باید حداقل و متناسب با هدف باشد. گزارش crash نباید payload کامل مشتری را ارسال کند.

معماری Backend و صف سمت سرور

کلاینت آفلاین به API مقاوم و idempotent نیاز دارد. سرور باید درخواست‌های تکراری را تشخیص دهد، نسخه رکورد را کنترل کند و پاسخ مستقل برای هر عملیات بدهد. صف سمت سرور می‌تواند پردازش سنگین را جدا کند. اعتبارسنجی کسب‌وکار باید در سرور انجام شود؛ کلاینت فقط تجربه کاربری و نگهداری موقت را مدیریت می‌کند.

پایش کیفیت همگام‌سازی

شاخص‌هایی مانند مدت زمان تا همگام‌سازی، تعداد عملیات معوق، نرخ تعارض، خطای دائمی و حجم داده منتقل‌شده مفیدند. گزارش باید بر اساس نسخه برنامه، سیستم‌عامل و نوع شبکه تفکیک شود. افزایش تعارض ممکن است از تغییر فرایند یا ضعف طراحی API ناشی شود. هشدار برای صف‌های قدیمی و عملیات ناموفق لازم است تا داده محلی برای مدت طولانی معلق نماند.

جمع‌بندی

حالت آفلاین قابل اعتماد نیازمند انتخاب عملیات مناسب، ذخیره محلی امن، شناسه یکتا، صف پایدار، همگام‌سازی افزایشی و قواعد حل تعارض است. کاربر باید وضعیت واقعی داده را ببیند و عملیات حساس در سرور دوباره اعتبارسنجی شوند. آزمون قطع و وصل شبکه، مدیریت نسخه و پایش صف برای بهره‌برداری ضروری‌اند. طراحی آفلاین زمانی موفق است که کار ادامه پیدا کند و پس از اتصال، داده بدون تکرار یا از دست رفتن به وضعیت معتبر برسد.