بخش 1: توسعه موبایل چند سکویی و مشکلات آن

توسعه موبایل چند سکویی

صنعت کامپیوترهای شخصی یک تغییر بزرگ را در سالیان اخیر تجربه کرده است. البته کامپیوترهای رومیزی هنوز وجود دارند , آن ها برای وظایفی که به کیبورد و صفحات بزرگ نیاز دارند , برنامه نویسی , صفحه گسترده و ردیابی داده , مهم وحیاتی هستند. اما بیشتر محاسبات شخصی هم اکنون بر روی دستگاه های کوچکتر رخ می دهند, به طور خاص برای اطلاعات سریع , استفاده رسانه ای و شبکه های اجتماعی. تبلت ها و گوشی های هوشمند  اساسا الگو تعامل با کاربر متفاوتی دارند که مبتنی بر صفحه لمسی با یک کیبورد که فقط در زمان نیاز به صورت پاپ آپ (pop up) نمایش داده می شود می باشند.

چشم انداز موبایل

هرچند بازار موبایل پتانسیل تغییرات سریع را دارد ولی در حال حاضر دو پلت فرم اصلی گوشی و تبلت حکمفرمایی می کنند:

• خانواده اپل از آیفون ها و آیپدها , که همه بر روی سیستم عامل iOS اجرا می شوند.
• سیستم عامل اندروید , که بر اساس هسته لینوکس توسط گوگل توسعه داده شده است و روی گوشی ها و تبلت های متنوعی اجرا می شود.

چگونگی تقسیم دنیا بین این دو غول به نحوه مقیاس بندی آن ها بستگی دارد: دستگاه های اندروید بیشتری در حال استفاده می باشند , اما کاربران آیفون و آیپد زمان بیشتری را با دستگاهشان سپری می کنند.

پلت فرم سومی هم وجود دارد که به اندازه iOS و اندروید محبوب نیست اما شرکتی با تاریخچه قوی در صنعت کامپیوترهای شخصی را شامل می شود:

• ویندوز فون مایکروسافت و ویندوز 10 موبایل

در سالیان اخیر , این پلت فرم ها آنقدر جایگزین قانع کننده ای شده اند تا جایی که مایکروسافت به ادغام API های موبایل , تبلت و پلت فرم های رومیزی اش روی آورده است. هر دو ویندوز 8.1 و ویندوز فون 8.1 مبتنی بر یک API مستقل به نام WinRT می باشند که بر مبنای مایکروسافت NET. ایجاد شده است. این API مستقل به این معنا است که اپلیکیشن های طراحی شده برای دستگاه های رومیزی , لپ تاپ ها , تبلت ها و گوشی ها می توانند بیشتر کدشان را به اشتراک بگذارند.

برای توسعه دهندگان نرم افزار , استراتژی مطلوب این است که بیشتر از یکی از این پلت فرم ها را هدف قرار دهند. اما این آسان نیست. 4 مانع بزرگ وجود دارد:

مشکل اول : الگوهای رابط کاربری متفاوت

هر سه پلت فرم راه های مشابهی را برای نمایش رابط گرافیکی کاربر (GUI) و فعل و انفعالات با دستگاه ترکیب می کنند  , ولی در جزئیات تفاوت هایی با یکدیگر دارند. هر پلت فرم راه های متفاوتی برای حرکت بین اپلیکیشن ها و صفحه ها دارد , قراردادهای متفاوتی برای ارائه داده دارد , روش های مختلفی برای فراخوانی و نمایش منوها ارائه می دهند و حتی راه های مخلتفی برای تاچ ارائه می دهند.

کاربرانی که به تعامل با اپلیکیشن ها روی یک پلت فرم خاص خو گرفته اند , انتظار دارند اپلیکیشن های بعدی را با دانش قبلی بتوانند استفاده کنند. هر پلت فرم  فرهنگ مرتبط با خود را بدست می آورد , و این قراردادهای فرهنگی روی توسعه دهندگان تاثیر می گذارند.

مشکل دوم : محیط های برنامه نویسی متفاوت

امروزه برنامه نویسان به کارکردن در یک محیط توسعه یکپارچه و پیچیده (IDE) خو گرفته اند. مانند IDEهایی که برای هر سه پلت فرم وجود دارند که البته متفاوت هستند:

• برای توسعه iOS , Xcode بر روی مک.
• برای توسعه اندروید , اندروید استدیو روی پلت فرم های مختلف.
• برای توسعه ویندوز , ویژوال استدیو روی کامپیوترهای شخصی.

مشکل سوم: رابط های کاربری متفاوت

هر سه پلت فرم مبتنی بر سیستم عامل های مختلف با APIهای متفاوت می باشند. در مواردی , هر سه پلت فرم انواع مشابهی از اشیا رابط کاربری را پیاده سازی می کنند ولی با نام های متفاوت.

برای مثال , هر سه پلت فرم چیزی دارد که به کاربر اجازه می دهد یک مقدار Boolean را تغییر وضعیت بدهد:

• روی آیفون یا آیپد , این مورد به صورت یک “view” به نام UISwitch می باشد
• روی دستگاه های اندروید , این مورد یک “widget” به نام Switch می باشد
• در API ویندوز , مورد یک “control” به نام ToggleSwitch می باشد

البته , تفاوت ها در رابط های برنامه نویسی فراتر از نام ها می روند.

مشکل 4: تفاوت در زبان های برنامه نویسی

توسعه دهندگان مقداری انعطاف پذیری در انتخاب زبان برای هریک از این سه پلت فرم دارند, اما به طور کلی , هر پلت فرم به طور خیلی نزدیکی با یک زبان برنامه نویسی خاص همراه شده است:

• Objective-C برای آیفون و آیپد
• جاوا برای دستگاه های اندروید
• #C برای ویندوز

Objective-C , جاوا و #C در واقع پسرعمو یک دیگر هستند چرا که تمام آن ها شی گرا و از نسل C می باشند , اما آن ها پسرعموهای دورهستند.

به همین دلایل , یک شرکت که می خواهد چند پلت فرم را به خوبی هدف قرار دهد , سه تیم برنامه نویسی مختلف که هرکدام در یک زبان خاص ماهر و متخصص می باشند استخدام می کند.

این مشکل زبان بسیار نامطبوع است ولی مشکلی است که به طور اغوا کننده ای حل شده است: اگر شما بتوانید از یک زبان برنامه نویسی برای این سه پلت فرم استفاده کنید , حداقل می توانید قسمتی از کد را بین پلت فرم ها به اشتراک بگذارید. این کد به اشتراک گذاشته شده رابط کاربری را درگیر نمی کند چرا که هر پلت فرم API متفاوتی دارد , اما ممکن است کد اپلیکیشنی باشد که اصلا کاری به رابط کاربری نداشته باشد.

یک زبان مستقل برای این سه پلت فرم مطمئنا می تواند مناسب باشد. اما آن چه زبانی است؟