گوشی‌های هوشمند همچنان فضای بیشتری را در زیر نور خورشید به دست می‌آورند، نه تنها به‌عنوان ابزاری برای مصرف عکس‌های گربه و فیلم‌های xxx، بلکه به‌عنوان یک ابزار کار. بنابراین، تقاضا برای توسعه تلفن همراه در حال رشد است. به طور کلی پذیرفته شده است که Objective-C/Swift برای iOS و Java/Kotlin برای اندروید درست و جالب هستند. بدون شک، درست و جالب است، اما تعداد زیادی از سناریوهای واقعی وجود دارد که در آنها استفاده از چارچوب های چند پلتفرمی در مقایسه با ابزارهای بومی ارجحیت بیشتری دارد.

برخی از توسعه دهندگان انتظار دارند که چارچوب های چند پلتفرمی تمام مشکلات زندگی آنها را حل کنند، در حالی که برخی دیگر آنها را با خصومت درک می کنند. هر دو "اردوگاه متخاصم" تصورات نادرست خود را دارند که ناشی از درک نادرست از چگونگی و آنچه کار می کند ایجاد می شود. این به آتش سوخت می افزاید، زیرا از احساسات به جای استدلال های فنی استفاده می شود.

همچنین در میان توسعه دهندگان، به ویژه مبتدیان، افسانه های زیادی در مورد فریم ورک های چند پلتفرمی موبایل وجود دارد. در مقاله ما محبوب ترین آنها را تجزیه و تحلیل خواهیم کرد. اما ابتدا، بیایید توسعه موبایل را از چشم کسب‌وکاری ببینیم که برای همه بلک جک‌های فناوری اطلاعات پول می‌دهد.

چرا به ابزارهای چند پلتفرمی نیاز داریم؟

از لحاظ تاریخی، همیشه رقابت در بازار رایانه وجود داشته است و هر سازنده مجموعه بهینه ای از ابزارهای به اصطلاح بومی (بومی) را برای توسعه برنامه های کاربردی برای سیستم عامل ها و دستگاه های خود ارائه می دهد.

ابزار بومی = توسط صاحب اکوسیستم ارائه شده است.

همه نشانه‌های دیگر "زادروز" ثانویه هستند - رفتار و رابط برنامه‌ها، دسترسی به ویژگی‌های سیستم عامل، عملکرد، و غیره.

علاوه بر این، تقریباً همیشه مشخص شد که ابزارهای بومی نه تنها در سطح زبان های توسعه، قراردادها و معماری های پذیرفته شده، بلکه در سطح مکانیسم های کار با سیستم عامل و کتابخانه ها با یکدیگر ناسازگار هستند. در نتیجه، برای پیاده‌سازی الگوریتم‌ها و رابط‌های یکسان، لازم بود یک برنامه کاربردی برای چندین محیط به زبان‌های برنامه‌نویسی مختلف نوشته شود و سپس آن را بر اساس «یک فرمان برای هر پلتفرم» نگهداری کنیم. در عین حال، قابلیت ها و ظاهر اپلیکیشن ها در پلتفرم های مختلفآه تقریبا همیشه 90٪ یکسان است. برای علاقه مندی، اجرای برنامه های مورد علاقه خود را برای iOS و اندروید مقایسه کنید.

دومین نکته مهم- در دسترس بودن دانش و تجربه لازم در تیم: اگر آنها نباشند، یادگیری زمان می برد.

برای حل هر دوی این مشکلات، ابزارهای توسعه چند پلتفرمی (نه تنها موبایل) مدت‌هاست که در بازار ظاهر شده‌اند و ارائه می‌دهند:

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

از آنجایی که در حال حاضر زبان‌های برنامه‌نویسی (و محیط‌های) زیادی (و متخصصانی که این زبان‌ها را می‌دانند) وجود دارد، ابزارهای زیادی برای توسعه بین پلتفرم‌ها وجود دارد. به عنوان مثال، ما بر محبوبیت در منطقه خود تمرکز خواهیم کرد PhoneGap، Xamarin، React Native و Qt.

اکنون می توانیم در مورد اسطوره ها صحبت کنیم.

افسانه 1. جادو

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

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

• کراس پلتفرمزندگی در محیط مجازیو داشتن دسترسی محدودبه قابلیت های سکوی هدف از طریق یک پل ویژه؛
• بومی، که مقداردهی اولیه برنامه، کنترل را فراهم می کند چرخه زندگیاشیاء کلیدی و دارد دسترسی کاملبه API های سیستم

برای اتصال دنیای "بومی" و جهان "کراس پلتفرم"، لازم است از یک ابزار ویژه استفاده شود. پل، اوست که امکانات و محدودیت های چارچوب های چند پلتفرمی را تعیین می کند.

هنگام استفاده از یک پل، عملکرد همیشه با تبدیل داده ها بین "جهان ها" و همچنین تبدیل تماس ها و کتابخانه های API کاهش می یابد.

بنابراین، همه برنامه های کاربردی کراس پلتفرم باید یک بخش بومی داشته باشند، در غیر این صورت سیستم عامل به سادگی قادر به اجرای آنها نخواهد بود. بنابراین بیایید نگاهی دقیق‌تر به API‌ها و مکانیسم‌های سیستمی داشته باشیم که توسط خود iOS، Android و Windows ارائه شده‌اند. بیایید به اسطوره بعدی برویم.

افسانه 2. بومی نیست!

بنابراین، ما یک بخش کراس پلتفرمی از برنامه داریم که در یک محیط مجازی زندگی می کند و از طریق زیرساخت چارچوب و پل با سیستم عامل تعامل دارد.

همه سیستم عامل ها: iOS، Android و Windows UWP - دسترسی به زیرسیستم های زیر (مجموعه ای از API های سیستم) را فراهم می کند:

• WebView (مرورگر وب تعبیه‌شده در برنامه) در برنامه‌های ترکیبی مبتنی بر PhoneGap استفاده می‌شود و عملاً به‌عنوان زمان اجرای وب‌سایت محلی عمل می‌کند.
• موتورهای جاوا اسکریپت در React Native و همتایان آن برای اجرای سریع کد JS و تبادل داده بین Native و JS استفاده می شود.
• OpenGL ES (یا DirectX) در موتورهای بازی و برنامه های کاربردی مبتنی بر Qt/QML یا مشابه برای رندر رابط استفاده می شود.
• زیرسیستم UI مسئول رابط کاربری بومی برنامه است که مربوط به React Native و Xamarin است.

برنامه های کراس پلتفرم دارای یک بخش بومی و همان دسترسی کامل به API های سیستم به عنوان برنامه های "بومی" هستند. تفاوت این است که فراخوانی متد سیستم از طریق زیرساخت پل و چارچوب می‌گذرد:

مشاهده وب- برنامه در مرورگر وب خود مانند یک وب سایت یک صفحه ای زندگی می کند. بدون دسترسی به کنترل های بومی (دکمه ها، لیست ها و غیره)، همه چیز بر اساس HTML/CSS/JavaScript است. از سوی دیگر، یک توسعه‌دهنده وب مانند یک اردک به آب احساس می‌کند.

موتورهای جاوا اسکریپتاخیراً محبوب شده است ، زیرا مکانیزم مشابه فقط در نسخه 7.0 به iOS اضافه شده است. از میان ویژگی‌ها، نیاز به سریال‌سازی ساختارهای داده پیچیده که بین محیط‌های جاوا اسکریپت و بومی به JSON منتقل می‌شوند، ارزش دارد. اگر به طور خلاصه چنین کلاسی از راه حل ها را توصیف کنیم، در محیط جاوا اسکریپت، کد JS که برنامه بومی را کنترل می کند، اجرا می شود.

OpenGL ES و DirectXزیرسیستم های سطح پایینی هستند و برای ترسیم رابط کاربری در بازی ها و به عنوان مثال Qt/QML استفاده می شوند. به این معنی که هنگام استفاده از OpenGL / DirectX، توسعه دهندگان خود کنترل ها و انیمیشن هایی را ترسیم می کنند که فقط می توانند مشابه موارد بومی باشند. از طرفی یک زیرسیستم سطح پایین با کارایی بسیار بالا است و به همین دلیل در موتورهای بازی کراس پلتفرم نیز از آن استفاده می شود.

همه برنامه‌های کاربردی کراس پلتفرم دارای یک بخش بومی هستند، و بنابراین، به طور بالقوه دسترسی کامل به APIهای سیستم مانند برنامه‌های «بومی» دارند. همچنین، برنامه های کاربردی کراس پلتفرم توسط ابزارهای «بومی» در بسته های نصب «بومی» ساخته و بسته بندی می شوند. سوال کلیدی این است که چگونه تعامل بین بخش کراس پلتفرم و بخش بومی سازماندهی می شود. به عنوان مثال، در داخل یک WebView یا با استفاده از Open GL ES / DirectX، هیچ راهی برای ایجاد یک رابط کاربری با ظاهر کاملاً بومی وجود ندارد، اما دسترسی کامل به GPS، اعلان‌های فشاری و سایر عملکردها وجود دارد. و کد جاوا اسکریپت یا سی شارپ می تواند کاملاً آزادانه برنامه بومی و رفتار آن را کنترل کند و ظاهری کاملاً بومی ارائه دهد.

به طور خلاصه - بله، "غیر بومی" از نظر ابزارهای توسعه استفاده شده (نه از اپل، گوگل). اما یک اپلیکیشن می تواند از نظر دسترسی به API های سیستم کاملا بومی باشد و ظاهر و احساس کاملا بومی ارائه دهد. و ما به اسطوره بعدی می رویم.

افسانه 3. عصا روی عصا

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

به نظر می رسد که عصا نحوه ادغام قسمت کراس پلتفرم با قسمت بومی است. برای درک بهتر نحوه عملکرد فریمورک‌های مختلف، از مثال PhoneGap، Xamarin، Qt و React Native استفاده می‌کنیم تا مکانیسم‌های سیستم‌عاملی را که برای پیوند میان پلتفرم‌ها و بخش‌های داخلی استفاده می‌شوند، بررسی کنیم.

ما با PhoneGap شروع می کنیم. در زیر معماری سطح بالای یک اپلیکیشن مبتنی بر این فریم ورک آورده شده است.

برنامه PhoneGap در واقع یک برنامه بومی است که WebView را به عنوان تنها کنترل رابط کاربری نمایش می دهد. از طریق او است که تعامل با بخش بومی صورت می گیرد. همه WebView های استاندارد در iOS، Android و Windows UWP از قابلیت افزودن کنترل کننده های بومی برای ویژگی ها و روش های JS پشتیبانی می کنند. در همان زمان، کد JS در محیط ایزوله خود زندگی می کند و چیزی در مورد قسمت اصلی نمی داند - به سادگی روش های JS لازم را می کشد یا ویژگی های JS لازم را تغییر می دهد. همه چیز در داخل وب DOM استاندارد قرار دارد که به سادگی عناصر جدید مرتبط با پیاده سازی بومی را اضافه می کند.

هنگام ایجاد برنامه‌های کاربردی در React Native، توسعه‌دهنده تقریباً همیشه نیاز به پیاده‌سازی بخش اصلی در Objective-C، Java یا C # دارد و مدیریت خود برنامه بومی از جاوا اسکریپت انجام می‌شود. در واقع موتور جاوا اسکریپت یک عنصر WebView است که به صورت جداگانه در دسترس است. این تعامل از طریق همان پل JS مانند مورد PhoneGap انجام می شود. با این حال، در React Native، کد JS درخت وب DOM را مدیریت نمی کند، بلکه برنامه بومی را مدیریت می کند.

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

اکنون Xamarin.iOS و Xamarin.Android کلاسیک را در نظر بگیرید، زیرا Xamarin.Forms (پشتیبانی از Windows UWP) یک افزونه برای آنها است.

Xamarin از کتابخانه Mono برای تعامل با سیستم عامل هدف استفاده می کند که به کدهای بومی اجازه می دهد تا با استفاده از مکانیزم P/Invoke فراخوانی شوند. همچنین برای برقراری ارتباط با API های بومی در iOS/Android استفاده می شود. یعنی Wrapperها در سی شارپ برای همه متدهای بومی API عمومی ایجاد می شوند که به نوبه خود APIهای سیستم را فراخوانی می کنند. بنابراین، تمام API های سیستم را می توان از یک برنامه Xamarin در دسترس قرار داد.

و در نهایت، بیایید به Qt نگاه کنیم، زیرا سوالات زیادی در مورد آن از سوی توسعه دهندگان با تجربه وجود دارد.

Qt به خودی خود یک چیز است، این هم مزایا و هم محدودیت هایی دارد. کتابخانه‌های Qt به سادگی به APIهای سیستم C++ موجود در همه سیستم‌عامل‌ها متصل می‌شوند. برای ترسیم رابط کاربری، از مکانیزم های سطح پایین استفاده می شود، اما موتور گرافیکی خودش که از استایل بومی پشتیبانی می کند. در همان زمان، در اندروید، شما باید از طریق یک پل مخصوص (JNI bridge) به Java API دسترسی داشته باشید و برای ویندوز UWP، از مبدل تماس Open GL ES به DirectX استفاده کنید، زیرا Open GL برای UWP در دسترس نیست.

به طور خلاصه: تمام چارچوب های چند پلتفرمی از ویژگی های استاندارد استاندارد سیستم عامل ها استفاده می کنند، بالغ هستند، توسط تیم های مجرب و جامعه منبع باز با پشتیبانی غول های صنعت فناوری اطلاعات ایجاد شده اند. و سرانجام، زمان "قوی ترین" استدلال فرا رسیده است.

افسانه 4. به آرامی

یک برگ برنده مهم که مردم دوست دارند در اختلافات در مورد چارچوب های چند پلتفرمی از آن استفاده کنند، عملکرد پایین است. باز هم بسته به اینکه با چه چیزی مقایسه کنیم و در کدام طوطی ها بشماریم.

به یاد بیاورید که یکی از ویژگی های برنامه های کاربردی چند پلت فرم وجود موازی دو جهان است که توسط یک پل به هم متصل شده اند:

• PhoneGap: HTML/JS و Native Java / Objective-C / C#.
• React Native: JS و Native Java / Objective-C / C#.
• Xamarin: Mono و Native Java / Objective-C.
• Qt: C++ و Native Java/Objective-C.

بنابراین، هنگام مقایسه عملکرد، لازم است سرعت کار را در نظر بگیرید:

• بخش کراس پلت فرم؛
• قسمت بومی؛
• پل

اگر در یک موتور جستجو تایپ کنید، به عنوان مثال، واکنش بومی در مقابل عملکرد سریع، می‌توانید آزمایش‌های مختلفی را مشاهده کنید، و بسیاری از آنها متوجه می‌شوند که هنگام استفاده فعال از پل، عملکرد به شدت کاهش می‌یابد، از جمله دستکاری فعال UI از کدهای چند پلتفرمی. برای Xamarin، وضعیت یکسان به نظر می رسد - بخش کراس پلتفرم در پردازش داده بسیار سریع و قابل مقایسه با بخش بومی است، با این حال، هنگام استفاده از یک پل، ممکن است عملکرد کاهش یابد. Qt عموماً در سطح C++ کار می کند که به خودی خود سریع است. اگر راه‌حل‌های مبتنی بر PhoneGap را در نظر بگیریم، در اینجا عملکرد بسیار به WebView وابسته خواهد بود، اما هنوز هم نباید به طور فعال رابط کاربری را در کد جاوا اسکریپت تغییر دهید یا محاسبات علمی انجام دهید.

به آرامی؟ بله، افت عملکرد به دلیل تعامل نادرست با سیستم عامل از طریق پل امکان پذیر است. با این حال، جهان های کراس پلتفرم خود به همان سرعتی هستند که جهان های بومی هستند.

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

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

برنامه های کاربردی بومی برنامه هایی هستند که به طور خاص برای یک پلت فرم خاص در زبان برنامه نویسی مناسب توسعه یافته اند. بنابراین، هنگام ایجاد یک برنامه برای اندروید از جاوا و برای برنامه های IOS از Objective-c یا Swift استفاده می شود. هنگام ایجاد چنین پروژه هایی، متخصصان تمام ویژگی های پلتفرم ها را در نظر می گیرند، توجه ویژه ای به طراحی UI / UX، الزامات / توصیه های توسعه دهندگان سیستم عامل و همچنین آخرین روندها در صنعت تلفن همراه دارند. یک متخصص نمی تواند به تمام زبان های فوق تسلط کامل داشته باشد، بنابراین، برای توسعه یک محصول بومی برای پلتفرم های مختلف، اتصال توسعه دهندگان مختلف ضروری است و این هزینه اضافی است و زمان توسعه چشمگیر خواهد بود. اما در همان زمان، برنامه ها برای یک پلت فرم خاص "تیز" می شوند، به منابع و عملکردهای داخلی دستگاه دسترسی پیدا می کنند و تا حد امکان کارآمد خواهند بود.

علیرغم فهرست قابل توجهی از مزایای توسعه بومی، مشتریان همیشه نمی خواهند زمان و هزینه خود را صرف توسعه خود کنند و چندین استاد را به فرآیند ایجاد متصل کنند. بهترین گزینه در چنین مواردی توسعه کراس پلتفرم است که به شما امکان می دهد با استفاده از فناوری های وب استاندارد برای هر پلتفرمی برنامه ایجاد کنید. در این مورد، توسعه می تواند توسط یک نفر انجام شود که دارد دانش لازمو تجربه با HTML5، جاوا اسکریپت و CSS3. توسعه های چند پلتفرمی را می توان در یک فایل apk. برای اندروید و یک فایل ipa. برای IOS کامپایل کرد. بنابراین، بر اساس یک توسعه، می توانید دو برنامه کاربردی برای سیستم عامل های محبوب دریافت کنید و زمان و هزینه کمتری را صرف آن کنید. با این حال، چنین پیشرفت هایی نیز دارای اشکالاتی هستند، بنابراین بسیار مطلوب است که به هر مورد خاص به صورت جداگانه نزدیک شوید و مناسب ترین گزینه - توسعه بومی یا چند پلتفرمی را انتخاب کنید.

بخش های سرویس گیرنده و سرور برنامه

اکثر برنامه های کاربردی جدی سمت کلاینت خود را دارند که اغلب به آن frontend می گویند و سمت سرور، backend. قسمت جلویی مسئول چیزی است که روی صفحه دستگاه تلفن همراه خود می بینید، یعنی کل نمایش بصری برنامه، از جمله طراحی، اندازه و مکان پنجره ها، منوها، دکمه ها، فلش ها و هر عنصر دیگر. همچنین، frontend مسئول واکنش برنامه به برخی اقدامات کاربر با هدف انتقال به بخش های مختلف برنامه، فراخوانی منوهای جدید و غیره است.

Backend بخش سرور برنامه است و بر روی یک سرور راه دور قرار دارد که می تواند در هر مکانی قرار داشته باشد و با استفاده از طیف گسترده ای از برنامه ها کنترل شود. ابزارهای نرم افزاری. ارتباط بین بخش های مشتری و سرور از طریق API (رابط برنامه نویسی برنامه) انجام می شود. به عبارت دیگر، API نوعی واسطه بین frontend و backend است که درخواست‌ها را از سمت کلاینت به سرور ارسال می‌کند و داده‌های لازم را برای کاربر برمی‌گرداند.

توسعه Frontend

بخش مشتری برنامه بسیار مهم است، زیرا خود کاربر با آن سروکار دارد و ایده کلی او از برنامه به راحتی قسمت ظاهری بستگی دارد. می توان آن را هم به صورت دستی توسعه داد، اما برای این کار باید به خوبی به HTML5، CSS3 و java-script و با کمک به اصطلاح فریمورک ها مسلط باشید. در مورد اول، محیط توسعه Apache Cordova که معمولاً با نام PhoneGap نیز شناخته می شود، اغلب استفاده می شود. با استفاده از این فریم ورک، می‌توانید برای هر پلتفرمی با استفاده از فناوری‌های وب برنامه‌هایی ایجاد کنید که Cordova آن‌ها را به کد قابل فهم برای یک پلتفرم خاص تبدیل می‌کند. Cordova تقریباً امکانات نامحدودی را برای توسعه دهندگان وب باز می کند که برای ایجاد برنامه های کاربردی برای سیستم عامل های خاص نیازی به یادگیری Objective-C یا Swift، Java یا Kotlin ندارند.

در حالی که Cordova هیچ محدودیتی در رابط کاربری و منطق ندارد، فریمورک ها راه حل های قالب آماده ای را ارائه می دهند. از یک طرف، این به طور قابل توجهی روند توسعه را سرعت می بخشد و ساده می کند، زیرا یک متخصص می تواند از دکمه های آماده، لیست ها، فیلدهای ورودی، کارت ها و سایر عناصر UI استفاده کند. از طرف دیگر، یک متخصص می تواند برای توسعه تنها از ابزارها و عناصری استفاده کند که در چارچوب انتخاب شده موجود است. محبوب ترین آنها Ionic است که به شما امکان می دهد برای هر سلیقه ای برنامه های cross-platform ایجاد کنید. این فریم ورک دارای یک مجموعه داخلی بزرگ است عناصر استاندارد، که از نظر بصری برنامه های بومی را تقلید می کنند، اما در صورت لزوم می توان طراحی آنها را تغییر داد. در عین حال، توسعه‌دهنده می‌تواند بسیاری از افزونه‌های اضافی را که قابلیت‌های فریم ورک یونی را گسترش می‌دهند، متصل کند و پروژه ایجاد شده بر روی این فریم ورک را می‌توان مستقیماً در پنجره مرورگر راه‌اندازی کرد و نحوه ظاهر و کارکرد آن را ارزیابی کرد. برنامه در حال ایجادبدون نیاز به شبیه ساز یا نصب بر روی گوشی هوشمند.

توسعه Backend

در حالی که طراحان و توسعه دهندگان با دانش HTML، CSS، JS و فریم ورک ها در سمت کلاینت مشغول هستند، برنامه نویسان با مشخصات متفاوت در backend مشغول هستند. برای پیکربندی سرورها می توان از زبان ها و ابزارهای برنامه نویسی مختلف استفاده کرد، نکته اصلی پیکربندی صحیح کار و تعامل آنها با بخش مشتری است. در اینجا باید استفاده کنید سیستم های مناسبمدیریت پایگاه داده (پایگاه های داده). این می تواند MySQL سنتی، Redis، PostgreSQL، یا هر پایگاه داده دیگری (به عنوان مثال، MongoDB) باشد که برای اجرای یک پروژه خاص مناسب است و توسعه دهنده Back-end به خوبی در آن مهارت دارد. توسعه دهندگان می توانند از PHP، NodeJS، C#، Ruby، Python، Java و سایر زبان های برنامه نویسی برای ایجاد سمت سرور برنامه استفاده کنند.

متخصصان استودیوی موبایل کیت اپ به موضوع توسعه بخش های فرانت اند و باطن به روشی جامع و حداکثر مسئولیت پذیر می پردازند. توسعه دهندگان ما یک برنامه کاربردی چند پلتفرمی با هر پیچیدگی و جهتی را تا حد امکان سریع و کارآمد برای شما ایجاد خواهند کرد! با ما تماس بگیرید و متخصصان ما به سرعت در مورد تمام سوالات شما به شما مشاوره خواهند داد!

برنامه های کاربردی چند پلتفرمی - بودن یا نبودن؟ این سوال آسان نیست، زیرا هر کسب و کار اهداف و الزامات خاص خود را برای برنامه های تلفن همراه دارد. اما امروز قطعا متوجه خواهیم شد که کدام توسعه برای شما مناسب است.

برنامه های کاربردی متقابل پلت فرم چیست؟

اپلیکیشن‌های کراس پلتفرم، برنامه‌هایی هستند که توسعه داده می‌شوند و سپس همزمان بر روی اندروید و iOS اجرا می‌شوند. ماهیت توسعه این است منبعبرنامه به بومی ترجمه شده است، یعنی برای یک دستگاه تلفن همراه خاص قابل درک است. در نتیجه، برنامه می تواند با سیستم عامل نصب شده بر روی آن تعامل داشته باشد.

به یاد بیاورید: برنامه های بومی، بر خلاف برنامه های چند پلتفرمی، برای یک سیستم عامل خاص نوشته شده اند.

مزایای توسعه چند پلتفرمی

• گسترش پایگاه کاربر به دلیل ظاهر برنامه به طور همزمان در چندین فروشگاه.
• کد منبع واحد شما را از استخدام چندین توسعه دهنده برای هر پلتفرم نجات می دهد.
• 75 درصد از پایه کد یک برنامه کاربردی چند پلتفرمی را می توان مجدداً استفاده کرد و آن را برای پروژه های جدید تطبیق داد.

معایب توسعه بین پلتفرمی

1. وابستگی زیاد به دستگاه تلفن همراه

برنامه های کراس پلتفرم معمولاً به صورت آفلاین کار نمی کنند. بنابراین، قابلیت‌های آن‌ها به شدت به داشتن یک اتصال اینترنتی پایدار توسط کاربر بستگی دارد. نسخه سیستم عاملو مدل دستگاه نیز مهم است. تقریباً تضمین شده است که یک برنامه cross-platform عملکرد دستگاه قدیمی‌تر از یک تا دو سال را کاهش می‌دهد. در حالی که برنامه بومی حتی بر روی یک ابزار باستانی با سیستم عامل قدیمی به طور پایدار کار می کند. بنابراین، اگر نمی‌خواهید مشتریان شما نظرات خشمگینانه‌ای درباره نحوه پایان یافتن اپلیکیشن شما در گوشی هوشمند شخصی بخوانند، توسعه بومی را انتخاب کنید.

2. رابط کاربری غیر دوستانه

کاربران بسیار معتاد هستند ظاهرو عملکرد گجت‌هایشان، این است که از برنامه‌های نصب شده روی آن‌ها انتظار حداکثر پاسخ‌گویی را دارند. آنها می خواهند مطمئن باشند که هر دکمه در جای مناسب خود قرار دارد، صفحه با سرعتی که برای آنها بهینه است پیمایش می کند، و هر اقدامی که انجام می دهند با واکنش فوری همراه است. برنامه های کاربردی کراس پلتفرم معمولاً برای تطبیق با دستگاه دشوار است و نمی توانند عملکردی با سرعت بالا داشته باشند.

مشکل این است که هیچ دستورالعملی برای توسعه چند پلتفرمی - استانداردهای توسعه از سوی سازندگان سیستم عامل وجود ندارد. بنابراین، یک برنامه cross-platform ساخته شده "برای Android" برای یک کاربر iOS راحت نخواهد بود و بالعکس. البته می‌توانید برای هر پلتفرم طرح‌های جداگانه ایجاد کنید، اما از نظر هزینه‌های نیروی کار، این برابر با ایجاد دو برنامه متفاوت، البته به یک زبان، خواهد بود.

3. مبارزه برای برتری در میان ابزارهای توسعه

در بازار راه حل های توسعه چند پلتفرمی، رقابت هر روز سخت تر می شود. تاکنون React Native و Xamarin محبوب‌ترین‌ها در میان توسعه‌دهندگان بوده‌اند، اما برای مثال Vue Native ممکن است به خوبی از آن‌ها پیشی بگیرد. در این صورت، رهبران سابق مسابقه مهمترین مزیت را از دست خواهند داد - پشتیبانی کد عملیاتی. و این می تواند با هر ابزار کراس پلتفرمی اتفاق بیفتد.

توسعه بومی از چنین مشکلی نمی ترسد. معرفی ابزارهای جدید تدریجی است و دانش چندین زبان برنامه نویسی، که برای یک متخصص باریک اجباری است، به او اجازه می دهد تا به سرعت با تمام نوآوری ها مقابله کند. علاوه بر این، جوامع حرفه ای عظیمی در اطراف هر سیستم عامل وجود دارد که در نتیجه هر مشکلی که پیش آمده است با جستجوی مشکل مشابه در انجمن ها حل می شود، جایی که هزاران نفر آماده پیشنهاد و کمک به حل آن هستند.

کدام اپلیکیشن برای کسب و کار شما مناسب است؟

قبل از پاسخ به این سوال، تجزیه و تحلیل کسب و کار شما بسیار مهم است. بخش‌های مصرف‌کننده، ارزش زمان و منابع پولی، عمق مطلوب یکپارچه‌سازی برنامه با دستگاه‌های کاربر، به‌علاوه اهداف بلندمدت مشخص - حداقلی که انتخاب شما به آن بستگی دارد. اما اگر همین الان به سوالات مربوطه پاسخ دهید، کار را آسانتر خواهیم کرد.

1. مخاطبان شما از چه چیزی استفاده می کنند؟

اگر می دانید که نسبت تعداد کاربران iOS و اندروید در بین کلاینت های شما نزدیک به 50/50 است، توسعه داخلی را انتخاب کنید. این نشان می دهد که شما به طور یکسان به نیازهای همه مشتریان خود صرف نظر از سطح درآمد آنها احترام می گذارید.

ارتباط بین انتخاب یک دستگاه تلفن همراه و سطح پرداخت بدهی بار دیگر توسط App Annie تایید شده است. در نتیجه بررسی تعداد دانلود و فروش اپلیکیشن های موبایل در گوگل پلیو اپ استوردر سه ماهه اول سال 2018، مشخص شد که کاربران تلفن های هوشمند اندرویدی 135 درصد بیشتر از بازدیدکنندگان فروشگاه iOS برنامه دانلود کرده اند. در همان زمان، اپ استور 85 درصد بیشتر از گوگل پلی درآمد برای صاحبان خود به ارمغان آورد.

مسیر موفقیت واضح است: بازی در دو زمین همزمان. به طور دقیق تر، دو فروشگاه. فقط محاسبه کنید که برنامه باید ابتدا در کدام یک ظاهر شود. البته، اگر انتشار همزمان بخشی از استراتژی دیجیتال شما نباشد).

2. چقدر زمان توسعه دارید؟

هزینه های مالی پروژه به پاسخ به این سوال بستگی دارد. واقعیت این است که از نقطه نظر زمان صرف شده برای توسعه، یک برنامه کاربردی چند پلتفرمی تنها راه حل سودآورتری به نظر می رسد. در واقع، تطبیق آن برای پلتفرم‌ها می‌تواند تقریباً به اندازه ایجاد دو برنامه بومی طول بکشد، زیرا توسعه‌دهندگان باید بخش‌های دیگری از کد را برای مناطق مشکل بنویسند.

با یک برنامه بومی، قطعا چنین مشکلاتی وجود نخواهد داشت، که برای حفظ مخاطبانی که به شدت نسبت به خطاها و اشکالات تحمل نمی کنند، بسیار مهم است. طبق آمار Compuware، 79٪ از کاربران آماده هستند تا برنامه را در صورتی که در اولین راه اندازی به درستی کار نکرد، راه اندازی مجدد کنند، اما تنها 16٪ موافقت می کنند که فرصتی دوباره به آن بدهند. بقیه به احتمال زیاد فقط برنامه را حذف خواهند کرد.

3. قصد دارید از چه ویژگی های دستگاه استفاده کنید؟

قبلاً در مورد این واقعیت صحبت کرده ایم که فقط برنامه های بومی قادر به بازتولید گرافیک های سنگین به سرعت و بدون افت کیفیت هستند. اما این مزایای فنیتوسعه بومی محدود نیست. به عنوان مثال برنامه فیس بوک را در نظر بگیرید. به لطف انتشار نسخه‌های مجزا برای اندروید و iOS، اسکرول نرم‌تر شده، زمان بارگذاری تصاویر کاهش یافته و تمامی مشکلات حافظه پنهان برطرف شده است.

علاوه بر این، برنامه‌های بومی به تمام خدمات دستگاه دسترسی مستقیم دارند و به شما امکان می‌دهند اطلاعاتی درباره مکان یا لیست مخاطبین کاربر دریافت کنید. برنامه های کراس پلتفرم باید از پلاگین های بومی ویژه استفاده کنند که بر سرعت انتقال داده و بارگذاری بیش از حد تأثیر منفی می گذارد. رمدستگاه ها

4. به دنبال چه نتایجی هستید؟

استراتژی دیجیتال لیستی از اهدافی است که شرکت شما می تواند با استفاده از ابزارهای دیجیتال به آنها دست یابد. انتخاب دومی تا حد زیادی به مزایایی بستگی دارد که می خواهید در پایان به دست آورید.

با در نظر گرفتن تمام منابع موجود، فرآیند را از ایده به نتیجه، نقطه به نقطه تجزیه کنید. اکتشافات می توانند غیرمنتظره ترین باشند.

برای مثال، ممکن است متوجه شوید که ترجمه سایت ریسپانسیو خود با ویژگی‌ها و عناصر تعاملی زیاد به یک برنامه چند پلتفرمی، همانطور که در ابتدا قصد داشتید، کاری بسیار پرهزینه است. یا در نهایت مطمئن شوید که یک سایت تلفن همراه همیشه به یک برنامه تلفن همراه بازنده می شود - درست مانند توسعه بین پلتفرم ها به بومی. و در میان دلایل، مواردی را که در بالا در مورد آنها صحبت کردیم بیابید.

نتیجه گیری: یک برنامه متقابل پلت فرم فقط در یک مورد مفید است - شما یک نسخه آزمایشی از برنامه ایجاد می کنید، از نظر زمان، پول و متخصصان با مشخصات محدود محدود هستید. در همه موارد دیگر، یک برنامه بومی چندین برابر مزایای بیشتری به شما می دهد، زیرا این یک سطح توسعه کیفی متفاوت است.

به نظر می رسد که در اینجا ما توسعه بین پلتفرمی داریم که امکان ایجاد برنامه های کاربردی جهانی برای پلتفرم های مختلف را فراهم می کند. من برنامه را سریعتر نوشتم، بلافاصله آن را در همه جا منتشر کردم - سود! و هیچ توسعه بومی مورد نیاز نیست. یا هنوز مورد نیاز است؟ ما از کارشناسان خود در مورد تفاوت های ظریف هر دو رویکرد برای توسعه اپلیکیشن موبایل سوال کردیم.

"توسعه دهنده موبایل" یک مفهوم گسترده است. توسعه دهنده ای که بخش هایی از سیستم عامل موبایل را پیاده سازی می کند، توسعه دهنده موبایل نیز هست. و اگر هدف تبدیل شدن به چنین توسعه دهنده ای است، پس باید به طور کلی با یادگیری C ++، سیستم عامل موبایل و سخت افزار دستگاه های تلفن همراه شروع کنید.

اگر منظور شما یک توسعه دهنده است که سفارشی را پیاده سازی می کند برنامه های موبایل، سپس باید با توسعه بومی شروع کنید.

چرا اینطور است؟ توسعه بومی به شما امکان می دهد تا توانایی های سیستم عامل های خاص (و برنامه های کاربردی برای آنها) و سخت افزار موبایل را بهتر و عمیق تر بررسی کنید.

از دیدگاه کاربر، توسعه بومی قطعا برنده است. برنامه‌های بومی سریع‌تر کار می‌کنند، رابط کاربری آن‌ها برای کاربران یک سیستم‌عامل تلفن همراه خاص، پاسخگوتر و آشناتر است، آنها بهتر از قابلیت‌های سخت‌افزاری دستگاه‌ها استفاده می‌کنند، آفلاین بهتر کار می‌کنند و کمتر «باگ» هستند.

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

هنگام انتخاب نوع توسعه برای یک کار خاص، توسعه دهنده باید ارزیابی کند که آیا این سازش قابل قبول است یا خیر. تعدادی کار وجود دارد که استفاده از توسعه بین پلتفرمی کاملاً توجیه پذیر است، به عنوان مثال، در پروژه های آزمایشی، نسخه های موبایلی سایت ها، بازی هایی با استفاده از چارچوب هایی مانند Unity 3D.

در عین حال، برای پروژه‌هایی که مشکلات کسب و کار تلفن همراه را حل می‌کنند (با بار بالا، نیاز به پشتیبانی از حالت آفلاین، با هدف توسعه بلندمدت)، توسعه بومی به عنوان تنها بهینه (و برای برخی کارها، تنها امکان ممکن) دیده می‌شود. ) گزینه.

در عین حال، معایب اصلی توسعه بومی زمان توسعه (بیشتر مورد نیاز است) و نیاز به منابع متنوع (توسعه دهندگان در زبان های برنامه نویسی بومی مختلف) است. راه هایی برای کاهش این کاستی ها وجود دارد - به عنوان مثال، استفاده از نوعی پلت فرم اپلیکیشن موبایل (کلاس MEAP) برای توسعه، که به شما امکان می دهد برنامه های کاربردی بومی ایجاد کنید.

ارتقاء Downgrade

, مدیر توسعه فناوری شرکت فناوری اطلاعات "ID - Management Technologies"

هر کتابخانه یا چارچوب متقابل پلتفرمی بر اساس مکانیسم‌های بومی مشابهی است که مستقیماً توسعه بومی را پیاده‌سازی می‌کنند. فقط در مورد راه‌حل‌های چند پلتفرمی، گردش‌های کاری به گونه‌ای ساخته می‌شوند که «گوشه‌ها» را از نظر رساندن رابط راه‌حل نهایی به یک مخرج مشترک خاص، «صاف کردن» کند.

به عنوان یک قاعده، جهانی گرایی همیشه پاسخی به کار ایجاد یک راه حل کارآمد تلفن همراه نیست: توسعه دهنده بهتر کار می کند، مکانیزم های دستگاه را عمیق تر درک می کند. فرآیندهای مختلفاز داخل، همانطور که می گویند، "زیر کاپوت".

همچنین، یک مدل کاملاً کارآمد، تسلط همزمان بر عناصر اساسی دو رویکرد خواهد بود، هیچ چیز غیرممکنی در چنین کار یادگیری در مرحله اولیه وجود ندارد. به عنوان مثال، چنین سناریویی ممکن است کاملاً عملی و امیدوارکننده باشد: شروع به کار در یک الگوی چند پلت فرمی، و به موازات آن، به طور مستقل یا با کمک همکاران، مطالعه کنید که چه فرصت‌های بومی برای توسعه راه‌حل‌های فعلی وجود دارد و چگونه می‌توانند در عمل اعمال شود.

در این مورد، دستیابی به درک جامعی از نحوه عملکرد اصولی فرآیند توسعه تلفن همراه، که به صورت end-to-end نامیده می شود، آسان تر است. این نیز به این دلیل مفید است که هر پلتفرم، حتی پیشرفته‌ترین، جهانی در قابلیت‌های خود از بومی عقب است: سازندگان سخت‌افزار و سیستم‌عامل موبایل اغلب با هم کار می‌کنند و دائماً قابلیت‌های راه‌حل‌های نهایی را افزایش می‌دهند - قابلیت‌های پلتفرم‌های توسعه موبایل، به‌ویژه راه‌حل‌های چند پلتفرمی. , ناگزیر عقب ماندن .

محصولات جدید در بخش موبایل همیشه در بازار ظاهر می شوند، برخی از آنها بسیار جلوتر از زمان خود هستند - سامسونگ و توسعه دستگاهی با صفحه نمایش تاشو را در نظر بگیرید: بدیهی است که به دلیل ظاهر کاملاً متفاوت ، پلتفرم های توسعه موجود برای چنین مواردی آماده نیستند.

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

توسعه بین پلتفرمی برای نمونه سازی، آزمایش سریع یک ایده و غیره عالی است. به محض اینکه نوبت به ایجاد محصولات واقعاً اساسی می رسد، توسعه دهنده به ناچار نیاز به مطالعه عمیق عناصر اساسی فرآیند، یعنی توسعه بومی را پیدا می کند.

ارتقاء Downgrade

, رئیس دانشکده توسعه iOS GeekUniversity، پورتال آموزشی GeekBrains

پاسخ کوتاه: اگر تجربه ای در برنامه نویسی ندارید، مطمئناً باید توسعه بومی را انتخاب کنید. توسعه بین پلتفرمی برای حرفه ای هایی که از حوزه های مرتبط به توسعه موبایل می روند خوب است. به عنوان مثال، اگر شما یک توسعه‌دهنده فرانت‌اند با دانش خوب جاوا اسکریپت هستید، با استفاده از چارچوب React Native (بر اساس چارچوب React) می‌توانید به سرعت و بدون دردسر بر توسعه موبایل مسلط شوید. همانند توسعه دهنده دات نت، تسلط بر فریم ورک Xamarin آسان تر خواهد بود.

توسعه بین پلتفرمی نیز برای مشتری مفید است - پیدا کردن یک تیم از توسعه دهندگان که با پیروی از یک الگوی مشترک، یک برنامه کاربردی را برای دو پلتفرم به طور همزمان توسعه دهند، آسان تر است.

مزایا مشخص است، اما معایب توسعه چند پلتفرمی چیست؟! اعتقاد بر این است که هرچه عملکرد یک برنامه تلفن همراه پیچیده تر و ظریف تر باشد، پیاده سازی آن با ابزارهای چند پلتفرمی دشوارتر، اگر نگوییم غیرممکن است - این اغلب بر تمام مزایای ابزارهای جهانی برتری دارد. بر اساس تجربه من، چندین شرکت بزرگ وجود دارند که با رشد برنامه های خود، مجبور به کنار گذاشتن کراس پلتفرم به نفع توسعه بومی شدند. بنابراین، برای پروژه های کوچک و احتمالاً کارهای مستقل، راه حل های کلی کافی است، در حالی که برای پروژه های بزرگ، راه حل های بومی مناسب تر هستند.

تقاضا برای هر دو منطقه بسیار زیاد است، اما برای توسعه بومی تا حدودی بیشتر است: به درخواست سوئیفت در hh.ru در روسیه - 369 خالی، Kotlin - 397، React Native - 111، Flutter - 13 Xamarin - 18. اما استراحت کنید. مطمئن باشید، یک متخصص خوب در هیچ زمینه ای کار نخواهد کرد.

ارتقاء Downgrade

برای شروع، توجه به این نکته مهم است که هر برنامه موبایلی از چندین لایه تشکیل شده است:

• UI - آنچه کاربر می بیند.
• منطق تجاری - برنامه برای چه چیزی نوشته شده است.
• سایر اجزای پلت فرم - کار با شبکه، پایگاه های داده و سایر اجزای سیستم که توسط منطق تجاری استفاده می شوند.

بسته به کاربرد خاص، اندازه اجزای این لایه ها می تواند بسیار متفاوت باشد. به عنوان مثال، برنامه خبرخوان یک وب سایت با یک سرویس گیرنده VPN بسیار متفاوت خواهد بود.

خود توسعه را می توان به سه نوع تقسیم کرد: بومی، کاملاً کراس پلتفرم و ترکیبی.

توسعه بومی

در توسعه بومی، هر سه لایه با استفاده از مجموعه ای از ابزارها نوشته می شوند. بنابراین، آنها می توانند بدون هیچ گونه پیچیدگی اضافی با یکدیگر تعامل داشته باشند.

مزایای توسعه بومی:

توسعه ترکیبی

این نوع توسعه ترکیبی از هر دو رویکرد قبلی است. لایه منطق کسب و کار به عنوان یک جزء "قابل حمل" ساخته شده است، و UI و پلت فرم یکپارچه سازی با استفاده از ابزار استاندارد ایجاد می شود. چندین زبان برای نوشتن منطق عمومی وجود دارد: C/C++ (بالغ و قدرتمند)، KotlinNative (بسیار فعالانه توسعه یافته) و جاوا اسکریپت (کمترین معمول).

مزایای:

• مناسب ترین مؤلفه ها برای این امر بومی باقی می مانند.
• منطق مشترک یک بار ایجاد می شود.

ایرادات:

• اگر یک مؤلفه مشترک توسط یک تیم سیار ایجاد شود، در این صورت باید به زبان دیگری تخصص کسب کرد.
• هزینه ای برای ادغام اجزای چند پلتفرمی وجود دارد.

برای شروع با چه نوع توسعه ای بهتر است؟

برای پاسخ به این سوال، باید بدانید که چه نوع پروژه هایی را می خواهید ایجاد کنید. پروژه های کوچک می توانند صرفاً چند پلتفرمی باشند و این کاملاً توجیه خواهد شد. در اینجا من به شما توصیه می کنم که نگاه دقیق تری به فلاتر بیندازید.

اما امروز با توسعه بومی شروع می کنم. اولاً، امروزه بیشتر پروژه ها به صورت بومی ایجاد می شوند. این بدان معناست که شما فرصت بیشتری برای تغییر پروژه ها/شرکت ها خواهید داشت. ثانیاً، با گذشت زمان می‌توان به سمت توسعه پلتفرمی هیبریدی رفت. این به شما امکان می دهد در مسائل فنی رشد کنید.

ارتقاء Downgrade

به نظر من، بهتر است با بومی شروع کنید و سپس، اگر واقعاً می خواهید، به یک یا چند ابزار کراس پلتفرم مسلط شوید. یک استثنا ممکن است توسعه بازی ها باشد، زیرا آنها عمدتاً در Unity نوشته شده اند و این یک موتور متقابل پلتفرم است.

اگر در مورد مزایای توسعه بومی صحبت کنیم، برای یک برنامه نویس به معنای موانع کمتر و ابزارهای مختلف بیشتر برای کار کردن است. او همچنین منابع اطلاعاتی بیشتری برای حل مسائل پیچیده ای خواهد داشت که در فرآیند ایجاد یک برنامه به وجود می آیند - این راز نیست که نکات و ترفندهای بیشتری برای توسعه بومی در اینترنت نسبت به توسعه بین پلتفرمی وجود دارد.

برای کاربر نهایی، توسعه بومی به این معنی است که برنامه دارای رابط های آشنا و قابل پیش بینی و الگوهای رفتاری خواهد بود - مشروط بر اینکه برنامه مطابق با تمام راهنماها نوشته شده باشد.

یک برنامه کراس پلتفرم همیشه نمی تواند به طور کامل با راهنمای هر دو پلتفرم مطابقت داشته باشد و این می تواند مشکلات بیشتری را برای توسعه دهنده و کاربر ایجاد کند. ساده ترین مثال- وضعیت دکمه "بازگشت": در اندروید تقریبا در همه صفحه ها وجود دارد، در حالی که در iOS اینطور نیست. اگر بدون این دکمه یک برنامه متقابل پلتفرم بسازید، ممکن است برخی از کاربران اندروید احساس ناراحتی کنند.

همچنین باید به تفاوت هزینه های توسعه اشاره کرد. اگر پروژه ساده است، پس انتخاب توسعه بین پلتفرمی به شما امکان می دهد در بودجه صرفه جویی کنید، زیرا در واقع، شما محصولات جداگانه ای را برای پلتفرم های مختلف توسعه نمی دهید، بلکه یک محصول برای همه ایجاد می کنید. اما اگر پروژه رشد کند، ترازو شروع به کج شدن در جهت دیگر می کند و توسعه بومی ممکن است سودآورتر باشد.

در مورد سرعت برنامه ها، محصولات کراس پلتفرم کندتر هستند. به عنوان مثال، آنهایی که مبتنی بر فناوری های وب هستند یک مرورگر به عنوان یک لایه دارند که به طور قابل توجهی سرعت برنامه را کاهش می دهد.

ارتقاء Downgrade

انتخاب یک رویکرد بین پلتفرمی یا بومی در واقع به دو عامل بستگی دارد: ماهیت توسعه تلفن همراه که شخصاً می خواهید انجام دهید یا درخواست کارفرمایان که علاقه مند به همکاری با آنها هستید. بنابراین، برای مثال، اگر به Upwork (پلتفرمی برای یافتن متخصصان از راه دور برای پروژه‌ها و وظایف) نگاه کنیم، می‌توانیم شاهد برتری آشکار پیشنهادات در جهت Xamarin و React Native باشیم. مزایای اینجا واضح است: ارزان، سریع است و به شما امکان می دهد پروژه ها را در همه سیستم عامل ها به طور همزمان اجرا کنید. با این حال، اگر شرکت های بزرگ فناوری اطلاعات را با جستجوی کارمندان در خانه در نظر بگیریم، با وجود اینکه این نوع به زمان بیشتری نیاز دارد و گران تر است، تأکید قابل توجهی بر توسعه بومی وجود دارد.

در شرکت ما، توسعه بومی را اولویت بندی کرده و انتخاب می کنیم، زیرا به طراحان و توسعه دهندگان این امکان را می دهد که یک UX/UI روانتر و بصری تر ایجاد کنند. علاوه بر این، توسعه بومی کنترل انعطاف پذیرتری بر عملکردهای سیستم می دهد.

ارتقاء Downgrade

اگر می‌خواهید یک توسعه‌دهنده موبایل شوید، پاسخ واضح است: باید هر یک از محیط‌های توسعه بومی را انتخاب کنید و به Objective-C/Swift برای iOS یا Java/Kotlin برای اندروید تکیه کنید. در این صورت، تمام ویژگی های سیستم در خدمت شما هستند، تقریباً می توانید هر تفاوت ظریف را کنترل کنید.

اگر فقط می خواهید برنامه ای بنویسید که روی تلفن ها نیز کار کند، نمی توانید زیاد فکر کنید و انتخاب کنید که روح شما در چه چیزی بیشتر است یا در چه چیزی تجربه قابل توجهی دارید: C ++، React Native، Xamarin یا پانصد هزار چارچوب های JS برای توسعه بین پلتفرمی یا حتی به ساخت وب سایت های [پاسخگو] خود ادامه دهید.

صادقانه بگویم، من نسبت به ایده توسعه بین پلتفرمی در پلتفرم های مختلف (و متفاوت) مانند اندروید و iOS تردید دارم. هیچ یک از فروشندگان توسعه دهندگان "اشتباهی" را دوست ندارند که سعی می کنند همزمان روی دو صندلی بنشینند. همه در تلاشند تا برنامه نویسان را به ابزارها و محیط ها گره بزنند و در آینده قابل پیش بینی تمایلی به همگرایی وجود ندارد. چه می توانم بگویم، اپل در این مسابقه حتی OpenGL را رها کرد، کراس پلتفرم ترین کتابخانه ها بعد از Curl، اما اکنون آنها Metal خود را دارند، که به نظر می رسد همان کار را انجام می دهد، فقط بهتر و به زبانی دیگر.

از سوی دیگر، اغلب توسعه موبایل ایجاد دو برنامه کاربردی است که برای برخی از خدمات شبکه یکسان به نظر می رسند. مشتریان همیشه آماده پرداخت هزینه برای دو محصولی نیستند که کاملاً غیرقابل تشخیص به نظر می رسند، بنابراین تقاضا برای فناوری های توسعه چند پلتفرمی وجود دارد و مسلماً بسیار زیاد است. برنامه نویسان همچنین از صرفه جویی در پول مخالف نیستند ، به خصوص اگر می خواهند یک برنامه تلفن همراه بفروشند ، تمایلی به یادگیری Swift / Kotlin وجود ندارد ، اما JS / C # در حال حاضر در نوک انگشتان آنها است.

البته، توسعه بین پلتفرمی، تفاوت های ظریف غیر واضح زیادی را به همراه دارد. همه راه حل های جهانی مجبور به ساختن قلعه هایی در شن و ماسه هستند: یا با تکیه بر پیچیده و شکننده راه حل های تکنولوژیکی(مانند Xamarin)، یا در تلفن همراه موتورهای جاوا اسکریپتمانند React Native. در عین حال، فروشندگان پلتفرم حتی فکر نمی کنند از هیچ یک از راه حل ها پشتیبانی کنند، و هر به روز رسانی SDK بومی دردسر بزرگی برای هر چارچوب چند پلتفرمی است. ناگفته نماند ویژگی‌های خاص سیستم مانند دسترسی به دوربین، جاکلیدی یا حتی گالری عکس معمولی که همه سعی می‌کنند با درجات مختلفی از موفقیت دور شوند. توسعه‌دهندگانی که مسیر جهانی را انتخاب می‌کنند توسط چارچوب خود گروگان گرفته می‌شوند و اغلب توسعه‌ای که وعده صرفه‌جویی قابل‌توجهی می‌دهد به مبارزه با یک چنگک تبدیل می‌شود.

همچنین اغلب در راه‌حل‌های چند پلتفرمی، قربانی کردن چیزی که با عبارت تجربه کاربر (UX) نشان داده می‌شود، مرسوم است: بسیاری از چارچوب‌ها سعی می‌کنند از کنترل‌هایی استفاده کنند که تا حد امکان برای هر دو سیستم عمومی باشد، و تقریباً همیشه این راه‌حل برای همه به یک اندازه ناخوشایند است. . یا سرعت خود را کم کنید. یا از مد افتاده. یا باتری را خالی می کند. لیست را خودتان ادامه دهید.

برنامه های کاربردی متقابل پلتفرم جدا هستند، هسته های آنها در سطح پایین نوشته شده اند، رایج ترین برای همه سیستم عامل ها: در زبان هایی مانند C/C++. در این مورد، مرسوم است که استفاده از کدهایی را تعمیم دهیم که در خدمت منطق تجاری هستند و رابط برای هر پلتفرم جداگانه نوشته می شود. در حالت ایده‌آل، می‌توان از تکرار یک بخش مهم از برنامه جلوگیری کرد، در حالی که تجربه کاربری خاص هر پلتفرم حفظ می‌شود. با این حال، در زندگی واقعی، همه چیز پیچیده تر است. به عنوان مثال، دراپ باکس چندین سال متوالی سعی کرد با یک هسته سطح پایین زندگی کند، اما در نهایت به دلایل زیادی دست از کار کشید و اکنون از برنامه های پلتفرم بومی راضی است. من کسانی را که علاقه مند هستند به مقاله کنجکاو خود در این زمینه ارجاع می دهم.

به نظر من، صرفه جویی در فریمورک های چند پلتفرمی همیشه توهمی است. احتمالاً، در برخی از پروژه‌های بی‌اهمیت، که برنامه فقط نسخه‌ای از سایت اصلی است که برای موبایل فوق‌العاده بهینه شده است، رویکرد تعمیم‌یافته کار می‌کند. در موارد دیگر، شما خطر تکرار سرنوشت Dropbox را دارید. توصیه من این است که اگر می خواهید یک توسعه دهنده موبایل باشید، روی یادگیری این پلتفرم سرمایه گذاری کنید. آنها همیشه نتیجه خواهند داد، حتی اگر مجبور باشید در یک پروژه چند پلتفرمی شرکت کنید.

ارتقاء Downgrade

, توسعه دهنده ارشد نرم افزار، مرکز فناوری Accenture Tver

بازار برنامه های کاربردی تلفن همراه به طور فعال در حال توسعه است و مجموعه فناوری های توسعه آنها بر این اساس در حال رشد است. ابزارهای زیادی وجود دارد که می توانید از آنها استفاده کنید.

برای توسعه بومی در پلتفرم اندروید، جاوا یا پوششی روی JVM - Kotlin وجود دارد. برای iOS، می توانید از Objective-C یا یک پوشش روی آن استفاده کنید - Swift. اینها همه زبان های OOP هستند که از Smalltalk و C به ارث برده اند.

برای توسعه بین پلتفرمی، اکنون از Flutter از Google استفاده می شود، که برای آن باید Dart را بشناسید. یا React Native از فیسبوک.

برای یک توسعه دهنده مبتدی موبایل، به احتمال زیاد، تجربه گذشته و دانش زبان او عامل تعیین کننده خواهد بود. اگر جاوا اساس جعبه ابزار او باشد، می‌تواند با استفاده از همان جاوا یا کاتلین، دنیای توسعه موبایل را از طریق پلتفرم اندروید بسیار سریع‌تر یاد بگیرد.

در عین حال، Objective-C برای توسعه iOS از Smalltalk و همچنین جاوا بسیار گرفته است، بنابراین در صورت تمایل می توانید به نفع iOS انتخاب کنید. اما به خاطر داشته باشید که توسعه اندروید می‌تواند در ویندوز یا لینوکس انجام شود، اما iOS به MacOS X نیاز دارد. اما برای یک توسعه‌دهنده جاوا اسکریپت با دانش React، React Native واضح است که سریع‌ترین راه است. درست مانند توسعه دهندگان دارت، انتخاب به نفع Flutter خواهد بود.

پس از اینکه یک توسعه‌دهنده مبتدی ایده‌ای در مورد چگونگی توسعه موبایل پیدا کرد، مزایا و معایب مسیر انتخاب شده چیست، خودش تصمیم می‌گیرد که آیا با هر رویکردی کار کند یا مشکلات را با استفاده از راه‌حل‌های چند پلتفرمی حل کند.

این رویکرد مزایای خود را دارد: روش cross-platform این امکان را فراهم می کند که یک پروژه را با استفاده از منابع کمتر، کمی سریعتر در یک محیط تولیدی منتشر کنید. علاوه بر این، نگهداری آن آسان تر است. اما معایب آشکاری هم برای توسعه دهنده و هم برای کاربر دارد. برای مثال، یک توسعه‌دهنده نیازی به دانستن فناوری‌های بومی ندارد، اما دستورالعمل‌های پلتفرم باید در نظر گرفته شود، زیرا برنامه‌ای که طبق دستورالعمل‌های iOS نوشته شده باشد، برای کاربران اندروید و بالعکس مشکلاتی ایجاد می‌کند.

برنامه‌های چند پلتفرمی نمی‌توانند به سطح یکپارچه‌سازی دستگاه‌ها مانند برنامه‌های بومی دست یابند. یعنی اگر برنامه در مورد تعامل با دستگاهی مانند دوربین، تقویم یا استفاده از قدرت پردازشدستیابی به این هدف با استفاده از رویکرد بومی آسانتر است و سریعتر و پربارتر خواهد بود.

هنگام توسعه یک برنامه کاربردی بین پلتفرم، متخصصان قابلیت های چارچوب را در نظر می گیرند که محدودیت هایی را اعمال می کند. همچنین شایان ذکر است که برای توسعه یک محصول در فناوری های بومی، برای هر پلتفرم به متخصصان نیاز است.

اگر به عنوان یک فریلنسر کار می کنید یا هدف دارید که حداکثر تعداد دستگاه ها را با حداقل بودجه پوشش دهید، در صورت تمرکز بر روی توسعه بین پلتفرمی تمرکز کنید. راه حل های موبایلیا کار جلویی

مزایا و معایب اصلی توسعه بومی و چند پلتفرمی موبایل چیست؟ توسعه بومی خود گران است زیرا این شرکت نیاز به سرمایه گذاری در دو تیم - iOS و Android دارد. برای برنامه های ساده، سرعت توسعه Flutter / React Native سریعتر است.

اما نکته مثبت این است که زیرساخت از قبل شکل گرفته و قابل درک است. شما به هر منبع دستگاهی دسترسی دارید و می توانید تحت آن توسعه دهید ساعت هوشمند، اتومبیل و موارد دیگر.

توسعه بین پلتفرمی نیز چیز جالبی است. اما هنوز در بازار کار فناوری اطلاعات روسیه توسعه زیادی پیدا نکرده است. متخصصان معقول - روی انگشتان دست حساب کنید. زیرساخت چارچوب جوان است، اما وضعیت به تدریج به سمت بهتر شدن تغییر می کند. این توسعه امکان نوشتن را برای چندین دستگاه به طور همزمان فراهم می کند. حتی اگر مثلاً در فلاتر بنویسید، به راحتی با کدهای بومی ادغام می شود.

ارتقاء Downgrade

هدف توسعه بین پلتفرمی نتایج سریع و صرفه جویی قابل توجه در بودجه است - ما یک کد برای همه دستگاه ها می نویسیم. حوزه های کاربرد آن یا راه حلی برای استفاده داخلی است، جایی که قابلیت استفاده از محصول چندان مهم نیست، و عملکرد نقش غالب را ایفا می کند، یا ایجاد یک پروژه "پایلوت" سریع، زمانی که مشتری نیاز به نشان دادن اصل یا ایده برنامه علاوه بر این، اگر درک دقیقی در مورد دستگاه وجود نداشته باشد که نمونه اولیه شما با کدام سیستم عامل مشاهده می شود، توسعه بین پلتفرم راه حل است. با این حال، باید از قبل بدانید که همه دستگاه‌ها معماری متفاوتی دارند، بنابراین از نظر فیزیکی، اجرای یک برنامه با کیفیت بالا تنها بر روی یک کد بین پلتفرمی تقریبا غیرممکن است. در سناریوهای پیچیده، باید کد بومی بنویسید. علاوه بر این، توسعه بین پلتفرمی به دلیل ویژگی خاص خود هزینه هایی را متحمل می شود که اجازه نمی دهد برنامه تا حد امکان کارآمد باشد. این قابل درک است، در این مورد، کد میانی کراس پلتفرم باید برای هر یک از پلتفرم ها ترجمه شود، که به دلیل این واقعیت که علاوه بر کد عملکردی، محیط اجرای آن را نیز در بر می گیرد، برنامه را "سنگین" می کند.

نظر دیگری بدهید

همه چیز روشن است، نتیجه گیری را نشان دهید

بنابراین کدام رویکرد توسعه را باید در پیش بگیرید؟

همه چیز به وظیفه بستگی دارد. اگر نیاز به نوشتن یک نمونه اولیه برنامه برای چندین پلتفرم یا نسخه موبایلسایت، می توانید به چارچوب های چند پلتفرمی نگاه کنید. با استفاده از آن‌ها، احتمالاً سریع‌تر از برنامه‌نویسی بومی برنامه‌نویسی می‌کنید، به خصوص اگر روی چارچوبی شبیه به ابزار معمول خود مانند React Native کار می‌کنید.

از سوی دیگر، جهانی بودن اپلیکیشن های چند پلتفرمی باید به نوعی جبران شود. در جایی یک عنصر رابط "غیر بومی" ظاهر می شود، در جایی تعامل با سیستم بدتر است، در جایی سرعت کار کاهش می یابد و غیره. علیرغم اینکه توسعه بومی به منابع بیشتری نیاز دارد، بسیاری از شرکت ها آن را ترجیح می دهند، زیرا در خروجی محصولی با ثبات تر و ظاهری بومی تر.

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

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

توسعه کراس پلتفرم به شما امکان می دهد یک برنامه تلفن همراه بسازید که به طور همزمان در محیط های iOS و Android کار کند. این یک جایگزین بودجه برای ایجاد یک برنامه کاربردی برای هر سیستم عامل به طور جداگانه است.

ویژگی های توسعه متقابل پلت فرم

توسعه یک اپلیکیشن برای پلتفرم های مختلف در عین حال خوب و بد است. خوب، زیرا می توان آن را سریعتر و ارزانتر از چندین برنامه برای هر سیستم عامل انجام داد. و این بد است، زیرا مصالحه در عملکرد برنامه منعکس می شود.

این ویژگی ها باید قبل از شروع پروژه در نظر گرفته شوند:

• در یک محیط کراس پلتفرم، کد یک بار نوشته می شود. برای اینکه برنامه روی یک سیستم عامل متفاوت کار کند، کد به زبان برنامه نویسی دیگری ترجمه می شود. زمان و پول صرف شده برای توسعه 1.5 برابر کمتر است.
• ممکن است برنامه ها به درستی کار نکنند.در توسعه کراس پلتفرم، در نظر گرفتن تمام تفاوت های ظریف کار با معماری هر سیستم عامل غیرممکن است، بنابراین برنامه ها می توانند کندتر از برنامه هایی که به طور خاص برای iOS یا Android طراحی شده اند اجرا شوند.
• الزامات رابط و طراحی برای عناصر از سیستم عاملی به سیستم عامل دیگر متفاوت است.. به عنوان مثال، در iOS مانند اندروید، دکمه بازگشت وجود ندارد. هنگام توسعه یک طراحی یکپارچه، باید این نکته را در نظر گرفت: در iOS، دکمه یا باقی می ماند، اما کار نمی کند، یا باید به صورت دستی قطع شود، و این کار اضافی با کد است.

اکثر خطاهای انتقال از یک پلت فرم به پلتفرم دیگر به صورت دستی رفع می شوند، اما حل کامل مشکلات مربوط به انطباق با یک سیستم عامل "غیر بومی" غیرممکن است.

پس توسعه بین پلتفرمی بد است؟

نه، توسعه بین پلتفرمی خوب است تا زمانی که از آن چیزی بیش از آنچه که می تواند بخواهد نخواهید.

این گزینه در موارد زیر قابل انتخاب است:

• پوشش تمام سیستم عامل ها با بودجه محدود.اگر یک مخاطب هدفبه طور فعال تر با استفاده از iOS یا Android، می توانید با یک برنامه بومی برای یک سیستم عامل شروع کنید. اگر حداکثر پوشش فوراً مهم است، بهتر است گزینه cross-platform را انتخاب کنید.
• طاقچه را بررسی کنید. اگر ایده امیدوار کننده ای وجود داشته باشد، اما اطمینانی وجود ندارد که کار خواهد کرد، سرمایه گذاری فوری بودجه زیادی در توسعه خطرناک است. منطقی است که با توسعه بین پلتفرمی شروع کنید، واکنش های کاربران را مطالعه کنید و بر اساس آن تصمیمات استراتژیک بگیرید.
• برنامه از انیمیشن پیچیده استفاده نمی کند و محاسباتی را انجام نمی دهد.این عملیات به طور جدی دستگاه را بارگذاری می کند و برنامه چند پلتفرمی برای استفاده کامل از منابع یک پلت فرم خاص بهینه نشده است.
• این برنامه فقط از عملکردهای اصلی دستگاه استفاده می کند. نمایش اطلاعات، آپلود فایل ها، استفاده از موقعیت جغرافیایی، ثبت سفارش - یک برنامه چند پلتفرمی می تواند همه اینها را مدیریت کند. یکپارچه سازی عمیق تری از قابلیت های دستگاه مورد نیاز است - شما باید توسعه بومی را انتخاب کنید.
• اپلیکیشن شرکتی برای کارمنداناگر برنامه برای کارهای داخلی باریک توسعه داده شود و افراد از طریق گجت های شخصی با آن کار کنند، یک اپلیکیشن cross-platform بهترین گزینه خواهد بود.

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