أول شيء أريد قوله هو أنه كان صعبًا. أصعب بكثير مما كنت اعتقد. لقد واجهت قبل هذه التجربة الصعبة للغاية في جلب المنتجات إلى العمل ، لكنني لم تصل إلى أي مشروع شخصي. لقد انتهوا جميعًا بنماذج أولية بدرجات متفاوتة من الاشمئزاز ، ولكن يبدو أن هذا النموذج قد بقي. في الوقت الحالي ، تم إطلاقه لأكثر من 80 دولة (جميع أوروبا وآسيا وأمريكا الشمالية) ، على كل من المنصات المحمولة ، وفي نهاية المقال سيكون هناك روابط للتنزيل - لذلك ، فإنني أدعو جميع المهتمين إلى المحاولة والاستراحة والتوبيخ.
فيما يلي فكرة موجزة بدأت بها جميعًا:
في رأيي ، يتم البحث عن خرائط الجوّال الحالية للمشاة ولا يعمل مع السائقين على الإطلاق. تحتاج إلى التوقف ، الخوض في الخرائط المليئة بالمعلومات والإعلانات الزائدة ، وكزة في الرموز الصغيرة. هذا غير مريح ، لن يساعدك ذلك في مكان غير معروف ، في النهاية إنه أمر خطير. هناك حاجة إلى حل بسيط ونظيف لا يشتت انتباهك ولا يجعلك تبطئ.
في
الجزء الأول ، وصفت طريقي من هذه الفكرة البسيطة إلى حل عملي ، ثم سأصف كيف جرّ هذا الحل إلى الإصدار.
لتوفير وقتك ، سأبدأ بإعادة سرد مختصرة للجزء السابق: هناك ، كتبت أنه بدلاً من البحث قررت استخدام المسح الضوئي في الحركة ، وتم تبسيط واجهة التطبيق قدر الإمكان. بدلاً من سطر دخول سخيف للسائق ، أضاف العديد من الأزرار الكبيرة للأشياء التي يمكن أن تكون مفيدة في الطريق: محطة وقود ، شحن ، صراف آلي ، موقف سيارات ، صيدلية. بدلاً من الخريطة ، قمت بإنشاء قائمة ، وعندما أقوم بتحديد نتيجة ، يتم فتح التنقل عبر Apple / خرائط Google. بالنسبة للتطبيق ، قررت استخدام Flutter (في نفس الوقت الذي تعرفت فيه على نوع الحيوان) ، أخذت البيانات من OpenStreetMap. أنهيت قصتي على حقيقة أن نموذجًا أوليًا أكثر أو أقل عقلانية كان جاهزًا.
ثم استغرق الأمر حوالي 4-5 أشهر ، ثم بدأت التغييرات في الحياة وذهب المشروع على جانب الطريق - وبدأت أتعب منه. بعد شهر ، قمت بإزالته ، وقمت بتحديثه في رأسي من خلال كتابة مقال على محور وقررت: دعنا ننهي الأمر. أي شخص يعرف الفرق بين النموذج الأولي والمنتج سوف يبتسم بحزن في هذا المكان.
ما حدث بعد ذلك استغرق أربعة أشهر أخرى. حصلت على نفسي متتبع مهام ، بعبارات عامة شكلت قائمة بالمشاكل ، تم جمع الأجهزة للاختبار. في المساء وفي عطلات نهاية الأسبوع ، جلست في العمل ونقلت المشروع إلى الأمام. في لحظات بدا أن القائمة كانت تنمو فقط ، وكنت أغرق في الفروق الدقيقة التي لا نهاية لها ولمسات. أخذ نفسه بيده ، وألقى شيئًا بعيدًا ، في مكان ما على العكس من ذلك قاد إلى الكمال. بعد ذلك ، سأحاول التحدث عن النقاط الأكثر إثارة للاهتمام في تطوير مثل هذا المشروع الذي يبدو بسيطًا.
التكنولوجيا
العمارة العامة
في مكان ما في منتصف العمل ، بدأ الشعور بالظهور بأن العمارة كانت تنتشر عن السيطرة. لقد انتهى عدد كبير من المكونات والوصلات ؛ وتم إخماد العديد من الاختناقات. لحسن الحظ ، فإن المشروع صغير ، وشعرت به في الوقت المناسب ، لذلك لم يكن ترتيب الأمور أمرًا صعبًا. على مستوى المكونات الفردية ، استلزم هذا إعادة إنشاء المكتبات غير الضرورية وطردها ؛ وعلى المستوى العالمي ، قمت بنشر الوظيفة على 3 خوادم صغيرة بدأت في
DigitalOcean .
- خادم API (Python) - الخادم الرئيسي ، ننتقل إليه. لا يوجد الكثير من المنطق ، وخاصة تشكيل النتائج للإخراج. الأكثر اقتصادا من حيث الموارد.
- الخادم المرن (Java) - يقوم Elasticsearch و فوتون (المكود الجغرافي المفتوح المصدر) بالدوران عليه. يستخدمون نفس الفهرس الذي يتم فيه استيراد الكوكب بالكامل من خريطة الشارع المفتوح. وظائف الخادم: البحث عن الأماكن عن طريق المكب والرمز الجغرافي. بطبيعتها ، تكون المرونة سريعة وخفيفة للغاية ، وبالتالي فإن الخادم ليس دهنيًا جدًا.
- خادم جيو (العقدة) هو الأصعب على الإطلاق. استنادًا إلى "جهاز توجيه المصادر المفتوحة" ، كتبت رسالة صغيرة ، وتشمل مهامها جميع الحسابات الجغرافية: وضع الطرق ، وحساب الأيزوكرون ، وتوليد البلاط. كل عملية فردية ليست حيلة للغاية ، ولكن هناك حاجة إلى العشرات منها لأي بحث ، وهذا يصبح عنق الزجاجة. في الوقت الحالي ، على هذا الخادم 16 جيجابايت من ذاكرة الوصول العشوائي ، وبشكل عام ، كل شيء يعمل في الثانية تقسيم - باستثناء توليد البلاط. عندما يكون هناك الكثير منهم في قائمة الانتظار ، يمكنك الانتظار بضع ثوان للصور مع البطاقات. لحسن الحظ ، تظهر على العميل بشكل غير متزامن ، وهذا لا يفسد إلى حد كبير الصورة الشاملة (آمل).
بالإضافة إلى ذلك ، قررت إطعام مقتطفات من OpenStreetMap لإجراء الحسابات الجغرافية بشكل منفصل حسب البلد. إنه يعمل مثل هذا: نحن نقدم الطلب الأول مع إحداثيات إلى الترميز الجغرافي لدينا ، فإنه يحدد البلد ، ثم نأخذ الملفات التي تم تنزيلها فقط من هذا البلد للمعالجات التي نحتاجها. يعد ذلك ضروريًا ، لأنه حتى الخادم القوي الخاص بي لا يستطيع تحويل المستخرج الأكبر من جيغابايت ، فعملية بسرعة تستهلك كل الذاكرة وتختنق. لحسن الحظ ، جميع الدول تقريبًا تتوافق مع هذا الحد ، باستثناء الولايات المتحدة: كان يجب تقسيم هذا الوحش إلى ولايات. أخيرًا ، للحفاظ على واحد وخمسمائة مقتطف ، قررت أن أكتب مجموعة من النصوص التي تتحقق من صحتها وإصلاحها وتحديثها.
بشكل عام ، كل هذا يبدو أكثر تعقيدًا مما يعمل في الممارسة. من حيث المبدأ ، أنا راضٍ عن الحل الناتج - فهو يتمتع باحتياطي جيد للتطوير حسب عدد المناطق المدعومة ومستوى التحميل.
isochron الديناميكي
لفترة طويلة ، كانت إحدى المشاكل الرئيسية بالنسبة لي هي الكثافة غير المتجانسة للنتائج. السبب مفهومة تمامًا - هذه هي الكثافة غير المتجانسة لشبكة الطرق نفسها والمباني الموجودة عليها. في مدينة متوسطة الحجم داخل دائرة نصف قطرها 5 دقائق ، يمكن أن يكون هناك 2-3 أجهزة صراف آلي ، والآن سننتقل إلى وسط المدينة - وفي نفس الوقت ، يمكن أن يكون هناك 20 أو 30 نتيجة. أخيرًا ، نقفز إلى الريف ونلاحظ نتائج مضمونة تقريبًا 0 حتى نقترب من المدينة ويلتقط نصف قطر البحث شيئًا ما.
توفر هذه المشكلة حمولة غير خطية وغير متوقعة على الخادم ، والأهم من ذلك - تجربة سيئة للغاية للمستخدم. إضافة عامل تصفية للخيارات (5 دقائق ، 10 دقيقة ، 30 دقيقة) بشكل أساسي لا يحل أي شيء. في القرية ، حتى دائرة نصف قطرها 30 دقيقة قد لا تعيد أي شيء ، لكن في المدن الكبرى ، حتى 5 دقائق ستفوقك في النتائج. بالإضافة إلى ذلك ، أضفنا وظائف إضافية ، إلى الأزرار التي يجب على السائق تشغيلها أثناء التنقل. بشكل عام ، هراء ، تحتاج إلى حل مختلف اختلافًا جذريًا.
عندما تم العثور على حل ، اتضح أنه بسيط للغاية. بدلاً من الانتقال من الجهة المقابلة ومطالبة المستخدم بتحديد نصف قطر بحث ، يمكننا جعل هذا نصف القطر تلقائيًا. المنطق هو في الواقع الابتدائية:
- تضع قيودًا على النتائج - على سبيل المثال ، 1 على الأقل ولا تزيد عن 20 - وتبدأ بـ 10 دقائق
- القيام بالبحث عن طريق المكان. حتى الآن ، لا نحتاج إلى الحصول على توجيهات إليهم ، لذلك نحن بحاجة فقط لحساب الأيزوكرون والمرشح بواسطة المضلع بطريقة مرنة - كلا العمليتين رخيصتان جدًا
- إذا كان عدد النتائج يتسلل في اتجاه واحد من الحدود (في حالتنا 0 أو 20+) ، قسّم أو اضرب الوقت على 2 وقم بالبحث مرة أخرى. إذا تم تضمينه في الحد الأقصى ، فسنبني بالفعل طرقًا ، والفرز حسب الوقت ، إلخ.
في الواقع ، هذا الأمر أكثر تعقيدًا قليلاً ، وهناك بعض الفروق الدقيقة ، على سبيل المثال ، شبكة مدينة شديدة الكثافة ، عندما قمنا بالفعل بتقليل الوقت إلى الحد الأدنى ، وما زالت هناك نتائج كثيرة للغاية. هنا من الضروري بالفعل الفرز ، وبالتالي لوضع طرق ، وهي مكلفة بعض الشيء. ومع ذلك ، هذه هي الحالات القصوى وأنها ليست ملفتة للنظر للغاية.
في الواقع ، من غير المرجح أن يقوم الشخص بالتمرير في القائمة أدناه من 5 إلى 6 مواقع ، لذلك في 95٪ من السيناريوهات ، قام isochron الحيوي بحل المشكلة. لقد أزلنا عنق الزجاجة - كمية لا يمكن التنبؤ بها من النتائج - وجعلنا الحمل على الخادم الجغرافي لأي طلب مسطح تقريبًا. التحقق من ذلك أمر سهل للغاية:
الطريقة القديمة: تأخذ نصف قطرها 10 دقائق و 30 النتائج
النتيجة: طلب واحد لـ isochron + 30 طلبًا للطرق = 31
طريقة جديدة: تحقق ، 30 نتيجة كثيرة ، قسّم نصف القطر إلى النصف ، والآن نحصل على 10 نتائج
النتيجة: طلبان isochrone + 10 طلبات للمسارات = 12
خريطة جديدة للمنطق
في الجزء الأخير ، وصفت آلية إنشاء البطاقات مع الطرق الموضوعة. اتضح بعد ذلك أنه معقد ومكلف للغاية فيما يتعلق بالحوسبة ، لكني أحببتها كثيرًا لدرجة أنني قررت تركها. في الوقت نفسه ، فهمت أنه في شكلها الحالي لم يكن لديهم فائدة عملية تذكر - لم يكن واضحًا منهم الطريقة التي تسير بها ، وقد تحولوا جميعًا شمالًا. كان من الضروري صقله.
أول شيء قررت القيام به هو نشر الخرائط في الوقت الفعلي باستخدام بوصلة. في الرفرفة ، تم وصف ذلك من خلال المنطق المجهري وعمل بسرعة كبيرة ، ومع ذلك ، مع 10+ النتائج التي تدور باستمرار ، بدأ الأداء في التصريف. بالإضافة إلى ذلك ، بدا الأمر مزعجًا تمامًا: في الواقع ، كانت الصور الثابتة تدور ، وكان هذا أكثر إرباكًا أثناء الركوب مما ساعد بطريقة ما.
كانت الفكرة التالية هي الإشارة على الخرائط إلى اتجاه حركة السهم. كان الأمر بسيطًا جدًا - كان لديّ بالفعل متجه محسوب ، وكل ما كان علي فعله هو إنشاء شكل هندسي للسهم. في الوقت نفسه ، في وضع ثابت ، واصلت البطاقات لإظهار موقف السائق مع علامة مستديرة. كان هناك تحذير واحد - كان من الضروري تطبيع أحجام العلامات والسهام لمستويات تكبير مختلفة. يبدو أن هذه مهمة بسيطة ، لكنني علقت فيها لفترة طويلة. كان الشيء هو هذا: لقد قمت بإنشاء جميع الرموز على الخريطة بالأمتار ، وأخذت أساسًا كسور ارتفاع الخريطة بأكملها بالأمتار. اتضح أنه أثناء إنشاء الخرائط - تحديد الصناديق المربعة مربعة ، والالتصاق وتقليم البلاط عليها ، وما إلى ذلك - الأخطاء المتراكمة ، وأدت هذه الأخطاء الصغيرة في النهاية إلى أحجام مختلفة تمامًا من العلامات المرئية. الجهنمية خاصة كان الوضع مع البطاقات الصغيرة. لن أخوض في تفاصيل الحل ، ومع ذلك ، وبسبب هذه الأخطاء ، يجب إعادة رسم منطق إنشاء البطاقات بالكامل. ساعدت
Turf كثيرًا في ذلك - مجموعة كبيرة من الأدوات لمعالجة البيانات الجغرافية.
مع بطاقات الأسهم كانت بالفعل أكثر فائدة ، ولكن لا يزال هناك شيء مفقود. بعد الاختبار المباشر ، أصبح من الواضح أن جميع البطاقات تحولت شمالًا. في الإحصائيات ، لم يكن هذا ملفتًا للانتباه ، ولكنه أصبح واضحًا على الفور عندما تقف خلف عجلة القيادة. يتوقع السائق دون وعي أن يشير السهم دائمًا عند القيادة. بعد أن اكتشفت هذا ، جلست مرة أخرى للعمل. كانت هذه مرة أخرى واحدة من تلك المهام التي تبدو بسيطة للغاية ، لكنك ستقضي يومين بعدها. يبدو - حساب السمت ، وتحويل GeoJSON النهائي قبل التنقيط. ولكن كان هناك مرة أخرى فارق بسيط - تم إنشاء GeoJSON النهائي بواسطة صندوق محيط مباشر ، وهو يجري تدويره واقتصاصه ، وهو يكتشف المساحات الفارغة.
في الرسم البياني أعلاه ، قدمت حلاً تقريبًا. ونتيجة لذلك ، اتضح أنها ليست مكلفة للغاية من حيث الموارد وتغطي 99 ٪ من السيناريوهات (أعتقد أن الأخطاء ستصعد في مكان ما بالقرب من القطبين). بشكل عام ، لا يزال خادم الحساب الجغرافي هو الجزء الأكثر كثافة للموارد في المشروع ، ولكن بطاقات المسار الخاصة به ، بالإضافة إلى جمالياتها ، أصبحت أيضًا عملية للغاية. لقد حاولت الوصول إلى المكان باستخدام هذه البطاقات على وجه الحصر ، وليس بما في ذلك التنقل. وحتى وصل.
جودة البيانات
أخذت جميع البيانات الخاصة بي بطرق مختلفة من خريطة الشارع المفتوح. كما تعلمون ، هذا المورد هو 100 ٪ غير هادفة للربح ويدعمها العقل الجماعي. هذه علامة زائد (إنها مجانية وذات بنية واضحة) ، كما أنها ناقص - البيانات غير متجانسة للغاية.
على مستوى عالٍ ، هذا يعني تغطية غير متساوية للعالم ككل: في البلدان والمدن التي تضم عددًا كبيرًا من المتحمسين ، يتم وصف كل مسار ومسار ، وفي أماكن أخرى ، توجد مناطق خالية تقريبًا بها كائنات سطحية أساسية. يتم تحديث البيانات بنفس التباين بالضبط. أثناء اختبار طلبي ، صادفت عدة مرات محطات وقود جديدة ، ومقاهي ، وأحيانًا طرقًا كاملة لم أتمكن من وضعها على الخرائط حتى الآن. الشكوى من هذا الغباء: نفس جوجل تنفق الميزانيات الفلكية وتحتوي على مجموعة كاملة من السيارات المسؤولة عن أهمية بياناتها. حتى هنا أفضل ما يمكننا فعله هو المزامنة في كثير من الأحيان مع مقتطفات OpenStreetMap. حسنًا ، أتمنى حظًا سعيدًا لمجتمعهم.
ولكن على مستوى أقل ، بسبب التحرير الفوضوي للخرائط ، هناك عدد من المشاكل الأخرى التي يمكن حلها بالكامل. يتعلق هذا بشكل رئيسي بالبيانات غير الهامة والتكرارات. تنوع هذه الفوضى ملفت للنظر: يمكن وصف المكان نفسه 3 مرات بطرق مختلفة ، والمؤسسات ليس لديها أسماء وأنواع وعلامات غير صحيحة ، وهكذا. كل هذا لا يحتوي على أي حل موحد ، بل هناك حاجة إلى مجموعة من التدابير لتنظيم المحتوى. على سبيل المثال ، لدي الشروط التالية:
هناك العديد من المرادفات وأشكال مختلفة من نفس العلامة -> نحن نصف قواميس الاسم المستعار (على سبيل المثال ، مواقف السيارات ، مواقف السيارات ، مواقف السيارات ، إلخ).
هناك العديد من الأماكن التي لها نفس النوع والإحداثيات نفسها:
- إذا كان الجميع ليس له اسم -> يصبح نوع المكان هو الاسم
- واحد فقط لديه اسم -> أعتبر
- كل شخص له اسم ومختلف -> يأخذ الاسم الأخير زمنياً
هناك العديد من الأماكن التي لها نفس النوع وتقريبا نفس الإحداثيات:
- إذا لم يكن لكل شخص اسم -> على الأرجح تكرارات ، فلن نعقّد ذلك. دمج في نقطة واحدة مع إحداثيات متوسط ، حيث يصبح نوع المكان هو الاسم. رجل سيأتي ويفهم
- واحد فقط له اسم -> نفس الشيء ، الآن فقط لدينا بالفعل اسم
- كل شخص له اسم وهو مختلف -> لكن هذه مجموعة
المجموعة في حالتنا هي بطاقة في رأسها موصوفة عدة أماكن. غالبًا ما تكون هذه مجموعات من المتاجر أو محطات الوقود القريبة. أو على سبيل المثال ، يوجد جهاز صراف آلي واحد داخل مبنى البنك والآخر بالخارج. إنها لا تمثل أي صعوبة بالنسبة لنا: فنحن نحسب الإحداثيات المتوسطة ونرسم الطريق إليها. في الواجهة ، نظهر هذا بشكل نظيف وبسيط:
واجهة والتصميم
لذلك حدث لي أنه قبل بدء التطوير ، عادة ما أتخيل الصورة النهائية. في الوقت نفسه ، لا أحب رسم المخططات والمفاهيم ، مفضلاً تشكيل تصميم بالتوازي مع الوظائف (إذا كان هذا هو مشروعي ، بالطبع). هذا الأسلوب التكراري رائع من ناحية ، لأنه يسمح لك بالتبديل بين الصور المرئية والرمز ، من ناحية أخرى - في بعض الأحيان يكون عليك إعادة كل شيء بشكل متكرر. حدث الشيء نفسه هنا: يبدو أنني جرفت أبسط واجهة مائة مرة. بدءًا من الرموز التافهة مثل الرموز والمسافات البادئة ، والتي تنتهي بتكوين البطاقات والقوائم وما إلى ذلك. لن أصف كل شيء ، سوف أتطرق بسرعة إلى القضايا الرئيسية. إذا لم تكن مهتمًا بالتصميم ، فلا تتردد في تخطيه.
لوحة الألوان
لفترة طويلة لم أستطع فهم ما يجب فعله باللوحة. أردت حقًا تعيين فئات الأماكن بألوان مختلفة ، باستثناء اللون الأخضر - قررت حفظه كلكنة. اخترت الألوان الغنية بسهولة ، ويبدو أن كل شيء على ما يرام. بعد بعض الوقت ، اكتشفت أن اللون الأزرق لمحطة الوقود يردد اللون الأزرق ، والذي يشير على خريطة السائق إلى موضعه. لم يفعل شيئًا حيال ذلك ، وترك الأمر كما هو - لكن الكمال الداخلي غير راضٍ.
"في الطريق" و "أنت قريب"
بعد أن ظهر المنطق الذي يحدد اتجاه حركة السائق ، أصبح من الممكن تقسيم الطرق إلى "على طول الطريق" والباقي. كما قلت من قبل ، يتم تحديد ذلك من خلال الجزء الأول من المسار الموصل إلى المكان: هل يتزامن ذلك مع الجزء الأخير من مسار السائق. إذا كان الأمر كذلك ، فإننا نذهب بالفعل إلى هذا المكان. ثم السؤال الذي يطرح نفسه حول كيفية إظهار هذا في الواجهة. بالإضافة إلى التغييرات في الخريطة التي وصفتها أعلاه ، جاءت الفكرة من لوحة "في الطريق" (أو "في الطريق" باللغة الإنجليزية - كما لو كانت تعني نفس الشيء). أعيد استخدام نفس القالب لسيناريو آخر: عندما تكون المسافة إلى المكان الموجود أقل من 25 مترًا. ثم لا معنى للحصول على الاتجاهات ، فأنا أخفي الخريطة وأكتب أنك قريب بالفعل ("أنت قريب" / "انظر حولي").
بطاقة المجتمع
في بداية التطوير لـ debug ، استخدمت خريطة ثابتة من Google لمشاهدة الأيزوكرون والنتائج. ثم ركض معها لوقت طويل ، دون أن يعرف أين يلتصق: يبدو أن الخريطة شيء مثير للاهتمام ، لكن يبدو أنه لا ينبغي أن يأخذ مكانًا. بالإضافة إلى ذلك ، لم تكن مؤلمة حتى تريد الاعتماد على جوجل في مثل هذا التافه. في النهاية ، قمت بإزالة الخريطة بعد ذلك ، لكن بعد فترة من الوقت بدأت في إنشاء بطاقات طريق وأدركت أنني قد "نمت" من الناحية التكنولوجية إلى الخريطة الكبيرة بنفسي. اتضح أنه لم يكن من الصعب القيام بذلك ، على الرغم من أن الخريطة المشتركة لا تزال حتى الآن الجزء الأكثر كثافة للموارد من المشروع بأكمله. ولكي لا تشغل مساحة في الواجهة ، أضع البطاقة على صفحة منفصلة (سوف يسحبونها كثيرًا).
التعريب
للحصول على ناتج طبيعي في الإنتاج ، التعريب ضروري. إنه دائمًا من ناحية العمل المباشر والبسيط للغاية ، من ناحية أخرى - عندما تبدأ في القيام بذلك ، تزحف حشود الصراصير من كل مكان. في حالتي ، تم ترجمة المحتوى الرئيسي من OSM بالفعل ، بحيث بقيت أنواع الأماكن وعناصر الواجهة فقط. باستثناء عدد قليل من المقابس (لفترة طويلة لم أستطع صياغة يموت "على طول الطريق") كان كل شيء سهل. تجدر الإشارة إلى أن أسماء الأماكن يمكن أن تشغل كلاً من سطرين و 3 خطوط ، وقد لا
تنسجم مع الشاشات ذات العرض الصغير - وبالتالي فإن أداة
auto_size_text التي ساعدت هنا ، أوصي بها ضمن حدود معقولة.
ولكن على الجانب التقني لم يكن الأمر سلسًا.
حتى الآن ، ما يقرب من الحل الوحيد للتوطين تحت رفرفة هو مكتبة Intl_translation ، وأنه ... غريب. من الواضح أنه يتعين عليهم الجلوس على كرسيين وإنشاء تنسيقات خطوط مختلفة تمامًا لنظامي Android و iPhone. ومع ذلك ، فإن هذا النهج بنقل الترجمات إلى فصل منفصل ، ثم تشغيل البرامج النصية من وحدة التحكم (!) لإنشاء بعض الملفات الوسيطة ، ثم تدوينها ... كل هذا غير واضح تمامًا للمبتدئين ، والأهم من الصعب الحفاظ عليه ، لأن كل تحرير مصحوب برقصات يدوية مع الدف.ومع ذلك ، هناك احتمال أنني لم أفهمها حتى النهاية - أو ربما تقوم بعض بيئات التطوير بالفعل بهذا كله تلقائيًا. على أي حال ، كانت تجربتي مرهقة للغاية ، وآمل أن تتم إعادة صياغة آليات التوطين للرفرفة.تاريخ الإصدار
في الواقع ، لا يوجد شيء مثير للاهتمام لإخباره عن الإصدار نفسه. كانت هناك شكوك غامضة حول رفض متجر أبل رفرفة التطبيق ، لكنها لم تتحقق - كل شيء سار بشكل جيد. قمت بإعادة رسم الرمز ورسمت صفحة مقدمة تلبي المستخدم لأول مرة. اضطررت إلى العبث قليلاً برسم الصور ، لكن يبدو أنه لم يحدث شيء. لا توجد مطبات مع permishens وتوطين بهم أيضا نشأت.في اللحظة الأخيرة ، تعطلت عملية إنشاء الإصدار for android بسبب الانتقال من الدعم إلى androidx: بعض المكتبات التي استخدمتها لم تدعمها على الفور. نتيجة لذلك ، لقد انتظرت بضعة أيام فقط ، لكن يجب أن نشيد بمؤلفي هذه المكتبات - لقد تم إصلاحها بسرعة كبيرة. ومع ذلك ، أقنعني هذا الحادث مرة أخرى: لن أسحب مشروع تجاري كبير بعد. على الرغم من أنني أعجبت به ، إلا أن القصة بأكملها لا تزال شديدة النضج.حسنًا ، كما وعدت ، روابط التنزيل:
خطط
والكلمات القليلة في النهاية عن الخطط. إذا كان هذا الشيء مفيدًا لأي شخص آخر غيري وكان هناك تنزيلات ، فلدي العديد من الأفكار لمزيد من التطوير. فيما يلي قائمة نماذج لما أود تضمينه في الإصدار رقم 2:- مزيد من البيانات حول الأماكن (على سبيل المثال ، أسعار الغاز أو أنواع رسوم السيارات الكهربائية)
- موضوع الظلام للسائقين الليل
- الوضع المضغوط لرؤية المزيد من النتائج دون التمرير (على سبيل المثال ، قم بإيقاف تشغيل الصورة المصغرة إذا رغبت في ذلك)
- تسريع رسم الخرائط (تحتاج حقًا إلى التفكير في عنق الزجاجة هذا - إما تحسين صعبة إلى حد ما ، أو النقل إلى الحاوية الافتراضية)
أرغب في دعم Android Auto و Apple CarPlay بشكل أكبر. لم أتقدم بطلبات من قبل ، لذلك أشعر بالفضول لتجربتها بنفسي.هذا كل شيء ، شكرا لكم جميعا على اهتمامكم.