img

توسعه ی اپلیکیشن ها در صنعت شتاب زده ی تلفن های همراه

/
/
/

تنها چیزی که در صنعت فناوری اطلاعات (IT) ثابت می ماند، تغییر است و این تغییر در صنعت تلفن همراه، هیجان انگیز تر است. در این مقاله، نگاهی کوتاه به تغییرات این صنعت در دو دهه ی گذشته و تاثیر آن بر توسعه ی اپلیکیشن های تلفن همراه خواهیم داشت.

 

صنعت تلفن‌های همراه (موبایل ها) از زمانی که نخستین گوشی تلفن همراه توسط Nokia به بازار آمد تا معرفی تلفن‌های هوشمند تجاری BlackBerry و پس از آن انقلاب تلفن‌های هوشمند Apple و Google در این سال ها، تغییرات گسترده ای داشته است.
با گذشت زمان و با بیشتر شدن ظرفیت‌های پردازشگر‌ها و حافظه‌های RAM، سخت افزار‌ها بهتر شده و امروزه سخت افزار‌های کوچک و بی نظیری برای کامل تر شدن تلفن‌های هوشمند تولید می‌شوند که از آن‌ها می‌توان به دوربین ها، GPS، شتاب سنج و اِسکَن کننده ی اثر انگشت اشاره کرد.
در طول سال ها، پایگاه/سیستم عامل‌های زیادی برای موبایل‌ها توسط شرکت هایی مانند Sun، Qualcomm، RIM، Microsoft، Google و Apple طراحی و به بازار فرستاده شدند و ما شاهد پیشرفت آن‌ها از J2ME/BREW برای BlackBerry (عرضه شده توسط RIM) تا Android، iOS و WP8 بوده ایم.
تمام این پایگاه (platform) ها، از مجموعه API‌های (مخفف Application Programming Interface به معنی رابط برنامه ‌نویسی نرم ‌افزار کاربردی، رابط بین یک کتابخانه یا سیستم عامل و برنامه هایی است که از آن تقاضای خدمات می‌کنند) مختلف پشتیبانی کرده و تفاوت هایی در چارچوب هایی که ارائه می‌کنند دارند. در حقیقت، زبان پایه ایِ این پایگاه‌ها با یکدیگر تفاوت دارند.
در J2ME، RIM و Android، زبان Java به کار رفته در حالی که در BREW از C++، در WP8 از C#/C++ و در iOS از Objective استفاده شده است.
با توجه به تقسیم شدن بازار موبایل بین این پایگاه/سیستم عامل ها، تا همین چند سال پیش، تولید اپلیکیشن‌های موبایلی که در تمام پایگاه‌ها قابل استفاده باشند، برای توسعه دهندگان آن‌ها سخت و پیچیده بود. تولید و توسعه ی اپلیکیشن هایی که در تمام پایگاه‌ها قابل استفاده باشند، نیازمند مجموعه ی گسترده ای از مهارت‌ها بوده و توسعه دهندگان را با چالش‌های زیادی از نقطه نظر زمان و هزینه روبرو می‌کرد.
یک راه حل مناسب، تولید اپلیکیشن‌های ترکیبی یا هیبرید (Hybrid Apps: اپلیکیشن‌های مبتنی بر وِب که در قالب اپلیکیشن‌های موبایل عرضه می‌شوند) بوده است. اپلیکیشن‌های ترکیبی (هیبرید)، محدودیت‌های مخصوص به خودشان را داشته و از نظر عملکرد، کارایی و استفاده از قابلیت‌های سخت افزاری، ناقص هستند.
نو آوری جدید پایگاه‌های بات (bot platforms)، امکانات جدیدی برای ایجاد اپلیکیشن‌های بی طرف (neutral) پایگاه‌ها برای تلفن‌های هوشمند را در اختیار توسعه دهندگان قرار داده است. پیش بینی می‌شود که در دراز مدت، بات‌ها (chat-bot‌ها یا همان ربات‌های سخنگو که برنامه هایی هستند که برای شبیه سازی یک مکالمه ی هوشمند با یک یا چند کاربر انسانی از طریق صدا یا متن طراحی شده اند)، جایگزین تعداد زیادی از اپلیکیشن‌های موبایل بشوند. البته پایگاه‌های Bot جدید از نظر مجموعه API، ویژگی‌ها و قابلیت ها، درست مانند داده‌ها و اطلاعات، محدود شده هستند.
بنا بر این، با در نظر گرفتن گوناگونیِ بوم سازگان (اکوسیستم) سیستم عامل ها، طراحی یک اپلیکیشن موبایل و راهبُرد توسعه ی آن، اهمیت بسیار زیادی دارد. یک روش راهبُردیِ هوشمندانه به شما اجازه می‌دهد که بدون کوتاهی کردن در طراحی جنبه‌های مختلف، بتوانید از دستگاه‌ها و پایگاه/سیستم عامل‌های مختلف پشتیبانی کنید.
این مقاله، بر اساس سال‌ها تجربه در طراحی و توسعه ی بازی‌ها و اپلیکیشن‌های تجاری شده ی تلفن‌های هوشمند برای تمام پایگاه‌های جدید اشاره شده نوشته شده است.
توسعه دهندگان و شرکت هایی که در زمینه ی توسعه ی اپلیکیشن‌های موبایل فعالیت می‌کنند می‌توانند پس از بررسی ویژگی‌های مثبت و منفیِ هر کدام از راهنمایی‌های این مقاله برای انتخاب یک راهبرد هدفمند در طراحی و توسعه ی اپلیکیشن هایشان، از آن‌ها استفاده کنند. هدف من از نوشتن این مقاله، به اشتراک گذاشتن اطلاعاتم در مورد پایگاه/سیستم عامل‌های مختلف تلفن‌های هوشمند، چالش هایی که در هر زمان با آن‌ها مواجه بوده اند و همچنین راهبُرد‌های طراحی و توسعه ی مورد استفاده قرار گرفته برای روبرو شدن با آن‌ها بوده است.

ابتدای دهه ی ۲۰۰۰ میلادی: شروع کار با اپلیکیشن‌های J2ME/BREW
در ابتدای دهه ی ۲۰۰۰ میلادی و تا حدود سال ۲۰۰۴، اپلیکیشن‌ها و بازی‌های BREW (مخفف Binary Runtime Environment for Wireless که به صورت Brew MP و Brew نیز نوشته می‌شود که یک پایگاه توسعه ی اپلیکیشن است که توسط Qualcomm و در اصل برای دسترسی چند گانه ی تقسیم کُدی یا CDMA تلفن‌های همراه ایجاد شده که به عنوان اپلیکیشن‌های شخص سوم، مانند بازی‌های موبایل، به کار گرفته می‌شود) و J2ME (مخفف Java 2 Micro-Edition به که نام قدیمی نسخه ی میکرو پایگاه جاوا است که برای برنامه نویسی بر روی دستگاه‌های کوچک به کار می‌رود)، تسلط کاملی به بازار داشتند.
دلیل این موضوع ساده بود، مردم از تلفن‌های نیمه هوشمند (feature phone‌ها که از نوع تلفن‌های هوشمند نیستند اما مجهز به سیستم عامل بوده و از نرم افزار‌های قابل اجرای کمتری که بیشتر با فرمت‌های Java و BREW هستند پشتیبانی می‌کنند) استفاده می‌کردند و به پایگاه‌های سَبُک (ساده) تری احتیاج داشتند. بیشتر تلفن‌های نیمه هوشمند، دست کم از یکی از دو پایگاه J2ME یا BREW پشتیبانی می‌کردند.
پایگاه BREW (ارائه شده توسط Qualcomm)، مبتنی بر C/C++ بود. از طرف دیگر، J2ME، یک نسخه ی کوچک شده ی ویرایش استاندارد این زبان برنامه نویسی (Java Standard) به حساب می‌آید که دارای مجموعه API محدود تری برای دستگاه‌های دارای سخت افزار‌های نه چندان پیشرفته بود. از این پایگاه بیشتر برای ساختن بازی‌های ساده و اپلیکیشن‌های نه چندان پیشرفته برای تلفن‌های نیمه هوشمند با ویژگی‌های محدود، مانند آن هایی که به PIM (مخفف Personal Information Management به معنی مدیریت اطلاعات شخصی، عبارت از روش‌های سازماندهی، حفظ و بازیابی مجموعه اطلاعات شخصی است که در عمل برنامه‌ای کاربردی شامل کتاب آدرس و سازمان ‌دهی اطلاعات پراکنده، مانند یادداشت‌ها، قرارها و نام‌ها می‌باشد) مربوط می‌شدند، استفاده می‌شُد.
دستگاه‌های J2ME به سختی اجازه ی دخالت در سخت افزار/سیستم را می‌دادند و اگر چنین اجازه ای را می‌دادند، عملکرد قابل قبولی مشاهده نمی‌شد. به همین دلیل J2ME بیشتر به اپلیکیشن‌های بازی بر روی تلفن‌های نیمه هوشمند محدود شده و برای اپلیکیشن‌های کاربری پیچیده مورد استفاده قرار نمی‌گرفت.

چالشِ سخت افزار ضعیف در کنار API‌ها و چند وظیفگیِ محدود: تلفن‌های نیمه هوشمند ابتدایی با چالش‌های کمی روبرو بودند.
۱- با توجه به محدود بودن قابلیت‌های سخت افزاری، ساختن بازی‌ها یا اپلیکیشن‌ها در J2ME چالش برانگیز بود. بیشتر تلفن ها، تنها اجازه ی استفاده از ۱۲۸ کیلو بایت حافظه ی RAM و/یا ۶۴ کیلو بایت JAR (اندازه ی دو دوییِ J2ME) را می‌دادند. در Nokia 6600 که معروف ترین تلفن J2ME در سال ۲۰۰۵ بود، تنها از ۱ مگا بایت حافظه ی RAM برای اپلیکیشن‌های J2ME استفاده می‌شد.
۲- همچنین از آن جایی که مجموعه API بسیار محدود بود، تنها می‌توانست اپلیکیشن‌های بسیار ساده و پایه ای را فعال کند.
۳- چند وظیفِگی (multi-tasking) در بیشتر تلفن‌های نیمه هوشمند وجود نداشت. اپلیکیشن‌های J2ME در زمان مراجعه کردن به پس زمینه، متوقف می‌شدند.

 

رهیافت‌های جایگزین برای روبرویی با اندازه‌های باینری اپیلیکیشن‌ها و RAM کوچک: با گذشت چند سال، راهبُرد‌های طراحی و توسعه، به شکل زیر تغییر پیدا کردند تا بر چالش‌های موجود، پیروز شوند.
۱- اپلیکیشن‌ها به همراه منابع (تصویر های) کمتری ارائه شده و منابع لازم، یک بار از سِروِر و توسط داده‌ها فراخوانده شده و بر روی سیستم مدیریت ضبط به صورت موضعی قرار می‌گرفت.
۲- اپلیکیشن‌ها به شکلی طراحی شدند که در هر زمان تنها اطلاعات یا منبع (تصویر) مورد نیاز همان لحظه را بار گذاری کنند.
در ادامه ی اجرای برنامه، منبع‌ها و داده‌های مورد نیاز بار گذاری شده و جایگزین منابع و داده‌های قبلی می‌شدند. برای نمونه، در یک اپلیکیشن بازی (Shadow Showdown›s FOP)، تصویر شخصیت اصلی بازی به سه قسمت جدا از هم تقسیم شده بود تا در هر زمان، قسمت مورد نیاز از آن تصویر بهینه سازی و نمایش داده شود.
۳- در ساختن اپلیکیشن‌های پایه و ساده، از مجموعه API و قابلیت چند وظیفگی استفاده نمی‌شُد.

۲۰۰۵ تا ۲۰۰۹ میلادی: ورود BlackBerry به بازار تلفن‌های هوشمند و نخستین تلفن هوشمند تجاری و کوچک این شرکت
بدون تردید در بین شال‌های ۲۰۰۵ تا ۲۰۱۰ میلادی، تلفن‌های BlackBerry دارای بیشترین محبوبیت در بین مردم بودند. شرکت BlackBerry که در ابتدا با نام RIM (مخفف Research in Motion) شروع به فعالیت کرد، به عنوان نخستین شرکت مخابراتی معرفی کننده ی تلفن/پایگاه هایی شناخته می‌شود که در این مقاله به بررسی آن‌ها پرداختیم. به دلیل ویژگی‌های امنیتی، این شرکت به عنوان بهترین تولید کننده ی تلفن‌های هوشمند تجاری شناخته شده و بیشتر شرکت‌های بزرگ تمایل داشتند تا از محصولات این شرکت استفاده کنند. باید اشاره کنیم که BlackBerry دارای سیستم عامل اختصاصی خودش بود که تامین کننده ی چند وظیفگی بوده و پیش از همه از دستگاه‌های کامپیوتری مجهز به حِسگَر لمسی (trackpad) و حلقه ی چرخان (trackwheel) پشتیبانی می‌کرد. مجموعه تلفن‌های معروف و شناخته شده ی زیادی مانند Curve، Pearl و Storm با این نام تجاری به بازار آمدند.
شرکت BlackBerry، یک Java مبتنی بر مجموعه API را ایجاد کرد. با وجود پشتیبانی از API‌ها و چند وظیفگی توسط سیستم عامل، توسعه دهندگان توانستند اپلیکیشن‌های تجاری پیچیده تری را در مقایسه با اپلیکیشن‌های J3ME طراحی کنند. با وجود امکان استفاده از قابلیت‌های داخلی (built-in) دستگاه، اپلیکیشن‌ها می‌توانستند دارای ویژگی هایی مانند عملیات فایل، بررسی ایمیل، تلفن و پیام کوتاه (SMS) باشند.
امکان طراحیِ اپلیکیشن‌های پیشرفته تر، از اپلیکیشن بازار سهام Reuter و اپلیکیشن رادیو Stitcher گرفته تا اپلیکیشن رِزِرو رستوران OpenTable و اپلیکیشن پس زمینه ی تماس Broadworks Assistant VoIP با استفاده از RIM وجود داشت. البته در این زمان، ارائه ی اپلیکیشن‌های مبتنی بر وِب یا وب سایت، به دلیل پشتیبانی بسیار محدود JavaScript، امکان پذیر نبود.

چالش: بیشتر محصولات BlackBerry دارای صفحه نمایش کوچک، یک UI API پیچیده، یک وِب کیت (Web kit) قدیمی و تطبیق پذیری نه چندان آسان با گذشته بودند.
۱- یکی از مهم ترین چالش‌های دستگاه‌های پُر طرف دار سریِ ۴٫x شرکت BlackBerry (که شامل Curve و Pearl می‌شدند)، طراحی و پیاده سازیِ UX بود. تلفن‌های BlackBerry در مقایسه با صفحه نمایش هایی که اجازه ی مشاهده ی چند ستونی برای محدوده ی گسترده تری از وِب را به کار بر می‌دهند، تنها یک ستون نمایش داشتند. صفحه کلیدی که در بالای این ستون نمایش قرار داشت، اجازه ی بیشتر شدن محدوده ی مشاهده را به کاربران نمی‌داد.
۲- تنها راه ایجاد یک رابط کاربری (UI مخفف User Interface)، برای اپلیکیشن‌های Java در BlackBerry، استفاده از API‌های اساسی (طبیعیِ) RIM بود. مجموعه UI API و اصول پایه ای، بسیار پیچیده بودند و به همین دلیل توسعه ی یک UI پیشرفته، سخت و دشوار بود.
۳- بیشتر کاربران BlackBerry در بازار از نسخه ی قدیمیِ سیستم عامل RIM (سری ۴٫x) استفاده می‌کردند و موتور Web kit بر روی ۴٫x از نظر عملکرد و قابلیت‌های JavaScript محدود شده بود. به همین دلیل ساختن وب سایت‌های موبایل بسیار سخت بود. به عنوان نمونه، ساختن یک کنترل تقویم Web واکنشی (interactive) برای سری BlackBerry OS 4.x تا بسیار دشوار و پیچیده بود.
۴- در RIM از بازبینیِ کلاس ایستا (static class verification) پشتیبانی می‌شُد و این موضوع به این معنی بود که اگر یک اپلیکیشن با مجموعه API کتابخانه ی طبیعیِ نسخه‌های بالا تر سیستم عامل ویرایش و ارائه می‌شد و دارای یک API سیستم عامل جدید تر بود، آن اپلیکیشن بر روی دستگاه‌های دارای سیستم عامل قدیمی تر نصب نمی‌شد. در چنین شرایطی و با وجود این که طراحی اپلیکیشن‌ها بر اساس جدید ترین نسخه ی سیستم عامل انجام می‌شُد، تطبیق آن‌ها با نسخه‌های قدیمی تر، بسیار سخت بود.

 

روبرویی با چالش: در ادامه، فهرستی از راهبُرد‌های طراحی و توسعه ی به کار برده برای روبرو شدن با چالش‌های مختلف را مطرح می‌کنیم:
۱- تمام ماژول (module)‌ها به عنوان گزینه‌های Home Screen ارائه شده و این موضوع به عنوان استانداردی برای راهبَری‌های مختلف اپلیکیشن‌ها نیز به کار برده شد.
۲- یک کتابخانه ی عضو رابط کاربری (UI component library) سفارشی شده ی ترکیبیِ قابل استفاده ی مجدد ایجاد شد. این کار با توسعه ی قسمت (component)‌ها و حامل (container)‌ها (مانند یک مدیر میدان (field)، مدیران میدان افقی/عمودی، میدان‌های متن/برچسب و غیره) انجام شده بود.
۳- از آن جایی که در ابتدا دستگاه‌های ۴٫x سهم بسیاری در بازار داشتند، اپلیکیشن‌های اساسیِ RIM تنها گزینه ی موجود تا زمان عرضه ی سری‌های ۶٫x و ۷٫x سیستم عامل RIM در کنار موتور web kit 2 در سال‌های ۲۰۱۰ تا ۲۰۱۲ میلادی بودند.
۴- تطبیق با گذشته (نسخه‌های قبلی) به شکل هوشمندانه ای با ویرایش یک نسخه ی پایه ی اپلیکیشن با نسخه ی ابتدایی سیستم عامل پشتیبانی شده توسط آن، انجام شُد. برای تمام ویژگی‌های دِلتایِ بَر اَفزا (add-on)، فایل‌های دو دوییِ بَر اَفزا برای اپلیکیشن با یک API سیستم عامل جدید (بالا) تر و کارایی پیشرفته تر ایجاد می‌شدند. کُد پایه دارای یک ویژگی هوشمند برای بررسی شدن با نسخه ی سیستم عاملی که اپلیکیشن بر روی آن اجرا می‌شُد بود و در صورتی که دستگاه دارای نسخه ی سیستم عامل مورد نیاز بود، به صورت پویا (dynamic)، پیاده سازیِ نسخه ی جدید تر سیستم عامل را بار گذاری می‌کرد. سِروِر توزیع کننده ی اپلیکیشن، نسخه ی سیستم عامل دستگاه درخواست کننده ی دریافت (دانلود) اپلیکیشن را بررسی می‌کرد. برای نسخه‌های جدید تر سیستم عامل، سِروِر توزیع کننده می‌توانست فایل JAD (مخفف Java Application descriptor)، که دارای تمام فایل‌های دو دویی بود، را بار گذاری کند که شامل دو دویی‌های پایه ای طراحی شده بر اساس قدیمی ترین نسخه ی سیستم عامل در کنار فایل‌های دو دوییِ بَر اَفزای همراه با نسخه‌های جدید تر سیستم عامل برای دستیابی به کاراییِ پیشرفته می‌شُد.

 

۲۰۱۰ میلادی: چگونه Android و iOS صنعت تلفن همراه را تغییر دادند
صنعت تلفن همراه با به بازار آمدن Android و iOS در بین سال‌های ۲۰۰۸ تا ۲۰۱۰ میلادی، با تغییرات جالب توجهی روبرو شد.
سیستم عامل‌های Android از Google و iOS از Apple برای استفاده بر روی تلفن‌های هوشمند جدید و به روزِ (مانند iPhone، HTC و غیره) به بازار آمدند. این دستگاه‌ها تنها گوشی‌های تلفن نبودند که کامپیوتر هایی کوچک با قابلیت‌های محاسبه ای و پردازشگرانه ی بزرگ بودند. آن‌ها دارای تعداد زیادی سخت افزار مفید داخلی (تو کار) مانند دریافت کننده‌های GPS، دوربین ها، شتاب سنج‌ها (accelerometer) و غیره بودند. سیستم عامل‌های Android و iOS دارای API‌های اساسی (طبیعی یا native) بوده، به قابلیت‌های داخلیِ اپلیکیشن‌ها دسترسی داشته و از آن‌ها استفاده کنند.
در کنار قابلیت‌های بی نظیر سخت افزاری، هر دو سیستم عامل Android و iOS به همراه دستگاه‌های دارای صفحه لمسی که بدون صفحه کلید فیزیکی بودند به بازار آمدند. به همین دلیل کاربران می‌توانستند برای استفاده از قابلیت‌های اپلیکیشن ها، از تمام ارتفاع تلفن هوشمندشان استفاده کنند. قابلیت بی نظیر لمس و تشخیص اشاره‌ها و حرکت‌ها در این دستگاه ها، تجربه ی جدیدی برای کاربران آن‌ها به حساب می‌آمد.

چالش: پایگاه‌های J2ME، BREW و RIM پیش از این در بازار وجود داشتند و با اضافه شدن Android و iOS به آن ها، در بین سال‌های ۲۰۱۰ تا ۲۰۱۳ میلادی، چند پایگاه مختلف موبایل در این صنعت وجود داشت. پایگاه‌های مختلف با API‌های طبیعی (native) مختلف، کارِ شرکت‌ها و توسعه دهندگان برای تولید اپلیکیشن‌ها برای کاربران تلفن‌های هوشمند را سخت کرده بود.
در این زمان، توسعه دهندگان و شرکت‌ها مجبور بودند تا از تمام این پایگاه‌ها پشتیبانی کنند تا تمام بازار تلفن‌های هوشمند را در اختیار داشته باشند. با وجود API‌های طبیعی و زبان‌های برنامه نویسیِ پایه ی متفاوت، این کار بسیار چالش بر انگیز بود.
برای طراحی اپلیکیشن‌های موبایل برای پایگاه‌های متفاوت، نیاز به مجموعه مهارت‌های بیشتر وجود داشت که هزینه و زمان لازم برای طراحی اپلیکیشن‌ها را بیشتر از قبل می‌کرد چرا که باید نسخه‌های متفاوتی برای هر پایگاه طراحی می‌شد. از طرفی، محدوده ی اطلاعاتی که یک تیم برای طراحی اپلیکیشن‌های یک پایگاه استفاده می‌کردند، قابل استفاده برای تیم‌های دیگری که بر روی پایگاه‌های دیگر کار می‌کردند نبود.

اپلیکیشن‌های Web/Hybrid: این صنعت، مشکلات و پیچیدگی‌های زیادی را با وجود API‌ها و پایگاه‌های مختلف تجربه کرده بود. همچنین، پایگاه/سیستم عامل‌های جدید موبایل بیشتری در حال به بازار آمدن بودند. نتیجه این بود که شرکت‌ها و توسعه دهندگان، تلاش و انرژیِ خودشان را به طراحی اپلیکیشن‌های موبایل مبتنی بر Web/HTML، که مبتنی بر پایگاه‌ها نبودند، اختصاص دادند.
موتور‌های Web kit با هر نسخه ی جدید سیستم عامل، بهتر می‌شدند. همچنین، معرفیِ HTML5 به توسعه دهندگان این اطمینان را داد تا وب سایت‌های موبایلی را طراحی کنند که بر روی تمام پایگاه‌های مختلف کار کنند. رابط‌های کاربری وب سایت‌ها برای نمایش تَک ستونیِ دستگاه‌های موبایل دوباره طراحی شده و محتویات آن‌ها به کمک JavaScript به صورت پویا ارائه می‌شدند.
وب سایت‌های موبایل، که به Thin Client‌ها (کامپیوتر یا برنامه ی کامپیوتری که برای انجام وظایف محاسباتی خود به کامپیوتر‌های دیگر وابسته است) نیز معروف هستند، راه حل‌های مستقل از پایگاه هایی را در اختیار ما گذاشتند اما شاهد تطبیق کمتری از کاربران بودند چرا که مشکلاتی در استفاده و مدیریت هم زمان وب سایت‌های مختلف بر روی دستگاه‌های موبایل وجود داشت. کاربران همیشه ترجیح می‌دادند از نشانه (آیکون)‌های راه اندازیِ سریع اپلیکیشن‌ها استفاده کنند.
همچنین، وب سایت هایی که تنها برای موبایل‌ها طراحی شده بودند، امکان تطبیق پذیری با سخت افزار‌های داخلی مانند دوربین، GPS و غیره را نداشتند.
اپلیکیشن‌های ترکیبی (Hybrid) موبایل توانستند مشکلات وب سایت‌های موبایل را برطرف کنند. آنها در داخل یک حامل (container) اپلیکیشن موبایل طبیعی (native) به محتویات مبتنی بر وِب (HTML) خدمات (سرویس) می‌دادند.
حامل اپلیکیشن موبایل، از نمایش وِب (Web view) میزبانی می‌کند تا URL (مخفف Uniform Resource Locator به معنی مکان یکنواخت منبع یا نشانیِ وِب که مشخص کننده ی موقعیت مکانی و چگونگیِ ارجاع به اطلاعات یک منبع در اینترنت یا شبکه‌های مشابه آن است) را برای محتویات وِب بار گذاری (load) کند (که می‌تواند به عنوان URL وب سایت در نظر گرفته شود).
اپلیکیشن‌های موبایل ترکیبی (Hybrid) با یک نشانه ی راه اندازی (اجرای) سریع اپلیکیشن، خیال کاربران را از مشکلات کار کردن با URL‌های وب سایت ها، راحت کرد. از طرفی، اپلیکیشن‌های موبایل ترکیبی (Hybrid)، امکان استفاده از رابط‌های ارتباطی طبیعی (plugin های) وِب را ایجاد کرد تا کاربران بتوانند از قابلیت‌های سخت افزاری تلفن هوشمندشان در داخل اپلیکیشن‌ها استفاده کنند.
این اپلیکیشن‌های موبایل به عنوان یک گزینه ی جایگزین برای روبرو شدن با مشکلات هزینه و زمان که در سال‌های ۲۰۱۰ تا ۲۰۱۲ به دلیل پشتیبانی از پایگاه‌های مختلف ایجاد شده بودند، به حساب می‌آمدند. متاسفانه، اپلیکیشن‌های هایبرید، به دلیل این که از نقطه نظر عملکرد و تجربه ی کاربر، اثر مخالفی بر محتویات وِب داشتند، خیلی زود مورد بررسی‌های دقیق قرار گرفتند. به همین دلیل ما شاهد گفتگو‌های زیادی در مورد «اپلیکیشن‌های ترکیبی (hybrid) در مقایسه با اپلیکیشن‌های طبیعی (native)» بودیم.
اپلیکیشن‌های طبیعی (Native) در مقایسه با اپلیکیشن‌های ترکیبی (Hybrid): این موضوع، مدت‌های زیادی موضوع بحث و گفتگو در میان توسعه دهندگان و شرکت هایی بود که می‌خواستند اپلیکیشن هایشان را برای پایگاه‌های مختلف طراحی کنند و همیشه با چالش انتخاب بین اپلیکیشن طبیعی یا ترکیبی روبرو بودند.

بهترین راه برای انتخاب یکی از این دو گزینه، جواب دادن به چند پرسش بود که برخی از آن‌ها عبارت بودند از:
۱- تا چه اندازه هزینه و زمان برای شما اهمیت دارد؟
آ) اگر یک تیم از متخصصان حرفه ای در اختیار داشته و زمان و عملکرد برای شما مهم است، اپلیکیشن طبیعی انتخاب بهتری خواهد بود. افراد یک تیم حرفه ای که دارای مهارت‌های زیادی هستند می‌توانند به سرعت با پایگاه‌های جدید موبایل آشنا شده و یک اپلیکیشن طبیعی را با یک پایگاه، تطبیق بدهند.
ب) اگر تیم متخصصان شما کوچک بوده و می‌خواهید یک اپلیکیشن را در زمان کوتاهی طراحی و به بازار بفرستید، اپلیکیشن ترکیبی انتخاب بهتری خواهد بود چرا که می‌توانید از کُد‌های یکسان آن در پایگاه/سیستم عامل‌های مختلف استفاده کنید.
۲- کاربران هدف (کسانی که از اپلیکیشن استفاده می‌کنند) چه کسانی هستند؟ اپلیکیشنی که قرار است طراحی شود یک اپلیکیشن داخلی (برای کاربران یک شرکت) یا یک اپلیکیشن عمومی برای مشتریان شما است؟
آ) اگر قرار است یک اپلیکیشن عمومی برای مشتریانتان را طراحی کنید، یک اپلیکیشن طبیعی بهتر از اپلیکیشن ترکیبی است چرا که تجربه ی کاربر، بیشترین اهمیت را برای کاربران موبایل دارد.گزارش‌ها نشان می‌دهند که در حدود ۸۰ درصد از کاربران، یک یا دو بار یک اپلیکیشن را امتحان کرده و اگر کارایی مورد نظرشان را نداشته یا کُند باشد، دیگر به سراغ آن نخواهند رفت.
مهم است که با استفاده از عملکرد سریع اپلیکیشن‌های طبیعی، کاربران را همیشه راضی نگه دارید. یک نمونه ی عملی، تغییر Facebook از HTML به یک اپلیکیشن طبیعی موبایل است که توانسته با این کار با ارائه ی خدمات بیشتر، کاربرانش را راضی نگه دارد.
ب) اگر می‌خواهید یک اپلیکیشن درون سازمانی را طراحی کنید که هدف از آن انجام فعالیت‌های روزمره است، اپلیکیشن ترکیبی انتخاب بهتری به حساب می‌آید. در حقیقت تا زمانی که اپلیکیشن‌های داخلی، برای دستیابی به اهداف زمان بندی شده به کار برده می‌شوند، نیازی نیست که دارای جذابیت‌های زیادی برای کاربران باشند.
۳- محدوده ی حغرافیایِ کاربران شما کجاست؟ چه تعدادی از پایگاه‌های موبایل باید پوشش داده شوند؟
آ) اگر می‌خواهید اپلیکشن را تنها در یک محدوده ی مشخص جغرافیای عرضه کنید، با توجه به این که در هر منطقه ی جغرافیایی، یک پایگاه مشخص دارای سهم بازار بیشتری است (برای نمونه در آمریکا بیشتر از iOS استفاده می‌شود)، بهتر است یک اپلیکیشن طبیعی را طراحی کنید چرا که تنها باید از یک پایگاه مشخص پشتیبانی کنید.
ب) اگر می‌خواهید یک اپلیکیشن سراسری (برای تمام دنیا) را طراحی کنید، انتخاب اپلیکیشن ترکیبی به دلیل قابل استفاده بودن بر روی پایگاه/سیستم عامل‌های مختلف، بهتر است.
۴- اپلیکیشن مورد نظر شما قرار است تا چه اندازه بزرگ بوده و می‌بایست چه قابلیت هایی را داشته باشد؟
آ) اگر می‌خواهید یک اپلیکیشن با کیفیت و با قابلیت‌های زیاد را به بازار بفرستید که امکان استفاده از ویژگی‌های سخت افزاری تلفن‌های هوشمند مانند دوربین، GPS و غیره را نیز داشته باشد، اپلیکیشن طبیعی به دلیل بالا تر بودن قابلیت‌های عملکردی و مدیریت بهتر لمس/اشاره ها، انتخاب بهتری است.
ب) اگر به دنبال به بازار فرستادن یک محصول کمینه ی پذیرفتنی (MVP مخفف Minimum Viable Product، محصولی که در مقابل خطر تولید ضریب بازگشت سرمایه بالایی دارد) هستید، اپلیکیشن ترکیبی انتخاب بهتری خواهد بود چرا که با توجه به کوچک تر بودن و کمتر بودن قابلیت ها، اشکالی در عملکرد اپلیکیشن ایجاد نمی‌شود.
همچنین، این نوع اپلیکیشن به توسعه دهندگان اجازه می‌دهد که طرح‌های مختلف را امتحان کرده و پس از بررسی آن ها، بهترین روش را به دست آورده و با استفاده از آن یک اپلیکیشن طبیعی را به بازار بفرستند (درست مانند کاری که توسط Facebook انجام شد).

۲۰۱۷ میلادی: Android و iOS پیشگامان بازار تلفن همراه
با وجود پیشرفت‌های همیشگیِ فناوری در تولید سخت افزار‌های کامپیوتری، سیستم عامل Android و iOS امروزه به انتخاب اصلی کاربران تبدیل شده‌اند. با توجه به گسترش بسیار زیاد اپلیکیشن‌ها در Play Store و همچنین App Store، این دو سیستم عامل توانسته اند حجم زیادی از بازار دنیا را به دست بیاورند.
بر خلاف BlackBerry، سیستم عامل‌های Android و iOS با تمرکز بر کاربر نهایی (end user، کسی که از دستگاه کامپیوتری استفاده می‌کند) به بازار آمدند. به تدریج، این دو سیستم عامل، API‌ها و برنامه‌های امنیتی لازم برای وارد شدن به بازار تجاری را نیز طراحی و تولید کردند.
با توجه به پیشتازی این دو سیستم عامل در بازار و فرهنگ رو به گسترش BYOD (مخفف Bring your own device به معنی «دستگاه کامپیوتری خودتان را بیاورید»، فرهنگی است که در شرکت‌های بزرگ به کارمندان اجازه می‌دهد که از دستگاه‌های کامپیوتری خودشان در محیط کار استفاده کنند)، این دو پایگاه به انتخاب اصلی اپلیکیشن‌های تجاری نیز تبدیل شده‌اند.
سادگیِ توسعه دادن با توجه به وجود یک مجموعه API بی نظیر و ساده، باعث شده تا بیشتر توسعه دهندگان و شرکت‌ها به سرعت با این دو پایگاه تطبیق پیدا کنند.
به عنوان یک نتیجه، سیستم عامل/پایگاه‌های دیگر موبایل مانند J2ME، RIM و همچنین Windows Phone، که آخر از همه به بازار آمده بود، سهم کوچکشان در بازار را از دست داده و در حال نابود شدن هستند. در چنین شرایطی و با توجه به این که برای تولید یک اپلیکیشن تنها باید این دو پایگاه را در نظر داشته باشیم، دیگر مشکل هزینه و زمان عرضه به بازار در سر راه تولید کنندگان و توسعه دهنگان وجود ندارد.
در حقیقت امروزه توسعه دهندگان/شرکت‌ها اپلیکیشن هایشان را تنها برای دو پایگاه Android و iOS طراحی می‌کنند. در کنار این ها، با توجه به wizard‌های ساده و بی نظیر برای طراحیِ رابط‌های کاربری در Android و با وجود زبان‌های برنامه نویسیِ ساده تری مانند Swift در iOS، طراحی اپلیکیشن‌های طبیعی برای این دو سیستم عامل، آسان تر از همیشه شده است.

چالش هجوم اپلیکیشن‌ها به دستگاه‌های متحرک کامپیوتری: توسعه دهندگان، شروع به طراحی اپلیکیشن‌ها برای سیستم عامل‌های Android و iOS (به صورت جدا از هم) کرده و کاربران نهایی را تشویق به نصب تعداد زیادی از آن‌ها می‌کنند. اکنون به مشکل جدیدی به عنوان چالش هجوم اپلیکیشن‌ها روبرو هستیم.

آینده: پایگاه‌های Bot و اپلیکیشن‌های تخصصی
امروزه، بیشتر کاربران تلفن‌های هوشمند همواره به کانال‌های پیام رسان شبکه‌های اجتماعی مانند WhatsApp و Facebook Messenger یا کانال‌های پیام رسان‌های مخصوص به سیستم عامل مانند iMessage متصل هستند. افزایش زمان مشغول بودن کاربران به کانال‌های پیام رسان بر روی شرکت‌های اپلیکیشن‌های پیام رسان مانند Facebook و Slack اثر گذاشته و آن‌ها را مجبور کرده که پایگاه‌های bot را ایجاد کنند تا امکان طراحی رُبات‌های سخن گوی (chat-bot های) مخصوص استفاده ی تجاری را برای ارتباط مشتریانشان با کانال‌های پیام رسان شبکه‌های اجتماعی، برای شرکت‌ها و توسعه دهندگان فراهم شود. از iMessage در Apple و Allo در Google انتظار می‌رود که پایگاه‌های Bot خودشان را برای کمک به ایجاد chat-bot‌ها داشته باشند.
پایگاه‌های Bot به شرکت‌ها اجازه می‌دهند که در کانال هایی که کاربران همیشه در حال وقت گذراندن در آن‌ها هستند، حضور داشته باشند. این حضور از نظر فعالیت تجاری، اهمیت زیادی دارد. رُبات‌های سخن گو (chat-bot ها) به عنوان پیام رسان‌های عادی در فهرست مخاطبان کاربر نهایی قرار گرفته و به همین دلیل آن‌ها نیازی به استفاده از یک اپلیکیشن مجزا برای کار کردن با آن‌ها ندارند.
همچنین، chat-bot‌ها مستقل از پایگاه‌ها و دستگاه‌های کامپیوتری بوده و می‌توان از آن‌ها بر روی تلفن‌های هوشمند و فناوری‌های پوشیدنی استفاده کرد.
پایگاه‌های Bot جدید بوده و از نظر قابلیت‌های کار کردن با سخت افزار‌های داخلی تلفن‌های هوشمند و ویژگی‌های پشتیبانی، دارای کمبود هایی هستند. بنا بر این انتظار می‌رود که chat-bot‌ها به عنوان توابع پایه و بدون نیاز به استفاده از اپلیکیشن‌های مجزا مورد استفاده قرار بگیرند.
انتظار می‌رود که اپلیکیشن‌های موبایل طبیعیِ Android و iOS برای نیاز‌های مشخص به کار گرفته شوند. به عنوان نمونه، منطقی تر است که یک اپلیکیشن موبایل طبیعی برای خدمات بانکی برای Android و iOS ایجاد شود که از تشخیص دهنده ی اثر انگشت برای باز شدن برنامه و تشخیص هویت کاربر یا از دریافت کننده ی GPS برای تشخیص موقعیت تلفن هوشمند کاربر و فهرست شعبه/خود پرداز‌ها استفاده کند.

نظر بدهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

It is main inner container footer text