بحث اپلیکیشن موبایل
مقدمه
برنامههای موبایل و HTML5 دو مورد از داغترین فناوریهای حال حاضر هستند و همپوشانی زیادی بین آنها وجود دارد. برنامههای وب در مرورگرهای موبایل اجرا میشوند و همچنین میتوانند به عنوان برنامههای بومی در پلتفرمهای مختلف موبایل بستهبندی مجدد شوند. با طیف گستردهای از پلتفرمها برای پشتیبانی، همراه با قدرت مطلق مرورگرهای موبایل، توسعهدهندگان به HTML5 به عنوان یک راهحل "یکی بنویس، چند تا اجرا کن" روی میآورند. اما آیا واقعاً عملی است؟ هنوز دلایل قانعکنندهای برای رفتن به سمت بومی وجود دارد و واضح است که بسیاری از توسعهدهندگان واقعاً این مسیر را طی میکنند. این مقاله بحثی در مورد بومی در مقابل وب است.
غنای ویژگی
نکته: بومی میتواند کارهای بیشتری انجام دهد
میتوانیم عملکرد موبایل را به دو بعد تقسیم کنیم: تجربه خود اپلیکیشن و نحوه اتصال آن به اکوسیستم دستگاه، مثلاً برای اندروید، این شامل ویژگیهایی مانند ویجتها و اعلانها میشود. نیتیو در هر دو بعد برتری دارد.
از نظر تجربه کاربری، اپلیکیشنهای بومی میتوانند کارهای بیشتری انجام دهند. آنها به راحتی میتوانند رویدادهای سوایپ و حتی چند لمسی را برای پلتفرمهایی که از آن پشتیبانی میکنند، دریافت کنند. آنها معمولاً میتوانند بر اساس فشردن کلیدهای سخت افزاری، مانند دکمه جستجوی اندروید و کنترل صدا، عمل کنند. آنها همچنین میتوانند به سختافزارهایی مانند GPS و دوربین دسترسی داشته باشند. و با اجازه کاربر، برخی از پلتفرمها دسترسی نامحدود به سیستم عامل را فراهم میکنند. فقط کافیست با HTML5 میزان باتری باقی مانده را تشخیص دهید!
البته این چیزی بیش از تجربه درون برنامهای است. یک سیستم عامل مانند اندروید روشهای مختلفی را برای تعامل برنامهها با کاربران و در واقع با سایر برنامهها فراهم میکند. شما ویجتهای فعال در صفحه اصلی دارید. اعلانهایی دارید که در نوار وضعیت دستگاه نمایش داده میشوند. و شما اهدافی دارید که به برنامه شما اجازه میدهد خود را به عنوان ارائه دهنده یک سرویس عمومی که ممکن است سایر برنامهها در مواقعی به آن نیاز داشته باشند، معرفی کند.
نقطه مقابل: ویژگیهای بومی را میتوان تقویت کرد، و وب به هر حال در حال جبران است
درست است که بسیاری از ویژگیهای درونبرنامهای برای یک برنامه HTML5 به سادگی غیرقابل دسترس هستند. مهم نیست که مهارتهای وبفوی شما چقدر داغ باشد، اگر برنامه شما در یک محیط بسته بدون API دوربین گیر کرده باشد، به این زودیها نمیتواند عکس بگیرد! خوشبختانه، لازم نیست در آن محیط بسته باشید. اگر واقعاً به عکس گرفتن از برنامه وب خود نیاز دارید، میتوانید یک برنامه بومی ایجاد کنید، برنامهای با یک نمای وب تعبیهشده که بخش عمدهای از رابط کاربری را فراهم میکند. چارچوب منبع باز PhoneGap اینگونه عمل میکند: این چارچوب با نمایش ویژگیهای بومی به عنوان سرویسهای وب، که نمای وب با استفاده از یک API شبکه استاندارد آنها را فراخوانی میکند، این شکاف را پر میکند. وقتی یک برنامه ترکیبی مانند این میسازید، میتوانید به آن ویژگیهای پلتفرم مانند ویجتها، اعلانها و اهداف نیز دسترسی پیدا کنید.
ساخت یک اپلیکیشن ترکیبی - بومی به علاوه وب - به سختی یک راه حل ایدهآل است. این کار پیچیدگی ایجاد میکند و فقط برای اپلیکیشنهای وب که به صورت بومی بستهبندی شدهاند، به جای وبسایتهای سنتی که از طریق مرورگر تلفن همراه قابل دسترسی هستند، کاربرد دارد. اما ممکن است برای مدت طولانی لازم نباشد. استانداردهای وب به سرعت در حال تکامل هستند و مرورگرهای تلفن همراه مدرن نیز همگام با آنها پیش میروند. به عنوان مثال، ذخیرهسازی آفلاین، موقعیت جغرافیایی، گرافیک بوم و پخش ویدیو/صوت، همگی از پشتیبانی گستردهای در بین تلفنهای هوشمند مدرن برخوردارند. حتی دوربین نیز در حال پشتیبانی است - از اندروید ۳.۱، امکان ضبط عکس و فیلم با استفاده از استانداردهای وب وجود دارد. و آخرین مرورگر iOS از WebSocket برای پخش دو طرفه و همچنین تشخیص جهت دستگاه پشتیبانی میکند.
به طور کلی، موبایل در حال تکامل است. اما وب نیز به سرعت در حال تکامل است. تنها در بین مرورگرهای دسکتاپ، پنج فروشنده اصلی مرورگر وجود دارند که استانداردها را متحول میکنند و با سرعت برقآسا ویژگیها را اضافه میکنند. اگرچه انتقال این ویژگیها به موبایل فرآیند سادهای نیست، اما بسیاری از آنها قبلاً راه خود را به مرورگرهای موبایل باز کردهاند.
بومیسازی یک هدف سریع در حال حرکت است، اما وب در حال کم کردن این شکاف است.
عملکرد
نکته: بومی سریعتر اجرا می شود
برنامههای بومی با مشکل زمان اجرای وب مواجه نیستند. آنها با سرعت بالا اجرا میشوند و میتوانند از تقویتکنندههای عملکرد مانند شتابدهی GPU و چندرشتهای بودن بهره ببرند.
نقطه مقابل: زمان اجرای وب امروزه بسیار سریعتر است و اکثر برنامهها به هر حال به این سرعت نیاز ندارند
اگر بگوییم وب در سالهای اخیر سریعتر شده است، کم گفتهایم. V8، موتور جاوا اسکریپتی که با کروم عرضه میشود، در زمان عرضه خود پیشرفت بزرگی در عملکرد وب بود و از آن زمان تاکنون، فقط سریعتر شده است:
موتورهای رندر گرافیکی نیز سرعت وب را افزایش دادهاند و اکنون شتابدهی سختافزاری در حال وقوع است. نگاهی به افزایش سرعت ارائه شده توسط بوم شتابدهی سختافزاری بیندازید:
علاوه بر این، رابط برنامهنویسی کاربردی جدید Web Workers امکان چندرشتهای شدن را فراهم میکند و توسعهدهندگان وب مدرن میتوانند از طیف وسیعی از کتابخانههای بهینهشده از نظر عملکرد و تکنیکهای بهینهسازی عملکرد که به خوبی تحقیق شدهاند، استفاده کنند. در حالی که اکثر این موارد در وب دسکتاپ شروع به کار کردهاند، هنوز هم به موبایل مرتبط هستند و توجه بیشتری به موبایل میشود، به عنوان مثال، متخصص عملکرد، استیو سودرز، صفحهای را به ابزارهای عملکرد موبایل اختصاص داده است.
هنوز همه پیشرفتهای دسکتاپ به همه پلتفرمهای موبایل راه پیدا نکردهاند، اما روندها نشان میدهد که این پیشرفتها در راه هستند. همچنین لازم به ذکر است که اکثر برنامههای موبایل، بازیهای سهبعدی پیشرفته نیستند، بلکه اساساً مبتنی بر اطلاعات هستند: اخبار، ایمیل، برنامههای زمانی، شبکههای اجتماعی و غیره. از چند سایت از طریق موبایل خود بازدید کنید، مانند GMail، Amazon، Twitter، و میتوانید تأیید کنید که عملکرد وب موبایل بیش از حد کافی است. در مورد بازیها، بازیهای پایه از قبل با canvas دوبعدی امکانپذیر هستند و WebGL در حال ظهور در موبایلها است - به Firefox 4 مراجعه کنید. تا زمانی که این فناوری گسترده شود، خانوادهای رو به رشد از چارچوبها وجود دارد که برنامههای WebGL را به برنامههای بومی کامپایل میکنند که میتوانند از OpenGL بهره ببرند، مانند ImpactJS .
تجربه توسعهدهنده
نکته: توسعهی بومی آسانتر است
برنامههای بومی از زبانهای برنامهنویسی قوی (مانند جاوا، Objective C، C++) استفاده میکنند که برای توسعه برنامههای پیچیده طراحی شدهاند و سابقه اثباتشدهای دارند. APIها به گونهای طراحی شدهاند که از پلتفرم موجود پشتیبانی کنند. میتوانید به راحتی برنامهها را در شبیهسازهای دسکتاپ که نمایش دقیقی از دستگاه هدف ارائه میدهند، اشکالزدایی کنید.
چیزی که توسعه وب را به طور خاص مشکلساز میکند، تنوع بسیار زیاد مرورگرها و زمانهای اجرا است. وقتی برنامه شما اجرا میشود، هیچ تضمینی وجود ندارد که ویژگی X در دسترس باشد. و حتی اگر باشد، مرورگر چگونه آن را پیادهسازی خواهد کرد؟ استانداردها قابل تفسیر هستند.
نقطه مقابل: توسعه وب اغلب آسانتر است، به خصوص اگر چندین دستگاه را هدف قرار دهد
بیایید ابتدا به فناوری اصلی بپردازیم. درست است که استانداردهای وب در ابتدا در دورانی شکل گرفتند که وب اساساً مربوط به اسناد بود، نه برنامهها، و جاوا اسکریپت تنها در 10 روز ساخته و مستقر میشد! اما آنها بسیار توانمندتر از تصور از آب درآمدهاند - توسعهدهندگان وب یاد گرفتهاند که از بخشهای خوب استفاده کنند و بخشهای بد را رام کنند، و اکنون الگوهایی برای طراحی مقیاسپذیر شناخته شدهاند. علاوه بر این، استانداردها راکد نماندهاند و تلاشهایی مانند HTML5، CSS3 و EcmaScript Harmony همگی در حال بهبود تجربه توسعهدهندگان هستند. اینکه شما C++ یا جاوا یا جاوا اسکریپت را ترجیح میدهید، موضوع بحثهای مذهبی است و همچنین به پایه کد قدیمی شما بستگی دارد. اما مطمئناً میتوانیم جاوا اسکریپت را این روزها به عنوان یک رقیب جدی در نظر بگیریم.
روی دیگر سکهی چندپارگی مرورگر/زمان اجرا این واقعیت است که همه این محیطها از ابتدا وجود دارند. اگر یک برنامه اندروید را با جاوا توسعه دهید، با یک پورت کامل به Objective C برای پشتیبانی از iOS مواجه خواهید شد. اگر یک برنامه وب را یک بار توسعه دهید، در اندروید و iOS اجرا خواهد شد، و نیازی به ذکر WebOS، BlackBerry، Windows Mobile و... نیست، خب، این در هر صورت تئوری است. در عمل، اگر واقعاً میخواهید تجربه را درست کنید، باید چیزهایی را برای هر پلتفرم تغییر دهید. اما برای اکثر سیستم عاملهای موبایل باید این کار را به صورت بومی نیز انجام دهید - نسخههای مختلف و دستگاههای مختلف وجود دارد.
خبر خوب این است که «تکهتکه شدن» همیشه در وب به این شکل بوده است و تکنیکهای شناختهشدهای برای مقابله با آن وجود دارد. مهمتر از همه، اصل بهبود تدریجی، توسعهدهندگان را ترغیب میکند که ابتدا یک دستگاه پایه را هدف قرار دهند و در صورت وجود، لایههایی از جذابیت خاص پلتفرم را اضافه کنند. شعار تشخیص ویژگی نیز کمک میکند و این روزها، ما از پشتیبانی کتابخانهای مانند Modernizr برای پشتیبانی از طراحی وب واکنشگرا برخورداریم. با استفاده هوشمندانه از این تکنیکها، میتوانید دسترسی خود را به اکثریت قریب به اتفاق دستگاهها، حتی «گوشیهای ساده» قدیمی، حتی فرمفکتورهایی مانند ساعتها و تلویزیونها، صرف نظر از سازنده و سیستم عامل، گسترش دهید. شاهد نمایش چند رابط کاربری ما در Google IO 2011 باشید، جایی که ما فرمفکتورهای متمایز (گوشی ساده، تلفن هوشمند، تبلت، دسکتاپ، تلویزیون) را با یک کد پایه مشترک از منطق و نشانهگذاری هدف قرار دادیم.
ظاهر و احساس
نکته: بومی با ظاهر و حس پلتفرم سازگار است
یکی از ویژگیهای تعیینکننده هر پلتفرمی، ظاهر و حس آن است. کاربران انتظار دارند که کنترلها به طور مداوم ارائه شوند و به یک شکل دستکاری شوند. اصطلاحات خاصی وجود دارد که از پلتفرمی به پلتفرم دیگر متفاوت است، به عنوان مثال وقتی کاربر "نگه داشتن طولانی" (لمس کردن یک عنصر برای چند ثانیه) را انجام میدهد چه اتفاقی میافتد؟ پلتفرمها اصطلاحات استانداردی برای چنین مواردی دارند و شما نمیتوانید همه آنها را با یک برنامه HTML5 واحد برآورده کنید.
علاوه بر این، ظاهر و حس پلتفرم توسط کتابخانه نرمافزار بومی پلتفرم تنظیم میشود که ویجتهای آن، نوع ظاهر و حس مورد انتظار کاربران را در بر میگیرد. شما میتوانید بسیاری از ظاهر و حس مورد انتظار را «به صورت رایگان» و تنها با استفاده از جعبه ابزار بومی دریافت کنید.
نقطه مقابل: وب ظاهر و حس و حال خاص خود را دارد و شما همچنین میتوانید رابط کاربری وب را برای پلتفرمهایی که بیشتر به آنها اهمیت میدهید، سفارشی کنید.
همانطور که در بخش قبلی توضیح داده شد، روش توسعه وب نوشتن یک نسخه پایه "یک اندازه برای همه" و سپس بهبود تدریجی آن است. در حالی که این بهبود معمولاً مبتنی بر ویژگیها است، میتوانید آن را با هدف قرار دادن پلتفرمهایی که بیشتر به آنها اهمیت میدهید، بهبود بخشید. این نوعی "تشخیص مرورگر" است که گاهی اوقات توسط جامعه وب مورد انتقاد قرار میگیرد، عمدتاً به این دلیل که مرورگرهای زیادی وجود دارد. اما اگر دو یا سه پلتفرم با اولویت بسیار بالا را مشاهده میکنید و مایل به تلاش بیشتر برای رقابت با جایگزینهای بومی هستید، این ممکن است راه مناسبی باشد.
تا جایی که به نسخه پایه مربوط میشود، وب ظاهر و حس خاص خود را دارد و حتی میتوانیم بگوییم که هر پلتفرم موبایل «ظاهر و حس وب» مخصوص به خود را دارد که توسط مرورگر پیشفرض و زمان اجرای وب ایجاد میشود. «ظاهر و حس وب» ممکن است برای کاربران شما مناسب باشد و در واقع به شما این امکان را میدهد که به درجه بالاتری از سازگاری با تجربه مرور دسکتاپ و همچنین دستگاههای دیگری که کاربر ممکن است با آنها کار کند، دست یابید. علاوه بر این، بسیاری از برنامههای موفق وجود دارند که به هر حال از ظاهر و حس بومی پشتیبانی زیادی نمیکنند. این موضوع قطعاً در مورد بازیها صادق است (آیا بازی موبایل مورد علاقه شما از ظاهر و حس سیستم عامل موبایل شما پیروی میکند؟) و حتی در مورد برنامههای مرسومتر نیز صادق است، به عنوان مثال، کلاینتهای بومی توییتر محبوبتر را در پلتفرم مورد نظر خود بررسی کنید و طیف گستردهای از مکانیسمهای رابط کاربری را در حال کار خواهید دید.
قابلیت کشف
نکته: کشف برنامههای بومی آسانتر است
مکانیسمهای توزیع اپلیکیشن، مانند مارکت اندروید و اپ استور اپل، در سالهای اخیر به شدت محبوب بودهاند و نیروی محرکه اصلی برای کل صنعت موبایل محسوب میشوند. هر توسعهدهندهای میتواند اپلیکیشن بومی خود را به مارکت ارسال کند، جایی که کاربران میتوانند از طریق ترکیبی از مرور، جستجو و دریافت توصیهها، آن را پیدا کنند. نه تنها این، بلکه اگر کار خود را به درستی انجام داده باشید، رتبهبندیها و نظرات درخشان، کاربران را متقاعد میکند که دکمه نصب را که بسیار مهم است، بزنند.
نقطه مقابل: در واقع، برنامههای وب راحتتر پیدا میشوند
مسلماً وب قابل کشفترین رسانهای است که تاکنون ایجاد شده است. در URL ساده، ما (حداقل در تئوری) یک شناسه منحصر به فرد برای هر چیزی که تاکنون در وب منتشر شده است، داریم که شامل هر برنامهای است که در وبسایتهای استاندارد منتشر شده است. موتورهای جستجو به راحتی میتوانند کشف کنند که محتوا و سایر وبسایتها میتوانند به آن لینک دهند، از جمله کاتالوگ برنامههای وب مشابه بازارهای تلفن همراه. در واقع، هر فردی میتواند برنامههای وب را با دوستان خود تنها با لینک دادن به آن در ایمیلها و پیامهای شبکههای اجتماعی به اشتراک بگذارد. لینکها را میتوان از طریق پیامک نیز ارسال کرد، جایی که کاربران تلفن همراه میتوانند روی لینک کلیک کرده و برنامه را در مرورگر دستگاه خود اجرا کنند.
ما هنوز بازارهای مشابهی نداریم که کاربران بتوانند در آنها به برنامهها امتیاز بدهند و نظر بدهند، اما این هم در حال تغییر است. ادامه مطلب را بخوانید…
کسب درآمد
نکته: میتوان از نیتیو کسب درآمد کرد
«یک بچه ۶ ساله در ساعت ناهار برنامهای میسازد و میلیونها نسخه از آن را به قیمت ۳ دلار برای هر نسخه میفروشد». این روزها این تیتر را زیاد میبینید، بنابراین جای تعجب نیست که توسعهدهندگان بزرگ و کوچک برای کسب درآمد به بازارهای موبایل روی آوردهاند. پلتفرمهای موبایل راههای مختلفی را برای توسعهدهندگان ارائه میدهند تا مستقیماً برای برنامههای خود هزینه دریافت کنند. سادهترین آنها پرداخت یکباره است که برای باز کردن قفل برنامه برای همیشه کاربرد دارد. همچنین در برخی پلتفرمها مکانیسمهای پرداخت درون برنامهای و اشتراک وجود دارد و آنها کاملاً در یک مکانیسم سازگار و امن ادغام شدهاند. این اشکال جدیدتر پرداخت به توسعهدهندگان این امکان را میدهد که یک برنامه موفق را به یک جریان درآمد بلندمدت تبدیل کنند.
علاوه بر پرداختهای اپلیکیشن، میتوانید با مدلهای سنتی وب، مانند تبلیغات و حمایت مالی، درآمد کسب کنید.
نقطه مقابل: همیشه امکان کسب درآمد در وب وجود داشته است و این فرصتها در حال افزایش هستند
اگر فرصتهای فراوانی برای کسب درآمد وجود نداشت، وب موتور صنعت مدرن نمیشد. اگرچه مکانیسمهای مستقیم «پرداخت به ازای استفاده» هنوز شکوفا نشدهاند، اما حوزههای مختلفی وجود دارند که در آنها راهحلهای «نرمافزار به عنوان سرویس» مبتنی بر اشتراک، واقعاً قابل اجرا شدهاند. از جمله این حوزهها میتوان به Google Apps، طیف محصولات 37Signals و نسخههای پریمیوم سرویسهای ایمیل مختلف اشاره کرد. علاوه بر این، پرداختهای مستقیم تنها راه سودآوری از برنامههای وب نیستند. تبلیغات آنلاین، لینکهای وابسته، حمایتهای مالی، تبلیغات متقابل برای سایر محصولات و خدمات نیز وجود دارد.
با این اوصاف، کاملاً منطقی است که یک توسعهدهنده وب تیترها را بخواند و حسادت به پرداخت را تجربه کند. شما نمیتوانید یک URL وب را به بازارهای بومی ارسال کنید، پس یک توسعهدهنده وب چه کاری باید انجام دهد؟ کاری که شما انجام میدهید ایجاد یک "برنامه پوششی" بومی است - برای هر پلتفرمی که میخواهید هدف قرار دهید، یک برنامه بومی خالی ایجاد کنید که به سادگی شامل یک نمای وب باشد. نمای وب جایی است که شما برنامه واقعی را در آن جاسازی میکنید. سپس شما فقط این برنامهها را به بازارهای مختلف ارسال میکنید (و امیدوارم شاهد گردش پول باشید!). امروزه احتمالاً صدها، اگر نگوییم هزاران، برنامه تحت وب در بازارهای اصلی وجود دارد، که برخی از آنها آنقدر ماهرانه جذب شدهاند که ما اصلاً برنامههای وب آنها را نمیشناسیم.
نکتهی منفی، مسئولیت کامپایل متقابل برای هر پلتفرم است. اینجاست که یک چارچوب موجود مانند PhoneGap میتواند کمک کند. حتی بهتر از آن، سرویسهای وب مانند PhoneGap Build و Apparatio در حال توسعه هستند. این وبسایتها را به مخزن کد خود ارجاع دهید و یک برنامهی اندروید، یک برنامهی iOS و غیره بیرون میآید... آماده برای ارسال به فروشگاههای مربوطه. نیازی به نصب SDK های بومی روی دستگاه شما نیست؛ تنها چیزی که برای ساخت همهی این برنامههای بومی نیاز داشتید یک ویرایشگر کد و یک مرورگر وب بود.
آیا این بازارها هرگز مستقیماً از برنامههای وب، بدون تمام هزینههای سربارِ بستهبندی بومی آنها، پشتیبانی خواهند کرد؟ هنوز مشخص نیست. ما میدانیم که گوگل سال گذشته فروشگاه وب کروم را معرفی کرد و اگرچه فقط برای دسکتاپ اعمال میشود، اما این فروشگاه توجه سایر فروشندگان مرورگر را نیز به خود جلب کرده است و در کل بخشی از روندی به سمت کاتالوگهای برنامههای وب، از جمله برخی تلاشهای خاص موبایل، است. این روزهای اولیه برای مفهوم فروشگاه وب است، اما نشانهها امیدوارکننده هستند.
نتیجهگیری
خوب است که اینجا یک برنده اعلام شود، اما در حال حاضر، هیچ برنده مشخصی وجود ندارد. برخی از برنامهها برای بومی مناسبتر هستند و برخی دیگر برای وب. مسلماً پشته وب از شتاب بیشتری برخوردار است، اما از نظر قابلیتها و کیفیت اجرا، برنامههای بومی نیز به سرعت در حال پیشرفت هستند. و مگر اینکه زمانی فرا برسد که فناوریهای وب در اکثر سیستمعاملهای تلفن همراه به یک شهروند درجه یک تبدیل شوند، بومی همیشه یک ملاحظه مهم خواهد بود.
یکی از تکنیکهای ذکر شده در این مقاله، برنامههای ترکیبی است و این ممکن است بهترین راه برای برخی از توسعهدهندگان باشد: نمای وب در جایی که امکانپذیر است و اجزای بومی مختص پلتفرم در جایی که امکانپذیر نیست.
اگر مسیر وب را انتخاب میکنید، به استانداردهای وب و اصل بهبود تدریجی توجه داشته باشید. وب فناوریای است که میداند چگونه انبوه دستگاهها و سیستمعاملهای اطراف را هدف قرار دهد. چه آن را «تکهتکه شدن» بنامید و چه «تنوع»، وب آن را میپذیرد و شما توسعهدهندگان میتوانید از تمام هنرهای پیشین موجود بهرهمند شوید.