امروز به یک چالش خوردم ، با بابام تماس میگرفتم تلفنش زنگ میخورد ولی پاسخ نمیداد.

دقیقا چی شده؟ آخرین بار کجا بوده؟ الان تقریباً کجاست؟ آیا باید نگران شوم یا نه؟
همون موقع داشتم فکر میکردم کاش یه اپ درست میکردم و روی گوشی بابام نصب میکردم که حداقل الان لوکیشنش رو بهم میداد.

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

اول باید ایده رو بررسی میکردم ، جوانب مشکل رو میسنجیدم و تحقیق رو شروع میکردم.

راه حل های پیدا کردن بابام چی میتونه باشه؟ چه محدودیت هایی داریم ؟ چه ابزارها و امکاناتی داریم ؟ بقیه چی ساختن ؟ و در کل به دید یک ایده چقدر ارزش بررسی داره ؟

مثل همیشه اول رفتم سراغ خداوندگار دوست داشتنی جناب جی پی تی

و نتیجه جستجوهای اولیه:

راه‌حل	مناسب برای	چیزی که به تو می‌دهد	ضعف اصلی
Google Maps Location Sharing	Android/iPhone	لوکیشن اخیر، وضعیت باتری و شارژ، Location Sharing دائمی	بیشتر یک feature داخل Maps است تا safety product
Apple Find My / Family Sharing	خانواده تماماً Apple	لوکیشن افراد و کمک به پیدا کردن دستگاه اعضای خانواده	اکوسیستم Apple
Life360	خانواده	Real-time location، battery، places، crash/SOS و حتی No-show alerts	محصول نسبتاً سنگین، بخشی از امکانات پولی/منطقه‌ای
OwnTracks	کاربر فنی/privacy-conscious	Open-source، self-hosted، کنترل داده	UX برای والدین عادی پیچیده است
Traccar	فنی / self-hosted	سیستم کامل GPS tracking + server + apps + API	بیشتر حس ابزار tracking دارد تا consumer family app

(بررسی ها عمومی بدون در نظر گرفتم موقعیت جغرافیای زیر سایه ننگ های اجباری)

برای همین نیاز امروزت، Google Maps از چیزی که شاید فکر می‌کردی کامل‌تر است ولی آیا جواب میده ؟!

Google Maps اجازه می‌دهد شخص Location Sharing را روی Until you turn this off بگذارد. بعد تو می‌توانی recent location گوشی، میزان باتری و اینکه در حال شارژ هست یا نه را ببینی. حتی notification ورود/خروج از مکان هم وجود دارد.

اگر پدرت iPhone دارد، Family Sharing + Find My تقریباً همان safety net پایه را می‌دهد و اعضای خانواده می‌توانند دستگاه‌های همدیگر را در Find My پیدا کنند

نزدیک‌ترین محصول به چیزی که امروز در ذهنت آمد: Life360

جالب اینجاست که Life360 الان رسماً use case مخصوص Aging Parents دارد؛ یعنی تقریباً سناریوی «Where’s Dad?» را دقیقاً هدف گرفته. Real-time location، Place Alerts، No-Show Alerts، Crash Detection و SOS از قابلیت‌هایی هستند که ارائه می‌کند.

نتیجه اولیه خدا برای یک شرایت عادی:

پس اگر فقط هدفت این باشد که این مشکل برای خودت حل شود، احتمالاً لازم نیست اپ بسازی.

حالا بریم به بررسی شرایط موجود:

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

ایده ال ترین حالت اینه که نیازی نباشه بابا کاری انجام بده و به حداقل ترین دسترسی ها نیاز باشه

روی گوشی های اپل که داستان زیاد داریم و خداروشکر گوشی بابا اندروید هست پس فعلا اون بخش رو میزاریم واسه فازهای بعدی

یک اپ فوق‌العاده ساده برای والدین و اعضای خانواده

طرفی که روی گوشی پدرت نصب می‌شود شاید اساساً فقط این را داشته باشد:

You’re sharing your location with Sayid ✓

و تمام.

نه داشبورد پیچیده، نه نقشه، نه تنظیمات عجیب.

یه چیز تخصصی که توی جستجو خدا بهم گفت:

نکته خیلی جالبی که در بررسی پیدا کردم

اگر تصمیم بگیری بسازی، اصلاً لازم نیست background GPS engine را از صفر بنویسی.

Traccar همین July 11, 2026 یک SDK جدید منتشر کرده که دقیقاً کار سخت این پروژه را انجام می‌دهد:

Traccar Client SDK

برای:

Native Android/iOS + Flutter + React Native

و کاملاً Apache 2.0 / Open Source است.

کارهای سختی مثل:

background location
battery optimisation
offline queue
retry upload
stop detection
motion detection

را از قبل حل کرده.

حتی می‌تواند اطلاعات را به server خودت بفرستد و الزاماً لازم نیست از Traccar Server استفاده کنی.

این به‌نظرم پروژه را از:

«چند ماه دردسر native background tracking»

تبدیل می‌کند به:

«یک محصول UX-driven که backend و UI اصلی‌اش را خودمان می‌سازیم.»

و این خیلی جذاب‌تر است.

یک محدودیت مهم که باید بررسی بشه و به حداقل ترین برسه

هیچ اپی نمی‌تواند تضمین کند:

«هر لحظه که خواستم مکان دقیق را می‌گیرم.»

اگر گوشی خاموش باشد، اینترنت نداشته باشد، GPS خاموش شده باشد یا OS اپ را متوقف کرده باشد، فقط last known location خواهی داشت.

مثلاً Traccar هم توضیح می‌دهد که iOS/Android محدودیت‌های background processing دارند و در شرایطی مثل force-quit، battery optimisation و Low Power Mode ممکن است tracking متوقف یا کند شود.

پس UX درست نباید بنویسد: و دقیقا نقش UX همینجا دیده میشود ( چیزی بسازیم که محدودیت ها رو پوشش بده و به حداقل برسونه )

Dad is here.

بلکه:

Dad was here 3 minutes ago.

این تفاوت خیلی مهمی است.

رفتم توی فاز تحلیل شخصی و تشریح شرایط:

نکات من:

چیزی که توی ذهن من هست اینه یک اپ بدون هیچ ظاهر و امکانی در داخل خود گوشی

حتی در بک گراند هم سرویسی رو همیشه ران نمیکند

بررسی های برنامه روی ایونت ها فعال میشود

ایونت هایی که به ذهنم میرسد:

اگر از یک مخاطب بیش از سه مرتبه تماس اومد و پاسخ داده نشد

اگر تعداد تماس های پاسخ داده نشده در گوشی به تعداد مشخصی رسید

اگر باتری به زیر ۱۰ درصد رسید

اگر پیامکی با متن مشخص از شماره های مشخص وارد گوشی شد

دسترسی های برنامه:

از ابتدای نصب برنامه به لوکیشن ، خواندن پیامک ها و لاگ تماس ها ، اماکن ارسال پیامک و برقراری تماس

اگر اینترنت روشن باشد هم میتواند از اینترنت برای ارسال داده های بیشتر استفاده کند

تجسم شرایط:

به عنوان مثال همین امروز من بیشتر از سه مرتبه از شماره خودم با بابام تماس گرفتم و پاسخ نداد. تماس هام با فاصله بود و نه پشت سر هم

مثلا میشد با همین تماس های مکرر برنامه یک پیامک برای من ارسال کند از گوشی پدر با ساختار فشرده و کوتاه شده ترکیبی

شامل: لوکیشن ، میزاین باتری ، وضعیت اینترنت دستگاه (خاموش/روشن)

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

یا حتی در شرایط دیگه من یک پیامک مشخص به گوشی بابام ارسال کنم ، مثلا: باباکجایی-پاسخ-خودکار

و برنامه به این پیام حساس باشد و با دریافت این پیامک همان مختوای لازم رو ارسال کند

نکنه: چون موقعیت ممکن است دقیق نباشد و شرایط در زمان کوتاهی تغییر کند در هر دو حالت برنامه باید چند مرتبه و در فاصله ۲ تا ۵ دقیقه همه جزئیات رو ارسال کند تا برآیند این ارسال ها کمک کند موقعیت دقیق تر شود

و اما نظر کارشناسی خداوندگار درباره استراکچر ذهنی من:

آیا دقیقاً همین ساخته شده؟

قسمت‌هایی از آن بله؛ ترکیبی که تو تعریف کردی نه به این شکل.

مثلاً پروژه Open Source به نام PhoneTrack SMS وجود دارد که با دریافت یک keyword از شماره تأییدشده، GPS، accuracy و battery را با SMS برمی‌گرداند و حتی بدون اینترنت کار می‌کند.

پروژه Anchor هم تقریباً remote-control-via-SMS است: location، battery، ring، callback و whitelist دارد.

حتی ابزارهای قدیمی‌تری وجود داشته‌اند که با missed call یا SMS command لوکیشن می‌فرستادند.

ولی چیزی که در ایده تو مهم است این ترکیب است:

passive + event-driven + no internet dependency + multiple safety triggers + compact one-SMS protocol + temporary high-accuracy sampling

این ترکیب را در چیزی که بررسی کردم به شکل یک محصول مدرن و تمیز ندیدم.

معماری‌ای که تو گفتی از نظر Android کاملاً منطقی است

من حتی ترجیح می‌دهم هیچ daemon دائمی برای GPS نداشته باشیم.

Android خودش می‌تواند برای SMS_RECEIVED و تغییر وضعیت تماس BroadcastReceiver را بیدار کند، حتی اگر process اپ در آن لحظه فعال نباشد.

پس فلسفه‌ی تو درست است:

اپ لازم نیست دائماً اجرا شود؛ سیستم‌عامل خودش آن را در event مناسب بیدار می‌کند.

بیاییم Triggerهای تو را یکی‌یکی بررسی کنیم

Trigger	امکان‌پذیری	نکته
۳+ تماس بی‌پاسخ از یک نفر	✅	بسیار خوب
تعداد کل missed callها به N برسد	✅	Call Log لازم دارد
SMS خاص از شماره مشخص	✅	یکی از بهترین triggerها
Battery < 10%	⚠️	شدنی، ولی exact 10% کمی داستان دارد
اینترنت قطع/وصل	✅	هنگام اجرای session قابل بررسی
Location on demand	✅	Background Location لازم دارد
چند sample طی ۲–۵ دقیقه	✅/⚠️	باید با محدودیت background Android طراحی شود
ارسال SMS خودکار	✅	SEND_SMS لازم است

اینجا دیگه وارد مباحث فنی تولید شدیم. کاندیشن ها و ظرفیت ها. واسه خوندن این موارد میریم ادامه رو روی مستندات ریپوی گیت هاب که اینجا دیکه بیشتر از این طولانی نشه

لینک ریپوزیتوری در گیت هاب

نتیجه گیری

به نظرم الان دیگر ایده به‌اندازه کافی مشخص شده که ارزش دارد به‌جای brainstorm عمومی، یک Product Spec واقعی برایش بنویسیم: دقیقاً state machine، trigger rules، SMS protocol، permission model، failure scenarios و معماری Android را مشخص کنیم. بعد خیلی راحت می‌توانیم تشخیص بدهیم آیا بهتر است از صفر Kotlin بنویسیم یا بخش‌هایی از PhoneTrack/Anchor را reuse کنیم.

بزن بریم بسازیم و منتشر کنیم ، روی ریپو میتونی نتیجه رو ببینی

ممنون که وقت گذاشتی و پستم رو خوندی