تطوير تطبيقات الهاتف المحمول الأصلية. التطبيقات المشتركة بين الأنظمة الأساسية والتطبيقات الأصلية: المقارنة واختيار الأساليب. سلبيات التطبيقات الأصلية
التطوير الأصلي يعني استخدام اللغات والأدوات الأصلية لتطوير نظام تشغيل الهاتف المحمول. يتم إنشاء تطبيقات iOS في بيئة تطوير XCode في Objective-C وSwift وC وC++. لإنشاء تطبيقات لنظام Android، يتم استخدام بيئة Android Studio ولغة Java. تحتوي كل بيئة تطوير على مجموعة كاملة من الأدوات المساعدة لكتابة التعليمات البرمجية وتصميم الواجهة وتصحيح الأخطاء والتنميط (المراقبة) وبناء التطبيقات. يتم إنشاء كل من البيئة ومجموعة الأدوات المساعدة المقابلة لها خصيصًا لكل نظام تشغيل للهاتف المحمول وهي الأدوات الأكثر ملاءمة وقوة لتطوير تطبيقات الهاتف المحمول.
يتضمن التطوير عبر الأنظمة الأساسية استخدام أدوات مساعدة خاصة (أطر العمل) لإنشاء تطبيق يعتمد على عائلة لغات JavaScript. يتم إنشاء بنية التطبيق ومنطقه بالكامل باستخدام هذه الأدوات (PhoneGap، وTitanium، وXamarin، وCordova، وما إلى ذلك) في JavaScript، ثم يتم تغليفها في عنصر تشغيل أصلي، أي. يتكامل مع المشروع الأساسي لـ XCode أو Android Studio. يتيح لك ذلك إنشاء تجميعات المشروع بنفس المنطق لعدة أنظمة تشغيل في وقت واحد.
وأقرب تشبيه هو في حالة أجهزة الكمبيوتر الشخصية. إن MS Word وSkype ووكلاء البريد والتقويمات هي تطبيقات تم تطويرها محليًا لنظام تشغيل سطح المكتب. كل ما يحدث في المتصفح (مواقع الويب، ومحرري النصوص والرسومات عبر الإنترنت، والشبكات الاجتماعية، والمحادثات، والمنتديات) هو عبارة عن تقنيات متعددة المنصات.
إيجابيات التطوير عبر المنصات
يتميز النهج متعدد المنصات للتنمية بالجوانب الإيجابية التالية:
- هناك حاجة إلى موارد أقل لتنفيذ تطبيق لعدة منصات في وقت واحد. هذا، في الواقع، هو جوهر النهج عبر الأنظمة الأساسية - نفس الكود يعمل على كل من iOS وAndroid. هناك حاجة إلى نصف عدد المبرمجين العاملين في المشروع بالضبط. يقوم المصمم بعمل مجموعة واحدة فقط من الرسومات. كل هذا يقلل من عدد ساعات العمل وميزانية المشروع.
⋅ - وقت تطوير أقل. نظرًا لعدم وجود عناصر واجهة فريدة وتقنيات أبسط، عادةً ما يكون الوقت اللازم لإنشاء منتجات بسيطة أقل.
⋅ - دورة تحديث المنتج المبسطة. إذا كانت هناك حاجة إلى إضافة شيء ما إلى المشروع أو الحاجة إلى تصحيح بعض الأخطاء، فسيتم ذلك على الفور لجميع الأنظمة الأساسية التي يتم توزيع المشروع عليها.
⋅ - إمكانية استخدام النسخة المحمولة من الموقع. تستخدم معظم الحلول عبر الأنظمة الأساسية مجموعة لغات JavaScript. لذلك، إذا كان لديك بالفعل نسخة محمولة من الموقع، فيمكن استخدام جزء كبير من التعليمات البرمجية والمواد في التطبيق دون تغييرات.
⋅ - باستخدام منطق تطبيق واحد. ويضمن المنطق المضمن في التطبيق العمل بنفس الطريقة لجميع الأنظمة الأساسية. في كثير من الأحيان قد يكون هذا عيبًا بسبب اختلاف بنية أنظمة التشغيل. ومن الأمثلة الصارخة على ذلك زر "الرجوع" في التنقل بين الشاشات. يوفر Android زر رجوع للجهاز لهذه الأغراض. بالنسبة لنظام التشغيل iOS، قم بتمرير إصبعك من الجانب الأيسر من الشاشة أو اضغط على زر على الجانب الأيسر من شريط التنقل. إذا لم تقم بإنشاء زر على الإطلاق، فلن يتمكن مستخدمو iOS من العودة. إذا تم ذلك، ولكن في المكان الخطأ ويبدو غير قياسي، فسيكون ذلك غير عادي وغير مريح لمستخدمي iOS؛ وإذا تم ذلك كما هو الحال في iOS، فسيكون ذلك غير معتاد بالنسبة لمستخدمي Android. ومع ذلك، فإن المنطق المكتوب والمصحح مرة واحدة يحتوي على عدد أقل من الأخطاء والتناقضات في تشغيله. لذلك لا يتعين عليك القيام بعمل مزدوج وثلاثي للعثور على المشكلات على كل منصة.
إيجابيات التنمية المحلية
يتميز التطوير في التقنيات واللغات الأصلية لنظامي التشغيل iOS وAndroid بالجوانب الإيجابية التالية:
1. سرعة التطبيق.
نظرًا لأنه تم إنشاء التطبيق باستخدام أدوات التطوير الأصلية (XCode، Android Studio)، فإن الكود الذي تم الحصول عليه نتيجة لتجميع المشروع هو الأمثل لهذه المنصة. يتلقى التطبيق دعمًا كاملاً للأجهزة الخاصة بالجهاز (يتم معالجة نفس الصور بواسطة معالج منفصل مصمم خصيصًا لهذا الغرض - GPU)، ويتم استخدام مؤشرات الترابط المتعددة لتنفيذ المهام المعقدة وتحميل المحتوى في الخلفية. أثناء عملية التطوير، يمكن للمبرمجين قياس سرعة جميع أقسام الكود وتحسينها إذا لزم الأمر. لديهم أيضًا أدوات تحت تصرفهم لمراقبة استخدام ذاكرة الوصول العشوائي (RAM)، والبحث عن التسريبات المحتملة، وما إلى ذلك.
2. المرونة في التنفيذ.
على النقيض من القيود المفروضة على إنشاء الواجهة وتعقيد التأثيرات المرئية التي تفرضها أطر تجميع المشاريع عبر الأنظمة الأساسية، يمكنك في التطوير الأصلي تنفيذ كل ما تستطيع تقنيات نظام تشغيل محمول معين تحقيقه.
3. استخدام أحدث التقنيات والاعتماد على أطر العمل المشتركة بين المنصات.
تصبح وظائف البرامج والأجهزة الجديدة التي توفرها الشركات المصنعة للأجهزة وأنظمة التشغيل متاحة للتنفيذ فورًا بعد إصدار التحديثات المقابلة. على سبيل المثال، يتضمن نظام التشغيل iOS 9 إمكانية البحث داخل التطبيقات. يجب على كل واحد منهم تنفيذ طريقة خاصة لإرجاع النتائج لاستعلام بحث محدد. نتيجة لذلك، بالنسبة لتلك التطبيقات التي يتم فيها تنفيذ هذه الوظيفة، تتوفر القدرة على البحث عن المحتوى من خلال قسم بحث النظام في iOS. نفس المكان الذي يتم فيه البحث عن التطبيقات وجهات الاتصال والأحداث والمعلومات الأخرى. في حالة التطوير عبر الأنظمة الأساسية، لتنفيذ هذه الوظيفة، سيتعين عليك الانتظار ليس فقط لإصدار iOS 9، ولكن أيضًا لتحديث الإطار المقابل، ومن المستحيل التنبؤ بموعد دعم بعض الميزات الجديدة سيظهر وما إذا كان سيظهر على الإطلاق.
⋅ 4. سهولة وجودة الاختبار.
بالإضافة إلى الأدوات المذكورة في الفقرة 1 لمراقبة استخدام التطبيق لموارد أجهزة الجهاز، يتوفر لدى المطورين والمختبرين مجموعة كاملة من التقنيات تحت تصرفهم. أولاً، يتم التحكم في جميع معلمات النظام تلقائيًا أثناء تشغيل التطبيق. إذا بدأ أحد التطبيقات في استخدام ذاكرة أكبر من المتوقع أو موارد وحدة المعالجة المركزية أكثر، فلن يمر هذا دون أن يلاحظه أحد. ثانيًا، إمكانية الاستخدام الواسع النطاق لاختبارات الوحدة - الاختبار التلقائي لكل طريقة تقريبًا في التطبيق. إذا توقف جزء من التطبيق عن العمل بشكل صحيح بسبب بعض التغييرات في التعليمات البرمجية، فلن يتم إنشاء الإصدار الجديد ببساطة، وسيرى المبرمج السبب على الفور. ثالثا، هناك فرص كبيرة متاحة لدمج أنظمة مراقبة الأخطاء عن بعد. يحتوي كل مشروع أصلي على الوظيفة المناسبة المضمنة فيه، والتي تتيح لك رؤية الخطأ وسببه الذي حدث على جهاز أي مستخدم.
5. الدعم الكامل من متجر التطبيقات وجوجل بلاي.
تهتم كلتا الشركتين بضمان حصول المستخدمين على التجربة الأكثر إيجابية عند استخدام التطبيقات على الأنظمة الأساسية الخاصة بهم، وهو ما هو ممكن حاليًا. هذا يعني أن التطبيق يجب أن يبدو عالي الجودة قدر الإمكان (إذا كانت الشاشة ذات دقة عالية وكانت الصور غير واضحة، فلن يتم قبول التطبيق ببساطة في متجر التطبيقات)، والعمل بأسرع ما يمكن (إذا كان التطبيق يعرض قائمة صغيرة من العناصر في 20-30 ثانية، لن يسمحوا لك بالدخول أيضًا)، وبشكل عام، يجب أن يكون كل شيء جميلًا ومريحًا. إذا كان أي من هذه المعلمات منخفضًا جدًا أو لم يتم استيفاءه على الإطلاق، فلن يُسمح للتطبيق بالدخول إلى المتجر. إذا لم تكن على المستوى المطلوب، وهو أمر يصعب تحقيقه للغاية باستخدام التقنيات عبر الأنظمة الأساسية وغالبًا ما يكون مستحيلًا من حيث المبدأ، فلن يتم النظر في طلبك أبدًا من قبل الشركات ذات الصلة لوضعه في أقسام إعلانية خاصة (مميزة). من بين التطبيقات الموجودة في الأقسام المميزة في كل من App Store وGoogle Play، لا يوجد تطبيق واحد تم إنشاؤه باستخدام تقنيات الأنظمة الأساسية المشتركة. باستثناء مشاريع الألعاب التي لا تكون فيها الواجهة نظامية.
الاستنتاجات
من وجهة نظر فنية ومن وجهة نظر جودة الواجهة التي تم إنشاؤها، يتمتع التطوير الأصلي بالعديد من المزايا. ومع ذلك، هناك مجالات تكون فيها التقنيات عبر الأنظمة الأساسية مبررة: وهي قطاع الألعاب والمشاريع الاختبارية.
تتم كتابة الألعاب الحديثة بأغلبية ساحقة باستخدام تقنيات الأنظمة الأساسية. يؤدي هذا إلى تسريع عملية التطوير بشكل كبير دون التضحية بالجودة، لأن... في هذه الحالة، يتم استخدام أطر رسومية خاصة (الأكثر شيوعًا هو Unity 3D). إذا كان المشروع بحاجة إلى تنفيذه بسرعة لإجراء بعض الاختبارات، وكان الوضع يتطلب أن يعمل المشروع على عدة منصات في وقت واحد، فقد يكون التنفيذ عبر الأنظمة الأساسية هو الحل الأمثل.
إذا لم يكن المشروع مشروع ألعاب، ويهدف إلى التطوير على المدى الطويل ويتطلب تجربة مستخدم إيجابية، فإن التطوير الأصلي يظل خيارًا أكثر ملاءمة.
في يوم من الأيام، من المحتمل أن يصبح الافتقار إلى المعرفة الأساسية حول تطبيقات الهاتف المحمول سلوكًا سيئًا. وفي غضون ذلك، دعونا نتحدث عن أي نوع من التطبيقات هناك. من بعيد، يمكننا التمييز بين ثلاثة أنواع فقط: ما هو التطبيق الأصلي، وما هو تطبيق الويب وما هو المختلط.
هل تعرف ما هو التطبيق الأصلي؟
بالنسبة للمستخدم، التطبيقات الأصلية هي تلك التي تتطلب التثبيت. بشكل عام، هذا صحيح، وكذلك حقيقة أن مثل هذه التطبيقات تم تطويرها خصيصًا لمنصات الأجهزة المحمولة (iOS، Android، Windows Phone). لذلك، يتعين على المطور أن يتمتع بمهارات البرمجة في بيئة تطوير محددة (xCode لنظام iOS، وEclipse لنظام Android).
والنتيجة هي مظهر جميل وتفاعل سلس للتطبيق مع نظام تشغيل الهاتف المحمول. يتقدم التطبيق الأصلي أيضًا بفارق كبير عن كل من التطبيقات الهجينة وتطبيقات الويب عندما يتعلق الأمر بالأمان. تستخدم هذه التطبيقات ذات الاستهلاك الأقل للموارد الكاميرا والميكروفون ومقياس التسارع والمشغل والوظائف الأخرى. تقليديًا، يمكن تقسيم التطبيق الأصلي إلى مجموعتين: التطبيقات التي تتطلب اتصالاً بالإنترنت والتطبيقات غير المتصلة بالإنترنت.
تختلف تطبيقات الويب عن التطبيق الأصلي
يعد استخدام موقع ويب عادي على الهاتف الذكي أمرًا غير مريح في أحسن الأحوال؛ وفي أسوأ الأحوال، ينهار تخطيط الموقع، وبعد ذلك يصبح من المستحيل تمامًا العمل معه. يتم إنشاء تطبيقات الويب بغرض استخدام موقع ويب من الهاتف. لذا، في جوهر الأمر، هذا هو نفس الموقع المُحسّن للأجهزة المحمولة. على عكس التطبيق الأصلي، لا تحتاج تطبيقات الويب إلى التثبيت - فهي تعمل في متصفح هاتفك. لذلك، لا شيء يعتمد على طراز الهاتف (على منصة الهاتف المحمول، لنكون أكثر دقة). وأيضًا، بغض النظر عن النظام الأساسي، لا يمكن لتطبيقات الويب العمل مع وظائف الهاتف الأصلية.
ولكن ما هو إذن التطبيق الأصلي مقارنة بموقع الويب للجوال؟ الخط الفاصل بين تطبيق الويب وموقع الهاتف المحمول رفيع جدًا. وفي هذا الشأن، لا يقتصر الأمر على المستخدمين فحسب، بل في بعض الحالات المطورين أنفسهم. ولكن هناك فرق. من الناحية التقليدية، يحتوي الموقع على معلومات ثابتة إلى حد ما، وهو يشبه الكتيب الرقمي. في تطبيق الويب، يمكن للمستخدم إدارة جزء من هذه المعلومات - إنشاء صفحاته الخاصة، وتبادل الروابط، والنصوص، وما إلى ذلك.
لذلك من الأسهل استدعاء كل ما يسمى عادةً بتطبيقات الويب للخدمات عبر الإنترنت. يمكن أيضًا تسمية تطبيق الويب بشيء تم تنفيذه سابقًا في Flash، والآن في HTML5.
التطبيقات الهجينة
يُطلق على التطبيق المختلط اسم Hybrid لأنه يجمع بين بعض وظائف التطبيق الأصلي وتطبيق الويب. هذا تطبيق متعدد المنصات يمكنه العمل مع برامج الهاتف. يتم تنزيل هذه التطبيقات، تمامًا مثل التطبيقات الأصلية، من متجر التطبيقات، ولكن يتم تحديث البيانات بشكل مستقل. لذلك، يحتاجون دائمًا إلى اتصال بالإنترنت - بدونه، لا تعمل وظائف الويب.
ماذا تختار؟ التطبيق الأصلي، الهجين أو الويب؟
يعد تطوير تطبيق مختلط أرخص وأسرع من إنشاء تطبيق أصلي. لكن المستخدمين لن يلاحظوا الفرق على أي حال. ولذلك، فإن التقنيات الهجينة هي الأكثر شعبية. على الرغم من كل هذا التعقيد، فإن اتخاذ قرار بشأن اختيار التكنولوجيا لتطوير التطبيق أمر بسيط للغاية. إذا كان تطبيقك لا يمكنه العمل بدون الوظائف الأصلية للأجهزة المحمولة، وإذا كانت سرعة معالجة البيانات العالية مهمة جدًا (الألعاب، والشبكات الاجتماعية، وتحديد الموقع الجغرافي)، فلا يمكن العثور على شيء أفضل من تطبيق أصلي. عندما يمكن إهمال السرعة، يكون التطبيق المختلط مناسبًا. يجب إنشاء تطبيق ويب عندما لا يحتاج المستخدم إلى أي شيء منك بخلاف المعلومات التي يمكن أن يحصل عليها من هاتفه إذا كان لديه الإنترنت.إن الجدل حول ما هو الأفضل والأكثر ربحية - التطوير الأصلي أو عبر المنصات - لم يهدأ منذ سنوات عديدة؛ تصبح هذه المشكلة حادة بشكل خاص عندما يكون من الضروري تطوير تطبيق للهاتف المحمول. من ناحية، تبدو فكرة تطوير تطبيق واحد لجميع المنصات مغرية للغاية، ولكن من ناحية أخرى، قد لا يكون لهذا النهج أفضل تأثير على تجربة المستخدم والمظهر والوظيفة والأداء. لقد أعددنا نظرة عامة مختصرة ستساعدك على فهم الفرق الأساسي بين هذين النهجين وتحديد أيهما تختار لتطبيقك.
لك يا عزيزي...
أولاً، دعونا نتحدث عن التنمية المحلية. كل شيء بسيط هنا: يوجد لكل منصة اللغة الأم: لنظام Android، هذا هو Java، لنظام iOS - Objective-C أو Swift، لنظام Windows Phone - C# وما إلى ذلك. كل لغة أصلية لديها مجموعة من التقنيات والأطر الخاصة بها.
مزايااستخدام اللغات الأصلية هو أن التطبيق الذي تم تطويره بها سيعمل بشكل أسرع، وسيكون قادرًا على استخدام جميع إمكانيات وميزات النظام الأساسي، وستكون الواجهة واضحة ومريحة لأي مستخدم للمنصة. بالإضافة إلى ذلك، غالبًا ما يكون تطوير التطبيقات المحلية أسهل من تطوير التطبيقات عبر الأنظمة الأساسية.
العيب الرئيسييتمثل هذا الأسلوب في أنه يتعين عليك إنشاء تطبيق منفصل لكل نظام أساسي، على الرغم من أن معظم الوظائف ستكون هي نفسها. بالإضافة إلى ذلك، فإن تطوير العديد من التطبيقات، كما يخبرنا المنطق، سيكون أطول وأكثر تكلفة. هذه هي بالضبط الطريقة التي ولدت بها فكرة كتابة تطبيق واحد، والذي سيتم إطلاقه بعد ذلك على عدة منصات. ويسمى هذا النهج
تطوير عبر المنصات
هناك طريقتان رئيسيتان لتطوير تطبيق مشترك بين الأنظمة الأساسية: القيام بذلك "يدويًا" عن طريق الكتابة كود C++ وأغلفة لمنصات مختلفةأو استخدم أحدها التقنيات المطورة خصيصا.
التنمية "باليد"
جوهر النهج الأول هو ذلك كود سي++يمكن إطلاقها في أي مكان. يستخدم Android NDK لهذا الغرض، ويستخدم Windows Phone Managed C، كما أن الأنظمة الأساسية الأخرى لديها أيضًا طرقها الخاصة لمعالجة التعليمات البرمجية وتشغيلها. شيء آخر هو أن هذا الرمز سيكون محدودًا في قدراته. على سبيل المثال، في نظام Android، لن يتمكن من الوصول إلى الشاشة أو حتى البدء من تلقاء نفسه. للتغلب على هذه القيود، تتم أولاً كتابة مكتبة ذات المنطق الرئيسي بلغة C++، ثم يتم تضمينها بلغة أصلية تدير المكتبة وتضمن تفاعلها مع الجهاز. ومع ذلك، تجدر الإشارة إلى أن هذا النهج مناسب فقط لمجموعة محدودة من التطبيقات - حيث يوجد بالفعل الكثير من المنطق على العملاء، مما يجعل من المنطقي وضعه في مكتبة منفصلة.
التقنيات
جوهر النهج الثاني هو استخدام إحدى تقنيات التطوير عبر الأنظمة الأساسية، والتي يوجد منها الكثير اليوم. وهنا الأكثر شعبية:
رد الفعل الأصليحظيت بشعبية خاصة مؤخرًا: حتى عمالقة السوق مثل Uber أو Sberbank يقومون بتجربتها بنشاط. نحن لا نتحدث كثيرًا عن التطبيقات عبر الأنظمة الأساسية، بل عن مبدأ "تعلم مرة واحدة - اكتب في أي مكان"، أي القدرة على استخدام نفس التكنولوجيا لإنشاء تطبيقات لمنصات مختلفة، مما يضمن نسبة عالية من إعادة استخدام التعليمات البرمجية.
هناك خيار آخر لكتابة تطبيق عبر الأنظمة الأساسية وهو الاستخدام HTML5 + جافا سكريبت. بالمناسبة، هذه هي بالضبط الطريقة التي تتم بها كتابة محرر النصوص Atom وVisual Studio Code وSlack (نعم، حتى إصدار سطح المكتب هو في الأساس متصفح تم تصميمه ليبدو وكأنه تطبيق عادي).
حقيقة مثيرة للاهتمام: أصدرت شركة Amperka مؤخرًا وحدة تحكم دقيقة غير عادية من طراز Espruino. الميزة الرئيسية هيالبرامج الثابتة التي تعمل على وحدة التحكم الدقيقة. وهو مكتوب بلغة C النقية، ويتم تحميله مرة واحدة في مكان منفصل في ذاكرة الفلاش الخاصة بوحدة التحكم الدقيقة ويكون مسؤولاً عن تنفيذ كود JavaScript المخصص. الآن يمكنك برمجة وحدات التحكم الدقيقة في JS. على شبيبة، كارل!!!
تبدو هذه الفكرة سخيفة، لكن إذا فكرت فيها، يمكن تبريرها. ومع تطور مفهوم إنترنت الأشياء وزيادة عدد أجهزة إنترنت الأشياء المختلفة في المستقبل، يمكننا أن نتوقع زيادة كبيرة في الطلب على المبرمجين الذين يمكنهم ضمان تفاعلهم مع العالم الخارجي. والعائق أمام الدخول إلى JavaScript أقل بكثير مما هو عليه في C أو Assembler، ولا يمكنك الجدال مع ذلك!
ليس بسيط جدا
تتمثل مزايا التطوير عبر الأنظمة الأساسية في أنه يمكنك كتابة تطبيق أو أي من مكوناته مرة واحدة، باستخدام C++ على سبيل المثال، وتشغيله على منصات وأجهزة مختلفة. ومن المنطقي أن هذا سيتطلب تكاليف أقل. يبدو - اكتب وابتهج! ومع ذلك، فإن هذا النهج لديه أيضا عدد من العيوب.
وكلهم لديهم سبب واحد:جميع المنصات مختلفة.
دعونا نفكر في المضايقات الرئيسية التي سيتعين عليك مواجهتها عند اتباع طريق التطوير عبر الأنظمة الأساسية.
تجربة المستخدم السلبية
كل منصة لها معاييرها الخاصة: الإيماءات وعناصر التحكم القياسية، وترتيب العناصر، ومظهر الرموز... على سبيل المثال، نظرة واحدة على الشاشة تكفي لفهم ما إذا كان نظام التشغيل iOS أو Android. بعد تطوير تطبيق سيبدو بنفس الشكل على جميع الأنظمة الأساسية، ستواجه حقيقة أن المستخدم لن يتمكن من استخدام طرق التحكم المعتادة ولن يرى التصميم المعتاد، وبالتالي سيجد تطبيقك أقل ملاءمة من الأصلي.
هذا، على سبيل المثال، غالبا ما يؤثر على الألعاب التي يتم نقلها إلى جهاز الكمبيوتر من PlayStation: العديد منها لا تدعم الماوس ولا تسمح لك بتخصيص مجموعات المفاتيح الملائمة للاعب، مما يجعلها أقل ملاءمة من الألعاب التي تم تطويرها خصيصًا للكمبيوتر الشخصي. وبينما يمكن أن يكون الحنين إلى تطبيقات مثل Mortal Combat أو Final Fantasy، يجب على مطوري الألعاب الجديدة التفكير مرتين قبل حرمان المستخدمين من عناصر التحكم المألوفة.
مثال آخر هو Matlab، والذي لا يستخدم قائمة علوية على نظام Mac، بل قائمة داخل النافذة، وهو أمر نموذجي لنظام التشغيل Windows ويتعارض مع جميع إرشادات iOS. باعتبارها شركة محتكرة، تستطيع MatLab تحمل تكاليف ذلك، ولكن إذا كنت تقوم بتطوير تطبيق يتنافس مع الآخرين، فمن المفيد التفكير فيما إذا كان المستخدمون سيفضلون الواجهة الأصلية التي يعرفونها.
شيء آخر - تختلف جميع الأنظمة الأساسية في المظهر: الخطوط، وحجم الأزرار وشكلها، ومظهر التقويم، ومربعات الاختيار، وأزرار الاختيار... حتى إذا كنت تريد فقط أن يبدو التطبيق وكأنه تطبيق أصلي، فسيتعين عليك تطوير الأسلوب أوراق لكل منصة، مما يزيد من الإطار الزمني، وتكلفة التطوير.
القيود عند تطوير الوظائف
بالإضافة إلى الإزعاج الذي يسببه المستخدم، فإن التطوير عبر الأنظمة الأساسية يطرح أيضًا عددًا من المشكلات للمطور. والحقيقة هي أن الإجراءات التي تبدو متشابهة تمامًا للمستخدم يمكن تنفيذها بشكل مختلف تمامًا على منصات مختلفة. دعونا نلقي نظرة على الأمثلة.
يختلف الإجراء المألوف مثل السحب والإفلات بشكل أساسي بالنسبة لنظام التشغيل Mac والأنظمة الأساسية الأخرى. بينما يتم التعامل مع هذا الإجراء على نظام التشغيل Windows أو Linux من خلال التطبيق نفسه، يتم تشغيل نظام التشغيل نفسه على نظام التشغيل Mac، مما يعني أن المطور سيحتاج إلى إنشاء حدث "فتح ملف" منفصل حتى يعمل هذا الإجراء بشكل صحيح على جهاز Mac. هذا يعني أنه سيتعين عليك التصالح مع زيادة تكاليف العمالة التطويرية، أو مع حقيقة أن السحب والإفلات المألوف لدى المستخدمين على هذه المنصة لن ينجح ببساطة.
مثال آخر هو فتح مستند معين. على جميع الأنظمة الأساسية، يقوم هذا الإجراء بتشغيل التطبيق وتمرير المستند الذي يجب فتحه كمعلمة؛ على نظام Mac، يتم استخدام حدث خاص "فتح ملف". ومرة أخرى نواجه زيادة في تكاليف العمالة، وبالتالي تكلفة التطوير.
بطء التطبيقات عبر الأنظمة الأساسية: أسطورة أم حقيقة؟
في أي نقاش تقريبًا حول مزايا وعيوب التطوير عبر الأنظمة الأساسية، سترى حجة مفادها أن التطبيقات عبر الأنظمة الأساسية أبطأ بشكل ملحوظ من نظيراتها الأصلية. وهذا صحيح وخاطئ في نفس الوقت. على سبيل المثال، التعليمات البرمجية المكتوبة بلغة C++ والتي يتم تشغيلها على Android باستخدام NDK ستعمل بشكل أسرع من التطبيقات الأصلية. من ناحية أخرى، إذا كنت تستخدم PhoneGap، على سبيل المثال، فإن التطبيق يبدأ في العمل مثل "The House That Jack Build": يستدعي PhoneGap JS، الذي يستدعي Java، الذي يعمل على جهاز Java، والذي يعمل بالفعل على جهاز حقيقي. هاتف. بالطبع، لم نعد نتحدث عن السرعة.
إذن ماذا يجب أن تختار؟
قد يعتقد البعض أن هدفنا هو إقناع الجميع بالتوقف عن تطوير التطبيقات عبر الأنظمة الأساسية. لا على الإطلاق: نحن نشجعك على تقييم النهج الأمثل بالنسبة لك، وعدم ملاحقة الرخص الواضح للحلول عبر الأنظمة الأساسية. لا توجد وصفة واحدة لجميع المناسبات، بل يجب تقييم كل طلب على حدة. دعونا نفكر في قطبين.
على سبيل المثال، تم تطوير لعبة الألغاز الشهيرة 2048 بشكل أفضل كتطبيق متعدد المنصات. تم تطويره على تقنيات الويب، وسيتم تشغيله في كل مكان: يمكنك استخدام نفس PhoneGap لتشغيله على منصات الأجهزة المحمولة، وElectron - لأنظمة التشغيل Windows وLinux وMac، وبالنسبة لمواقع الويب وتطبيقات VKontakte وFacebook، فلن تضطر حتى إلى بذل جهد : سيتم إطلاق التطبيق مباشرة. كل ما عليك فعله هو تجميع البرنامج باستخدام برامج حزم مختلفة وإنشاء رمز لكل نظام أساسي. تم، لا يمكن تمييز التطبيق عن التطبيق الأصلي!
في الطرف المقابل من المقياس، على سبيل المثال، يوجد محرر الرسومات Sketch، الذي اكتسب شعبية تحسد عليها بين مصممي UX وUI (نحن في Noveo نستخدمه أيضًا!). إنه موجود حاليًا فقط لنظام التشغيل OS X، ويتم طرح السؤال حول متى سيتم إصداره لمنصات أخرى كثيرًا حتى أنه تم تضمينه في الأسئلة الشائعة.
"هل Sketch متاح لنظام التشغيل Windows أو Linux؟
نظرًا للتقنيات والأطر الحصرية لنظام التشغيل OS X والتي تم بناء Sketch عليها، فمن المؤسف أننا لن نفكر في دعم Sketch على أي من هذه الأنظمة الأساسية.
(هل هناك إصدارات لنظام التشغيل Windows أو Linux؟
ونظرًا لأن Sketch تم تطويره باستخدام تقنيات وأطر عمل خاصة بنظام التشغيل OS X، فإننا للأسف لا نفكر في النقل إلى أي من هذه الأنظمة الأساسية.)
وبطبيعة الحال، تقع معظم التطبيقات في مكان ما بين هذين النقيضين، لذا فإن اختيار نهج واحد سوف يتطلب تحليلا دقيقا. حاول تقدير: ما هي النسبة المئوية للمستخدمين الذين سيتم تأجيلهم، على سبيل المثال، المظهر غير المعتاد للأزرار أو عدم استخدام القائمة العلوية في OS X؟ هل سيكون هؤلاء هم المستخدمون الذين يجعلون تطبيقك يدفع ثمنه؟ هل يحتوي التطبيق على الكثير من الوظائف التي قد تتطلب تعديلات كبيرة على نظام أساسي واحد أو أكثر؟
بالطبع، اختبار A/B فقط يمكنه تقديم نتائج دقيقة، ولكن مجرد التفكير فيه سيساعدك كثيرًا في اختيار نهج التطوير الخاص بك.
دعونا نلخص ذلك
كل من التطوير الأصلي وعبر الأنظمة الأساسية له مزاياه وعيوبه. تتمثل المزايا الرئيسية للتطبيقات الأصلية في السرعة واستخدام جميع الميزات والميزات الخاصة بكل نظام أساسي. عيبهم الرئيسي هو الحاجة إلى تطوير نفس الوظيفة عدة مرات.
هناك العديد من الأطر والتقنيات للتطوير عبر الأنظمة الأساسية. ومن أشهر هذه البرامج Ionic، وUnity 3D، وXamarin، وReact Native، واستخدام HTML + JavaScript.
تتمثل العيوب الرئيسية للتطوير عبر الأنظمة الأساسية في تجربة المستخدم السلبية والصعوبات في تطوير الوظائف. تؤدي محاولات تخصيص تطبيق لكل منصة إلى زيادة تكاليف العمالة، لذلك في بعض الحالات قد يتبين أن التطبيق عبر الأنظمة الأساسية أكثر تكلفة من عدد من التطبيقات الأصلية، على الرغم من أنه سيكون أقل شأنا منهم من حيث الإمكانيات و تفاعل المستخدم. بالإضافة إلى ذلك، غالبًا ما تعمل التطبيقات عبر الأنظمة الأساسية بشكل أبطأ من التطبيقات الأصلية.
لفهم النهج الذي يجب اختياره، قم بتقييم مدى تعقيد تطبيقك وتفرده. يعد تطوير حلول بسيطة باستخدام تقنيات الأنظمة الأساسية أكثر ربحية، ولكن كلما كانت الوظيفة أكثر تعقيدًا، أصبح التطوير المحلي أكثر ربحية.
بالطبع، من المستحيل تحليل جميع التفاصيل الدقيقة والفروق الدقيقة للتطوير الأصلي والمتعدد المنصات في مقال واحد. كان هدفنا هو توفير فهم للمفاهيم الأساسية والتعقيدات التي تكمن في هذه القضية. شاركنا رأيك وتجربتك في التعليقات!
إذا وجدت خطأ، يرجى تحديد جزء من النص والنقر عليه السيطرة + أدخل.
منذ حوالي عامين كنت أرغب في شراء ميكروفون. كالعادة، قبل الشراء، ألقيت نظرة على العديد من المراجعات للنماذج الأكثر شعبية، وتعرفت على الخصائص التي تميز الميكروفونات، وذهبت إلى الموقع الإلكتروني للمتجر الذي كنت سأشتري فيه الجهاز. وقع اختياري على طراز M1 (من أجل استبعاد اتهامات الإعلان ووضع المنتج، سنقوم بتغيير اسم الميكروفون). يأتي هذا النموذج في تكوينين: ميكروفون عادي وخيار مزود باتصال USB، وهو أكثر تكلفة. بخلاف ذلك، لم يكن الاختلافان مختلفين. حسنًا، لنأخذ المال ونذهب إلى المتجر. تم عرض كلا النموذجين في المتجر. أمسكت بالمستشارة وطلبت أن تريني الميكروفون الذي أعجبني. "هل ترغب في أخذ هذا النموذج؟" سألت الفتاة، مشيرة إلى نسخة أكثر تكلفة مع USB. "هل هي أفضل؟ على وجه التحديد من حيث الصوت؟ فكرت الفتاة للحظة: "نعم، بالطبع أفضل!" نصيحتي: لا تثق بالبائعين!
ولكن من يصدق؟ عندما نرغب في شراء منتج أو خدمة، فإننا نتواصل مع البائعين الذين، للأسف، ليسوا خبراء في هذا الأمر. في رأيي، لا يوجد سوى مخرج واحد في هذه الحالة. خذ كل شيء بين يديك، وعلى الأقل بشكل سطحي، افهم المشكلة التي تهمك أو ابحث عن محترف في هذا المجال واكتشف رأيه. دعونا نفعل ذلك تماما. السؤال الذي سنفهمه هو: "أيهما أفضل - التطبيقات الأصلية أم الهجينة لمنصات الأجهزة المحمولة؟"
الهجينة مقابل المستقيمة
للوصول إلى مكان ما للبدء، دعونا نلجأ إلى طريقة مجربة وحقيقية - ابحث في Google عن المشكلة التي تهمنا. تقوم Google بإرجاع عشرات المقالات المكتوبة كما لو كانت نسخًا كربونية. تحاول أنواع مختلفة من المدونين والمبرمجين والمديرين والمعلنين وأمهات المعلنين وجدات المديرين وغيرهم من الأشخاص "الممتازين" في هذا الموضوع أن ينقلوا إلينا الأشياء التالية بطريقة مثيرة وفردية وروح الدعابة:
- هناك تطبيقات ويب خالصة تشبه التطبيقات الأصلية تقريبًا. على سبيل المثال، app.ft.com. يجب فصلهم عن الهجين.
- لا تعمل تطبيقات الويب الخالصة بدون شبكة.
- ملاحظة مثيرة للاهتمام: من السهل البحث في محتوى تطبيقات الويب الخالصة. ما عليك سوى إدخال الاستعلام الذي يهمك في محرك البحث، وإذا أحبك Google، فسيرى المستخدم موقعك في الصفحة الأولى من نتائج البحث.
- ملاحظة أخرى مثيرة للاهتمام: يجب أن تمتثل التطبيقات الهجينة والمحلية لقواعد معينة حتى يتم نشرها في AppStore أو GooglePlay. من ناحية أخرى، يمكنك بسهولة إنشاء تطبيق موقع الويب المريح الخاص بك بتصميم مبهرج وملفت للنظر، ولن يقول لك أحد كلمة واحدة.
- تكاليف العمالة عند كتابة التطبيقات الهجينة أقل مقارنة بالتطبيقات الأصلية، حيث تتم كتابة جميع التعليمات البرمجية على جميع الأنظمة الأساسية في وقت واحد.
- يعد دعم التطبيقات المختلطة أرخص، حيث يبدو مرة أخرى أن الكود هو نفسه لجميع الأنظمة الأساسية. نقوم بتغييره في مكان واحد - وقد انتهيت.
- تعد التطبيقات الأصلية أسرع بكثير من التطبيقات الهجينة وتطبيقات الويب.
- يمكن أن يعمل التطبيق الأصلي مع جميع مكونات الجهاز، في حين أن التطبيقات الهجينة وتطبيقات الويب لها وصول محدود. على سبيل المثال، يعد الوصول إلى الكاميرا في التطبيقات الأصلية أمرًا معطى. ولكن لكي يتمكن الهجين من التقاط صورة بالكاميرا الخاصة بك، عليك مراوغتها.>
- عند تطوير التطبيقات الأصلية، نحصل على واجهة مستخدم أصلية لكل منصة. الهجين والويب لا يستطيعان القيام بذلك.
وهناك حاجة إلى عدد أقل من المطورين. دعنا فقط نجد اثنين من الرجال الأقوياء الذين يعرفون HTML وJavaScript. سوف يكتبون لنا كل شيء. بخلاف ذلك، ابحث عن جميع أنواع مطوري Java وC# وC++ وObjective-C ثم ادفع أموال هذا الحشد بالكامل.
نحن نمزق الأغطية
يبدو أننا الآن نعرف الفرق بين التطبيقات الهجينة والتطبيقات الأصلية. في هذه المرحلة، يمكنك إنهاء المقالة بهدوء والبدء في العمل - اذهب لكتابة التعليمات البرمجية. لكن لا! نتذكر: "لا تثق بالبائعين!" ومعظم الذين كتبوا كل هذه النقاط هم بائعون، بشكل أو بآخر. لذلك، دعونا معرفة المزيد.
تطبيقات الويب
إن فكرة إنشاء موقع ويب يشبه التطبيق هي بالطبع فكرة مثيرة للاهتمام. هذا النهج له عيوب ومزايا معينة. ولكن هناك سؤال واحد كبير: "لماذا؟" تخيل أنك مستخدم غير مثقل بالمعرفة الخاصة بتقنيات تكنولوجيا المعلومات. تفتح موقعًا إلكترونيًا ما و... يا إلهي! لقد تم فتح طلبي! الشياطين! ربما يكون نوعًا ما من الفيروسات! لكن مهلا، لماذا يظهر خط المتصفح؟ هل هذا موقع أم ماذا؟ أم أنه لا يزال التطبيق؟ حسنًا، إنه ليس في القائمة المثبتة. إنه يعمل ببطء شديد. أفضّل تثبيت تطبيق عادي بدلاً من هذا، ولا أفهم ما هو.
بشكل عام، معنى كل هذه التقليد ليس واضحا تماما. لماذا تضليل المستخدم؟ بعد كل شيء، قد يعتقد شخص ما أن هذا تطبيق ويتوقع سلوكًا يتوافق مع التطبيق العادي. أود إجراء المقارنة التالية: دعونا نجد حجرًا مستديرًا صحيًا ونرسمه بحيث يبدو مثل كرة القدم. وبعد ذلك سنسأل أول لاعب كرة قدم محتمل مصاب بكسر في ساقه عن انطباعاته عن حركة التصميم الأصلية لدينا.
الهجينة
وبما أنني لا أملك خبرة كبيرة في العمل مع PhoneGap وأطر العمل الأخرى من هذا النوع، فقد قررت مناقشة هذه المشكلة مع مطور JS/HTML، الذي كتب البرنامج باستخدام إطار عمل PhoneGap. اتضح أن معظم المشاكل الموصوفة قد تم حلها الآن. في هذه الصفحة، يعدنا اللورد الأسود المقنع بأن الاستجابة الآن للنقرات ستكون سريعة وغير مؤلمة. هناك عربة وعربة صغيرة تحتوي على العديد من المكونات الإضافية التي تتيح لك الوصول إلى أنظمة مختلفة للجهاز المستهدف. وإذا كان هناك شيء مفقود، فيمكنك كتابة البرنامج المساعد الخاص بك. ويبدو أن هذا هو الحل الأمثل لتطوير تطبيقات الهاتف المحمول عبر الأنظمة الأساسية! لكن دعونا نفكر بعمق أكبر في هذه المشكلة.
ما هي هذه الحبوب السحرية - المكونات الإضافية التي تحل جميع المشاكل؟ ربما هذا هو نوع من السحر؟ لسوء الحظ، لا يوجد سحر في عالمنا. على الأقل في مجال تكنولوجيا المعلومات. المكونات الإضافية عبارة عن أغلفة JavaScript فوق كود Android أو iOS الأصلي. لذا، فإن PhoneGap هو في الأساس واجهة مستخدم رسومية وهي في الواقع تطبيق ويب يعمل في WebView. يتفاعل الجزء المنطقي من البرنامج، الذي يتم تنفيذه باستخدام المكونات الإضافية، والتي هي في الواقع استدعاءات للتعليمات البرمجية الأصلية من خلال JavaScript، مع الجهاز. الآن، بعد أن عرفنا مكونات تطبيق fongap، يمكننا التكهن بكيفية عمل كل شيء.
- ماذا تعرف عن الألم؟يعد WebView لنظام التشغيل Android الإصدار 4.3 بطيئًا للغاية عندما تحتاج إلى إظهار شيء أكثر تعقيدًا قليلاً من المعلومات النصية. في الإصدار 4.4، أصبح محرك WebView هو Chromium، لذلك ربما يؤدي هذا إلى تحسين الوضع قليلاً. بشكل عام، بالنسبة لجميع المعجبين وأمثالهم، هذا يعني الألم والمعاناة عند محاولة تشغيل أحد التطبيقات على Android. على نظام التشغيل iOS، يكون الوضع أفضل بكثير، لأن محرك Safari يعمل بشكل أفضل.
- - عفوا، هل أنت امرأة؟ "سأكون ما تريد يا عزيزي."اعتمادًا على الجهاز، يمكن استخدام أنماط مختلفة لواجهة التطبيق. وهذا بالطبع ليس سيئا، لكنه لا يغير منطق التصميم. يوجد زر "رجوع" على نظام iOS، مما يعني أنه سيكون موجودًا على نظام Android أيضًا. ولا يهم أن لا أحد يحتاجها هناك. مثال آخر هو Actionbar. على نظام iOS، يوجد عادةً في الجزء السفلي من الشاشة، أما على نظام Android فهو في الجزء العلوي من الشاشة. في تطبيق PhoneGap، لن يتغير موضع Actiobar الخاص بك اعتمادًا على الجهاز، بل سيبدو مختلفًا فقط. وشيء آخر: كل OC لديه ميزات معينة. على سبيل المثال، الرسوم المتحركة. انظر إلى iOS وAndroid. الرسوم المتحركة للانتقالات بين الشاشات. إنها مختلفة! لن تتمكن التطبيقات المختلطة من تكرار هذه الميزات.
- الخراب ليس في الخزانات بل في الرؤوس.عامل مهم آخر لسبب ما لا يأخذه أحد في الاعتبار. عادةً ما يكون المطورون على PhoneGap مطورين للواجهة الأمامية. ليس لديهم أي فكرة عن الشكل الذي يجب أن تبدو عليه الواجهة لنظام Android أو iOS، حيث أنهم لم يقرؤوا أدلة الأنماط. إنهم لا يعرفون شيئًا عن ميزات النظام الأساسي لأنهم لم يقرؤوا الوثائق. لكنهم جيدون في إنشاء مواقع الويب. وبناء على ذلك، سوف تتلقى طلبا مماثلا للموقع. هل تحتاجها؟ هل حقا في حاجة إليها؟ أنظر لهذه الصورة؟ هل مازلت واثقاً في اختيارك؟
- التماثيل؟ هل أنت؟بجانب الإضافات. هذه مجرد أجزاء من التعليمات البرمجية التي تحل بعض المشكلات. يمكنك أيضًا استخدامها في تطبيق أصلي. تكمن المشكلة في أنه غالبًا ما يتعين على تطبيقك حل المشكلات التي تختلف قليلاً عن تلك التي تحلها هذه الأجزاء من التعليمات البرمجية. أي أنهم سيحتاجون إلى التغيير، ولكن من سيفعل ذلك؟ المطور الخاص بك يعرف فقط JavaScript وHTML. نقطة أخرى دقيقة هي الجمع بين المكونات الإضافية من مطورين مختلفين. إذا كانت المكونات الإضافية تعمل في مجالات ذات صلة، فقد تستخدم نفس المكونات. وهذا يمكن أن يؤدي إلى آثار جانبية مثيرة للاهتمام. والحجر الأخير في حديقة المكونات الإضافية: بعضها لا يحظى بشعبية خاصة، ونتيجة لذلك، تم اختباره بشكل سيئ. كن مستعدًا لحقيقة أنه سيتعين عليك أنت بنفسك أن تعمل كمختبر.
إذن ماذا أريد أن أقول؟ تعد الأنظمة الأساسية في هذه الحالة أمرًا وهميًا وستبدو التطبيقات غريبة. أعتقد أنه يجب استخدام التطبيقات المختلطة كنماذج أولية حيث يمكنك قياس رد فعل المستخدم تجاه فكرتك والحصول على بعض التعليقات. بالنسبة لإصدار الإنتاج، لا يزال من الأفضل استخدام التطبيقات الأصلية. هذه الاعتبارات ذات صلة بجميع الهجينة التي تعمل على مزيج من HTML/JS.
محلي
لن أكتب أي شيء خاص عن السكان الأصليين. كل شيء واضح هنا. إنها تعمل بسرعة وتبدو جيدة ولديها مجموعة واسعة من خيارات التخصيص. وتكلف وفقا لذلك. على الرغم من أن النقاط الثلاث الأولى تكون ذات صلة فقط إذا لم تقم بتعيين فريق من المحترفين الأقوياء الذين يتمتعون بخبرة سبع سنوات من نيودلهي.
حقا عبر منصة
في رأيي، إطار العمل الوحيد الذي يمكن أن يسمح لك حقًا بكتابة تطبيق جوال متعدد المنصات في الوقت الحالي هو C++ Qt. يقوم هذا الإطار بإنشاء كود Android الأصلي باستخدام Android NDK. لذلك، يجب أن يكون الأداء على مستوى التعليمات البرمجية التي كتبها مبرمج باستخدام Android SDK، وبالنسبة للأجزاء التي تستخدم حسابات ثقيلة أعلى - بسبب NDK. Qt هي مكتبة عالية الجودة ومختبرة. هذا يعني أنك لن تكتشف أي أخطاء غبية في هذه العملية. في حالة وجود أي مشكلة، يمكنك إلقاء نظرة على مصادر كيو تي. هذه بالفعل ميزة مطلوبة بشدة للمطورين. في بعض الحالات، هذه هي الطريقة الوحيدة للتغلب على الخطأ. للحصول على البرنامج الخاص بالمنصة المستهدفة (Android أو iOS)، ما عليك سوى إعادة ترجمة المصادر. على الرغم من أنه، على حد علمي، لا يزال يتعين عليك في بعض الأحيان كتابة تعليمات برمجية أصلية للنظام الأساسي، حيث لا تتوفر جميع الميزات من خلال مكتبات Qt. نأمل أن تكون ثابتة هذا قريبا.
ولكن هناك أيضا عيوب. لتطوير الإنتاج، سيتعين عليك شراء ترخيص Qt - والذي، وفقًا لذلك، يكلف أموالاً. هذه مشكلة خطيرة للمطورين الجدد. بالإضافة إلى ذلك، في الوقت الحالي، لا يزال Qt لتطوير الأجهزة المحمولة رطبًا. ونحن في انتظار الإصدارات القادمة.
خاتمة
في الوقت الحالي، لا توجد أداة يمكن أن تسمى بضمير حي بيئة حقيقية عبر الأنظمة الأساسية لتطوير تطبيقات الهاتف المحمول. ربما في المستقبل سوف يشغل هذا المكان كيو تي، لكنه في الوقت الحالي شاغر. لاختبار فكرتك من خلال تطوير نموذج أولي، يمكنك بسهولة استخدام أطر عمل JS/HTML المختلفة، لكنني لا أوصي باستخدامها لتطوير تطبيقات الإنتاج المعقدة. في مجال التطوير هذا، لا يوجد حاليًا بديل للتطبيقات الأصلية.
التنمية الهجينة والمحلية: قابلة للمقارنة؟
تطبيقات هجينة أم أصلية (من اللغة الإنجليزية الأصلية - اللغة الأصلية)؟ يعد هذا أحد أهم الأسئلة التي تطرح على عاتق عميل البرنامج عندما يحتاج إلى إصدار تطبيق جديد لاستخدام المستهلك.
لنبدأ بتعريف كل واحد منهم. يجمع التطبيق المختلط، كما يبدو، بين عناصر من التطبيقات الأصلية (يعمل التطبيق دون أي دعم خارجي) والويب (يتم تشغيل التطبيق باستخدام متصفح ويتم كتابته عادةً بتنسيق HTML5). يستعير التطبيق تقنيات الويب المتوافقة مثل HTML5 وCSS وJavascript ويستخدم بعضًا من التعليمات البرمجية الخاصة به ليكون أكثر استجابة لجهاز المستخدم. يتم وضع التطبيقات الهجينة داخل التطبيق الخاص بها حيث يوجد WebView الخاص بمنصة الهاتف المحمول (المتصفح مضمن داخل تطبيق الهاتف المحمول، إذا جاز التعبير). ببساطة، التطبيق المختلط هو موقع ويب يتم تعبئته في غلاف أصلي. من أمثلة العلامات التجارية التي تستخدم عمليات المزج: Amazon App Store، وGmail، وYelp.
تم تطوير تطبيق أصلي لنظام تشغيل محمول محدد (Objective-C /Swift لنظام iOS أو Java لنظام Android) وتم تحسينه لتحقيق الاستفادة الكاملة من جميع إمكانات النظام الأساسي (الكاميرا، وقائمة جهات الاتصال، ونظام تحديد المواقع العالمي (GPS)، وما إلى ذلك). بشكل أساسي، يتم تنفيذ التطبيق الأصلي باستخدام الأدوات الخاصة بالمنصة. ومن أمثلة هذه التطبيقات ستاربوك، وهوم ديبوت، وفيسبوك (على الرغم من أن البعض يختلف مع الأخير).
دعونا نلقي نظرة على بعض الاعتبارات المهمة التي ستساعدك على الاختيار بين التطبيق الأصلي أو المختلط.
تكلفة التطوير
تم تطوير التطبيقات الهجينة للعديد من المنصات. يمكن تطبيق كود HTML المتطابق وإعادة استخدامه على أكثر من نظام تشغيل للهاتف المحمول. ببساطة، عندما تطلب تطوير تطبيق مختلط، سيعمل منتجك النهائي على الفور على معظم الهواتف الذكية والأجهزة اللوحية الحديثة. بهذه الطريقة، يتم تقليل تكاليف التطوير بشكل كبير.
من ناحية أخرى، يتطلب تطوير التطبيقات الأصلية كتابة برامج مختلفة تمامًا لكل جهاز فريد. على عكس البرمجة الهجينة، التي تقتبس من تجربة HTML5 السابقة على الويب، غالبًا ما تعتبر البرمجة الأصلية أكثر تخصصًا. وبالتالي ترتفع التكلفة، وهو أمر غير عملي بالنسبة للشركات الصغيرة والأفراد.
وقت
غالبًا ما تحظى التطبيقات المختلطة بشعبية لدى الشركات التي تتطلع إلى توصيل شيء ما إلى السوق الشامل في أسرع وقت ممكن. مرة أخرى، نظرًا لأنه يتم إعادة استخدام نفس كود HTML عبر أنظمة تشغيل مختلفة ولا يلزم إعادة كتابة سوى جزء من كود الجهاز المعقد، فسيكون التطبيق جاهزًا للتشغيل على أجهزة متعددة في أسرع وقت ممكن.
إذا لم يكن الوقت أولوية، فقد يكون التطوير الأصلي مناسبًا لك. خلاف ذلك، سيكون من الأفضل الهجين.
التحديثات
يتيح لك التطوير المختلط تحديث المحتوى مباشرةً من الإنترنت. إذا لم يكن هناك تغيير مفاجئ في الوظائف، فإن التحديثات تكون غير ملحوظة تقريبًا. قد لا يتم تثبيت العديد من هذه التحديثات من خلال متجر التطبيقات. وهذا يجعل إصلاح الأخطاء وإضافة التحديثات أكثر كفاءة وأقل إحباطًا للمستخدم. ومع ذلك، هناك تحذير واحد مرتبط بتحديثات الويب.
قد ينشأ موقف حيث يستهدف أحد التطبيقات ميزات النظام الأساسي للجوال التي لم تعد تعمل لأن المكون الإضافي أصبح قديمًا. عندما يحدث هذا، فإنك تواجه معضلة - يجب عليك إما إزالة ميزة التطبيق أو استئجار مبرمج لكتابة مكون إضافي. وينطبق نفس السيناريو عند إصدار إصدارات جديدة من النظام الأساسي للجوال. إذا كنت تريد أن يتمكن تطبيقك من الاستفادة من الميزات الجديدة، فعليك تكليف المطور مرة أخرى بإنشاء مكون إضافي لاستضافة التحديث، أو يمكنك الانتظار حتى يقوم المجتمع بإنشاء مكون إضافي.
من خلال التطوير الأصلي، يمكنك تحديث تطبيقك للتعامل مع تغييرات النظام الأساسي والاستفادة من الميزات الجديدة دون الاعتماد على دعم المجتمع المستمر للمكونات الإضافية الخاصة بك أو الاعتماد على دورات إصدار المجتمع. بالنسبة للتطوير الهجين، من الضروري إجراء دراسة شاملة لموثوقية المكونات الإضافية لتجنب المفاجآت غير السارة في المستقبل القريب.
المستخدمين
من خلال التطبيق الأصلي، يمكنك بسهولة استخدام الوظائف الواسعة لجهازك المحمول: الكاميرا والميكروفون ونظام تحديد المواقع العالمي (GPS) وغير ذلك الكثير. ومع ذلك، فإن منحنى تعلم المستخدم صغير.
يتم أيضًا تطوير التطبيقات الأصلية عادةً للاستخدام في حالة عدم توفر شبكة Wi-Fi أو القدرة على تلقي البيانات من الخارج. يمكن أن يعمل الهجين أيضًا في الوضع المستقل، وسيكون لديك خيارات أقل قليلاً.
ومن الجدير بالذكر أن سرعة الاستجابة، مع تساوي الأمور الأخرى، عادة ما تكون أعلى بالنسبة للتطبيقات الأصلية. غالبًا ما يشعر المستخدم بهذا في بيئة الألعاب التي تعتمد على أداء الرسومات. وينطبق هذا حتى عندما يستخدم التطبيق المختلط HTML5 Canvas وWebGL. الفرق في السرعة هو جزء من الثانية، والأمر متروك لك لتقرر ما إذا كان الأمر بالغ الأهمية أم لا.
أمان
قد يشير النقاد المختلطون إلى عمليات حقن جافا سكريبت أو ثغرات أمنية في طبقة المقابس الآمنة (SSL)، ولكن إذا قمت بتأمين موقعك، فهذا ليس مصدر قلقك. ومع ذلك، تحتوي التطبيقات المختلطة على المزيد من المعلومات المعرفية المتاحة للعامة، مما يزيد من احتمالية إجراء عملية الهندسة العكسية. كما أنها تعتمد أيضًا على المكونات الإضافية، التي تشكل طبقة إضافية من التعليمات البرمجية حيث يمكن العثور على ثغرة أمنية.
تستخدم التطبيقات الأصلية ميزات الأمان الخاصة بها بدون مكونات إضافية. وبالتالي، بالنسبة للتطبيقات التي تتطلب مستوى عالٍ من الأمان، قد يكون التطوير الأصلي أكثر تفضيلاً. بالنسبة لجميع احتياجات تطبيقات الأعمال الأخرى، يوفر التطوير المختلط مستوى مرضيًا تمامًا من الأمان.
التوافق عبر الأنظمة الأساسية
الأمر بسيط هنا - هذا هو المكان الذي تفوز فيه التطبيقات المختلطة: التطبيق الأصلي الذي تم تطويره لجهاز iPhone لن يعمل على نظام Android، والعكس صحيح.
خاتمة
هل تبحث عن إجابة محددة؟ الشيء الوحيد الذي يمكنني أن أخبرك به هو أن أفضل شكل من أشكال تطوير التطبيقات هو الذي يناسب احتياجاتك الفريدة. سيعتمد هذا على مواردك واحتياجات المستخدم النهائي. اسمحوا لي أن أذكرك أنه يمكنك دائمًا الاتصال بي لتطوير البرنامج؛ يمكنني إنشاء تطبيق بلغة Java أو C#. لدي أيضًا خبرة في تطوير J2ME وAndroid.
