التاريخ الطويل للدليل - كيف كتبت خدمة لمسارات المشي لمسافات طويلة الذكية لمدة 5 سنوات

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

في هذا المقال ، سأشارك تجربتي وأخبركم كيف عملت لمدة 5 سنوات في بعض الأحيان على تطوير دليل ذكي لسانت بطرسبرغ ، وكيف تمكنت من عدم التخلي عن هذا العمل ، وكيف تغير الموقف من المشروع وما حدث في النهاية.

يتم وصف العديد من الحلول التقنية المشكوك فيها والدراجات أدناه ، ولكن لا تفاجأ - فكلها تقريبًا لها ما يبررها للأهداف والموارد المتاحة في ذلك الوقت (= عادةً ما أعلم وقتي)

فكرة

يوجد في أي مدينة سياحية كبيرة المئات من الأدلة ، جيدة وغير جيدة ، حيث يتم رسم الطرق الرئيسية ، وتتم الإشارة إلى النقاط الرئيسية ومجموعة من المعلومات المفيدة الأخرى.
لكن الطرق هناك ثابتة ومحدودة ، والمشاهد عادة ما تكون الأكثر أهمية ، مثل "ما يجب رؤيته في 3 أيام".

لذلك ، جاءت فكرة بناء طرق ذكية. يختار المستخدم النقطتين A و B ولا يستقبل أقصر طريق كلاسيكي ، ولكن شيء قريب منه ، ولكن يمر عبر مناطق الجذب القريبة.

جمهور مثل هذا الدليل ليس فقط السياح ، ولكن أيضًا السكان المحليين الذين يرغبون في تنويع طرقهم المعتادة إلى المنزل / العمل / المتجر (وكانت هناك مثل هذه المراجعات في النهاية على التطبيق!) أو ببساطة للتعرف على المدينة بشكل أفضل.

TL ؛ د
خلاصة القول هي تطبيق Wander Android ، والذي يعمل الآن فقط لسانت بطرسبرغ.

الفصل 1: النموذج الأولي

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

كان من المفترض أن تكون خدمة ويب ، وكنت أعرف القليل عن PHP ، لذلك اخترت PHP.
كان من الضروري حل العديد من المشاكل:

1. قاعدة الجذب السياحي
هنا التقينا خريطة الشارع المفتوح ، اتضح أن هذا هو أروع مشروع يناسبنا تمامًا. OSM هو مشروع خريطة مجتمع غير ربحي قائم على المجتمع. مثل ويكيبيديا ، فقط حول الخرائط.
قم بتنزيل الخريطة بتنسيق xml في سان بطرسبرغ - توجد قائمة بالموارد التي يمكنك من خلالها القيام بذلك.
في ذلك الوقت ، أتذكر أن ملفات الخرائط كانت تزن أكثر من 1 غيغابايت ، لذلك يتم كتابة محلل التدفق الذي يحدد كائنات الفئات المحددة مسبقًا - الآثار والمتنزهات والكنائس والمتاحف.
لدى OSM وثائق مستفيضة حول العلامات والسمات وكل ما تحتاجه هنا ، وبفضل ذلك لن يكون من الصعب معرفة كيفية الحصول على البيانات التي تحتاجها من البطاقات.

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

إذا اكتشفت الكود القديم بشكل صحيح ، فاستخدمت العلامات التالية لجلب الكائنات:

• building معنى cathedral ، chapel ، أصبحت church فئة church
• amenity مع القيم fountain يقع في monument
• tourism مع القيم artwork viewpoint تذهب إلى monument zoo museum إلى museum ، ومدينة park إلى park
• historic مع boundary_stone ، castle ، memorial ، والقيم monument يذهب إلى فئة monument
• leisure مع قيمة في park ينتهي بطبيعة الحال في park

نضع كل الكائنات المستلمة في قاعدة بيانات مع الإحداثيات ونفرح! تم إصدار أكثر من 1200 نقطة في سان بطرسبرغ.

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

تم إنشاء طريق بين النقاط المحددة بواسطة Google Maps API ، الذي بنى طرق سيارات جيدًا ، ولكن في ذلك الوقت لم يكن يعرف كيفية المشي ، على الأقل في روسيا.

كان اختيار الأشياء ليتم تنفيذها من قبل نفسك. اتضح المخطط التالي للتطبيق:

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

بعد ذلك ، توصلنا إلى خوارزمية لاختيار نقاط في الطريق. من ناحية ، من الضروري ألا يؤدي المسار إلى تحويل الكثير إلى الجانب ، لكن من ناحية أخرى لا يزال يختار بعض النقاط في الأحياء المعينة.

ليس بيانًا واضحًا جدًا للمشكلة ، فقد ظهرت نفس الخوارزمية ، شيء مشابه لـ A * ( wiki ): يُعتقد أنه من كل نقطة هناك انتقالات لكل منها. علاوة على ذلك ، في A * ، يتم عادةً التعبير عن سعر الانتقال إلى الرأس n عند البحث عن المسار AB على النحو التالي: f(n) = g(An) + h(nB) ، حيث g(x,y) هي طول المسار من x إلى y ، و h(x,y) هو تقدير إرشادي للمسافة من x إلى y. السعر الخاص بي هو نفسه - f(n) = h(x,n) + h(n,y) * q ، حيث q ثابت أقل من 1. عن طريق تغيير قيمة q ، يمكنك التأثير على عدد النقاط في المسار.

نحن ننفذ الخوارزمية و ، هتافات ، كل شيء يعمل ، ربط الواجهة ، شراء النطاق ، تحميله على الاستضافة ، كتابة التقارير والبيروقراطية الأخرى ونفرح! بدا الأمر مثل هذا (ولم يتغير كثيرًا بعد):

المجموع: حصلت على نموذج أولي لفكرة رائعة ، تعرفت على OSM ، Google API ، عملت كفريق واحد ، وحصلت على رصيد في الجامعة ، وكانت مثيرة للاهتمام أيضًا.

الفصل 2: ​​أول نسخة ويب كاملة

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

كان ذلك في عام 2015 ، وواصلت العمل على TravelPath ، وتولت تصحيح هذا الخلل القاتل - بدأت في بناء طرق بمفردي.

لم أغير التكنولوجيا ، PHP + MySQL . بالطبع ، أدركت على الفور أن هذا لم يكن أفضل مكدس تقني لمثل هذه المهمة (إنشاء طرق في PHP؟ محمل الجد؟).
لكنني كنت محدودًا في الوقت ولم أكن مستعدًا للتبديل إلى مكدس أكثر منطقية ، وثانيًا ، حتى الآن تمت كتابة المشروع "على الطاولة" - أرغب في استخدام هذا التطبيق من جهاز محمول ، وكان يعني في تلك السنوات التطوير المحلي فقط. وهذا يعني أن عدم قابليته للتطبيق على شكل إصدار ويب كان واضحًا ، على الرغم من بعض المحاولات لإنشاء واجهة تكيفية.

نشأت المهام التالية:

1. الحصول على رسم بياني للمدينة
هنا نفس OSM ينقذنا. مرة أخرى ، قم بتنزيل الرسم البياني بتنسيق xml ، وقم بتحليله ، وحدد فقط الأنواع الضرورية من الطرق وتتعجب من كمية البيانات - في ذلك الوقت ، خرج أكثر من 3 ملايين رأس وحافة 500 كيلو. الفكرة الأولى هي أن الرسم البياني قد يكون غير ذي صلة.
أي فناءات أو أقاليم مغلقة أو أشياء غير مفهومة ليست مثيرة للاهتمام للغاية لإنشاء مسار ، لذلك نختار نقطة ما ، ونلتف حول الرسم البياني بأكمله منه ، ونشير الرؤوس مرت ونحصل على الجزء المتصل من الرسم البياني.
في المجموع ، خرج أكثر من 600k قمم وحواف 150k.
حفظ المستلمة في قاعدة البيانات واليسار حتى أوقات أفضل.

2. بناء الطريق
هناك بيانات ، يتم تركها كلها للصغيرة: إنشاء طرق عليها. لم يكن علينا اختراع أي شيء جديد - تذكر مسار الخوارزميات ، وقراءة المقالات بعناية حول العمل مع الرسوم البيانية ، خذ خوارزمية A * ، وقم بتنفيذها في PHP و نفرح بالاحباط كيف ببطء كل ​​شيء يعمل.

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

(الإطار الأحمر = ~ تم قراءة هذا الرسم البياني لبناء المسار)

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

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

1. الأول - تم تطبيع البيانات ، والتي كانت مريحة عند التحليل ، ولكن قراءة عشرات الآلاف من السجلات وحتى من جدولين أمر مؤلم. يتمثل الحل الواضح في جعل واحد من جدولين (للرؤوس والحواف) ، فقط للحواف ، حيث يتم في كل سجل إحداثيات كل من الرؤوس ومعرفها.
2. نحن نعول مسبقًا على أقرب قمم الرسم البياني إلى المعالم السياحية ، ولا نفعل ذلك سريعًا في كل مرة.
3. يتم قضاء وقت كبير في البحث عن نقطة الرسم البياني الأقرب إلى المستخدم المحدد. لتسريع ذلك ، قسمت الرسم البياني بأكمله إلى قطاعات صغيرة ، باستخدام صيغة الإحداثيات التي يمكنك الحصول عليها على الفور من معرف القطاع ، ثم حدد الرأس فقط داخل القطاع ، وليس في الرسم البياني بأكمله ، وهو أسرع بكثير.

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

الإجمالي: تعرفت على بيانات OSM بشكل أفضل ، في الممارسة العملية ، قمت بحل مشاكل الرسم البياني (الحالة عندما كانت خوارزميات الرسم البياني مفيدة أخيرًا) ، كتبت مقاييسي الأولى.

الفصل 3: أول إصدار ويب عادي

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

1. كان من الواضح على الفور أن بناء الطرق كما فعلت في الفقرة الأخيرة غير صحيح.
2. قد لا يكون أي دليل في المتصفح مناسبًا لأي شخص - فأنت تريد التجول في أنحاء المدينة ، والبحث في تطبيق مناسب حيث يمكنك قراءة ما هو خاص وما إلى ذلك. باختصار ، على الأقل - أنت بحاجة إلى واجهة تكيفية باردة ، وبطريقة جيدة تطبيق الهاتف المحمول.

لكن في هذه المرحلة ، قررت التعامل فقط مع النقطة الأولى. ندرس الإنترنت حول هذا الموضوع وهنا مرة أخرى يساعد OSM في الخروج ، أو بالأحرى المشروع الذي وُلد بفضله - OSRM .
استنادًا إلى بيانات الخريطة من OSM ، يمكن لآلة التوجيه مفتوحة المصدر إنشاء مجموعة متنوعة من المسارات في وقت مناسب. نعم ، ومشروع مفتوح المصدر مع وثائق جيدة يمكنك تثبيتها على الخادم الخاص بك واستخدامها.
كمكافأة ، لديها أيضًا واجهة برمجة تطبيقات ملائمة إلى حد ما.
و antaresm كتب بالفعل عن OSRM على habr التي ساعدتني في ذلك الوقت. صحيح ، لقد تدفقت الكثير من المياه والمادة عفا عليها الزمن. لكن شكرا جزيلا للمؤلف! الوثائق الفعلية وجيدة جدا هنا .
بعد التثبيت الناجح ، يتم التخلص من جميع التعليمات البرمجية الخاصة بنا ، دون أي ندم ، حول الطرقات وتبدأ في اتباع التوجيهات في OSRM api ، ويظهر الرسم البياني النهائي كما يلي:

نحن لا نلمس جزء العميل - من جانبه ، لا تتغير واجهة برمجة التطبيقات الخاصة بخدمتنا بأي شكل من الأشكال.

المجموع : لقد فكرت في الاستخدام الفعلي للتطبيق من قبل الآخرين ، فقد تحولت إلى بنية طبيعية وطرق جيدة. لا يزال إصدار الويب متاحًا ، رغم أنه لم يتغير منذ ذلك الحين. https://travelpath.ru/

الفصل 4: تطبيق Android

على الرغم من حل مشكلة الماضي ، ما زال من الواضح أن المشروع لا يزال عديم الفائدة بالنسبة للجميع باستثناء لي. لأنك تحتاج إلى واجهة عادية ، والأهم من ذلك ، تطبيق جوال ، وليس إصدار متصفح. لقد مضت التكنولوجيا الآن قدما ، وربما سيكون من الممكن بالفعل إنشاء تطبيق متصفح جيد الأداء من هذا النوع لعملاء الأجهزة المحمولة ، ولكن ليس في 2015-2016. مما يعني إمكانية ضيقة للغاية لاستخدام المشروع في شكل نسخة على شبكة الإنترنت - للجلوس في المنزل ، واختيار أماكن مثيرة للاهتمام لزيارتها مقدما. لذلك ، إذا كنا نتحدث عن منتج عادي ، فأنت بحاجة إلى تطبيق محمول بواجهة جيدة.

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

التخطيطات الأولى والنموذج
بادئ ذي بدء ، نحن نحاول التوصل إلى اسم جديد ، لأن TravelPath ليس اختصارًا كبيرًا للغاية. وهكذا من خلال جهود كيرلس تظهر "يهيمون على وجوههم" مع شعار مضحك:

لقد ربطته بقوة مع رجل شارب ، ولكن بشكل عام أحببته.

ثم تظهر المخططات الأولى للتطبيق في المستقبل:

نعتقد أيضًا أن الخيار الثاني سيناقش ويصبح الإصدار الأول من التطبيق:

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

من المشاكل والمهام التي يتم تذكرها:

• بالنسبة ProGuard Android ، هناك ProGuard - أداة مساعدة تضغط الكود المصدري أثناء التجميع ، وتقطع الأسماء غير المستخدمة ، وتغير الأسماء وغيرها. من المعقول وجودها ، ولكن عندما تبدأ التطوير وتنفذها بنفسك - ليس من الواضح أن هناك حقولًا لإعادة التسمية ويمكن أن يؤثر ذلك على السلوك. وأن كل شيء يحدث فقط في التجمع همز. كنتيجة للإصدار ، كل شيء رائع ، لكن لسبب ما لا توجد إحصائيات. يمكنك بدء تسجيل الدين من الواجهة الخلفية - ويرسل العميل بعض الهراء ، بدلاً من أسماء الحقول العادية - a, b, c ، إلخ. العكازات حتى يتمكن API من تحليل هذا بمهارة ، ومن ثم تكتشف أن ProGuard حاول وتحتاج إلى تحديد الفئات الضرورية كاستثناء في التكوين الخاص بها. لا شيء غير عادي بشكل عام ، ولكن ساعة التصحيح حلقت بعيدًا.
• كانت مهمة مثيرة للاهتمام تحديث بيانات التطبيق. قاعدة البيانات الرئيسية تأتي مع ملف apk وأنا أقوم بتحديثه قبل كل إصدار. لكنك تحتاج أيضًا إلى دعم التحديث عبر الشبكة بحيث يكون لدى العملاء دائمًا بيانات جديدة في حالة وجود أي تغييرات.
  في الإصدار الأول ، قررت التركيز فقط على وقت التحديث الأخير. يخزن التطبيق وقت الكائن الأحدث ، في كل مرة يسأله عن الواجهة الخلفية مع هذا الوقت إذا ظهر شيء جديد. يتم إرسال التحديثات إليه ، يتذكر العميل مرة أخرى وقت أحدث الكائنات المستلمة (ولكن ليس وقت التحديث نفسه ، فهذا مهم).
  اتضح أنني فكرت بشدة - لأنه بعد عام ظهرت فئة خامسة - المباني. وعند الترقية من الإصدار القديم إلى الإصدار الجديد ، تنشأ مشكلة. كان علي أن أتغير قليلاً ويقوم العميل بإرسال الوقت لكل فئة ، وليس الفئة العامة. لكن المخطط لا يزال غير مثالي - عند إضافة حقول جديدة إلى الكائنات ، تنشأ مشاكل لا يمكن حلها بهذه الطريقة. هناك أفكار حول كيفية القيام بعمل أفضل ، لكن الأيدي لم تصل ، وبصفة عامة فإن المهمة ليست ذات أولوية كبيرة. الأخلاق - يجدر التعامل مع هذه القضايا بعناية والتفكير مقدمًا قليلاً.

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

5 ديسمبر 2016 ، يضرب التطبيق Google Play
كان لديه وظائف أساسية فقط - وضع طريق ، وعرض معلومات حول النقاط. لكن حتى بدا ذلك نجاحًا! النجاح ، بالطبع ، فقط في عيونهم. كان هناك فهم أن التطبيق لا يزال الخام ويحتاج إلى تحسين.

النسخة الكاملة الأولى والوسائط
لذلك ، أنا أعتبر الإصدار التالي نسخة كاملة وإطلاق أول.
بادئ ذي بدء ، قمنا بمراجعة كل من التصميم والشعار - والآن أصبح الأمر كما يلي:

وأضافوا وظائف مهمة للدليل - المفضلات ، وجهات النظر على الخريطة نفسها ، وقائمة من مناطق الجذب مع البحث. بدا التطبيق المحدث هكذا:

ظهرت فكرة أخرى - للاتصال بمتحف Night Night ووضع وضع منفصل للحدث في سان بطرسبرغ.
Museum Night هي عطلة دولية سنوية حيث تفتح المتاحف ليلًا مع برامج خاصة. تذكرة واحدة صالحة والعديد محاولة للتجول في العديد من المتاحف في وقت واحد. في الوقت نفسه ، لا يوجد متصفح / خريطة للجوال - فقط بعض الوظائف على الموقع الرسمي للحدث.
يبدو أنها تتناسب تمامًا مع فكرة Wander وهي أيضًا مطلوبة. لقد اتصلت بمنظمي الحدث ، لكن لسوء الحظ ، لم تكن الفكرة موضع تقدير وبقيت في ذهني إلى أن تتحسن الظروف.

في النهاية ، اتضح أنه بارد وأخيراً يمكن استخدام التطبيق بالكامل. في 2 يونيو ، 2018 ، تم إصدار إصدار وقررنا محاولة عرضه على العالم - لقد اشترينا بعض الإعلانات على VKontakte و Instagram. ولكن الأهم من ذلك أنهم كتبوا إلى عدد من وسائل الإعلام. كتبت الصحيفة ملاحظة حول إطلاق التطبيق ، بعد ذلك تم كتابة أو إعادة طبع عدد من منشورات بطرسبورغ - القرية ، والكلب وغيرها - مع أحد المعجبين. وأخيرا كان هناك حركة المرور! اندفعت عمليات التثبيت مع ذروة الرسوم البيانية للنشاط داخل التطبيق أيضًا. بالطبع ، لم يكن علينا أن نفرح لفترة طويلة - ولكن حصلنا على المستخدمين الأوائل ، وردود فعل مفيدة وبشكل عام كانت محفزة للغاية. في نفس الصيف ، كانت حركة المرور من بحث Google Play ملحوظة ، وكان ذلك ممتعًا للغاية ، ولكن في وقت لاحق لم يكن من الممكن إعادة إنتاج النتيجة.
جميعًا ، أعطى هذا دافعًا قويًا وساعد على مواصلة العمل على التطبيق.

ماذا تفعل بعد ذلك؟ ليلة المتحف ، جوجل الشر ، وطرق دائرية

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

بالإضافة إلى هذا الوضع ، فقد خرجنا أيضًا من الأعمال المتراكمة التي نجحت في توفير المسار ، والأهم من ذلك - الميزة المتعلقة بالطرق الدائرية.

كانت الطرق الدائرية أكثر أهمية دائمًا من الطرق AB ، ولكن تم تجاهلها بعناد. ومع ذلك ، غالبًا ما يتجول الناس حول المترو / المنزل / العمل / الفندق عن طريق الهدف من الألف إلى الياء. أخيرًا ، وصلوا إلى أيديهم وصعدت إلى مجريات الأمور البسيطة:
نحصل على جميع النقاط داخل دائرة نصف قطرها معين. نصف القطر هو المحدد لطول الطريق. نختار بعض النقاط أولاً (عشوائية مشروطة). يتم فرز جميع الآخرين منه بترتيب تصاعدي للزاوية بينه وبين الوسط ونقطة معينة. / , .

, .

, , :

, , , , , . — , , .

Kotlin , , Wander. , . , . , java — .

, , , . — The Village. - 1000 , 1400 . , Wander , , , . .

Google . — 2018 , API. — 2018- Places API . API, - — . .

— Places API , . , . , — Google Maps, . .

: android Google Play, . burovk , Wander , .

, , , — . , , , — . , — , . , , .

• — git tag v1.0.5 .
• , , , .
• - , .
• — , //etc .

Android . , , , .

— , .

! , . , , , , , .
:

1. — ? - ?
2. . , — .
3. IOS

. , IOS , .

— . Google Play .

النتائج

• , — . , . . , .
• — , . backend , , android Kotlin, , , . , .
• — . - , . - . , — .

. IOS ( ) — !

PS
— https://habr.com/post/414433/ . . , ( -!), .