هناك ثلاث طرق لتحديد تجربة استخدام الهاتف الذكي: حسب شركة الاتصالات ، وبحسب الجهاز ، والتطبيقات. يؤدي الاختيار من قبل شركة الاتصالات إلى وضع جودة الخدمة الخلوية أولاً ، بينما يعني اتخاذ القرار بناءً على الجهاز أنك بعد تجربة منصة معينة وميزات الأجهزة. لكن الاختيار عن طريق التطبيقات يمكن أن يكون أكثر صعوبة.
المجموعة الحالية من الأنظمة البيئية المتنقلة مجزأة وموحدة عبر الأنظمة الأساسية في وقت واحد. تتوفر بعض التطبيقات الرئيسية على العديد من الأنظمة الأساسية ، وكذلك التطبيقات من مطورين أصغر. التطبيقات الأخرى حصرية للمنصة بحكم الميزات الفريدة لنظام التشغيل أو قيود الموارد للمطور. ولكن إذا كنت حقًا بحاجة إلى هذا التطبيق ، فلن يكون لمشغل الشبكة أو الجهاز أهمية كبيرة.
ولكن ماذا لو كانت جميع التطبيقات متاحة على جميع المنصات؟ هل التطوير عبر الأنظمة الأساسية أمر يجب على المطورين القلق بشأنه ، وهل هناك مخاطر يجب مواجهتها عند القيام بذلك؟ هل من الأفضل إنشاء تطبيق خصيصًا لكل نظام أساسي ، أم يجب إنشاء التطبيق باستخدام إطار عمل يستند إلى الويب عبر الأنظمة الأساسية؟
يمكن للمستخدمين والمطورين على حد سواء الاتفاق على أن وجود تطبيق متاح بغض النظر عن النظام الأساسي يعد مثاليًا. لكن بأي ثمن؟
دعنا نبدأ المحادثة!
في الواقع ، السؤال أكثر تعقيدًا. في كثير من الأحيان ، تم إنشاء "الشيء الكبير التالي" بواسطة مطور موهوب حقًا أو فريق صغير ليس لديه الموارد أو المهارات أو القدرات اللازمة للبرمجة عبر الأنظمة الأساسية. لقد رأينا هذا في وقت مبكر مع Instagram و Android - الشركة المشهورة بالتطبيق كان لديها ثلاثة عشر موظفًا فقط. أدت هذه القيود إلى تأخير تطبيق Android Instagram لبعض الوقت ، وحتى الآن بعد شرائه Facebook مقابل مليار دولار لم يطلقوا بعد تطبيقًا متوافقًا مع BlackBerry 10 أو Windows هاتف.
يجب أن تصل المنصة في كثير من الأحيان إلى بعض المقاييس غير المرئية والغامضة التي تعتبر "مقبولة" من قبل الجماهير.
الشركات الصغيرة ليست وحدها هنا ، لأننا غالبًا ما نرى شركات إعلامية ضخمة تتردد في إنشاء تطبيقات عبر الأنظمة الأساسية. يجب أن تصل المنصة المعنية في كثير من الأحيان إلى بعض المقاييس غير المرئية والغامضة التي تعتبر "مقبولة" من قبل الجماهير وعندها فقط ستفكر الشركات في إنشاء تطبيق لها. في بعض الأحيان ، يقوم المطورون "المعجبون" بنظام تشغيل معين بإنشاء تطبيق لتلك المنصة أولاً ، حتى لو لم تكن المشاركة السوقية العملاقة موجودة. حدث هذا مع تطبيق Disqus الرسمي لنظام Windows Phone ، والذي كان أول منصة متنقلة (والوحيدة حتى الآن) تحصل على تطبيق رسمي من خدمة التعليق.
لذا ، نعم ، يجب أن تسعى الشركات دائمًا للعمل عبر الأنظمة الأساسية عندما تستطيع ذلك ، وإذا لم تتمكن من ذلك ، فعليها الوصول إلى المطورين في هذا المجتمع للعمل على شراكة. قامت Foursquare بهذا عندما قام المطور Zhephree بإنشاء تطبيق Foursquare بشكل مستقل لـ webOS مرة أخرى في عام 2009 وأصبح التطبيق هو تطبيق Foursquare الفعلي للمنصة. لسوء الحظ ، هذا أمر نادر الحدوث ، وغالبًا ما يكون المستهلكون مثقلين باختيارات التطبيق التي لا تتضمن الأحدث أو الأكبر لمجرد اختيارهم لمنصة الجوال.
هل ستساعد لغة البرمجة عبر الأنظمة الأساسية مثل HTML5 أو Unity للألعاب؟ المعايير بالتأكيد أفضل من الفوضى ، على الرغم من أنه كما رأينا مع HTML5 حتى الآن ، فقد كانت في الغالب عبارة عن ضجيج وليس نجاحًا.
دبليوعلى الرغم من وجود استثناءات لكل قاعدة ، فأنا أريد حقًا أن أعيش في عالم حيث غالبية تطبيقات الأجهزة المحمولة تعمل عبر الأنظمة الأساسية وتعمل فقط متى وأينما أريدها. خذ الويب على سبيل المثال. يمكنني الوصول إلى أي موقع ويب تقريبًا من أي جهاز في السوق تقريبًا. لا يهتم موقع Facebook إذا كنت أستخدم جهاز كمبيوتر يعمل بنظام Mac أو Windows ، أو على هاتف ذكي أو جهاز لوحي ، أو على Android أو BlackBerry 10.
طالما أن النظام الأساسي يحتوي على متصفح ويب حديث ، يمكنني الوصول إلى أي موقع أريده تقريبًا. يمكنني إنشاء موقع ويب ونشره على مجموعة كاملة من الأجهزة ويمكن للجميع رؤيته. بالنسبة للجزء الأكبر ، إذا كان الموقع ملتزمًا بالمعايير ، فإنه حقًا "يعمل فقط".
حالة تطبيقات الأجهزة المحمولة متعددة المنصات مختلفة تمامًا.
خذ Android Central و CrackBerry و iMore و Windows Phone Central. تستخدم المواقع رمزًا مشابهًا جدًا وتعمل على معظم متصفحات سطح المكتب أو الجوال. أربعة مواقع ، جميع المتصفحات. صفقة جيدة.
ولكن القيام بذلك باستخدام التطبيقات قد يعني استخدام أطر عمل منفصلة ومختلفة إلى حد كبير لأجهزة Android و BlackBerry 10 و iOS و Windows Phone لكل تطبيق من تطبيقات المواقع. أربعة تطبيقات تضرب أربع منصات ليصبح المجموع ستة عشر تطبيقًا. ليست هذه صفقة جيدة.
يمكن قول الشيء نفسه عن الملحقات التي تعتمد على التطبيقات المتصلة. تم إطلاق Nike + FuelBand باعتباره iOS فقط ، ولكن بالنسبة للاستثمار الذي وضعته Nike في أجهزتها ، فإنها ستدعم بشكل مثالي جميع المنصات. كان من الممكن أن يشتري الكثير من غير مستخدمي iOS واحدًا لقضاء عطلة 2012 ، لكن عدم دعم شركة FuelBand وما زال لا يدعم الأنظمة الأساسية الأخرى يحد من سوقها المحتمل. لن يهتم المستخدمون بالنظام الأساسي المشترك - كل ما يهم هو أنه يعمل مع أجهزتهم.
آمل أن يكون HTML5 قويًا ومرنًا بدرجة كافية بحيث يمكنك إنتاج تطبيقات شبه أصلية فيه. وإذا كان الأمر كذلك ، فأنا أفضل HTML5.
- ليو لابورترئيس TWiT ، TWiT.TV
لا أحد يريد تطبيقًا على BlackBerry 10 يبدو تمامًا كما هو الحال على iOS ، ولا يتضمن دعمًا لإيماءات BlackBerry 10.
غالبًا ما تكون الألعاب هي الأبعد في هذا الأمر بفضل المحركات متعددة المنصات مثل Unity و Titanium. ومع ذلك ، تميل الألعاب إلى امتلاك واجهات خاصة بها لا تتوافق مع النظام الأساسي. تطبيقات غير الألعاب مختلفة. بينما يمكن للتطبيقات مشاركة الميزات والخدمات المشتركة وحتى التعليمات البرمجية بين الأنظمة الأساسية ، فإنها تحتاج إلى شكل وأسلوب النظام الأساسي ، ويمكنها الاستفادة من الميزات الخاصة بالمنصة. لا أحد يريد تطبيقًا على BlackBerry 10 يبدو تمامًا كما هو الحال على iOS ، ولا يتضمن دعمًا لإيماءات BlackBerry 10.
في النهاية ، إذا أخرجت مالكي المنصات والمصنعين وحتى المطورين من المعادلة ، فإن الناس يريدون فقط التطبيقات التي يحبونها على الأجهزة التي يحبونها. هذا يعني أن كل تطبيق رئيسي يحتاج إلى دعم كل منصة رئيسية. الآن.
تينظريًا ، يجب أن يكون وجود نفس التطبيقات على جميع المنصات أمرًا لا يحتاج إلى تفكير ، أليس كذلك؟ المزيد من التطبيقات في أماكن أكثر. لكن الحقيقة المخيبة للآمال هي أنه حتى اليوم لا يتم إنشاء جميع التطبيقات على قدم المساواة.
الأنظمة الأساسية المختلفة تفعل الأشياء بشكل مختلف. في بعض الأحيان يتعلق الأمر بالمعدات. لا يتمتع كل من BlackBerry 10 و Windows Phone بقوة المعالجة الخالصة لنظام Android. يمكن القول إن نظام iOS من Apple أسهل في التطوير ويمكنه فعل المزيد بتكلفة أقل. وبالتالي ، فإن التطبيق المتاح لأجهزة iPhone و iPad قد يكون له وظائف مختلفة عن تلك الموجودة على Android أو BlackBerry 10 أو Windows Phone. في الواقع ، لقد رأينا حالات من التطبيقات الشائعة التي تفقد جزءًا كبيرًا من وظائفها عند نقلها من نظام أساسي إلى آخر.
الحقيقة المخيبة للآمال هي أنه حتى اليوم لا يتم إنشاء جميع التطبيقات على قدم المساواة.
ومع ذلك ، فهو ليس دائمًا بهذا العمق. في بعض الأحيان يكون الأمر مجرد مسألة مظهر. ربما لا يبدو التطبيق جيدًا على نظام أساسي كما هو الحال في نظام آخر. سطحي؟ ربما. يجب أن تتمتع التطبيقات بتجربة متسقة عبر الأنظمة الأساسية. أو على الأقل محاولة الحصول على نفس التجربة. لكنهم ما زالوا بحاجة إلى تجربة النظام الأساسي أيضًا. إنه شعر صعب التقسيم.
الخبر السار هو أن التطبيقات هي وحوش سلسة. إنها تتغير وتتحسن باستمرار. ربما ليس بالسرعة التي نرغب بها جميعًا ، ولكن نادرًا ما يكون التطبيق الشائع الذي لا يتم تحديثه أبدًا ، ولا يتحسن أبدًا ، ولا يعيد تصميم نفسه أبدًا.
حتم تصميم تطبيقات TML5 باستخدام تقنيات متوافقة مع معايير الويب مثل HTML و CSS وجافا سكريبت. تعمل هذه التطبيقات في متصفحات ، مثل خرائط Google أو iCloud.com ، أو على الأجهزة المحلية مثل Chrome OS أو webOS المتأخر الذي يشعر بالأسى. نظرًا لأن العديد من المطورين يعرفون بالفعل كيفية بناء تجارب ويب ثرية ، فمن المفترض عمومًا أن تطبيقات HTML5 ستكون أسهل طريق لجلب هؤلاء المطورين إلى الهاتف المحمول. ومن ثم كل شيء من حل Apple الأصلي "الحلو" للتطبيقات في متصفح iPhone إلى Palm's Mojo وأطر Enyo اللاحقة إلى WebWorks من BlackBerry.
أدى ذلك إلى الافتراض ، عمومًا من غير المطورين ، أن HTML5 هو الأمل الأخير والأفضل لمستقبل مثالي حيث تمت كتابتها مرة واحدة ونشرها في كل مكان ، عبر الأنظمة الأساسية ، من سطح المكتب إلى الجهاز اللوحي إلى الهاتف وإلى كل شيء وأي شيء فيه ما بين.
وهي مجموعة من BS.
كان الحل "الحلو" الأصلي من Apple سيئًا للغاية لدرجة أنهم سارعوا لإصدار App Store الأصلي بعد عام ، وهو تطبيق التقويم على webOS 1.0 استغرق إطلاقه عشرين ثانية ، وتنتج Google تجارب أفضل بكثير مع التطبيقات المشفرة محليًا على Android و iOS مما هي عليه في الويب. حتى أفضل تطبيقات الويب للجوال ، مثل Gmail.com و Forecast.io ، تبدو باهتة مقارنة بأبناء عمومتهم الأصليين الأغنى والأفضل أداءً.
ستستفيد التطبيقات الأصلية من الأجهزة الجديدة وأطر العمل الجديدة. سيبقى تقدمهم ، إن لم يكن ينمو.
يقول البعض أنه مع زيادة قوة الأجهزة ، وتحسين JavaScript ، سيزداد أداء ووظائف تطبيقات الويب. هذا صحيح تمامًا. لكن التطبيقات الأصلية ستستفيد أيضًا من الأجهزة الجديدة وأطر العمل الجديدة. سيبقى تقدمهم ، إن لم يكن ينمو.
هذا هو سبب تسمية تطبيقات HTML5 بالمستقبل - إنها تأتي دائمًا ولكنها لا تصل أبدًا.
إن محاولة إنشاء تطبيق كامل في HTML5 يشبه محاولة إنشاء تطبيق كامل موجود تمامًا في وضع عدم الاتصال ، في وضع الطائرة. إنه ليس مستحيلًا ، لكنه ليس مثاليًا ، ويحد بشكل كبير من النطاق والخبرة التي يمكن توفيرها.
إذا أصبح HTML5 أكثر تميزًا من التطبيقات المحلية ، فهذا عالم لا أريد العيش فيه.
- مات بيشوف وبريان كابس ،مهندسو iOS ، Lickability
يتعلق الأمر بهذا: الإنترنت هو الأفضل في توفير البيانات الديناميكية ، والتطبيقات الأصلية هي الأفضل للواجهة والتفاعل. ستستخدم التطبيقات الرائعة أفضل ما في كليهما. مثل iTunes. مثل خرائط Google لأجهزة Android و iOS. مثل الإصدار الأصلي الجديد من Facebook للجوال (حتى Facebook تعلم هذا الدرس بالطريقة الصعبة).
لا يُعد HTML5 بأي حال من الأحوال المستقبل النهائي للتطبيقات. لكنه جزء مهم للغاية من ذلك المستقبل.
جتطبيقات منصة روس هي مهمة صعبة. يجب على المطورين التنقل في حزم SDK و APIs وأدلة UI و UX ، مع محاولة الحفاظ على المظهر الفريد والميزات والتجربة الفريدة لتطبيقهم الخاص. إنها عملية موازنة بين المتطلبات والرغبات والتوقعات والقيود.
من الناحية المثالية ، ستكون التطبيقات التي من المنطقي أن تكون عبر الأنظمة الأساسية ، وسيكون من السهل القيام بذلك. لكنها سوق قاسية ولا يوجد اهتمام كبير من أصحاب المنصات الأكبر في تسهيل إنشاء التطبيقات سيعمل هذا على أجهزة المنافسين ، بينما يرغب اللاعبون الأصغر في تسهيل نقل هذه الأجهزة قدر الإمكان تطبيقات.
توجد الأطر والأدوات عبر الأنظمة الأساسية ، لكنها محدودة النطاق والقوة. إنها تجعل من السهل بناء تجربة متسقة عبر كل منصة ، لكنها تضحي بما يجعل كل منصة فريدة وتساوم على الجودة والأداء. لكن إنشاء تطبيقات مخصصة للنظام الأساسي يستغرق وقتًا ومالًا لا يمتلكه جميع المطورين.
لا توجد إجابة جيدة - ولكن ما هي الإجابة الأفضل؟