عبدالله سنكر: الخرائط والموقع الجغرافي في التطبيقات، الصلاحيات والتكلفة

تطلب من المطوّر «خريطة في التطبيق»، وتظن إنها ميزة صغيرة. بعد الإطلاق تكتشف ثلاث مفاجآت: نص المستخدمين رفضوا صلاحية الموقع من أول شاشة، والبطارية تنزل بسرعة عند السائقين، وفاتورة مزوّد الخرائط أكبر مما حسبت. عبدالله سنكر يبني تطبيقات Flutter لآيفون وأندرويد، ويشوف إن أغلب هذي المفاجآت سببها واحد: الكل يتعامل مع «الموقع» كأنه ميزة وحدة، وهو في الحقيقة ثلاثة احتياجات مختلفة. خلنا نقارنها.

ثلاثة تطبيقات، ثلاث احتياجات ما تتشابه

• تطبيق يعرض أقرب فرع أو يملأ عنوان التوصيل: يحتاج الموقع مرة وحدة، وغالباً موقعاً تقريبياً يكفي لترتيب الفروع حسب القرب. ما يحتاج تتبعاً ولا خلفية.
• تطبيق توصيل يعرض للعميل مكان السائق: تطبيق العميل ما يحتاج موقع العميل أصلاً بعد تحديد العنوان، وتطبيق السائق يرسل موقعه والتطبيق مفتوح أو أثناء الرحلة فقط.
• تطبيق فريق ميداني يسجّل زيارات المندوبين طول اليوم: هذا الوحيد اللي ممكن يحتاج الموقع والتطبيق في الخلفية، وهو الأصعب في الصلاحيات ومراجعة المتاجر والبطارية.

لاحظ إن أكثر مشروع يتخيله الناس معقداً، وهو التوصيل، يحتاج من تطبيق العميل أقل بكثير مما يتوقعون. والخطأ الشائع إن الفريق يطلب أقوى صلاحية «احتياطاً»، فيدفع ثمنها في الرفض والمراجعة بدون فايدة.

الصلاحيات: اطلب أقل شي يكفيك

النظامين صاروا يعطون المستخدم تحكماً دقيقاً، وتصميم الطلب لازم يحترم هذا:

• في iOS فيه «أثناء استخدام التطبيق» و«دائماً»، والمستخدم يقدر كمان يختار موقعاً تقريبياً بدل الدقيق. تطبيقك لازم يشتغل لو اختار التقريبي، ولو احتجت الدقيق لعملية معيّنة تطلبه مؤقتاً لها.
• في أندرويد فيه صلاحية الموقع التقريبي وصلاحية الدقيق، والموقع في الخلفية صلاحية منفصلة تُطلب بعد صلاحية الاستخدام، والمستخدم يمنحها من الإعدادات.
• التتبع المستمر في أندرويد والتطبيق خارج الشاشة يحتاج عادةً خدمة أمامية بإشعار ظاهر يعرف منه المستخدم إن موقعه يُستخدم.
• كل صلاحية في iOS تحتاج نصاً في ملف Info.plist يشرح السبب، والنص هذا يظهر للمستخدم ويقرأه مراجع آبل.
• متجر Google Play يطلب تصريحاً ومبرراً لأي تطبيق يستخدم الموقع في الخلفية، والتطبيق اللي ما تكون الميزة فيه أساسية وواضحة ممكن ينرفض.

وقبل الإطلاق اختبر التطبيق في أربع حالات على الأقل، لأن أغلب الأعطال تختبي فيها: المستخدم رفض الصلاحية، أو وافق على الموقع التقريبي بس، أو وافق ثم سحب الموافقة من الإعدادات والتطبيق مفتوح في الخلفية، أو خدمة الموقع في الجهاز كله مقفلة. كل حالة لها شاشة واضحة ورسالة تفهّم المستخدم وش يقدر يسوي، بدل مؤشر تحميل يلف للأبد بانتظار إحداثيات ما راح توصل.

لحظة الطلب تفرق أكثر من نص الطلب

تطبيق يفتح لأول مرة ويطلب الموقع قبل ما يشوف المستخدم أي شي، يحصل على «لا» كثير. نفس الطلب لما يضغط المستخدم «استخدم موقعي الحالي» في شاشة العنوان، يحصل على «نعم» أكثر بكثير، لأن السبب صار واضحاً. وبعض التطبيقات تعرض شاشة شرح صغيرة من تصميمها قبل نافذة النظام، لأن نافذة النظام ما تتكرر بسهولة: لو رفض المستخدم، ما تقدر تعرضها له مرة ثانية متى ما بغيت، وأحياناً يبقى خيارك الوحيد إنك توجهه للإعدادات. وصمّم دائماً طريقاً بديلاً: كتابة الحي يدوياً، أو تحريك دبوس على الخريطة. المستخدم اللي رفض الصلاحية لازم يقدر يكمل الطلب، مو يعلق في شاشة فاضية.

فاتورة الخرائط: وين تتسرب الفلوس

مزوّدو الخرائط الكبار يحاسبون غالباً حسب الاستخدام: تحميل الخريطة، والبحث عن الأماكن، وتحويل العنوان لإحداثيات، وحساب المسارات، كل واحد له تسعيرة. والأسعار والحصص المجانية تتغير، فراجعها في صفحة المزوّد وقت التخطيط. لكن مواضع التسرب ثابتة تقريباً:

• إكمال تلقائي للعناوين يرسل طلباً مع كل حرف يكتبه المستخدم. أضف تأخيراً بسيطاً قبل الإرسال، واستخدم رموز الجلسة اللي يوفرها المزوّد لتجميع طلبات البحث الواحد.
• تحويل نفس العنوان لإحداثيات كل مرة يفتح الطلب. احفظ النتيجة في حدود ما تسمح به شروط المزوّد.
• خريطة تفاعلية كاملة في شاشة تحتاج بس صورة صغيرة للموقع. الخرائط الثابتة أخف وأرخص لصفحات التفاصيل والإيصالات.
• حساب المسافة والوقت المتوقع مع كل تحديث للشاشة بدل ما يُحسب عند تغير الموقع بشكل ملحوظ.
• مفتاح خرائط بدون قيود. مفتاح الخرائط يبقى داخل التطبيق بطبيعته، فقيّده بمعرّف تطبيقك وبصمة توقيعه، وحدد الخدمات المسموحة له، وفعّل حدوداً يومية وتنبيهات ميزانية. المفتاح المكشوف بدون قيود دعوة مفتوحة لأي أحد يستخدمه على حسابك.

وفيه بدائل تستاهل المقارنة حسب المشروع: خرائط آبل الأصلية في iOS، ومزوّدين مبنيين على بيانات OpenStreetMap. بس انتبه إن خوادم البلاطات المجانية لمشروع OpenStreetMap نفسه لها سياسة استخدام ما تسمح بحمل تطبيق تجاري، فتحتاج مزوّداً يقدّم هذي البيانات بخدمة مدفوعة أو تستضيفها بنفسك.

البطارية والخصوصية: وجهين لنفس القرار

كل ما زادت الدقة وتكرار التحديث، زاد استهلاك البطارية. تطبيق السائق ما يحتاج دقة عالية كل ثانية وهو واقف عند إشارة: حدد مسافة دنيا للتحديث، وخفف الدقة لما تكفي، وأوقف التتبع تماماً لما تنتهي الرحلة. ونفس المنطق يخدم الخصوصية. الموقع من أحساس البيانات اللي ممكن يجمعها تطبيق، لأنه يكشف البيت ومكان الشغل والعادات. خزّن أقل شي تحتاجه، وقرّب الإحداثيات لما الدقة ما تلزم، وامسح سجل التحركات بعد ما تنتهي الحاجة له. ولا ترسل الإحداثيات لأدوات التحليلات أو الإعلانات المدمجة في التطبيق، لأن هذي أسرع طريقة يطلع فيها موقع المستخدم من يدك لجهات ما يعرفها.

هذا الأسلوب جزء من مبدأ «الخصوصية أولاً» اللي يمشي عليه عبدالله عبدالرحيم بن سنكر الكندي، واللي وصل لأقصاه في تطبيق «مَثابة» اللي ما يجمع أي بيانات أصلاً. وفي مشاريع منصة أزهل الرقمية، سؤال الموقع يبدأ دائماً من الطرف الأدنى: وش أقل دقة، وأقل تكرار، وأقل مدة تخزين تخدم الميزة؟ وكل خطوة فوق هذا تحتاج سبباً يقنع المستخدم قبل ما يقنع المتجر.