تحليل آند أندرويد: توصيات للمطورين المبتدئين

الشرح

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

المشكلة رقم 1: استخدام خادم التحليل بالاشتراك مع PostgreSQl

كان استخدام هذا التكوين يرجع إلى حقيقة أن الخادم قد تم نشره على استضافة VDS ، وأن استخدام قاعدة بيانات MLab عن بعد لم يكن عمليا ، لأنه في وقت التطوير ، كان Roskomnadzor يحاول منع Telegram في روسيا ، وكانت هناك مشاكل في الاتصال دون VPN. لم يكن هناك وقت لتكوين VPN على وحدة التحكم Linux ، وكان المشروع قيد التشغيل ، لذلك قررت استخدام قاعدة بيانات محلية على الخادم. لقد اخترت PostgreSQL لأن لدي تجربة جيدة معها.

القرصنة رقم 1: لكي تعمل قاعدة البيانات دون أخطاء في أنواع البيانات ، عند تثبيت postgres ، تحتاج إلى تثبيت postgis. بعد ذلك ، تحتاج إلى إنشاء قاعدة بيانات وفور إنشاء ، قم بتوصيل جميع امتدادات postgis. يمكنك أن تقرأ عن كيفية توصيل امتدادات postgis بقاعدة البيانات هنا . بعد توصيل جميع الملحقات ، يمكنك توصيل قاعدة البيانات بالخادم ، وفتح لوحة القيادة ومعرفة أن الجداول يتم إنشاؤها دون أخطاء.

Lifehack رقم 2: استخدام إصدار خادم التحليل> = 2.7.2. عندما قمت بتنزيل مشروع الاختبار من gita ، كان هناك إصدار خادم 2.2.5 ، ويبدو أن كل شيء يعمل ، ولكن في وقت لاحق حدث خطأ واحد: مع الحفاظ على إحداثيات تحديد الموقع الجغرافي ، تغيرت خطوط الطول وخطوط lng. وكانت هناك حالتان: إذا كانت الإحداثيات أقل من 90 في القيمة المطلقة ، فكانت العلامة الموجودة على الخريطة في مكان آخر ، وإلا فسيتعطل التطبيق ، وسقط السجل الذي يجب ألا يتجاوز Lat في 90 قيمة مطلقة في وحدة التحكم. ثم بدأت dumbass لمدة يومين في البحث عن حلول. ما لم أجده في مختلف المنتديات وفي مشاكل github: التقليب الإحداثيات في وظيفة Cloud (لا يعمل!) ؛ التقليب الإحداثيات في PostgresStorageAdapter (بعد التغييرات كانت هناك مجموعة من الأخطاء ، لم أكن أريد الخوض في نهاية يوم العمل ، وإيقاف تشغيل الكمبيوتر واليسار). في اليوم التالي ، نظرت إلى الإصدارات ، ورأيت أنه في الإصدار 2.7.2 تم إصلاح الخلل في PostgresStorageAdapter. ثابت بسرعة الإصدار في package.json ، وها ، هو يعمل كما يجب. في هذه المرحلة ، كان هناك إصدار 3.x.x بالفعل ، وحاولت استخدامه ، لكن المطورين قاموا بالعديد من التغييرات المتعلقة بوظائف Cloud ، وظهرت مجموعة أخرى من الأخطاء عند بدء التشغيل. لم يكن هناك وقت لإصلاح رمز العمل ، لذلك كان الإصدار 2.7.2 مناسبًا لي. إذا بدأت مشروعك للتو ، فمن الأفضل بالطبع استخدام أحدث إصدار.

المشكلة رقم 2: LiveQuery لا إلغاء الاشتراك

قضيت أكثر من يوم واحد بقليل لحل هذه المشكلة. وكانت لعنة غريبة وغير واضحة.

في البداية ، كانت الهندسة المعمارية مثل هذا:

public class Subclass extends ParseObject { // init columns, create getters & setters } public class QueryHelper { public static ParseQuery getQuery(Param... params) { ParseQuery query = ParseQuery.getQuery(Subclass.class); // init query by params return query; } } public class MainActivity extends Activity { public void onResume() { ParseLiveQueryClient.getClient().subscribe(QueryHelper.getQuery(), callback); } public void onPause() { ParseLiveQueryClient.getClient().unsubscribe(QueryHelper.getQuery(), callback); } } 

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

بدا الأمر مثل هذا:

 public class Subclass extends ParseObject { // init columns, create getters & setters } public class QueryHelper { public static final ParseQuery query; public static ParseQuery getQuery(Param... params) { if (query == null) { query = ParseQuery.getQuery(Subclass.class); // init query by params } return query; } } public class MainActivity extends Activity { public void onResume() { ParseLiveQueryClient.getClient().subscribe(QueryHelper.getQuery(), callback); } public void onPause() { ParseLiveQueryClient.getClient().unsubscribe(QueryHelper.getQuery(), callback); } } 

بعد مرور بعض الوقت ، ظهرت الفكرة حول كتابة مديري الذي سيراقب الاشتراكات ، لكنني لم أدرك ذلك أبدًا.

الخاتمة

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

• ما هو BaaS
• ما هو تحليل؟ | 5 بدائل لتحليل
• تحليل الوثائق
• تثبيت وتكوين PostgreSQL على أوبونتو
• كيفية توصيل بوستجرس إلى خادم تحليل

حظا سعيدا للجميع!