اكتب مرة واحدة ، انشر في كل مكان: متى تصبح محليًا؟

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

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

ومع ذلك ، حتى مصطلح "أصلي" تم تشويشه مؤخرًا من خلال أطر العمل التي تجمع وصولاً إلى الكود الأصلي (على سبيل المثال ، React Native و Xamarin وما إلى ذلك).

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

اكتب مرة واحدة ، انشر في كل مكان

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

تتضمن الطريقة البديلة - والتاريخية - لتطوير تطبيقات الهاتف المحمول عملية مباشرة تتمثل ببساطة في كتابة تطبيق منفصل لكل منصة ، والتي ، بالطبع ، تحمل معها التكلفة العالية المحتملة للوقت والموارد.

بشكل عام ، تشمل العوامل التي يجب مراعاتها عند اختيار مسار التطوير ما يلي:

• عمر المشروع
• تشكيل وحجم فريق التطوير
• المنصة (المنصات) المرغوبة للتوزيع
• الجدول الزمني المطلوب للسوق
• النطاق الترددي المتاح للتغيير إلى مسار آخر إذا لزم الأمر

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

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

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

غالبية أطر WODE مختلطة ؛ ومع ذلك ، من أجل تحسين كل من الأداء وقيود UX للأطر الهجينة مع الاستمرار في توفير فوائد إطار WODE ، فإن الاتجاه الحالي هو نحو غير مختلط . بسبب هذا الاتجاه ، تكتسب أطر عمل مثل React Native و Xamarin و Appcelerator شعبية.

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

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

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

التطبيقات الأصلية

تتم كتابة التطبيقات الأصلية باللغة الأساسية للنظام الأساسي المحدد. على سبيل المثال ، تتم كتابة تطبيقات Android بلغة Java ، بينما تتم كتابة تطبيقات iOS إما بلغة Obj-C أو Swift. تتطلب من مهندس التطوير فهم اللغة بالإضافة إلى الفروق الدقيقة الخاصة بالنظام الأساسي ، والتي تشمل ، على سبيل المثال ، تكامل حزمة الطرف الثالث ، وإدارة التخطيط ، وتفاعل نظام التشغيل (OS) ، وما إلى ذلك.

الايجابيات

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

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

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

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

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

سلبيات

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

دورة تطوير أبطأ . تتمتع التطبيقات الأصلية بإمكانية أن يكون لها دورة تطوير أبطأ لمجرد أنه يجب كتابة تطبيق منفصل لكل نظام أساسي مرغوب فيه. الحالة القصوى هي عندما يكون هناك مهندس تطوير محمول واحد في الفريق لأن كل تطبيق مكتوب بشكل أساسي في سلسلة.

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

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

تطبيقات هجينة

عادةً ما تتم كتابة التطبيقات الهجينة باستخدام HTML / CSS / LESS لتصميم واجهة المستخدم: الحرف "V" في نمط تصميم MVC. تتم كتابة "C" ، أو وحدة التحكم ، عادةً في JavaScript - بشكل مثالي ، باستخدام إطار عمل JavaScript MVC مثل AngularJS. يسمح استخدام إطار عمل مثل AngularJS بفصل الفئات والمسؤوليات بشكل أفضل مما هو ممكن عادةً باستخدام jQuery فقط.

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

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

• مشكلة جافا سكريبت
  
• لماذا أنا لست مطور React Native

الايجابيات

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

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

سلبيات

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

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

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

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

تأخر دعم نظام التشغيل . تتفاقم مشكلة مكون الجسر المتتالي / المكون الإضافي لـ Cordova الذي تم ذكره سابقًا عندما يغير نظام التشغيل الوظائف الأساسية. بمجرد تحديث Cordova و PhoneGap و Ionic لدعم التغييرات ، من الممكن أن تحتاج المكونات الإضافية المخصصة ومكونات الجسر إلى التحديث أيضًا. بغض النظر عن ترتيب الحجم الذي قد يتطلبه هذا العمل ، فإنه ينتج عنه وقت إضافي لا يدعم خلاله التطبيق المستخدمين النهائيين الذين قاموا بالتحديث إلى نظام التشغيل الجديد. هذا ، بالطبع ، هو أسوأ سيناريو يتم فيه إجراء تغييرات متقطعة وغير متوافقة مع الإصدارات السابقة بواسطة Apple أو Google ، وهو ما لا يحدث أبدًا ... أليس كذلك؟ بشكل عام ، أي إطار عمل وسيط خارج عن سيطرة المطور ويجب تحديثه أولاً يعمل فقط على تأخير العملية. أخيرًا ، يمكن أن يكون الاعتماد على إطار عمل وسيط بمثابة صداع لمديري المشاريع للتخطيط حوله نظرًا لأن توقيت هذه الأطر غير معروف.

تطبيقات غير هجينة

تبدأ التطبيقات غير الهجينة الحياة تمامًا مثل نظيراتها الهجينة - طبقة واجهة مستخدم مصممة بلغة نظام أساسي غير أصلية: تستخدم React Native HTML / CSS مدعومًا بجافا سكريبت أو Xamarin ، والتي تستند إلى C # نظرًا لجذورها .NET.

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

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

الايجابيات

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

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

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

تكرارات أسرع (رد فعل) . يوفر إطار عمل React ميزة قوية تتيح عرض التغييرات على التطبيق في الوقت الفعلي: لا حاجة إلى إعادة الترجمة أو إعادة البناء وما إلى ذلك. ونتيجة لذلك ، يعد محاكي React أداة تطوير قوية بشكل لا يُصدق تقلل بشكل كبير من مدة كل تنفيذ دورة.

سلبيات

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

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

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

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

دعم طويل المدى (React Native) . هذه المشكلة خاصة بـ React Native وتتعلق بالحقيقة الغريبة المتمثلة في أن Facebook ، حتى الآن ، لم يلتزم بخطة دعم طويلة الأجل لإطار العمل الخاص به. يمكن القول أن هذا يمثل مخاطرة منخفضة نظرًا لأن الشركة تستخدم إطارها الخاص لتطبيقات الأجهزة المحمولة الخاصة بها ، ولكن الأمر يستحق التوقف مؤقتًا لأي مدير مشروع للنظر في سبب رفض Facebook التعليق على هذا الموضوع.

اختيار النهج الصحيح

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

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

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

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

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