استفاده از Swift با WinUI در ویندوز

یک ابزار منبع باز جدید از شرکت مرورگر ما را در مسیر آوردن برنامه های Swift از iOS و macOS به ویندوز قرار می دهد.

شاید فکر کنید که Swift اپل یک زبان برنامه نویسی فقط برای macOS و iOS است. این یک نتیجه گیری طبیعی است، زیرا سوئیفت ارتباط نزدیکی با محیط توسعه Xcode خود اپل دارد. اما یک بخش از داستان سوئیفت اغلب نادیده گرفته می شود: سوئیفت یک زبان برنامه نویسی چند پلتفرمی است که از لینوکس، اندروید و ویندوز پشتیبانی می کند.

بیشتر سردرگمی ناشی از ارائه ابزارهای رابط کاربری اپل فقط برای پلتفرم های خودش است. برای پلتفرم‌های دیگر، سوئیفت به عنوان یک زبان برنامه‌نویسی سیستم‌های قابل حمل در نظر گرفته شده است که به شما اجازه می‌دهد شما می‌توانید منطق کسب‌وکار را از دستگاه‌های موبایل و دسک‌تاپ به فضای ابری بیاورید و APIهایی را برای قسمت‌های جلویی وب اضافه کنید. اگر UI می‌خواهید، به مرورگر وب نیاز دارید، زیرا تعدادی چارچوب وب برای Swift وجود دارد که عمدتاً نسخه لینوکس را هدف قرار می‌دهند.

استفاده از Swift در ویندوز

یکی از مزایای Swift به‌عنوان یک زبان این است که جایگزین امن‌تری برای C، با بسیاری از ویژگی‌های Objective C ارائه می‌کند. برخلاف بسیاری از زبان‌های کامپایل‌شده، Swift از استفاده از یک زبان مبتنی بر REPL پشتیبانی می‌کند. محیط اشکال زدایی و تست می توانید کد را قبل از کامپایل ارزیابی کنید و از زمین های بازی Xcode برای کشف ساختارهای پیچیده تر استفاده کنید. این رویکرد «اشکال‌زدایی در حین کدنویسی» به منظور بهبود بهره‌وری توسعه‌دهنده، تبدیل کردن اشکال‌زدایی به بخشی از جریان عادی شما و جلوگیری از له کردن خطا در متن کدی که می‌نویسید، در نظر گرفته شده است.

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

بازگشت به “پل” ویندوز ۱۰

در حالی که ما نمی‌توانیم انتظار داشته باشیم که Swift برای Windows کل تجربه کاربری macOS یا iOS را پیاده‌سازی کند، داشتن نوعی ابزار UI، پورت انواع برنامه‌ها و ابزارهای macOS را به ویندوز بسیار آسان‌تر می‌کند. مایکروسافت چیزی شبیه به این را برای Objective C به عنوان بخشی از پروژه “پل” ویندوز ۱۰ خود در Project Islandwood (اکنون یک پروژه منبع باز در GitHub). WinObjC، همانطور که در نهایت نامگذاری شد، پروژه های Xcode موجود را می گیرد و آنها را به پروژه های ویژوال استودیو تبدیل می کند، نقشه برداری معمول کنترل‌ها و سرویس‌های مشابه ویندوز آنها.

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

Windows App SDK و پیش‌بینی‌های زبان

مایکروسافت بیشتر دهه گذشته را صرف تفکر و تجدید نظر در استراتژی UI خود کرده است. ابتدا WinRT ویندوز ۸ با کنترل های مترو آن بود. این به پلتفرم ویندوز و کتابخانه رابط کاربری ویندوز، WinUI تبدیل شد. همانطور که داستان اصلی توسعه ویندوز تغییر کرد، WinUI با آن تکامل یافت و امروز ما را به WinUI 3 رساند. ارسال به عنوان بخشی از Windows App SDK، WinUI 3 کنترل‌های مدرنی را برای هر جایی که ویندوز اجرا می‌شود ارائه می‌دهد.

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

در حالی که WinUI به عنوان ابزاری برای دات نت شناخته می شود، اما به سایر محیط های ویندوز از جمله C++ منتقل شده است. برگزاری زبان C++ WinRT یک کتابخانه هدر فایل ارائه می‌کند که به شما امکان می‌دهد از APIهای Windows App SDK از هر استانداردی که مطابق با استانداردها باشد استفاده کنید. کامپایلر C++، مانند LLVM’s Clang یا حتی GCC.

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

WinUI در Swift در ویندوز

چند هفته پیش توییتی از میگل دی ایکازا، یکی از خالقان پروژه مونو، به من اشاره کرد که توسط The Browser Company برای استفاده از ابزار CppWinRt برای ساخت مجموعه ای از پیش‌بینی‌های زبانی برای افزودن پشتیبانی WinUI به Swift. این به آن‌ها اجازه می‌دهد Arc مرورگر جدید و ساخته‌شده از پایه خود را به ویندوز بیاورند، بدون اینکه نیازی به بازنویسی کامل کد Swift موجود خود داشته باشند.

این یک نیاز مهم برای یک تیم کوچک است. اگر تنها چیزی که باید تغییر دهید رابط کاربری است، پس نیازی نیست که توسعه هسته را دوچندان کنید و مجبور باشید از یک مدل برنامه نویسی به مدل دیگر ترجمه کنید، با خطر افزایش سطح حمله. درعوض، می‌توانید مانند The Browser Company، روی ساخت جایگزینی برای Chromium، Gecko و WebKit تمرکز کنید که هم با استانداردهای وب همگام باشد و هم ویژگی‌ها و سرعت مورد انتظار کاربران را ارائه دهد. این مستلزم آن است که هر نسخه برای هر پلتفرم به طور همزمان منتشر شود.

تیم سازنده نسخه ویندوز مرورگر Arc از Swift با COM استفاده کرده است، بنابراین داشتن پیوندهای زبانی بر اساس ابزار C++ WinRT قدم بزرگی نیست. کد مورد نیاز برای ارائه یک رابط کاربری ویندوز با این اتصالات برای هر کسی که برنامه های کاربردی ویندوز را با استفاده از یک زبان مدرن ساخته است آشنا به نظر می رسد. سینتکس Swift خالص است و تماس‌ها برای افزودن مؤلفه‌های رابط کاربری به برنامه شما بسیار شبیه به مواردی است که برای ارائه تجربه iOS یا macOS استفاده می‌شود.

از Swift به WinUI از طریق WinRT

از آنجایی که WinUI از رابط های WinRT استفاده می کند، طرح Swift بر اساس تعاریف رابط WinRT ساخته می شود و C IDL (زبان تعریف رابط) را به فراخوانی تابع ترجمه می کند. در حالی که می‌توانید مستقیماً از سوی Swift با API کار کنید و از قابلیت‌های interop آن استفاده کنید، کار به این شکل عملی نیست. این رویکردی است که به جای ارائه یک مسیر ساده برای افزودن یک رابط کاربری ویندوز به عنوان یک ساخت جایگزین برای پروژه سوئیفت، پیچیدگی می‌افزاید.

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

در حالی که کار بین پلتفرمی مایکروسافت به طور طبیعی بر انتقال کد ویندوز به پلتفرم‌های دیگر متمرکز است، دیدن این که شرکت مرورگر رویکرد متفاوتی دارد، بسیار خوب است. مانند کار گوگل با Flutter، که برنامه های ساخته شده برای یک پلتفرم طراحی شده برای اندروید را به سایر سیستم عامل ها می آورد، این گامی به سوی انجام همین کار برای iOS و macOS است. مهم است که به یاد داشته باشید که Windows App SDK بسیار بیشتر از WinUI 3 است، بنابراین در حالی که زبان swift-winrt حاصل می‌شود پیش بینی ها ابزار مفیدی هستند، آنها تنها بخشی از آنچه برای انتقال کد iOS به اکوسیستم دیگر نیاز است.

مراحل بعدی

داشتن یک روش کاربردی برای خارج کردن کد سوئیفت از iOS و macOS چیز خوبی است و توانایی پورت کردن آن به WinUI و Windows می‌تواند به توسعه‌دهندگان امکان دسترسی به بازار دیگری را بدهد، بازاری که قبلاً یک فروشگاه برنامه و مجموعه‌ای از ابزارهای ساخت میزبانی ابری که می‌توانند فرآیند انتقال از درخواست کشش به در دسترس بودن فروشگاه را خودکار کنند.

آنچه در مرحله بعد به آن نیاز داریم این است که کسی ابزارهای قدیمی Project Islandwood یا شاید برخی از کارهای Xamarin را بگیرد و از آن برای ادغام APIهای ویندوز بیشتر در برنامه های Swift استفاده کند که بر اساس میراث Objective-C Swift است. پس از همه، همه آنها منبع باز هستند. مهم نیست که چه کسی این کار را انجام می دهد، ابزار جدید شرکت مرورگر پیشرفت قطعی در ساختن دنیای بازتر و بین پلتفرمی است. جالب است که ببینیم سویفت در ویندوز از اینجا به کجا می رود.