صاحبِ یک کلینیکِ دندانپزشکی در بلوارِ وکیلآباد مشهد به تیمِ توسعهی اپلیکیشنِ آنوبز پیام میدهد: «میخواهیم هم اپلیکیشنِ اندروید داشته باشیم هم آیفون، ولی نه بودجهمان کششِ دو تیمِ جدا را دارد نه وقتمان. اسمِ فلاتر را زیاد شنیدهایم، ولی نمیدانیم دقیقاً چیست.» فلاتر یک فریمورکِ متنبازِ گوگل است که با یک کدِ پایه، هم اپلیکیشنِ اندروید میسازد هم iOS — و برخلافِ ابزارهای قدیمیِ کراسپلتفرم که در واقع یک صفحهی وب را داخلِ یک قاب نمایش میدادند، خروجیِ فلاتر مستقیم به کدِ نیتیوِ هر پلتفرم کامپایل میشود.
همین تفاوت است که فلاتر را از نسلِ قبلیِ ابزارهای کراسپلتفرم جدا میکند. ولی همینجا هم یک هشدار لازم است: فلاتر معجزه نیست و برای هر پروژهای بهترین انتخاب نیست. در ادامه هم چیزی که واقعاً از آن میگیرید را میگوییم، هم جایی که هنوز نیتیو برنده است.
فلاتر دقیقاً چیست و چطور با نیتیوِ دو-پروژهای فرق دارد؟
برنامهنویسیِ فلاتر با زبانی بهنامِ Dart انجام میشود؛ زبانی که خودِ گوگل برایش ساخته و توسعه داده. رابطِ کاربری از واحدهای کوچکی بهنامِ ویجت ساخته میشود — یک دکمه، یک کارت، یک لیست، همه ویجتاند و کنارِ هم ترکیب میشوند تا صفحهی نهایی شکل بگیرد. این ویجتها را میشود کاملاً مطابقِ هویتِ بصریِ برندِ شما شخصیسازی کرد؛ دقیقاً همانجایی که طراحیِ رابطِ کاربری با توسعه تلاقی میکند.
نکتهی مهم اینجاست: این ویجتها به اجزای رابطِ کاربریِ خودِ اندروید یا iOS متکی نیستند؛ فلاتر موتورِ رندرینگِ خودش را دارد و مستقیم روی صفحه ترسیم میکند.
نتیجه چیست؟ ظاهرِ اپلیکیشن روی هر دو پلتفرم دقیقاً یکسان میماند، نه شبیه، عینِ هم.
نسلِ قبلیِ ابزارهای کراسپلتفرم — مثلِ فونگپ یا کوردووا — در عمل یک صفحهی وب را داخلِ یک قابِ اپلیکیشن نشان میدادند؛ کند بود و حسِ اپلیکیشنِ واقعی نداشت. فلاتر این مشکل را حل کرده: کدِ Dart با کامپایلِ ازپیش (AOT) به کدِ نیتیوِ ARM تبدیل میشود، دقیقاً همانطور که یک اپلیکیشنِ کاتلین یا سوییفت کامپایل میشود. اگر دنبالِ مقایسهی کاملِ مسیرهای مختلفِ ساختِ اپلیکیشن هستید — نیتیو، کراسپلتفرم و PWA — این راهنما هر سه را کنارِ هم گذاشته است.
با فلاتر واقعاً چقدر در زمان و هزینهی توسعه صرفهجویی میشود؟
پاسخِ صادقانه این است که به پروژه بستگی دارد، ولی مکانیزمِ صرفهجویی روشن است. وقتی یک کدِ پایه هم اندروید میسازد هم iOS، یک تیم آن را مینویسد، یک تیم تستش میکند و یک تیم نگهداریاش میکند — نه دو تیمِ موازی که باید هر تغییر را دوبار پیادهسازی کنند.
همین منطق در نگهداریِ بعد از تحویل هم ادامه دارد. یک باگ، یک اصلاح؛ یک قابلیتِ تازه، یکبار کدنویسی. برای کسبوکارهایی که بودجهی محدود دارند ولی نمیخواهند از یکی از دو پلتفرم صرفنظر کنند، این تفاوت در درازمدت محسوستر از روزِ اولِ پروژه است.
ابزارِ دیگری هم به سرعتِ توسعه کمک میکند: قابلیتِ Hot Reload. توسعهدهنده کد را عوض میکند و همان لحظه، بدونِ بستن و بازکردنِ اپلیکیشن، نتیجه را روی صفحه میبیند.
برای تفکیکِ دقیقِ عواملی که هزینهی نهاییِ ساختِ اپلیکیشن — با فلاتر یا هر مسیرِ دیگر — را تعیین میکنند، این تفکیکِ واقعیِ قیمت را بخوانید؛ چون آنوبز رقمِ ثابت اعلام نمیکند و هر برآورد باید بعدِ شناختِ دقیقِ دامنهی پروژهی شما مشخص شود، نه قبلش.
فلاتر چه محدودیتهایی دارد که باید از قبل بدانید؟
اکوسیستمِ پلاگین و جامعهی توسعهدهندگانِ فلاتر بزرگ است، ولی همهچیز را پوشش نمیدهد. وقتی یک قابلیتِ بسیار تازهی سیستمعامل منتشر میشود — یک API جدیدِ اپل یا گوگل — معمولاً اول در نیتیو در دسترس است و بعد پلاگینِ فلاترش میرسد؛ گاهی این فاصله چند هفته است، گاهی بیشتر.
دستهی دومِ محدودیت، پردازشهای سنگینِ سختافزاری است: بینایی ماشین با پردازشِ لحظهای روی خودِ گوشی، گرافیکِ سهبعدیِ پیچیده، یا دسترسیِ عمیق به سنسورهای اختصاصی. در این موارد، یا باید سراغِ کدِ نیتیو رفت یا از پلتفرمچنلِ فلاتر — پُلی که Dart را به کدِ نیتیوِ اندروید و iOS وصل میکند — استفاده کرد. پلتفرمچنل کار میکند، ولی دیگر «یک کد برای دو پلتفرم» بهمعنایِ کاملش نیست؛ بخشی از منطق باز هم دوبار نوشته میشود.
عملکردِ اپلیکیشنِ فلاتر واقعاً به نیتیو نزدیک است یا فقط شعار است؟
برای اکثرِ اپلیکیشنهای کسبوکاری — فروشگاهی، نوبتدهی، پنلِ مدیریتی، سامانهی رزرو — کاربرِ نهایی هیچ تفاوتی حس نمیکند. رندرینگِ فلاتر روی گرافیکِ خودِ دستگاه اجرا میشود، نه روی یک لایهی وب. اسکرول، انیمیشن و واکنشِ لمسی همان حسِ نیتیو را میدهد.
جایی که فرق ظاهر میشود، بارِ پردازشیِ فوقسنگین است — بازیهای سهبعدیِ گرافیکِ بالا یا اپهایی که باید هر فریم را در کسری از ثانیه با الگوریتمِ بینایی ماشین تحلیل کنند.
در پروژهی سوپراَپِ شهرداریِ بردسکن، همین مرزِ دقیق بود که یک تصمیمِ فنی را عوض کرد — نه اینکه فلاتر ضعیف باشد، بلکه یک قابلیتِ خاص، سختافزار را مستقیم میخواست.
تجربهی واقعی: چرا برای سوپراَپِ شهرداریِ بردسکن فلاتر را انتخاب کردیم؟
سوپراَپِ شهرداریِ بردسکن یک بسترِ یکپارچه برای خدماتِ شهری است: خدماتِ شهروندی، شهرسازی، گردشگری، گزارشهای مردمی، پرداخت و پیگیریِ درخواستها، بههمراهِ دو قابلیتِ هوشمند بهنامِ «چشمِ شهر» و «هوشیارِ ضوابط». دهها ماژول، یک اپلیکیشن. با فلاتر جلو رفتیم چون معماریِ ماژولارش اجازه میداد بدونِ بازنویسیِ کدِ قبلی، خدماتِ تازه اضافه شود — و چون قرار بود همان روزِ اول هم اندروید پوشش داده شود هم iOS، بدونِ اینکه شهروندانِ صاحبِ هرکدام از این دو پلتفرم، تجربهای درجهدو بگیرند.
بیشترِ ماژولها — ثبتِ درخواست، پیگیری، پرداخت، رزروِ نوبت — دقیقاً همان کارهای استانداردِ یک اپلیکیشنِ کسبوکاریاند که ساختِ اپلیکیشن با فلاتر برایشان طراحی شده. نمونهی کاملِ این پروژه و چند نمونهکارِ دیگرِ تیم را میتوانید در نمونهکارهای آنوبز ببینید.
چه پروژههایی اصلاً مناسبِ فلاتر نیستند؟
قبل از انتخابِ فلاتر، این چکلیست را با پروژهی خودتان مقایسه کنید:
| نوعِ پروژه | فلاتر گزینهی خوبی است؟ |
|---|---|
| اپلیکیشنِ فروشگاهی، نوبتدهی، پنلِ مدیریتی، سامانهی رزرو | بله — دقیقاً همان چیزی که فلاتر برایش طراحی شده |
| اپلیکیشنِ محتوایی یا معرفی با رابطِ کاربریِ سفارشی | بله — سرعتِ توسعه و یکپارچگیِ ظاهر مزیتِ اصلی است |
| بازیِ سهبعدیِ گرافیکِ بالا یا اپِ واقعیتِ افزوده | خیر — موتورهای اختصاصیِ بازی یا نیتیو مناسبترند |
| بینایی ماشین با پردازشِ لحظهایِ سنگین روی خودِ گوشی | خیر، یا فقط با پلتفرمچنل و کدِ نیتیوِ اضافه |
| اپلیکیشنی که همان روزِ انتشارِ نسخهی تازهی سیستمعامل باید از جدیدترین API استفاده کند | خیر — تأخیرِ رسیدنِ پلاگین ریسک دارد |
اگر پروژهی شما در ردیفهای «بله» قرار میگیرد، فلاتر معمولاً هم زمانِ توسعه را کوتاهتر میکند هم نگهداریِ بعدی را سادهتر. اگر در ردیفهای «خیر» است، پیشنهادِ صادقانهی ما نیتیوِ جداگانه یا ترکیبِ فلاتر با پلتفرمچنل است، نه چسباندنِ زورکیِ یک ابزار به پروژهای که برایش ساخته نشده.
سؤالاتِ پرتکرار دربارهی فلاتر
آیا فلاتر برای اپلیکیشنهای بزرگ و پرماژول مناسب است؟
بله، مادامیکه ماژولها به سراغِ کارهای استانداردِ کسبوکاری بروند نه پردازشِ سنگینِ سختافزاری. سوپراَپِ شهرداریِ بردسکن، با دهها ماژولِ خدماتِ شهری، نمونهی همین موضوع در پروژههای آنوبز در مشهد است؛ معماریِ ماژولار اجازه میدهد خدماتِ تازه بدونِ بازنویسیِ بخشهای قبلی اضافه شوند.
تفاوتِ اصلیِ فلاتر با ریاکتنیتیو در چیست؟
هر دو کراسپلتفرماند، ولی معماریشان فرق دارد: ریاکتنیتیو برای رندرِ رابطِ کاربری به اجزای نیتیوِ خودِ سیستمعامل متکی است، درحالیکه فلاتر موتورِ رندرینگِ خودش را دارد و مستقل از ویجتهای سیستمعامل ترسیم میکند. نتیجه این است که ظاهرِ اپلیکیشنِ فلاتر روی اندروید و iOS دقیقاً یکسان میماند، درحالیکه ریاکتنیتیو بیشتر به سبکِ بومیِ هر پلتفرم نزدیک میشود. کدام بهتر است به هدفِ پروژه بستگی دارد، نه به محبوبیت.
هزینه یا مدتِ زمانِ ساختِ اپلیکیشن با فلاتر چقدر است؟
آنوبز رقمِ ثابت یا مدتِ زمانِ ازپیشتعیینشده منتشر نمیکند، چون این عدد به دامنهی واقعیِ پروژه — تعدادِ صفحه، یکپارچهسازی با سامانههای دیگر، سطحِ پیچیدگیِ طراحی — بستگی دارد. مشاوره و برآوردِ اولیه در آنوبز مشهد رایگان است و بعد از شناختِ دقیقِ نیازِ شما، شفاف و بدونِ هزینهی پنهان اعلام میشود.
تجربهی خودم توی همین پروژهی سوپراَپِ بردسکن یک درسِ مشخص داد. برای قابلیتِ «چشمِ شهر» اولش فکر میکردم پلاگینهای آمادهی فلاتر برای پردازشِ تصویر کافیاند و میشود همهچیز را با همان یک کدِ پایه جلو برد. وقتی به سطحِ دقتی که این قابلیت لازم داشت رسیدیم، دیدم پلاگینها آنقدر که نیاز بود عمیق نبودند. خودم نشستم و یک پلتفرمچنل نوشتم که پردازشِ تصویر را به کدِ نیتیوِ اندروید و iOS بسپارد و فقط نتیجهاش را به رابطِ کاربریِ فلاتر برگرداند. راستش اگر از اول همین تصمیم را میگرفتم چند روزِ کمتری صرف میکردم؛ ولی همان اشتباه بود که مرزِ دقیقِ فلاتر را به من نشان داد — و همین مرز الان معیارِ من برای تصمیمِ هر پروژهی تازهی آنوبز در مشهد است.
اگر برای پروژهی بعدیِ کسبوکارتان بینِ فلاتر، نیتیو یا مسیرِ دیگری ماندهاید، بهتر است این تصمیم را بر اساسِ نیازِ واقعیِ پروژه بگیرید نه شنیدهها. تیمِ آنوبز در مشهد آماده است دامنهی پروژهی شما را رایگان بررسی کند و مسیرِ فنیِ مناسب را پیشنهاد بدهد — از صفحهی تماس شروع کنید.
