همگامسازی آفلاین در موبایل
اپلیکیشنی که فقط با اینترنت کار کند، در بازار ایران محصول نصفهای است. شبکه در آسانسور، پارکینگ، جاده و بسیاری از ساختمانها قطع میشود.
ذخیرهٔ محلی، بخش ساده است. همگامسازی، بخشی است که پروژهها را زمین میزند.
آفلایناول، نه آفلاین بهعنوان قابلیت
تفاوت بنیادی که در جمعآوری داده میدانی هم گفتیم و اینجا تکرارش لازم است:
آنلاین با پشتیبانی آفلاین: اپ به سرور وصل میشود و اگر نبود، چیزی را موقتاً نگه میدارد. شکننده، و در مرزها میشکند.
آفلایناول: اپ همیشه با پایگاه دادهٔ محلی کار میکند. همگامسازی فرایند جدایی است که در پسزمینه اتفاق میافتد.
دومی درست است. در این معماری، کاربر تفاوتی حس نمیکند و همان حس اطمینان، مهمترین ویژگی محصول است — کاربری که مطمئن نباشد دادهاش ذخیره شده، روی کاغذ هم مینویسد.
صف تغییرات
هر تغییر محلی در صفی مینشیند و به ترتیب ارسال میشود.
سه الزام:
شناسهٔ یکتای تولیدشده روی دستگاه. رکورد باید پیش از رسیدن به سرور شناسه داشته باشد، وگرنه نمیتوانید به آن ارجاع دهید.
ارسال قابل اجرای دوباره بدون اثر مضاعف. در تایماوت نمیدانید سرور دریافت کرد یا نه. اگر دوباره بفرستید و سرور رکورد تکراری بسازد، هر گزارشی دو برابر میشود. شناسهٔ یکتا این را حل میکند — سرور اگر آن شناسه را دیده باشد، دوباره نمیسازد. همان اصلی که در کارهای پسزمینه گفتیم.
تلاش مجدد با فاصلهٔ فزاینده. نه بلافاصله، که فقط باتری و شبکه را هدر میدهد.
و ترتیب را حفظ کنید: اگر رکوردی ساخته و بعد ویرایش شده، ارسال ویرایش پیش از ساخت، خطا میدهد.
تعارض، و الگویی که بیشترشان را حذف میکند
دو نفر یک رکورد را آفلاین ویرایش کردهاند. حالا چه؟
مهمترین نکته: بیشتر تعارضها را میشود از اساس حذف کرد.
اگر معماریتان افزودنی باشد — یعنی رکورد جدید ثبت شود بهجای ویرایش رکورد مشترک — تعارض تقریباً پیش نمیآید.
مثال: بهجای «ویرایش موجودی انبار به عدد ۵۰»، ثبت «۱۰ عدد کم شد». دو نفر میتوانند همزمان ثبت کنند و نتیجه درست است.
این تصمیم مدل داده است و باید از روز اول گرفته شود.
برای تعارضهای باقیمانده، سه سیاست:
آخرین نوشته برنده است. ساده، و ممکن است داده از دست برود. برای فیلدهای کماهمیت قابل قبول.
سرور برنده است. برای دادههای مرجع — قیمت، کاتالوگ.
به کاربر نشان بده. برای دادههای حساس. پرهزینهترین از نظر تجربهٔ کاربری و گاهی تنها گزینهٔ درست.
سیاست را به تفکیک نوع داده تعیین کنید، نه یکسان برای همه.
همگامسازی دوطرفه و افزایشی
همگامسازی فقط ارسال نیست؛ دریافت هم هست: کاتالوگ بهروزشده، فهرست وظایف، دادههای پایه.
و باید افزایشی باشد، نه کامل. دانلود کل داده در هر همگامسازی، هم حجم اینترنت کاربر را میخورد و هم کند است.
روش استاندارد: مهر زمانی یا شمارندهٔ تغییر. دستگاه میگوید «آخرین همگامسازی من تا این نقطه بود»، سرور فقط تغییرات بعدش را میدهد.
و ساعت دستگاه قابل اعتماد نیست — کاربر میتواند عوضش کند و پس از قطع برق ممکن است صفر شود. مبنا باید شمارندهٔ سرور باشد، نه زمان دستگاه.
مسئلهٔ حذف
بخشی که همیشه جا میماند: اگر رکوردی در سرور حذف شود، دستگاه از کجا بفهمد؟
در همگامسازی افزایشی، شما فقط تغییرات را میفرستید — و رکورد حذفشده دیگر وجود ندارد که فرستاده شود.
راهحل: حذف نرم. رکورد حذف نمیشود؛ پرچم حذف میخورد و در همگامسازی بعدی فرستاده میشود. دستگاه آن را از حافظهٔ محلی پاک میکند.
بدون این، رکوردهای حذفشده تا ابد روی دستگاهها میمانند — و کاربر سفارشی را میبیند که دیگر وجود ندارد.
فایلها
عکس و ویدیو باید متفاوت با داده مدیریت شوند:
- جدا از داده ارسال شوند. فرم ثبت شود حتی اگر عکسها نرفتهاند.
- فشردهسازی روی دستگاه، پیش از صف.
- ارسال قابل ازسرگیری.
- گزینهٔ فقط وایفای.
- پس از ارسال موفق، از دستگاه پاک شوند — حافظهٔ گوشی محدود است.
وضعیت را نشان دهید
کاربر باید بداند کجا ایستاده:
- چند رکورد ارسال شده، چند در انتظار.
- آخرین همگامسازی موفق کِی بود.
- آیا خطایی هست.
و اگر رکوردی مکرر شکست میخورد، به کاربر بگویید — نه اینکه بیصدا در صف بماند. رکوردی که سه هفته است ارسال نشده و کسی خبر ندارد، دادهٔ ازدسترفته است.
امنیت
پایگاه دادهٔ محلی حساس را رمزنگاری کنید.
دادهای که همگام شده، لازم نیست روی دستگاه بماند — بهویژه اگر دستگاه مشترک یا در معرض گم شدن است.
و توکن در حافظهٔ امن سیستمعامل، نه در همان پایگاه دادهٔ محلی. جزئیاتش در امنیت اپلیکیشن موبایل.
چکلیست
- پایگاه دادهٔ محلی منبع اصلی است، نه کش
- شناسهٔ یکتا روی دستگاه تولید میشود
- ارسال در تایماوت رکورد تکراری نمیسازد
- ترتیب عملیات در صف حفظ میشود
- سیاست تعارض به تفکیک نوع داده تعریف شده
- همگامسازی افزایشی است، نه کامل
- حذف نرم پیاده شده
- فایلها جدا و قابل ازسرگیریاند
- وضعیت برای کاربر قابل دیدن است
- در شرایط قطع شبکه تست شده
بند آخر را با ابزار شبیهسازی شبکه انجام دهید، نه با امید — فهرست کاملش در تست اپلیکیشن موبایل.
و یک هشدار برآوردی
همگامسازی آفلاین، معمولاً بین بیست تا چهل درصد به زمان توسعهٔ اپ اضافه میکند و در برآوردهای اولیه تقریباً همیشه دیده نمیشود.
اگر محصولتان واقعاً به آن نیاز دارد، از ابتدا در معماری و برآورد بیاوریدش. افزودنش به اپی که فرض کرده همیشه آنلاین است، بازنویسی لایهٔ داده است.