أكثر 10 أخطاء شائعة ارتكبها مطورو Android: برنامج تعليمي عن البرمجة

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

مع آخر تحديث لـ Lollipop ، تستمر برمجة Android في التحسن. لقد نضجت المنصة قليلاً منذ الإصدار الأولي لـ AOSP ، ووضعت شريط توقعات المستخدم عالياً للغاية. انظروا كيف يبدو نمط تصميم المواد الجديد جيدًا!

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

بغض النظر عن هذا التقسيم الضخم ، فإن غالبية الأخطاء يتم تقديمها بالفعل بسبب أخطاء منطقية. يتم منع هذه الأخطاء بسهولة ، طالما أننا نحصل على الأساسيات الصحيحة!

إليك برنامج تعليمي لبرمجة Android لمعالجة الأخطاء العشرة الأكثر شيوعًا التي يرتكبها مطورو Android.

الخطأ الشائع الأول: التطوير لنظام iOS

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

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

ما لم يكن هناك سبب وجيه للغاية لخرق الإرشادات ، فلا تفعل ذلك. (تقوم Google بهذا طوال الوقت ، ولكن لا تفعل ذلك أبدًا عن طريق النسخ واللصق.)

فيما يلي بعض الأمثلة الأكثر شيوعًا لخطأ Android هذا:

1. لا يجب أن تنشئ علامات تبويب ثابتة ، ولا تنتمي إلى الأسفل (أنا أشير إليك في Instagram).
2. يجب ألا تحتوي رموز إعلام النظام على ألوان.
3. لا يجب وضع أيقونات التطبيقات داخل مستطيل دائري (إلا إذا كان هذا هو شعارك الفعلي مثل facebook).
4. شاشات البداية زائدة عن الحاجة بعد الإعداد الأولي / المقدمة. لا تستخدمها في سيناريوهات أخرى.
5. يجب ألا تحتوي القوائم على علامات إقحام.

هذه ليست سوى عدد قليل من العديد من الأشياء الصغيرة الأخرى التي يمكن أن تدمر تجربة المستخدم.

الخطأ الشائع الثاني: التطوير لجهاز Android الخاص بك

ما لم تكن تقوم بإنشاء تطبيق kiosk / promo لجهاز لوحي واحد ، فمن المحتمل ألا يبدو تطبيق Android الخاص بك جيدًا على كل جهاز. إليك بعض النصائح المتعلقة ببرمجة Android التي يجب تذكرها:

• تختلف وحدات البكسل المستقلة عن الكثافة (dp) عن وحدات البكسل العادية (بكسل).
• يتم تضمين الموارد عدة مرات لحساب الكثافات والتوجهات المختلفة.
• يتم تمديد أدوات الرسم ذات 9 رقعات لتناسب الشاشة.

يوجد بالفعل الآلاف من السيناريوهات المحتملة ، ولكن بعد فترة من الوقت تتطور إحساسًا بتغطيتها جميعًا بعدد قليل من الحالات.

لا تملك آلاف الأجهزة؟ لا مشكلة. يعد Android Emulator جيدًا للغاية في نسخ الأجهزة المادية. والأفضل من ذلك ، جرِّب Genymotion ، فهو سريع للغاية ويأتي مع العديد من الأجهزة الشائعة المُعدة مسبقًا.

أيضا ، هل حاولت تدوير جهازك؟ كل الجحيم يمكن أن ينفجر ...

الخطأ الشائع الثالث: عدم استخدام النوايا

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

لنفترض أن لديك تطبيق معرض يمكنه مشاركة رابط تنزيل لبعض الصور عبر الرسائل القصيرة. أي من الخيارين يبدو أكثر منطقية؟

الخيار 1:

• اطلب إذن SEND_SMS.

   <uses-permission android:name="android.permission.SEND_SMS" />

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

الخيار 2:

• ابدأ نية SMS ودع تطبيقًا مصممًا للرسائل القصيرة يقوم بالعمل

   Intent sendIntent = new Intent(Intent.ACTION_VIEW); sendIntent.setData(Uri.parse("sms:" + telephoneNumber)); sendIntent.putExtra("sms_body", x); startActivity(sendIntent);

في حال كان لديك أي شك ، فإن أفضل حل هو الخيار الثاني!

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

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

الخطأ الشائع الرابع: عدم استخدام الأجزاء

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

يعد بدء نشاط منفصل لكل شاشة تطبيق غير فعال بشكل رهيب ، حيث سيحاول النظام الاحتفاظ بها في الذاكرة لأطول فترة ممكنة. قتل أحدهم لن يحرر الموارد التي يستخدمها الآخرون.

ما لم ترغب في التعمق في جوهر Android وقراءة هذه المقالة ، والدعوة ضد استخدام الأجزاء ، يجب عليك استخدام الأجزاء كلما أمكن ذلك. تقول بشكل أساسي أن الشظايا ولوادر المؤشر لها غرض جيد مقصود ، لكن التنفيذ ضعيف.

الخطأ الشائع # 5: حجب الخيط الرئيسي

الموضوع الرئيسي له غرض واحد: الحفاظ على استجابة واجهة المستخدم.

على الرغم من أن العلم وراء قياس معدل الإطارات الذي يمكن لأعيننا / دماغنا إدراكه معقد ويتأثر بالعديد من العوامل ، فإن القاعدة العامة هي أن أي شيء أقل من 24 إطارًا في الثانية مع تأخير أكبر من 100 مللي ثانية لن يُنظر إليه على أنه سلس.

هذا يعني أن إجراءات المستخدم ستتضمن ردود فعل متأخرة ، وسيتوقف تطبيق Android الذي قمت ببرمجته عن الاستجابة. يؤدي تجريد المستخدم من سيطرته على التطبيق إلى الإحباط ، ويميل المستخدمون المحبطون إلى إعطاء ملاحظات سلبية للغاية.

والأسوأ من ذلك ، إذا تم حظر الخيط الرئيسي لفترة من الوقت (5 ثوانٍ للأنشطة ، و 10 لأجهزة استقبال البث) ، فسيحدث ANR.

كان هذا شائعًا جدًا في Android 2.x ، بحيث لا يسمح لك النظام في الإصدارات الأحدث بإجراء مكالمات عبر الشبكة في السلسلة الرئيسية.

لتجنب حظر الخيط الرئيسي ، استخدم دائمًا مؤشرات ترابط العامل / الخلفية من أجل: 1. مكالمات الشبكة 2. تحميل الصورة النقطية 3. معالجة الصور 4. الاستعلام عن قاعدة البيانات 5. قراءة / كتابة SD

الخطأ الشائع السادس: إعادة اختراع العجلة

"حسنًا ، لن أستخدم الموضوع الرئيسي. سأكتب الكود الخاص بي الذي يتصل بخادمي في سلسلة رسائل خلفية ".

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

1. استخدم gradle كنظام بناء.
2. استخدم التعديل التحديثي / Volley لمكالمات الشبكة.
3. استخدم بيكاسو لتحميل الصور.
4. استخدم Gson / Jackson لتحليل JSON.
5. استخدام تطبيقات مشتركة لتسجيل الدخول الاجتماعي.

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

الخطأ الشائع السابع: عدم افتراض النجاح

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

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

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

الخطأ الشائع الثامن: عدم فهم الصور النقطية

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

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

لنفترض أنك تريد عرض صورة على شاشتك التقطتها للتو بالكاميرا. يتم حساب إجمالي الذاكرة المطلوبة لهذا باستخدام الصيغة التالية: memory_needed_in_bytes = 4 * image_width * image_height;

لماذا 4؟ حسنًا ، تكوين الصور النقطية الأكثر شيوعًا / الموصى به هو ARGB_8888 . هذا يعني أنه لكل بكسل نرسمه ، نحتاج إلى الاحتفاظ بـ 8 بت (1 بايت) لقناة ألفا ، والأحمر ، والجشع ، والأزرق في الذاكرة ، من أجل عرضها بشكل صحيح. هناك بدائل ، مثل تكوين RGB_565 الذي يتطلب نصف الذاكرة من ARGB_8888 ، لكنه يفقد الشفافية ودقة اللون (مع إضافة صبغة خضراء ربما).

لنفترض أن لديك جهازًا جديدًا مزودًا بشاشة عالية الدقة بالكامل وكاميرا بدقة 12 ميجابكسل. الصورة التي التقطتها للتو كبيرة 4000 × 3000 بكسل وإجمالي الذاكرة المطلوبة لعرضها هو: 4 bytes * 4000 * 3000 = 48 MB

48 ميغا بايت من ذاكرة الوصول العشوائي الخاصة بك فقط لصورة واحدة !؟ هذا كثير!

الآن دعنا نأخذ دقة الشاشة في الاعتبار. أنت تحاول إظهار صورة بحجم 4000 × 3000 على شاشة بها 1920 × 1080 بكسل ، وفي أسوأ الحالات (عرض الصورة ملء الشاشة) يجب ألا تخصص أكثر من 4 * 1920 * 1080 = 8.3 MB من الذاكرة.

اتبع دائمًا نصائح برمجة Android لعرض الصور النقطية بكفاءة:

1. قم بقياس العرض الذي تظهر فيه صورك.
2. مقياس / اقتصاص الصورة الكبيرة وفقًا لذلك.
3. أظهر فقط ما يمكن عرضه.

الخطأ الشائع رقم 9: استخدام التسلسل الهرمي للعرض العميق

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

هذه هي الطريقة التي يعمل بها ListView (ومؤخرًا RecyclerView).

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

لنفترض أنك تريد إنشاء شبكة 3x3 بالصور. إحدى طرق القيام بذلك هي تخطيط LinearLayout عمودي يحتوي على 3 LinearLayout بوزن متساوٍ ، تحتوي كل واحدة منها على 3 ImageViews للصور ذات وزن متساوٍ.

ماذا نحصل على هذا النهج؟ تحذير من أن "الأوزان المتداخلة ضارة بالأداء".

هناك قول مأثور في عالم برمجة Android ، لقد اختلقته للتو: "ببذل القليل من الجهد يمكن تسوية كل التسلسل الهرمي" .

في هذه الحالة ، ستستبدل RelativeLayout أو GridLayout بكفاءة LinearLayouts المتداخلة.

الخطأ الشائع رقم 10: عدم ضبط الإصدار minSdkVersion على 14

حسنًا ، هذا ليس خطأ ، لكنه ممارسة سيئة.

كان Android 2.x علامة فارقة في تطوير هذه المنصة ، ولكن يجب ترك بعض الأشياء وراء الركب. يضيف دعم الأجهزة القديمة مزيدًا من التعقيد لصيانة الكود ويحد من عملية التطوير.

الأرقام واضحة ، انتقل المستخدمون ، ولا ينبغي للمطورين البقاء في الخلف.

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

يتم إحتوائه

يعد Android نظامًا أساسيًا قويًا يتطور بسرعة. قد لا يكون من المعقول أن نتوقع من المستخدمين مواكبة الوتيرة ، ولكن من الضروري لمطوري Android القيام بذلك.

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