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