الجدل حول تطبيقات الأجهزة الجوّالة
مقدمة
تطبيقات الأجهزة الجوّالة وHTML5 هما من أهم التقنيات في الوقت الحالي، وهناك الكثير من التداخل بينهما. تعمل تطبيقات الويب في متصفّحات الأجهزة الجوّالة ويمكن أيضًا إعادة حزمها كتطبيقات محلية على مختلف الأنظمة الأساسية للأجهزة الجوّالة. With the wide range of platforms to support, combined with the sheer power of mobile browsers, developers are turning to HTML5 as a "write one, run many" solution. ولكن هل هو قابل للتطبيق حقًا؟ لا تزال هناك أسباب مقنعة لاستخدام التطبيقات الأصلية، ومن الواضح أنّ العديد من المطوّرين يسلكون هذا المسار. هذه المقالة عبارة عن مناقشة حول التطبيقات الأصلية مقابل الويب.
ميزات وافية
النقطة: يمكن للتطبيقات الأصلية تنفيذ المزيد من المهام
يمكننا تقسيم وظائف الأجهزة الجوّالة إلى بُعدَين: تجربة التطبيق نفسه، وطريقة ربطه بمنظومة الجهاز المتكاملة، على سبيل المثال، بالنسبة إلى Android، ستكون هذه ميزات مثل التطبيقات المصغّرة والإشعارات. وتتفوّق الإعلانات المدمجة مع المحتوى في كلا البُعدَين.
في ما يتعلق بتجربة التطبيق، يمكن للتطبيقات الأصلية أن تفعل المزيد. يمكنهم بسهولة الحصول على أحداث التمرير السريع، حتى اللمس المتعدد، لتلك الأنظمة الأساسية التي تدعمها. ويمكنها عادةً الاستجابة للضغط على المفاتيح المادية، مثل زر البحث في Android وعناصر التحكّم في مستوى الصوت. ويمكنها أيضًا الوصول إلى الأجهزة، مثل نظام تحديد المواقع العالمي (GPS) والكاميرا. وبإذن من المستخدم، توفّر بعض المنصات وصولاً غير مقيّد إلى نظام التشغيل. ما عليك سوى محاولة اكتشاف مقدار البطارية المتبقية باستخدام HTML5!
ومع ذلك، فإنّ الأمر يتجاوز تجربة التطبيق. يوفّر نظام تشغيل مثل Android طرقًا مختلفة تتيح للتطبيقات التفاعل مع المستخدمين ومع التطبيقات الأخرى. لديك تطبيقات مصغّرة نشطة على الصفحة الرئيسية. لديك إشعارات تظهر في شريط الحالة على الجهاز. ولدينا أيضًا الأغراض، والتي تتيح لتطبيقك الإعلان عن نفسه باعتباره يقدّم خدمة عامة قد تتطلبها التطبيقات الأخرى في بعض الأحيان.
وجهة نظر معارضة: يمكن تحسين الميزات الأصلية، والويب يواكب التطور على أي حال
صحيح أنّ العديد من الميزات داخل التطبيق لا يمكن ببساطة الوصول إليها من خلال تطبيق HTML5. مهما كانت مهاراتك في تطوير الويب، إذا كان تطبيقك عالقًا في وضع الحماية بدون واجهة برمجة تطبيقات للكاميرا، فلن يتمكّن من التقاط الصور في أي وقت قريب. لحسن الحظ، ليس عليك أن تكون في بيئة الاختبار هذه. إذا كنت بحاجة إلى تطبيق الويب الخاص بك لالتقاط صورة، يمكنك إنشاء تطبيق أصلي، تطبيق يحتوي على عرض ويب مضمن يوفر الجزء الأكبر من واجهة المستخدم. هذه هي الطريقة التي يعمل بها إطار عمل PhoneGap مفتوح المصدر: فهو يسد الفجوة من خلال الكشف عن الميزات الأصلية كخدمات ويب، والتي يستدعيها عرض الويب باستخدام واجهة برمجة تطبيقات شبكة قياسية. عند إنشاء تطبيق هجين مثل هذا، يمكنك أيضًا الاستفادة من ميزات النظام الأساسي مثل الأدوات والإشعارات والمهام.
إنّ إنشاء تطبيق هجين، أي تطبيق أصلي وتطبيق ويب، ليس حلاً مثاليًا. ويضيف هذا الإجراء تعقيدًا ولا ينطبق إلا على تطبيقات الويب المغلّفة كتطبيقات أصلية، وليس على المواقع الإلكترونية التقليدية التي يتم الوصول إليها من متصفّح الأجهزة الجوّالة. ولكن قد لا يكون ذلك ضروريًا لفترة طويلة. تتطوّر معايير الويب بسرعة، وتواكبها متصفّحات الأجهزة الجوّالة الحديثة. على سبيل المثال، تحظى ميزات التخزين بلا إنترنت والموقع الجغرافي ورسومات اللوحة وتشغيل الفيديو/الصوت بدعم واسع النطاق بين الهواتف الذكية الحديثة. حتى الكاميرا بدأ دعمها، فاعتبارًا من Android 3.1، أصبح من الممكن التقاط الصور والفيديوهات باستخدام معايير الويب. ويدعم أحدث إصدار من متصفّح iOS بروتوكول WebSocket للبث الثنائي الاتجاه، بالإضافة إلى رصد اتجاه الجهاز.
بشكل عام، تتطوّر الأجهزة الجوّالة. لكنّ الويب يتطوّر أيضًا بسرعة. من بين متصفّحات أجهزة الكمبيوتر المكتبي وحدها، هناك خمسة مورّدين رئيسيين للمتصفّحات يطوّرون المعايير ويضيفون الميزات بوتيرة سريعة جدًا. على الرغم من أنّ نقل هذه الميزات إلى الأجهزة الجوّالة ليس عملية بسيطة، فقد تم نقل العديد منها إلى متصفّحات الأجهزة الجوّالة.
تتطوّر التطبيقات الأصلية بسرعة، ولكن الويب يقلّص الفجوة.
الأداء
النقطة: تعمل التطبيقات الأصلية بشكل أسرع
لا تواجه التطبيقات الأصلية عائق وقت تشغيل الويب. وتعمل هذه التطبيقات بالقرب من الأجهزة ويمكنها الاستفادة من معززات الأداء مثل تسريع وحدة معالجة الرسومات وتعدد سلاسل العمليات.
وجهة نظر معارضة: أصبحت بيئات تشغيل الويب أسرع بكثير اليوم، ومعظم التطبيقات لا تحتاج إلى السرعة على أي حال
سيكون من التقليل من شأن الويب أن نقول إنّه أصبح أسرع في السنوات الأخيرة. V8 هو محرّك JavaScript الذي يتم شحنه مع Chrome، وكان يمثّل تطورًا كبيرًا في أداء الويب عند إطلاقه، ومنذ ذلك الحين، أصبح أسرع:
كما ساهمت محركات عرض الرسومات في تسريع الويب، والآن بدأ تسريع الأجهزة. لنلقِ نظرة على زيادة السرعة التي توفرها لوحة تسريع الأجهزة:
بالإضافة إلى ذلك، تتيح واجهة برمجة التطبيقات Web Workers API الجديدة إمكانية تنفيذ سلاسل مهام متعددة، ويمكن لمطوّري تطبيقات الويب الحديثة أيضًا الاستعانة بمجموعة من المكتبات المحسّنة الأداء وأساليب تحسين الأداء التي تم بحثها جيدًا. ومع أنّ معظم هذه الأدوات تم إنشاؤها في البداية لخدمات الويب على أجهزة الكمبيوتر، إلا أنّها لا تزال مفيدة للأجهزة الجوّالة، وهناك اهتمام متزايد بالأجهزة الجوّالة، على سبيل المثال، لدى خبير الأداء "ستيف سودرز" صفحة مخصّصة لأدوات الأداء على الأجهزة الجوّالة.
لم تصل جميع التطورات في أجهزة الكمبيوتر المكتبية إلى كل منصات الأجهزة الجوّالة بعد، ولكن تشير المؤشرات إلى أنها في طريقها إلى ذلك. من المهم أيضًا ملاحظة أنّ غالبية تطبيقات الأجهزة الجوّالة ليست ألعابًا ثلاثية الأبعاد متطورة، ولكنها تعتمد بشكل أساسي على المعلومات: الأخبار والبريد والجداول الزمنية والشبكات الاجتماعية وما إلى ذلك. يمكنك زيارة بعض المواقع الإلكترونية من جهازك الجوّال، مثل GMail وAmazon وTwitter، ويمكنك التأكّد من أنّ أداء الويب على الأجهزة الجوّالة أكثر من كافٍ. أما بالنسبة إلى الألعاب، فيمكن بالفعل إنشاء الألعاب الأساسية باستخدام لوحة ثنائية الأبعاد، وبدأ ظهور WebGL على الأجهزة الجوّالة، مثل Firefox 4. وحتى يصبح واسع الانتشار، هناك مجموعة متزايدة من أُطر العمل التي تجمع تطبيقات WebGL في تطبيقات أصلية يمكنها الاستفادة من OpenGL، مثل ImpactJS.
تجربة المطوّرين
النقطة: التطبيقات الأصلية أسهل في التطوير
تستخدم التطبيقات الأصلية لغات برمجة قوية (مثل Java وObjective C وC++) تم تصميمها لتطوير التطبيقات المعقدة ولها سجل حافل. تم تصميم واجهات برمجة التطبيقات من الأساس لدعم المنصة المتاحة. يمكنك تصحيح أخطاء التطبيقات بسهولة في محاكيات سطح المكتب التي توفر تمثيلاً دقيقًا لجهاز الاختبار.
ما يجعل تطوير الويب مزعجًا بشكل خاص هو التنوع الهائل في المتصفحات وأوقات التشغيل. عند تشغيل تطبيقك، ليس هناك ما يضمن أنّ الميزة "س" ستكون متاحة. وحتى لو كان الأمر كذلك، فكيف سيقوم المتصفح بتنفيذه؟ المعايير مفتوحة للتفسير.
وجهة نظر معارضة: غالبًا ما يكون تطوير الويب أسهل، خاصةً إذا كان يستهدف أجهزة متعددة
لنبدأ بالتكنولوجيا الأساسية. صحيح أنّ معايير الويب تم وضعها في الأساس في عصر كان فيه الويب يركّز بشكل أساسي على المستندات وليس التطبيقات، مع إنشاء JavaScript ونشرها في غضون 10 أيام فقط. ولكن تبيّن أنّها أكثر فعالية مما كان متوقّعًا، فقد تعلّم مطوّرو تطبيقات الويب الاستفادة من الجوانب الإيجابية والحدّ من الجوانب السلبية، مع فهم الأنماط الآن لتصميم قابل للتوسّع. علاوة على ذلك، لا تزال المعايير قائمة، وتعمل الجهود مثل HTML5 وCSS3 وEcmaScript Harmony على تحسين تجربة المطورين. إنّ تفضيلك للغة C++ أو Java أو JavaScript هو مسألة نقاش ديني، ويعتمد أيضًا على قاعدة الرموز البرمجية القديمة لديك. ولكن يمكننا بالتأكيد تضمين JavaScript كمنافس جاد هذه الأيام.
الجانب الآخر من مشكلة تجزئة المتصفّحات/بيئات التشغيل هو أنّ كل هذه البيئات موجودة في الأساس. إذا طوّرت تطبيق Android بلغة Java، عليك نقله بالكامل إلى لغة Objective C ليتوافق مع نظام iOS. يمكنك تطوير تطبيق ويب مرة واحدة وسيعمل على Android وiOS، بالإضافة إلى WebOS وBlackBerry وWindows Mobile و… حسنًا، هذه هي النظرية على أي حال. من الناحية العملية، ستحتاج إلى تعديل بعض الأمور لكل منصة إذا كنت تريد حقًا الحصول على تجربة مناسبة. ولكن عليك القيام بذلك في التطبيقات الأصلية أيضًا، بالنسبة لمعظم أنظمة تشغيل الأجهزة المحمولة - هناك إصدارات مختلفة وأجهزة مختلفة.
الخبر السار هو أنّ "التجزئة" كانت دائمًا على هذا النحو على الويب، وهناك أساليب معروفة للتعامل معها. والأهم من ذلك أنّ مبدأ التحسين التدريجي يحثّ المطوّرين على استهداف جهاز أساسي أولاً، ثم إضافة طبقات من الميزات الرائعة الخاصة بالمنصة حيثما كان ذلك متاحًا. يساعد أيضًا شعار رصد الميزات، وفي الوقت الحالي، لدينا دعم للمكتبات من أمثال Modernizr لدعم تصميم الويب السريع الاستجابة. من خلال الاستخدام الحكيم لهذه الأساليب، يمكنك توسيع نطاق وصولك إلى الغالبية العظمى من الأجهزة، حتى "الهواتف العادية" القديمة، وحتى أشكال الأجهزة مثل الساعات وأجهزة التلفزيون، بغض النظر عن الشركة المصنّعة ونظام التشغيل. يمكنك الاطّلاع على عرضنا التوضيحي لواجهات المستخدم المتعددة في مؤتمر Google IO لعام 2011، حيث استهدفنا أشكالاً مختلفة من الأجهزة (الهواتف العادية والهواتف الذكية والأجهزة اللوحية وأجهزة الكمبيوتر المكتبي وأجهزة التلفزيون) باستخدام قاعدة رموز برمجية مشتركة من المنطق والترميز.
الشكل والأسلوب
النقطة: الإعلانات المدمجة مع المحتوى تتناسب مع شكل المنصة وأسلوبها
إحدى الميزات المحددة لأي منصة هي شكلها وأسلوبها. يتوقع المستخدمون أن يتم تقديم عناصر التحكم بشكل متسق والتعامل معها بنفس الطريقة. هناك بعض المصطلحات التي تختلف من منصة إلى أخرى، على سبيل المثال، ماذا يحدث عندما يقوم المستخدم بـ "الضغط المطوّل" (الاستمرار في لمس عنصر لعدة ثوانٍ)؟ تتضمّن المنصات تعبيرات اصطلاحية عادية لمثل هذه الأمور، ولا يمكنك تلبيتها جميعًا باستخدام تطبيق HTML5 واحد.
علاوة على ذلك، يتم تنسيق شكل وأسلوب النظام الأساسي من خلال مكتبة البرامج الأصلية للنظام الأساسي، والتي تلخص عناصر واجهة المستخدم الخاصة بها نوع الشكل والأسلوب الذي يتوقعه المستخدمون. يمكنك الحصول على الكثير من المظهر المتوقع "مجانًا" بمجرد استخدام مجموعة الأدوات الأصلية.
وجهة نظر معارضة: يتميز الويب بمظهره وأسلوبه الخاص، ويمكنك أيضًا تخصيص واجهة الويب لتلك الأنظمة الأساسية التي تهتم بها أكثر من غيرها
كما هو موضّح في القسم السابق، تتمثل طريقة تطوير تطبيقات الويب في كتابة إصدار أساسي "يناسب الجميع"، ثم تحسينه تدريجيًا. على الرغم من أنّ التحسين يعتمد عادةً على الميزات، يمكنك أيضًا تحسينه من خلال استهداف المنصات التي تهمّك أكثر من غيرها. هذا نوع من "اكتشاف المتصفح"، والذي يرفضه مجتمع الويب أحيانًا، في الغالب بسبب وجود العديد من المتصفحات الممكنة. ولكن إذا كنت ترى منصتين أو ثلاث منصات ذات أولوية عالية جدًا، وكنت على استعداد لبذل جهد إضافي من أجل مواجهة البدائل الأصلية، فقد يكون هذا هو السبيل للذهاب.
بالنسبة إلى الإصدار الأساسي، يتميز الويب بمظهره وأسلوبه الخاص، ويمكننا القول إنّ كل نظام أساسي للأجهزة الجوّالة له "مظهر وأسلوب ويب" خاص به يحدّده المتصفّح التلقائي ووقت تشغيل الويب. قد يكون "مظهر الويب" مناسبًا للمستخدمين، وفي الواقع، يتيح لك تحقيق درجة أكبر من الاتساق مع تجربة التصفّح على متصفّح متوافق مع أجهزة الكمبيوتر المكتبي، بالإضافة إلى تلك الموجودة على الأجهزة الأخرى التي قد يعمل عليها المستخدم. علاوة على ذلك، هناك العديد من التطبيقات الناجحة التي لا تدعم المظهر الأصلي على أي حال. ينطبق هذا بالتأكيد على الألعاب (هل تتبع لعبتك المفضلة على الأجهزة الجوّالة مظهر نظام تشغيل الجوال ومظهره؟)، وحتى على التطبيقات الأكثر تقليدية، على سبيل المثال، تحقق من عملاء Twitter الأصليين الأكثر شيوعًا على النظام الأساسي الذي تختاره، وسترى مجموعة واسعة من آليات واجهة المستخدم في العمل.
سهولة العثور على المحتوى
النقطة: يسهل اكتشاف التطبيقات الأصلية
حققت آليات توزيع التطبيقات، مثل Android Market وApple App Store، شعبية هائلة في السنوات الأخيرة، وهي تمثّل قوة دافعة رئيسية لصناعة الأجهزة الجوّالة بأكملها. يمكن لأي مطوّر إرسال تطبيقه الأصلي إلى السوق، حيث يمكن للمستخدمين اكتشافه من خلال مجموعة من عمليات التصفّح والبحث والحصول على الاقتراحات. ليس هذا فحسب، بل إذا قمت بعملك بشكل صحيح، فإن التقييمات والتعليقات المتوهجة ستقنع المستخدمين بالضغط على زر التثبيت المهم للغاية.
وجهة نظر معارضة: في الواقع، يسهل العثور على تطبيقات الويب
يمكن القول إنّ الويب هو الوسيط الأكثر قابلية للاكتشاف على الإطلاق. في عنوان URL البسيط، لدينا (نظريًا على الأقل) معرّف فريد لكل ما تم نشره على الويب، بما في ذلك أي تطبيقات منشورة على مواقع إلكترونية عادية. تسهّل محرّكات البحث العثور على هذا المحتوى، ويمكن للمواقع الإلكترونية الأخرى إضافة روابط تؤدي إليه، بما في ذلك كتالوجات تطبيقات الويب المشابهة للأسواق على الأجهزة الجوّالة. في الواقع، يمكن لأي شخص مشاركة تطبيقات الويب مع أصدقائه من خلال ربطها في رسائل البريد الإلكتروني ورسائل الشبكات الاجتماعية. يمكن أيضًا إرسال الروابط في رسائل SMS، حيث سيتمكّن مستخدمو الأجهزة الجوّالة من النقر على الرابط وتشغيل التطبيق في متصفّح أجهزتهم.
ليس لدينا حتى الآن الأسواق نفسها التي يمكن للمستخدمين من خلالها تقييم التطبيقات والتعليق عليها، ولكن هذا يتغير أيضًا. متابعة القراءة…
تحقيق الربح
Point: Native can be monetized
"طفل في السادسة من عمره يصنع تطبيقًا خلال ساعة الغداء، ويبيع عددًا هائلاً من النسخ بسعر 3 دولارات لكل نسخة". هذا العنوان شائع جدًا في هذه الأيام، لذا ليس من المستغرب أن يتطلع المطوّرون الكبار والصغار إلى أسواق الأجهزة الجوّالة لتحقيق الربح. توفّر المنصات المخصّصة للأجهزة الجوّالة عدة طرق للمطوّرين لتحصيل رسوم مقابل تطبيقاتهم مباشرةً. أبسط طريقة هي الدفع لمرة واحدة، لفتح التطبيق إلى الأبد. هناك أيضًا آليات دفع عبر التطبيق والاشتراك المعروضة في بعض المنصات، وهي مدمجة بإحكام في آلية متسقة وآمنة. تتيح طرق الدفع الجديدة هذه للمطوّرين تحويل التطبيقات الناجحة إلى مصدر إيرادات طويل الأجل.
بالإضافة إلى الدفعات داخل التطبيق، يمكنك تحقيق الربح من خلال النماذج التقليدية على الويب، مثل الإعلانات والرعاية.
وجهة نظر معاكسة: لطالما كان من الممكن تحقيق الربح على الويب، والفرص في تزايد
لم تكن الويب لتصبح محرّك الصناعة الحديثة لولا توفّر فرص كثيرة لتحقيق الربح. على الرغم من أنّ آليات "الدفع مقابل الاستخدام" المباشرة لم تزدهر بعد، هناك العديد من المجالات التي أصبحت فيها حلول "البرمجيات كخدمة" المستندة إلى الاشتراك قابلة للتطبيق. وتشمل الأمثلة تطبيق Google ومجموعة منتجات 37Signals والإصدارات المدفوعة من خدمات البريد الإلكتروني المختلفة. بالإضافة إلى ذلك، لا تُعدّ الدفعات المباشرة الطريقة الوحيدة لتحقيق الربح من تطبيقات الويب. هناك الإعلانات على الإنترنت، وروابط التسويق بالعمولة، والفيديوهات الدعائية، والترويج المتبادل لمنتجات وخدمات أخرى.
ومع ذلك، من المنطقي تمامًا أن يقرأ مطوِّر تطبيقات ويب العناوين الرئيسية ويشعر ببعض الغيرة من الأرباح. لا يمكنك إرسال عنوان URL للويب إلى الأسواق الأصلية، فما الذي يجب على مطوّر الويب فعله؟ ما عليك فعله هو إنشاء "تطبيق تضمين" أصلي، أي إنشاء تطبيق أصلي فارغ لكل نظام أساسي تريد استهدافه، بحيث يحتوي هذا التطبيق على عرض ويب فقط. "عرض الويب" هو المكان الذي يتم فيه تضمين التطبيق الحقيقي، ثم يتم إرسال هذه التطبيقات إلى الأسواق المختلفة (ونأمل أن تتدفق الأموال!). هناك على الأرجح مئات، إن لم يكن آلاف، التطبيقات المستندة إلى الويب في الأسواق الرئيسية اليوم، وبعضها مدمج بذكاء لدرجة أنّنا لا نعرف حتى أنّها تطبيقات ويب على الإطلاق.
الجانب السلبي هو عبء التجميع المتبادل لكل منصة. هنا يمكن أن يساعد إطار عمل حالي مثل PhoneGap. والأفضل من ذلك، هناك خدمات ويب مثل PhoneGap Build و Apparatio قيد التطوير. ما عليك سوى توجيه هذه المواقع الإلكترونية إلى مستودع الرموز البرمجية، وستحصل على تطبيق Android وتطبيق iOS وما إلى ذلك، جاهزَين لإرسالهما إلى المتاجر المعنيّة. لا حاجة إلى تثبيت حزم تطوير البرامج (SDK) الأصلية على جهازك، فكل ما تحتاجه لإنشاء كل هذه التطبيقات الأصلية هو أداة تعديل الرموز ومتصفح ويب.
هل ستتيح الأسواق استخدام تطبيقات الويب مباشرةً بدون الحاجة إلى تضمينها في تطبيقات أصلية؟ لم يتّضح ذلك بعد. We do know that Google introduced the Chrome Web Store last year, and although it applies only to the desktop, the store has triggered interest from other browser vendors, and is overall part of a trend towards web app catalogues, including some mobile-specific attempts. لا يزال مفهوم السوق الإلكتروني في مراحله الأولى، ولكن المؤشرات واعدة.
الاستنتاجات
سيكون من الجيد الإعلان عن فائز هنا، ولكن في الوقت الحالي، لا يوجد فائز واضح. بعض التطبيقات هي الأنسب للتطبيقات الأصلية وبعضها الأنسب للويب. يمكن القول إنّ حزمة الويب تتمتع بزخم أكبر، ولكن من حيث الإمكانات وجودة التنفيذ، فإنّ التطبيقات الأصلية تتحرك بسرعة أيضًا. وإلى أن يحين الوقت الذي تصبح فيه تكنولوجيات الويب من الدرجة الأولى على معظم أنظمة تشغيل الأجهزة الجوّالة، ستظل التطبيقات الأصلية دائمًا من الاعتبارات المهمة.
من الأساليب المذكورة في هذه المقالة التطبيقات المختلطة، وقد تكون هذه أفضل تسوية لبعض المطوّرين: عرض الويب حيثما أمكن ذلك والمكوّنات الأصلية الخاصة بالنظام الأساسي حيثما لا يكون ذلك ممكنًا.
إذا اخترت مسار الويب، فضع في اعتبارك معايير الويب ومبدأ التحسين التدريجي. إنّ الويب هو تكنولوجيا تعرف كيفية استهداف العديد من الأجهزة وأنظمة التشغيل المختلفة. سواء اخترت تسمية ذلك "تجزئة" أو "تنوّع"، فإنّ الويب يتبنّى ذلك ويمكنكم كمطوّرين الاستفادة من جميع معلومات الاختراع السابق المتاحة.