اس سال کے شروع میں میں نے فلٹر میں Decoupling Material اور Cupertino شائع کیا۔ اس کتاب کا احاطہ کیا گیا ہے جو اس وقت ایک پیش نظارہ خصوصیت تھی۔ فلٹر کا یہ منصوبہ تھا کہ وہ میٹریل اور کپرٹینو ڈیزائن لائبریریوں کو بنیادی SDK سے pub.dev میں اسٹینڈ تنہا پیکجوں میں الگ کرے۔
اس وقت، خصوصیات پیش نظارہ میں تھیں، منتقلی کے ٹولز نامکمل تھے، اور ایکو سسٹم نے کام نہیں کیا تھا۔ یہ ایک سمت سیکشن تھا جس نے وضاحت کی کہ فلٹر کہاں جا رہا ہے اور کیوں۔
یہ 12 اگست 2026 کو ریلیز ہونے والے Flutter 3.47 کے ساتھ مکمل طور پر بدل گیا ہے۔
اسٹینڈ material_ui اور cupertino_ui پیکیج ورژن 1.0 تک پہنچ گیا ہے۔ نقل مکانی کا آلہ تیار ہے۔ ایک ہم آہنگ پل بھیج دیا جائے گا۔ پرانی درآمدات کے لیے حمایت کی فرسودگی کی گھڑی باضابطہ طور پر شروع ہو گئی ہے۔
یہ اب کوئی پیش نظارہ یا ہدایات نہیں ہے۔ یہ موجودہ ہے اور تمام فلٹر ڈویلپرز کو متاثر کرتا ہے۔
یہ کتابچہ ان تمام تبدیلیوں کے لیے ایک مکمل عملی رہنما ہے۔ ہم اس بات کا احاطہ کریں گے کہ فلٹر ٹیم نے یہ آرکیٹیکچرل فیصلے کیوں کیے، نئے پیکجز میں کیا ہے اور وہ موجودہ درآمدات سے کیسے مختلف ہیں، خود کار طریقے سے اور دستی طور پر کیسے منتقل کیا جائے، انحصار کو کیسے ہینڈل کیا جائے جو ابھی تک منتقل نہیں ہوئے ہیں، لوکلائزیشن فی الحال کیسے کام کرتی ہے، آپ کے پروجیکٹ میں موجود ویجٹس کا کیا ہوتا ہے، اور مکمل فرسودگی کا وقت آپ کو بالکل ٹھیک طریقے سے معلوم ہو جائے گا جب آپ چیزوں کو پرانا کر دیں گے۔
اگر آپ ہمارا پچھلا مضمون پڑھتے ہیں، تو یہ وہ فالو اپ ہے جس کا آپ انتظار کر رہے ہیں۔ اگر آپ اس تازگی والی جگہ پر آتے ہیں تو آپ کی ضرورت کی ہر چیز یہاں موجود ہے۔
انڈیکس
شرطیں
اس گائیڈ کے ساتھ آگے بڑھنے سے پہلے، یقینی بنائیں کہ درج ذیل درست ہیں:
فلٹر 3.47 اور اس سے زیادہ: یہ گائیڈ ان خصوصیات کا احاطہ کرتا ہے جو اس ریلیز کے لیے منفرد ہیں۔ چلائیں flutter upgrade جب آپ ٹرمینل پر پہنچیں تو براہ کرم چیک کریں۔ flutter --version.
Dart SDK 3.10 اور اس سے زیادہ: فلٹر 3.47 کے ساتھ ڈارٹ 3.10 جہاز۔ چیک کریں dart --version.
موجودہ فلٹر پروجیکٹ یا سینڈ باکس کے لیے منتقلی کے مراحل پر عمل کرنے کی خواہش: نقل مکانی کے تصورات تمام Flutter ایپس پر لاگو ہوتے ہیں، سائز سے قطع نظر۔
فلٹر پروجیکٹ کی ساخت کا بنیادی علم: آپ کو کیا جاننے کی ضرورت ہے۔ pubspec.yaml وہ کیا ہے؟ flutter pub get ڈارٹ کا درآمدی بیان کیسا لگتا ہے؟
ڈیکپلنگ کی خصوصیات کے بارے میں پہلے سے علم کی ضرورت نہیں ہے۔ یہ گائیڈ شروع سے ہر چیز کی وضاحت کرتا ہے۔ تاہم، Flutter میں Decoupling Material اور Cupertino کو پہلے پڑھنا تبدیلی کے محرک کے بارے میں مفید پس منظر کی معلومات فراہم کرے گا۔
کیا بدلا ہے اور یہ کیوں اہم ہے: بڑی تصویر
فلٹر 3.47 سے پہلے، میں نے لکھا: import 'package:flutter/material.dart'میں فلٹر SDK میں براہ راست بیک کی گئی ایک میٹریل ویجیٹ لائبریری درآمد کر رہا تھا۔ آپ میٹریل ویجٹ کا تازہ ترین ورژن حاصل نہیں کر پائیں گے جب تک کہ آپ پورے فلٹر SDK کو اپ گریڈ نہیں کر لیتے۔ آپ کے پاس اس معاملے میں کوئی چارہ نہیں تھا۔
فلٹر 3.47 کے بعد سے، میٹریل اور کپرٹینو کو pub.dev میں ان کے اپنے پیکجز کے طور پر شامل کیا گیا ہے۔ material_ui اور cupertino_ui. آپ فلٹر SDK سے آزادانہ طور پر اپ گریڈ کر سکتے ہیں۔ وہ اپنے ہفتہ وار شیڈول کے مطابق بگ فکسز اور نئے اجزاء فراہم کرتے ہیں۔ اور Flutter SDK اب ترقیاتی روڈ میپ کا مالک نہیں ہے۔
فلٹر ٹیم نے ایسا کیوں کیا۔
اصل فن تعمیر کو 2018 میں سمجھا گیا جب فلٹر ریلیز ہوا تھا۔ مواد اور Cupertino کو براہ راست SDK میں بنڈل کرنے کا مطلب یہ تھا کہ ڈویلپر انہیں ہمیشہ بغیر کسی ترتیب کے استعمال کر سکتے ہیں۔ شروع کرنا آسان اور مکمل طور پر رگڑ سے پاک تھا۔
تاہم، جیسے جیسے فلٹر پختہ ہوا، بنڈلنگ ایک حد بن گئی۔ میٹریل ڈیزائن 3 کی ریلیز توقع سے زیادہ سست تھی کیونکہ تمام میٹریل تبدیلیوں کو سہ ماہی SDK ریلیز کا انتظار کرنا پڑتا تھا۔ کمیونٹی کے تعاون کنندگان کو ویجیٹ کی بہتری کو ضم کرنا زیادہ مشکل محسوس ہوا کیونکہ بنیادی SDK کوڈ کو چھونے کی بار زیادہ تھی۔ مکمل طور پر حسب ضرورت ڈیزائن سسٹمز کے لیے فلٹر استعمال کرنے والی ٹیمیں اب بھی میٹریل اور کپرٹینو کو عبوری انحصار کے طور پر گھسیٹ رہی ہیں، چاہے وہ اسے پسند کریں یا نہ کریں۔
علیحدگی تینوں مسائل کو حل کرتی ہے۔ میٹریل ویجیٹ استعمال کرنے والی ٹیمیں سہ ماہی کے بجائے ہفتہ وار اصلاحات اور نئے اجزاء حاصل کر سکتی ہیں۔ اپنی مرضی کے مطابق ڈیزائن سسٹم بنانے والی ٹیموں کو انحصار کے طور پر مواد کے ارد گرد لے جانے کی ضرورت نہیں ہے۔ اور جب کہ فریم ورک لے آؤٹ، رینڈرنگ، اور پلیٹ فارم کے تعامل کو ہینڈل کرتا ہے، ڈیزائن لائبریری مکمل طور پر اختیاری ہے، اور حقیقی انداز سے غیر جانبدار فلٹر کور کی طرف راستہ واضح ہے۔
موجودہ کوڈ پر اثر
موجودہ کوڈ فلٹر 3.47 میں مرتب ہوتا رہے گا۔ قابل احترام package:flutter/material.dart اور package:flutter/cupertino.dart درآمدات ابھی تک کام کرتی ہیں۔ جب آپ Flutter 3.47 پر اپ گریڈ کرتے ہیں تو اس میں کوئی رکاوٹ نہیں ہے۔
فرسودگی موسم خزاں 2026 کی مستحکم ریلیز کے لیے طے شدہ ہے، نومبر میں متوقع ہے۔ اس وقت پرانے بنڈل کی درآمد کو سرکاری طور پر فرسودہ کر دیا جاتا ہے۔ اسے فرسودگی کے فوراً بعد نہیں ہٹایا جائے گا، لیکن گھڑی شروع ہو گئی ہے۔
موجودہ فن تعمیر کو سمجھیں۔
Flutter 3.47 سے پہلے، Flutter UI کے کلیدی اجزاء بنڈل کیے گئے تھے اور Flutter SDK کے اندر ایک ساتھ جاری کیے گئے تھے۔ میٹریل ڈیزائن، کپرٹینو، وجیٹس، رینڈرنگ، پینٹنگ، پلیٹ فارم سروسز، اور لوکلائزیشن سب ایک ہی SDK ریلیز ڈھانچے کے اندر تھے۔
اس کے نتیجے میں کچھ حدود پیدا ہوئیں۔ آپ کو مادی کیڑے ٹھیک کرنے کے لیے فلٹر SDK ریلیز کا انتظار کرنا پڑ سکتا ہے۔ ٹیمیں جو اپنے ڈیزائن سسٹم بناتی ہیں وہ اب بھی مواد سے منسلک ہوسکتی ہیں۔ بنیادی SDK میں تبدیلیوں میں حصہ ڈالنے میں رکاوٹ پیدا ہو گئی ہے، جس سے بہتری کی رفتار کم ہو گئی ہے۔ مواد کو بنیادی فلٹر SDK سے آزادانہ طور پر ورژن نہیں بنایا جا سکتا ہے اور اسی ریلیز کے بہاؤ کی پیروی کی ہے یہاں تک کہ اگر صرف میٹریل اور کپرٹینو کو فوری اپ ڈیٹس کی ضرورت ہو۔
موجودہ فن تعمیر نے Flutter کی UI لائبریریوں کو SDK کے ساتھ مضبوطی سے جوڑ دیا ہے، جس سے انفرادی اجزاء کو ماڈیولر فن تعمیر میں آزادانہ طور پر تیار ہونے اور ترسیل سے روکا جاتا ہے۔
تمام پھڑپھڑانے والے منصوبے استعمال ہوئے۔ package:flutter/material.dart یہ SDK کے ریلیز شیڈول سے قریب سے جڑا ہوا تھا۔ اگر ہمیں میٹریل میں کسی بصری مسئلے کا سامنا ہوا، تو ہم اسے ٹھیک کرنے کے لیے اگلی سہ ماہی SDK ریلیز تک انتظار کریں گے، چاہے فلٹر انجن میں ہی کوئی مسئلہ نہ ہو۔ یہ سخت جوڑا وہ بنیادی مسئلہ تھا جسے حل کرنے کے لیے علیحدگی کا منصوبہ بنایا گیا تھا۔
نیا فن تعمیر: اسٹینڈ تنہا پیکیج
فلٹر 3.47 سے شروع کرتے ہوئے، فن تعمیر فلٹر کے ڈیزائن سسٹم کو بنیادی SDK سے الگ کرتا ہے۔ میٹریل UI اور Cupertino UI آزاد پیکجز ہیں جو pub.dev کے ذریعے شائع ہوتے ہیں۔ ہر پیکج آزادانہ طور پر اس کا اپنا ورژن ہو سکتا ہے اور اپ ڈیٹ جاری کر سکتا ہے۔
دونوں پیکجوں پر منحصر ہے: فلٹر SDK کوربنیادی ویجیٹس، رینڈرنگ، پینٹنگ، پلیٹ فارم کی خدمات، اور فاؤنڈیشن لیئرز پر مشتمل ہے۔ جبکہ بنیادی SDK کو سہ ماہی ریلیز سائیکل پر برقرار رکھا جاتا ہے، UI پیکجز زیادہ کثرت سے اپ ڈیٹ فراہم کر سکتے ہیں۔
فلٹر کا بنیادی حصہ زیادہ ماڈیولر ہوتا جا رہا ہے۔ مواد اور کپرٹینو مکمل فلٹر SDK جاری کیے بغیر آزادانہ طور پر تیار ہو سکتے ہیں۔
ایک اہم تعمیراتی بصیرت خدشات کی علیحدگی ہے۔ فلٹر SDK اب رینڈرنگ انجن، بیس ویجیٹ لیئر، اور پلیٹ فارم تجرید کا مالک ہے۔ ڈیزائن سسٹم (material_ui اور cupertino_ui) pub.dev میں ایک فرسٹ پارٹی پیکج ہے جو فلٹر ٹیم کی ملکیت ہے لیکن اسے ورژن بنایا گیا ہے اور آزادانہ طور پر جاری کیا گیا ہے۔
ترتیبات: نیا پیکیج شامل کریں۔
Material_ui شامل کریں۔
flutter pub add material_ui
یہ واحد کمانڈ شامل کرتا ہے: material_ui آپ کو pubspec.yaml نیچے dependencies اور چلائیں flutter pub get خود بخود چلانے کے بعد: pubspec.yaml پر مشتمل ہے:
dependencies:
flutter:
sdk: flutter
material_ui: ^1.0.0
flutter pub add material_ui یہ پیکجوں کو شامل کرنے کا ایک محاوراتی طریقہ ہے۔ خودکار طور پر تازہ ترین مطابقت پذیر ورژن کا انتخاب کرتا ہے اور درست رکاوٹ کی شکل شامل کرتا ہے۔ کہ ^1.0.0 رکاوٹ کا مطلب ہے "1.0.0 یا اس سے زیادہ ورژن جو 1.x کے ساتھ مطابقت رکھتا ہے” ڈارٹ کے سمور رولز کے مطابق۔
یہ مطلوبہ پابندی ہے۔ پیچ اور معمولی اپ ڈیٹس لانچ ہونے پر خود بخود چل سکتے ہیں۔ flutter pub upgradeتاہم، یہ مجازی تبدیلیوں کو روکتا ہے. 2.0.0 اسے اپنے منصوبے کی راہ میں حائل نہ ہونے دیں۔
cupertino_ui شامل کریں۔
flutter pub add cupertino_ui
اسے صرف اس صورت میں شامل کریں جب آپ کا پروجیکٹ Cupertino طرز کے ویجٹ استعمال کرے۔ یہ ان ایپس کے لیے ضروری نہیں ہو سکتا جو صرف اینڈرائیڈ کو نشانہ بناتے ہیں یا مکمل طور پر حسب ضرورت ڈیزائن سسٹم استعمال کرتے ہیں۔
dependencies:
flutter:
sdk: flutter
material_ui: ^1.0.0
cupertino_ui: ^1.0.0
دونوں کو ایک ساتھ شامل کریں۔
flutter pub add material_ui cupertino_ui
ایک میں دو پیکیج کے نام درج کریں۔ flutter pub add کمانڈ ان کو ایک ساتھ جوڑتا ہے اور پورے انحصار گراف کو ایک بار چیک کرتا ہے۔ یہ دو الگ الگ کمانڈ چلانے سے زیادہ تیز ہے۔
پروجیکٹ ہجرت: خودکار راستہ
فلٹر ٹیم ہجرت کے ٹولز مہیا کرتی ہے جو خود بخود سب سے زیادہ عام معاملات کو ہینڈل کرتی ہے۔ زیادہ تر منصوبوں کے لیے، یہ ایک مکمل منتقلی ہے۔
مرحلہ 1: مائیگریشن ٹول چلائیں۔
dart fix --apply --code=migrate_design_widgets
dart fix ڈارٹ میں بنایا گیا ایک خودکار کوڈ ریکوری ٹول۔ --apply آپ کو ہر ایک کی تصدیق کرنے کے لیے کہے بغیر تمام مجوزہ اصلاحات کو لاگو کرنے کی ہدایت کرتا ہے۔ --code=migrate_design_widgets خاص طور پر عملدرآمد کریں۔ migrate_design_widgets یہ ایک نیا کوڈ فکس ہے جو ڈیکپلنگ ہجرت کو ہینڈل کرتا ہے۔ پروجیکٹ کو اسکین کرکے package:flutter/material.dart اور package:flutter/cupertino.dart درست نئی درآمد کے ساتھ درآمد اور اپ ڈیٹ کریں۔ package:material_ui/material_ui.dart اور package:cupertino_ui/cupertino_ui.dartہر ایک
ٹول اپ ڈیٹ کرنے کی بھی کوشش کرے گا۔ pubspec.yaml ایک نیا پیکیج انحصار شامل کریں۔ کچھ معلوم ابتدائی کیڑے ہیں۔ pubspec.yaml کچھ معاملات میں، اپ ڈیٹس صحیح طریقے سے لاگو نہیں ہوسکتے ہیں۔
مرحلہ 2: معلوم pubspec.yaml بگز کو ایڈریس کریں۔
اگر مائیگریشن ٹول کامیابی سے اپ ڈیٹ ہونے میں ناکام ہو جاتا ہے۔ pubspec.yamlچلائیں:
flutter pub add material_ui
flutter pub add cupertino_ui
dart fix --apply
flutter pub add material_ui اور flutter pub add cupertino_ui دستی طور پر پیکجز شامل کریں۔ pubspec.yaml پیکیج کی توثیق چلائیں۔ پھر dart fix --apply (بغیر --code اس بار جھنڈا لگایا گیا) اب جب کہ پیکیج دستیاب ہے، کسی بھی باقی اصلاحات کو لاگو کریں جو آپ نے ابتدائی دوڑ میں چھوٹ گئے ہوں۔
چل رہا ہے dart fix پیکج داخل ہونے کے بعد pubspec.yaml آپ اصل انسٹال شدہ پیکیج کے خلاف درآمدی راستے کی توثیق کر سکتے ہیں۔
مرحلہ 3: منتقلی کی تصدیق کریں۔
flutter analyze
flutter analyze پورے پروجیکٹ میں ڈارٹ اینالائزر چلائیں اور باقی مسائل کی اطلاع دیں۔ اگر منتقلی کامیابی کے ساتھ مکمل ہو جاتی ہے، تو آپ کو گمشدہ درآمدات یا فرسودہ APIs سے متعلق کوئی خرابی نظر نہیں آئے گی۔ اگر غلطیاں باقی رہتی ہیں، تو وہ دو زمروں میں سے ایک میں آتی ہیں: وہ درآمدات جنہیں منتقلی کا آلہ خود بخود اپ ڈیٹ نہیں کر سکتا ہے (ذیل میں مینوئل پاتھ سیکشن میں بیان کیا گیا ہے)، یا تھرڈ پارٹی پیکجز پر انحصار جو ابھی تک منتقل نہیں ہوئے ہیں (مطابقت برج سیکشن میں بیان کیا گیا ہے)۔
اصل میں ٹول کیا بدلتا ہے۔
یہ بالکل وہی ہے جو خودکار منتقلی درآمدی بیان میں کرتی ہے:
// BEFORE: What every Flutter app used to write
import 'package:flutter/material.dart';
import 'package:flutter/cupertino.dart';
// AFTER: What the migration tool produces
import 'package:material_ui/material_ui.dart';
import 'package:cupertino_ui/cupertino_ui.dart';
کہ import 'package:flutter/material.dart' بیان نے فلٹر SDK کے اندر بنڈل کے مقام سے میٹریل لائبریری درآمد کی ہے۔ کہ import 'package:material_ui/material_ui.dart' بیانات آپ کے شامل کردہ اسٹینڈ اکیلا پیکج سے لیے گئے ہیں۔ pubspec.yaml.
ویجیٹ کا نام، کلاس کا نام، اور API کی سطح ایک جیسی ہے۔ Scaffold اب بھی Scaffold. ThemeData اب بھی ThemeData. AppBar اب بھی AppBar. ویجیٹ کا نام تبدیل نہیں کیا گیا ہے یا اس کی ساخت تبدیل نہیں ہوئی ہے۔ صرف تبدیلی درآمد کا راستہ ہے۔
اس کی وجہ یہ ہے کہ Flutter ٹیم نے جان بوجھ کر اسے ڈیزائن کیا ہے کہ درآمدی راستے میں ایک سادہ تلاش اور تبدیلی کے ساتھ منتقلی ممکن ہو۔ material_ui یہ بنڈل شدہ میٹریل لائبریری کو فوری طور پر بدل سکتا ہے۔ API کی سطح اسی حالت میں منجمد ہو جاتی ہے جس حالت میں بنڈل لائبریری منجمد ہونے پر ہوتی ہے۔ یہی وجہ ہے کہ README پیکیج کہتا ہے کہ اپریل میں تعاون کو منجمد کر دیا گیا ہے تاکہ آسانی سے منتقلی کو یقینی بنایا جا سکے۔
آپ کو کیا ملتا ہے material_ui 1.0 بالکل وہی ہے جو آپ کے پاس تھا۔ package:flutter/material.dart Flutter 3.44 کے لیے تیز رفتار کیڈینس کے لیے اضافی بہتری حاصل کرنے کا ایک راستہ ہے۔
پروجیکٹ ہجرت: دستی راستہ
خودکار ٹولز زیادہ تر نقل مکانی کو سنبھالتے ہیں۔ تاہم، کچھ معاملات ایسے ہیں جہاں دستی مداخلت کی ضرورت ہے۔
مخلوط درآمد فائل
اگر آپ کے پاس ایسی فائلیں ہیں جو ایک سے زیادہ فلٹر سبلائبریریوں سے درآمد کرتی ہیں، یا تو ایک ہی لائن پر یا اس طرح کہ ٹول پارس نہیں کر سکتا:
// A file with multiple flutter imports
import 'package:flutter/material.dart';
import 'package:flutter/rendering.dart';
import 'package:flutter/services.dart';
import 'package:flutter/gestures.dart';
یہ ٹول صرف درج ذیل آئٹمز کو اپ ڈیٹ کرتا ہے۔ material.dart درآمد دوسرے لوگ اشارہ کرتے رہتے ہیں۔ package:flutter/... کیونکہ rendering.dart, services.dartاور gestures.dart یہ ایک بنیادی فریم ورک لائبریری ہے جو اسٹینڈ تنہا پیکج کے طور پر حرکت نہیں کرتی ہے۔ وہ بالکل وہیں رہتے ہیں جہاں وہ ہیں۔ صرف ڈیزائن سسٹم کی درآمد میں تبدیلی آتی ہے۔
// After migration: correct state
import 'package:material_ui/material_ui.dart'; // Updated
import 'package:flutter/rendering.dart'; // Stays the same
import 'package:flutter/services.dart'; // Stays the same
import 'package:flutter/gestures.dart'; // Stays the same
package:flutter/rendering.dart اسی طرح کے بنیادی فریم ورک کی درآمدات کو منتقل نہیں کیا جاتا ہے کیونکہ وہ SDK کے اپنے ڈومین (لے آؤٹ، رینڈرنگ، پینٹنگ، اور پلیٹ فارم سروسز) کا حصہ ہیں۔ علیحدگی خاص طور پر ڈیزائن کے نظام کے بارے میں ہے نہ کہ بنیادی فریم ورک کے ابتدائی۔ اس فرق کو سمجھنا ضروری ہے تاکہ آپ غلطی سے فرق تلاش کرنے کی کوشش نہ کریں۔ rendering_ui پیکیج موجود نہیں ہے۔
مشروط درآمد اور پلیٹ فارم کے لیے مخصوص فائلیں۔
// Platform-specific file that used conditional imports
export 'package:flutter/material.dart'
if (dart.library.html) 'package:flutter/material.dart';
مشروط درآمد کے دونوں اطراف کو دستی طور پر اپ ڈیٹ کریں۔
// After migration
export 'package:material_ui/material_ui.dart'
if (dart.library.html) 'package:material_ui/material_ui.dart';
مشروط درآمد if (dart.library...) مرتب کرنے کے وقت، پلیٹ فارم کی بنیاد پر دو درآمدی راستوں میں سے انتخاب کریں۔ مائیگریشن ٹولز ہر صورت میں مشروط درآمدات کی دونوں شاخوں کو صحیح طریقے سے نہیں سنبھال سکتے۔ اپنے پروجیکٹ میں تمام فائلوں کو دستی طور پر چیک کریں، بشمول: if (dart.library.html) یا ریونیو اسٹیٹمنٹ میں پلیٹ فارم کی اسی طرح کی شرائط۔
تیار کردہ فائل
کے ساتھ ختم ہونے والی فائلیں۔ .g.dart, .freezed.dartیا دوسرے پیدا کردہ لاحقے build_runner کے ذریعہ تیار کیے جاتے ہیں اور دستی طور پر ترمیم نہیں کی جانی چاہئے۔ درج ذیل کو چلانے سے یہ درست درآمدات کے ساتھ دوبارہ تخلیق کرے گا۔
dart run build_runner build --delete-conflicting-outputs
dart run build_runner build اپنی سورس فائلوں کے خلاف کوئی بھی کوڈ جنریٹر (json_serialized، Freeze، Riverpod_generator، وغیرہ) چلائیں۔ --delete-conflicting-outputs پرانے جنریشن کوڈ کو تنازعات کا باعث بننے سے روکنے کے لیے تخلیق نو سے پہلے پہلے سے تیار کردہ فائلوں کو ہٹاتا ہے۔
کیونکہ ذریعہ .dart فائل میں اب مائیگریشن ٹول میں درآمدات کو اپ ڈیٹ کر دیا گیا ہے اور جنریٹر اپنی سورس فائلوں کو دوبارہ پڑھتا ہے اور مستقل درآمدات سے تیار کردہ فائلیں تیار کرتا ہے۔ منتقلی کے بعد دوبارہ جنریٹر چلانے کے علاوہ، آپ کو پیدا کردہ فائلوں کے ساتھ کچھ خاص کرنے کی ضرورت نہیں ہے۔
MaterialUiCompatibilityBridge: خلا کو ختم کرنا
ماحولیاتی نظام راتوں رات حرکت نہیں کرتے۔ استعمال کے لیے ایپ کو اپ ڈیٹ کرتے وقت material_uiکچھ تھرڈ پارٹی پیکیج پر انحصار اب بھی استعمال میں ہو سکتا ہے۔ package:flutter/material.dart اندرونی طور پر۔ اس کا نتیجہ ایسی صورت حال میں ہوتا ہے جہاں آپ کے ایپ کے ویجیٹ ٹری میں دو مختلف مادی ذرائع سے ویجٹ ہوتے ہیں: نیا اسٹینڈ پیکج اور پرانا بنڈل پیکیج۔
کہ MaterialUiCompatibilityBridge یہ بالکل اس صورتحال کو سنبھالنے کے لئے موجود ہے۔ ایک مطابقت کی پرت فراہم کرتا ہے جو رن ٹائم کی غلطیوں کے بغیر ایک ہی ویجیٹ ٹری میں مادی وجیٹس کے دو ذرائع کو ایک ساتھ رہنے کی اجازت دیتا ہے۔
import 'package:material_ui/material_ui.dart';
void main() {
runApp(const MyApp());
}
class MyApp extends StatelessWidget {
const MyApp({super.key});
@override
Widget build(BuildContext context) {
return MaterialApp(
theme: ThemeData(
colorScheme: ColorScheme.fromSeed(
seedColor: const Color(0xFF6750A4),
),
),
builder: (BuildContext context, Widget? child) {
return MaterialUiCompatibilityBridge(child: child!);
},
home: const HomeScreen(),
);
}
}
import 'package:material_ui/material_ui.dart' یہ ایک نئی درآمد ہے۔ تمام مادی وجیٹس، بشمول: MaterialApp, ThemeData, ColorSchemeاور MaterialUiCompatibilityBridge آپ اسے اس واحد درآمد میں استعمال کر سکتے ہیں:
MaterialApp(...) نام اور طرز عمل اس سے تبدیل نہیں ہوا جو پہلے استعمال کیا جاتا تھا۔ ایک جیسے کنسٹرکٹر پیرامیٹرز، ایک ہی سلوک۔ کلاسیں یہاں سے آتی ہیں: material_ui کوئی بھی کوڈ جو اب بنڈل SDK کے بجائے اس کا استعمال کرتا ہے کوئی تبدیلی نہیں رہے گی۔
builder: (BuildContext context, Widget? child) { return MaterialUiCompatibilityBridge(child: child!); } مطابقت کی پرت کا اندراج۔ کہ builder پیرامیٹر MaterialApp ویجیٹ کے پورے درخت کو لپیٹ دیتا ہے۔ MaterialApp بنائیں۔ ڈال کر MaterialUiCompatibilityBridge اس سطح پر، یہ ایپ میں موجود تمام ویجٹس سے اوپر بیٹھتا ہے۔ اس کا مطلب ہے کہ تمام ویجٹ درخت میں کہیں بھی ہیں، قطع نظر اس کے کہ وہ کوڈ سے آئے ہیں یا نہیں (استعمال کرتے ہوئے: material_ui) یا انحصار میں (اب بھی استعمال کر رہے ہیں۔ package:flutter/material.dart) پل کے مطابقت کے تناظر میں کام کرتا ہے۔
کہ child! null دعووں کا استعمال یہاں محفوظ ہے۔ MaterialApp اگر آپ کی ایپ میں درج ذیل ہیں، تو ہمیشہ بلڈر کو غیر null اولاد فراہم کریں۔ home, routesیا initialRoute تشکیل شدہ۔
مطابقت کا پل کب استعمال کرنا ہے۔
ایک سوال سے شروع کریں: کیا آپ کے پروجیکٹ میں کوئی انحصار ہے جو میٹریل وجیٹس استعمال کرتا ہے؟
نہیں: مطابقت کے پل کی ضرورت نہیں ہے۔ آپ اس کے بغیر آگے بڑھ سکتے ہیں۔
ہاں: یقینی بنائیں کہ ان انحصارات کو فعال کرنے کے لیے اپ ڈیٹ کیا گیا ہے۔ material_ui.
پلوں کی ضرورت صرف اس صورت میں ہے جب آپ کا پروجیکٹ اب بھی انحصار پر انحصار کرتا ہے جو پرانے میٹریل ویجٹ استعمال کرتے ہیں۔ اگر سب کچھ پہلے ہی منتقل ہو چکا ہے۔ material_uiپلوں کو ہٹا یا جا سکتا ہے.
یہ ایک تبادلوں کا آلہ ہے۔ جیسا کہ آپ کا ماحولیاتی نظام منتقل ہو چکا ہے، آپ چیک کر سکتے ہیں کہ آیا آپ کے انحصار کو چلا کر اپ ڈیٹ کیا گیا ہے:
flutter pub outdated
تمام انحصار استعمال کرتے وقت material_uiپل کو ہٹا دیں۔ اس کا مقصد ایپ کا مستقل حصہ بننا نہیں ہے۔
لوکلائزیشن: کیا بدلا ہے اور کیسے اپ ڈیٹ کیا جائے۔
اس ہجرت میں لوکلائزیشن سب سے اہم عملی تبدیلیوں میں سے ایک ہے۔ کہ flutter_localizations پیکیج نے پہلے ایک ہی بنڈل پیکج میں میٹریل اور کپرٹینو ویجٹ دونوں کے لیے ترجمہ اور لوکلائزیشن کے مینڈیٹ فراہم کیے تھے۔ اب اسے دو الگ الگ پیکجوں میں تقسیم کر دیا گیا ہے۔
پچھلی لوکلائزیشن کی ترتیبات
// BEFORE: The old way with flutter_localizations
import 'package:flutter_localizations/flutter_localizations.dart';
import 'package:flutter/material.dart';
MaterialApp(
localizationsDelegates: const >[
GlobalCupertinoLocalizations.delegate,
GlobalMaterialLocalizations.delegate,
GlobalWidgetsLocalizations.delegate,
],
supportedLocales: const [
Locale('en'),
Locale('ar'),
Locale('fr'),
],
// ...
)
پچھلے نقطہ نظر میں واضح طور پر تین مندوبین کی فہرست کی ضرورت تھی۔ GlobalCupertinoLocalizations.delegate Cupertino ویجیٹ کے تاروں کے لیے GlobalMaterialLocalizations.delegate مادی ویجیٹ تاروں کے لیے: GlobalWidgetsLocalizations.delegate ڈیفالٹ ویجیٹ سٹرنگ کے لیے۔ آپ کو بھی الگ سے ضرورت ہے flutter_localizations درآمد یہ لفظی تھا اور ڈویلپرز کو یہ جاننے کی ضرورت تھی کہ کس مندوب نے کون سا ویجیٹ سنبھالا۔
لوکلائزیشن کی نئی ترتیبات
// AFTER: The new way with material_ui
import 'package:material_ui/material_ui.dart';
MaterialApp(
localizationsDelegates: GlobalMaterialLocalizations.delegates,
supportedLocales: const [
Locale('en'),
Locale('ar'),
Locale('fr'),
],
// ...
)
GlobalMaterialLocalizations.delegates یہ ایک ایسا گیٹر ہے جو تینوں مندوبین کو ایک ساتھ واپس کرتا ہے: میٹریل ڈیلیگیٹ، کیپرٹینو ڈیلیگیٹ، اور وجیٹس ڈیلیگیٹ۔ اس سنگل گیٹر کو تفویض کرکے localizationsDelegates، آپ کم کوڈ کے ساتھ روایتی تین افراد کی نمائندہ فہرست کے برابر کوریج حاصل کر سکتے ہیں۔
Cupertino سٹرنگز کو الگ سے درآمد کیے بغیر خود بخود شامل کیا جاتا ہے۔ cupertino_uiکیونکہ material_ui پر منحصر ہے cupertino_ui اندرونی طور پر، ہم ان لوکلائزیشن مندوبین کو ایک پابند گیٹر میں بنڈل کرتے ہیں۔
الگ flutter_localizations مزید درآمدات کی ضرورت نہیں ہے۔ پیکیج اب بھی موجود ہے (لیکن اب استعمال نہیں کیا جاتا ہے) material_uiآپ اسے اپنی آمدنی کے گوشوارے اور سبھی سے ہٹا سکتے ہیں۔ pubspec.yaml انحصار۔
لوکلائزیشن آرکیٹیکچر ڈایاگرام
خاکہ آرکیٹیکچر کی تبدیلی سے پہلے اور بعد میں فلٹر کی لوکلائزیشن سیٹنگز کا موازنہ کرتا ہے۔
پہلے: لوکلائزیشن ایک علیحدہ سروس کے ذریعے فراہم کی گئی تھی۔ flutter_localizations پیکج ڈویلپرز کو واضح طور پر مواد، کیپرٹینو، اور وجیٹس لوکلائزیشن کے مندوبین کو شامل کرنا تھا۔
بعد میں: لوکلائزیشن کو آسان بنایا گیا ہے: material_ui پیکج GlobalMaterialLocalizations.delegates نمائندوں کو اکٹھا کرنے کے لیے Cupertino اور ویجیٹ کی لوکلائزیشن خود بخود شامل ہوجاتی ہے۔
نیا نقطہ نظر لوکلائزیشن کنفیگریشن ڈویلپرز کو لکھنے کی ضرورت کی مقدار کو کم کرتا ہے اور سیٹ اپ کو برقرار رکھنا آسان بنا دیتا ہے۔
پہلے اور بعد میں: ساتھ ساتھ کوڈ کا موازنہ
ڈیفالٹ ایپ کی ترتیبات
// BEFORE: Standard Flutter app entry point
import 'package:flutter/material.dart';
import 'package:flutter_localizations/flutter_localizations.dart';
void main() {
runApp(const MyApp());
}
class MyApp extends StatelessWidget {
const MyApp({super.key});
@override
Widget build(BuildContext context) {
return MaterialApp(
title: 'My App',
theme: ThemeData(
colorScheme: ColorScheme.fromSeed(seedColor: Colors.deepPurple),
useMaterial3: true,
),
localizationsDelegates: const [
GlobalMaterialLocalizations.delegate,
GlobalCupertinoLocalizations.delegate,
GlobalWidgetsLocalizations.delegate,
],
supportedLocales: const [Locale('en')],
home: const HomeScreen(),
);
}
}
// AFTER: Migrated app entry point
import 'package:material_ui/material_ui.dart';
void main() {
runApp(const MyApp());
}
class MyApp extends StatelessWidget {
const MyApp({super.key});
@override
Widget build(BuildContext context) {
return MaterialApp(
title: 'My App',
theme: ThemeData(
colorScheme: ColorScheme.fromSeed(seedColor: Colors.deepPurple),
useMaterial3: true,
),
localizationsDelegates: GlobalMaterialLocalizations.delegates,
supportedLocales: const [Locale('en')],
home: const HomeScreen(),
);
}
}
فرق تین تبدیلیوں کا ہے: درآمدی لائن اس سے تبدیل ہوتی ہے: package:flutter/material.dart کو package:material_ui/material_ui.dart, flutter_localizations درآمد ہٹا دیا جاتا ہے اور localizationsDelegates فہرست کو تین واضح مندوبین سے کم کر کے ایک حاصل کرنے والے تک پہنچا دیا گیا ہے۔ باقی سب کچھ (MaterialApp, ThemeData, ColorScheme.fromSeed, useMaterial3اور home) ایک جیسے ہیں کیونکہ API تبدیل نہیں ہوا ہے۔
مادی وجیٹس کے ساتھ اسکرین
// BEFORE
import 'package:flutter/material.dart';
class ProfileScreen extends StatelessWidget {
const ProfileScreen({super.key});
@override
Widget build(BuildContext context) {
return Scaffold(
appBar: AppBar(
title: const Text('Profile'),
backgroundColor: Theme.of(context).colorScheme.inversePrimary,
),
body: ListView(
padding: const EdgeInsets.all(16),
children: [
Card(
child: ListTile(
leading: const CircleAvatar(child: Icon(Icons.person)),
title: const Text('Ade Mensah'),
subtitle: const Text('Flutter Developer'),
trailing: const Icon(Icons.chevron_right),
),
),
const SizedBox(height: 16),
FilledButton(
onPressed: () {},
child: const Text('Edit Profile'),
),
],
),
floatingActionButton: FloatingActionButton(
onPressed: () {},
child: const Icon(Icons.add),
),
);
}
}
// AFTER: Migrated screen
import 'package:material_ui/material_ui.dart';
class ProfileScreen extends StatelessWidget {
const ProfileScreen({super.key});
@override
Widget build(BuildContext context) {
return Scaffold(
appBar: AppBar(
title: const Text('Profile'),
backgroundColor: Theme.of(context).colorScheme.inversePrimary,
),
body: ListView(
padding: const EdgeInsets.all(16),
children: [
Card(
child: ListTile(
leading: const CircleAvatar(child: Icon(Icons.person)),
title: const Text('Ade Mensah'),
subtitle: const Text('Flutter Developer'),
trailing: const Icon(Icons.chevron_right),
),
),
const SizedBox(height: 16),
FilledButton(
onPressed: () {},
child: const Text('Edit Profile'),
),
],
),
floatingActionButton: FloatingActionButton(
onPressed: () {},
child: const Icon(Icons.add),
),
);
}
}
ویجیٹ کا درخت بالکل ویسا ہی ہے۔ Scaffold, AppBar, Card, ListTile, CircleAvatar, FilledButtonاور FloatingActionButton: تمام ویجیٹ کے نام، پیرامیٹرز، اور رویے میں کوئی تبدیلی نہیں کی گئی ہے۔
فرق صرف سب سے اوپر درآمد کا ہے۔ یہ ڈیزائن کے لحاظ سے ہے۔ فلٹر ٹیم کا واضح مقصد ہجرت کو ایک خالص درآمدی تبدیلی بنانا تھا، بغیر ویجیٹ API میں کسی تبدیلی کے۔
cupertino سکرین
// BEFORE
import 'package:flutter/cupertino.dart';
class SettingsScreen extends StatelessWidget {
const SettingsScreen({super.key});
@override
Widget build(BuildContext context) {
return CupertinoPageScaffold(
navigationBar: const CupertinoNavigationBar(
middle: Text('Settings'),
),
child: SafeArea(
child: CupertinoListSection.insetGrouped(
children: [
CupertinoListTile(
title: const Text('Notifications'),
leading: const Icon(CupertinoIcons.bell),
trailing: CupertinoSwitch(
value: true,
onChanged: (value) {},
),
),
],
),
),
);
}
}
// AFTER
import 'package:cupertino_ui/cupertino_ui.dart';
class SettingsScreen extends StatelessWidget {
const SettingsScreen({super.key});
@override
Widget build(BuildContext context) {
return CupertinoPageScaffold(
navigationBar: const CupertinoNavigationBar(
middle: Text('Settings'),
),
child: SafeArea(
child: CupertinoListSection.insetGrouped(
children: [
CupertinoListTile(
title: const Text('Notifications'),
leading: const Icon(CupertinoIcons.bell),
trailing: CupertinoSwitch(
value: true,
onChanged: (value) {},
),
),
],
),
),
);
}
}
ایک ہی کہانی۔ CupertinoPageScaffold, CupertinoNavigationBar, CupertinoListSection, CupertinoListTile, CupertinoSwitchاور CupertinoIcons سب میں استعمال کیا جا سکتا ہے۔ package:cupertino_ui/cupertino_ui.dart بالکل جیسا کہ انہوں نے کیا package:flutter/cupertino.dart. ایک درآمدی لائن بدل جاتی ہے اور ویجیٹ کوڈ میں کوئی تبدیلی نہیں ہوتی۔
ایسی ایپس جو مٹیریل اور کپرٹینو دونوں استعمال کرتی ہیں۔
کچھ ایپس ڈیزائن سسٹمز کو مکس کرتی ہیں۔ بنیادی طور پر میٹریل ایپس کے اندر کپرٹینو ڈائیلاگ اور سلیکٹرز کا استعمال کرنا ایک عام نمونہ ہے۔ دونوں لائبریریوں کو بغیر کسی تنازعہ کے بیک وقت استعمال کیا جا سکتا ہے۔
// BEFORE
import 'package:flutter/material.dart';
import 'package:flutter/cupertino.dart';
class DatePickerButton extends StatelessWidget {
const DatePickerButton({super.key});
void _showDatePicker(BuildContext context) {
showCupertinoModalPopup(
context: context,
builder: (context) => Container(
height: 216,
color: CupertinoColors.systemBackground,
child: CupertinoDatePicker(
mode: CupertinoDatePickerMode.date,
onDateTimeChanged: (DateTime newDate) {},
),
),
);
}
@override
Widget build(BuildContext context) {
return ElevatedButton(
onPressed: () => _showDatePicker(context),
child: const Text('Pick Date'),
);
}
}
// AFTER: Both packages imported
import 'package:material_ui/material_ui.dart';
import 'package:cupertino_ui/cupertino_ui.dart';
class DatePickerButton extends StatelessWidget {
const DatePickerButton({super.key});
void _showDatePicker(BuildContext context) {
showCupertinoModalPopup(
context: context,
builder: (context) => Container(
height: 216,
color: CupertinoColors.systemBackground,
child: CupertinoDatePicker(
mode: CupertinoDatePickerMode.date,
onDateTimeChanged: (DateTime newDate) {},
),
),
);
}
@override
Widget build(BuildContext context) {
return ElevatedButton(
onPressed: () => _showDatePicker(context),
child: const Text('Pick Date'),
);
}
}
دونوں material_ui اور cupertino_ui آپ انہیں نام کی جگہ کے تنازعات کے بغیر ایک ہی فائل میں درآمد کر سکتے ہیں۔ براہ کرم اس کا حوالہ دیں۔ material_ui پہلے سے ہی منحصر ہے cupertino_ui آپ دیکھ سکتے ہیں کہ اندرونی طور پر آپ کو اسے واضح طور پر درآمد کرنے کی ضرورت نہیں ہے۔ cupertino_ui اس کی وجہ یہ ہے کہ زیادہ تر فائلوں میں کیپرٹینو قسم کو میٹریل امپورٹ کے ذریعے حاصل کیا جا سکتا ہے۔ تاہم، واضح طور پر دونوں کو درآمد کرنے سے ارادہ صاف ہو جاتا ہے اور یہ ان فائلوں کے لیے تجویز کردہ عمل ہے جو دونوں سسٹمز کے ویجٹ کو معنی خیز طور پر استعمال کرتی ہیں۔
پیکیج تخلیق کار منتقلی
اگر آپ Flutter پیکجز کے ساتھ ساتھ Flutter ایپس کو برقرار رکھتے ہیں، تو منتقلی کے وقت اضافی تحفظات ہیں۔ فلٹر ٹیم واضح طور پر کہتی ہے: اسٹینڈ اکیلے پیکیج میں منتقلی کو پیکج کی ایک بڑی ریلیز سمجھا جاتا ہے۔
ایک پیکیج مصنف کے طور پر کیا کرنا ہے
# Your package's pubspec.yaml BEFORE migration
name: my_flutter_package
version: 1.5.0
dependencies:
flutter:
sdk: flutter
# Your package's pubspec.yaml AFTER migration
name: my_flutter_package
version: 2.0.0
dependencies:
flutter:
sdk: flutter
material_ui: ^1.0.0
ورژن تنازعہ 2.0.0 یہ ضروری ہے کیونکہ یہ پیکیج کے صارفین کے لیے ایک اہم تبدیلی ہے۔ پہلے پیکجز درآمد کرتے وقت اس کی ضرورت نہیں تھی۔ material_ui صارف کے پروجیکٹ (بنڈل) میں، پیکیج پھر واضح انحصار کا اعلان کرتا ہے: material_uiپیکیج کے انحصار گراف کو تبدیل کریں۔ صارف آپ کے 2.0.0 اس کے علاوہ ہونا ضروری ہے۔ material_ui یہ دستیاب ہے اور ہجرت کے وقت بھی استعمال کیا جا سکتا ہے۔ سیمور کا بنیادی ٹکرانا اس کو واضح طور پر بتاتا ہے۔
منتقلی کے دوران پسماندہ مطابقت کو برقرار رکھیں
اگر آپ منتقلی کی مدت (نومبر 2026 سے پہلے) کے دوران پرانی اور نئی دونوں فلٹر سیٹنگز کو سپورٹ کرنا چاہتے ہیں، تو آپ ڈارٹ کی مشروط ایکسپورٹ فیچر استعمال کر سکتے ہیں۔
// lib/src/widgets.dart
// This is the internal file that handles the conditional import
export 'package:material_ui/material_ui.dart'
if (dart.library.nonexistent) 'package:flutter/material.dart';
تاہم، یہ نقطہ نظر پیچیدہ اور شاذ و نادر ہی ضروری ہے۔ فلٹر ٹیم کی سفارش آسان ہے۔ اپنے پیکجز کو اس پر منتقل کریں: material_uiبڑے ورژن بنائیں اور صارفین کو اپنی رفتار سے اپ گریڈ کرنے دیں۔ مطابقت پل material_ui اپنے ایپس کو منتقل کرنے والے صارفین کے لیے صارف کی طرف سے بقائے باہمی کو ہینڈل کرتا ہے۔
pub.dev اسکور چیک کریں۔
پیکیج کو منتقل کرنے کے بعد material_uiجامد تجزیہ جو pub.dev سکور کا تعین کرتا ہے منتقلی کو تسلیم کرتا ہے اور مناسب معاوضہ دیتا ہے۔ یہ ٹول اب غیر ہجرت شدہ پیکجوں کو کم اشاعت پوائنٹ سکور کے ساتھ جھنڈا لگاتا ہے۔ یہ ماحولیاتی نظام کو اپنانے کے لیے جان بوجھ کر ترغیب دینے والا ڈھانچہ ہے۔
فلٹر 3.47 میں ایک اور تبدیلی
Decoupling ہیڈ لائن کی خصوصیت ہے، لیکن Flutter 3.47 کچھ اہم تبدیلیاں لاتا ہے جو حقیقی دنیا کے منصوبوں کو متاثر کرتی ہے۔
Impeller اب ڈیسک ٹاپ پر ڈیفالٹ ہے۔
Impeller، Flutter کا اگلی نسل کا رینڈرنگ انجن، جو پہلے سے ہی iOS اور Android پر مقامی ہے، اب macOS، Windows اور Linux پر ڈیفالٹ پیش کنندہ ہے۔ امپیلر شیڈر کمپائلیشن سٹٹر کو ختم کرتے ہوئے رن ٹائم کے بجائے بلڈ ٹائم پر شیڈرز کو مرتب کرتا ہے (جب ایک اینیمیشن پہلی بار چلتی ہے تو ایک مختصر سٹٹر)۔
زیادہ تر منصوبوں کے لیے، یہ ایک شفاف بہتری ہے۔ حرکت پذیری پہلے فریم سے ہموار ہوجاتی ہے۔ اگر آپ رینڈرنگ کے مسائل کا سامنا کر رہے ہیں اور آپ کو عارضی طور پر impeller کو غیر فعال کرنے کی ضرورت ہے:
FLTEnableImpeller
// Windows: windows/runner/main.cpp
project.set_impeller_switch(flutter::ImpellerSwitch::Disabled);
// Linux: linux/my_application.cc
fl_dart_project_set_enable_impeller(project, FALSE);
مسترد کرنے کا یہ طریقہ کار ان منصوبوں کے لیے موجود ہے جو نئے ڈیفالٹ کے ساتھ کیڑے تلاش کرتے ہیں۔ Skia کا متبادل مستقبل کی ریلیز میں ہٹا دیا جائے گا، لہذا اگر آپ کو آپٹ آؤٹ کرنے کی ضرورت ہے، تو براہ کرم Flutter ٹیم کے ساتھ بگ رپورٹ درج کریں تاکہ ہم بنیادی مسئلہ کو حل کر سکیں۔
کم از کم iOS اور macOS ورژن اٹھائے گئے۔
Xcode 27 سپورٹ کے ساتھ، کم از کم تعاون یافتہ OS ورژن تبدیل ہو گیا ہے۔
Platform Previous Minimum New Minimum (Flutter 3.47+)
iOS 13 15
macOS 10.15 (Catalina) 12 (Monterey)
آپ کی ایپ ios/Runner.xcodeproj یا macos/Runner.xcodeproj اگر آپ ان نئی کم از کم سے نیچے تعیناتی کا ہدف بتاتے ہیں، تو آپ کی تعمیر ناکام ہو جائے گی۔ Xcode میں اپنے تعیناتی ہدف کو اپ ڈیٹ کریں یا Flutter CLI کو چلا کر اسے سنبھالنے دیں: flutter build ios آپ کو تضادات سے آگاہ کرتا ہے۔
iOS UIScene لائف سائیکل کی ذمہ داریاں
Legacy کا استعمال کرتے ہوئے Xcode 27 کے ساتھ بنائی گئی ایپس UIApplication ڈیلیگیشن لائف سائیکل (تازہ ترین ورژن نہیں) UIScene lifecycle) iOS 27 پر نہیں چلتا ہے۔ زیادہ تر فلٹر ایپس کے لیے، CLI خود بخود اس منتقلی کو تعمیر کے دوران ہینڈل کرتا ہے۔
اگر آپ کے ایپ میں حسب ضرورت مقامی کوڈ ہے۔ AppDelegate.swift یا AppDelegate.mمتبادل طور پر، اگر آپ ایسے پلگ ان استعمال کرتے ہیں جو میراثی لائف سائیکل پر منحصر ہیں، تو آپ کو فلٹر دستاویزات میں UIScene/Delegate اپنانے کے گائیڈ کی پیروی کرتے ہوئے انہیں دستی طور پر منتقل کرنے کی ضرورت ہوگی۔
ویجیٹ کا پیش نظارہ اب قابل اعتماد طریقے سے کام کرتا ہے۔
ویجیٹ کا پیش نظارہ، جو آپ کو پوری ایپ بنائے بغیر انفرادی ویجٹ پیش کرنے کی اجازت دیتا ہے، اب مستحکم ہے۔ کوئی راستہ نہیں .widget_preview/ پروجیکٹ روٹ میں ایک فولڈر تیز اسٹارٹ اپ کے لیے پیش نظارہ حالت کو محفوظ کرتا ہے۔ اگر آپ کی ٹیم ویجیٹ UI پر بہت زیادہ اعادہ کرتی ہے، تو یہ قابل عمل ہے۔
WebAssembly ڈیفالٹ ہونے کے قریب آ رہا ہے۔
Wasm ابھی Flutter Web کے لیے ڈیفالٹ نہیں ہے، لیکن یہ قریب تر ہوتا جا رہا ہے۔ آپ ابھی منتخب کر سکتے ہیں:
flutter build web --release --wasm
--wasm فلٹر ویب ایپس بنائیں جو JavaScript کے بجائے WebAssembly کو نشانہ بنائیں۔ کمپیوٹیشنل طور پر گہرا UIs کے لیے، کارکردگی کو بہتر بنانا ضروری ہے۔ شرط یہ ہے کہ آپ کا کوڈ اور انحصار استعمال کریں: package:web اس کے بجائے dart:htmlاس کی وجہ یہ ہے کہ موجودہ HTML لائبریریاں Wasm کے ذریعے تعاون یافتہ نہیں ہیں۔ مقبول ترین پیکجز پہلے ہی منتقل ہو چکے ہیں۔
فرسودگی کا شیڈول: جب پرانی درآمدات کام کرنا چھوڑ دیتی ہیں۔
اپنی نقل مکانی کی منصوبہ بندی کرنے کے لیے، اپنی ٹائم لائن کو سمجھنا ضروری ہے۔
ٹائم لائن فلٹر کے پچھلے مواد اور کیپرٹینو کی درآمدات سے منصوبہ بند منتقلی کو ظاہر کرتی ہے۔
اگست 2026، فلٹر 3.47: نیا material_ui اور cupertino_ui پیکیج ورژن 1.0 تک پہنچ گیا ہے۔ کہ dart fix نقل مکانی کے اوزار دستیاب ہیں۔ موجودہ درآمدات اب بھی کام کریں گی اور فرسودگی کے انتباہات پیدا نہیں کریں گی۔ ماحولیاتی نظام نئے پیکجوں میں منتقل ہونے لگتا ہے۔
نومبر 2026، فلٹر فال مستحکم: قابل احترام package:flutter/material.dart اور package:flutter/cupertino.dart درآمدات سرکاری طور پر فرسودہ ہیں۔ اسے استعمال کرنے والے ڈویلپرز تجزیہ کار میں فرسودگی کا انتباہ دیکھیں گے۔ موجودہ ایپلی کیشنز اس مرحلے پر مرتب اور چلتی رہیں گی۔
2027 میں مستقبل کی ریلیز: پرانی درآمدات بنڈل فلٹر SDK سے ہٹا دی جاتی ہیں۔ وہ منصوبے جو منتقل نہیں ہوئے ہیں اب ان درآمدات کا استعمال کرتے ہوئے مرتب نہیں کریں گے۔
ہجرت کا سب سے محفوظ وقت اب نومبر 2026 سے پہلے ہے، اور آپ کی پرانی درآمدات اب بھی صاف طور پر مرتب ہوں گی۔ اگر آپ فرسودگی کے انتباہ کی مدت (نومبر 2026 کو ہٹانے تک) کے دوران ہجرت کرتے ہیں، تو یہ اب بھی کام کرے گا، لیکن آپ کو تجزیہ کار کے شور کا سامنا کرنا پڑے گا۔ ہٹانے کے بعد ہجرت کے لیے فوری کارروائی کی ضرورت ہوتی ہے، جس سے آگے کی منصوبہ بندی سے بچا جا سکتا ہے۔
بہترین طرز عمل
جلد ہجرت کریں، ایک بار ہجرت کریں۔
ہمارے خودکار مائیگریشن ٹولز پروڈکشن کے لیے تیار ہیں۔ ابھی چلانے سے، آپ فوری طور پر تیز میٹریل اور کپرٹینو اپ ڈیٹس سے فائدہ اٹھا سکتے ہیں، فرسودگی کے انتباہ کے وقفوں سے مکمل طور پر بچ سکتے ہیں، اور ایکو سسٹم کے منحنی خطوط سے آگے رہ سکتے ہیں۔
وہ ٹیمیں جو جلد ہجرت کرتی ہیں وہ پرانے پیکجوں کا استعمال جاری رکھتے ہوئے نادانستہ طور پر نئے پیکجوں میں بریکنگ تبدیلیاں متعارف کروانے سے پرہیز کرتی ہیں۔
منتقلی کے بعد flutter_localizations کو ہٹا دیں۔
ہجرت کے بعد material_ui, flutter_localizations آپ کا پیکج pubspec.yaml یہ بے کار ہے۔ فراہم کردہ لوکلائزیشن مندوبین اب شامل ہیں: material_ui. ختم کرنا:
# REMOVE this from pubspec.yaml after migration
# flutter_localizations:
# sdk: flutter
# Also remove the import from all dart files
# Remove: import 'package:flutter_localizations/flutter_localizations.dart';
ریٹائرمنٹ flutter_localizations یہ غلطی کا سبب نہیں بنے گا، لیکن یہ آپ کے پروجیکٹ کے انحصار کو پڑھتے وقت غیر ضروری وزن اور ممکنہ الجھن کا سبب بنے گا۔
مطابقت کے پلوں کو عارضی طور پر استعمال کریں، مستقل طور پر نہیں۔
کہ MaterialUiCompatibilityBridge یہ ایک تبادلوں کا آلہ ہے۔ موجودگی کے ارد گرد اپنے فن تعمیر کو ڈیزائن نہ کریں۔ ہجرت کے وقت ان کو شامل کرنے کے لیے اطلاعات مرتب کریں اور جب تمام انحصار منتقل ہو جائیں تو انہیں ہٹا دیں۔ material_ui. اس کا استعمال کرتے ہوئے اپنے انحصار کی منتقلی کی صورتحال کو باقاعدگی سے چیک کریں:
flutter pub outdated
مواد اور کپرٹینو پیکیج ورژن کو CI میں پن کریں۔
کیونکہ material_ui اور cupertino_ui ہفتہ وار اپ ڈیٹس اب دستیاب ہیں، جو آپ کو اپنے CI ماحول میں مخصوص ورژن کو پن کرنے کی اجازت دیتے ہیں تاکہ دوبارہ پیدا ہونے والی تعمیرات کو یقینی بنایا جا سکے۔
# pubspec.yaml for production stability
dependencies:
material_ui: 1.2.0 # Exact version pin for CI stability
cupertino_ui: 1.1.0
ترقی کے استعمال کے لیے: ^ پابندیاں ٹھیک ہیں اور تازہ ترین رہیں۔ CI اور پروڈکشن بلڈز کے لیے، درست ورژن کو پن کرنا اور انہیں جان بوجھ کر اپ گریڈ کرنا آپ کو بلڈز کے درمیان تبدیلیوں پر بہتر کنٹرول فراہم کرتا ہے۔
عام غلطیاں
ایک ہی فائل میں پرانی اور نئی درآمدات کو مکس کریں۔
// WRONG: Both old and new imports in the same file
import 'package:flutter/material.dart';
import 'package:material_ui/material_ui.dart'; // Duplicate
ایک ہی فائل میں دونوں درآمدات کو شامل کرنا بے کار ہے اور اس کے نتیجے میں ڈپلیکیٹ قسم کی تعریفوں کے بارے میں تجزیہ کار کی وارننگ ہو سکتی ہے۔ منتقلی کے بعد، ہر فائل میں بالکل ایک مواد درآمد ہونا ضروری ہے۔ package:material_ui/material_ui.dart. چلائیں flutter analyze اس مسئلہ کے ساتھ فائل کو تلاش کرنے کے لئے
جب آپ کو ضرورت ہو مطابقت کے پل کو بھول جانا
میں نے ایپ کی درآمدات کو منتقل کیا، لیکن MaterialUiCompatibilityBridgeاگر آپ کا کوئی انحصار اب بھی پرانا بنڈل مواد استعمال کرتا ہے، تو آپ کو رن ٹائم کی غلطی ہو سکتی ہے جہاں وراثت میں ملنے والا تھیم ڈیٹا نہیں مل سکتا کیونکہ ویجیٹ غلط سیاق و سباق کو دیکھ رہا ہے۔ علامات Null تھیم یا "Type MaterialLocalizations کے لیے کوئی والدین نہیں ملا” کی خرابی ہیں۔ حل ہمیشہ ایک پل شامل کرنا ہے۔
پہلے پیکیج کو شامل کیے بغیر پب گیٹ آف ڈارٹ فکس چلائیں۔
# WRONG order
dart fix --apply --code=migrate_design_widgets
# If pubspec.yaml was not updated, analysis errors remain
# CORRECT order if the tool fails to update pubspec.yaml
flutter pub add material_ui
flutter pub add cupertino_ui
dart fix --apply
کہ dart fix درآمدی اپ ڈیٹس کو درست طریقے سے درست کرنے کے لیے، آپ کو کمانڈ کا استعمال کرتے ہوئے اپنے پروجیکٹ میں پیکجز کو چیک کرنے کے قابل ہونا چاہیے۔ اگر آپ بھاگتے ہیں۔ dart fix پیکج آنے سے پہلے pubspec.yamlآپ امپورٹ سٹرنگ کو اپ ڈیٹ کر سکتے ہیں، لیکن اس سے ناقابل حل درآمدات رہ سکتی ہیں جنہیں تجزیہ کار غلطیوں کے طور پر جھنڈا دیتا ہے۔
پیکجوں کو منتقل کرتے وقت بڑے ورژن کو نہ ٹکرائیں۔
اگر آپ کسی پیکیج کو برقرار رکھتے ہیں اور اسے منتقل کر رہے ہیں۔ material_ui ایسے پیکجوں کے صارفین جنہوں نے ابھی تک بڑے ورژن کو لاگو نہیں کیا ہے اور انہیں ابھی تک شامل نہیں کیا ہے۔ material_ui ان کا pubspec.yaml پیکج کو اپ ڈیٹ کرتے وقت انحصار کے حل کی ناکامی ہوتی ہے۔
آپ کو ہمیشہ بڑے ورژن میں اضافہ کرنا چاہئے جب کوئی پیکج نئی بیرونی انحصار شامل کرتا ہے۔ اس کا مطلب ہے بنڈل شدہ SDK لائبریریوں سے واضح پیکیج انحصار میں تبدیل ہونا۔
منتقلی کے بعد وجیٹس سے مختلف برتاؤ کی توقع کریں۔
کچھ ڈویلپرز توقع کرتے ہیں کہ اس منتقلی کے حصے کے طور پر میٹریل 3 ایکسپریسیو یا دیگر میٹریل ڈیزائن اپ ڈیٹس میں منتقلی ہوگی۔ یہ سچ نہیں ہے۔ material_ui 1.0 اس کی وفادار کاپی ہے: package:flutter/material.dart منجمد ہونے کے مقام پر۔ یہ وہی ویجیٹ ہے جس میں ایک ہی طرز عمل کے ساتھ ایک ہی بصری انداز ہے۔ ڈیکپلنگ ایک آرکیٹیکچرل تبدیلی ہے، بصری دوبارہ ڈیزائن نہیں۔ میٹریل 3 ایکسپریسیو میں مستقبل کی بصری اصلاحات اگلے ہفتہ وار ریلیز میں دستیاب ہوں گی۔ material_ui 1.0 سے۔
نتیجہ
فلٹر SDK کور سے میٹریل اور کپرٹینو کو الگ کرنا فلٹر نے اپنی ابتدائی ریلیز کے بعد سے کی گئی سب سے اہم تعمیراتی تبدیلیوں میں سے ایک ہے۔ فلٹر میں ڈیکپلنگ میٹریل اور کپرٹینو کے پچھلے مضمون میں بیان کردہ وژن اب مکمل طور پر محسوس ہو چکا ہے اور فلٹر 3.47 میں پیداوار کو اپنانے کے لیے تیار ہے۔
فلٹر ٹیم نے جو ہجرت کا راستہ بنایا ہے وہ اتنا ہی ہموار ہے جتنا کہ ایک اہم تعمیراتی تبدیلی۔ ایک خودکار ٹول درآمدی اپڈیٹس کو ہینڈل کرتا ہے۔ مطابقت کے پل ماحولیاتی نظام کے خلا کو دور کرتے ہیں۔ API کی سطح ایک جیسی ہے اور ویجیٹ کوڈ تبدیل نہیں ہوتا ہے۔ لوکلائزیشن سیٹ اپ آسان ہو گیا ہے۔ اور نتائج فوری ہیں۔ ڈیزائن سسٹم کو ہفتہ وار اپ ڈیٹ کیا جاتا ہے، سہ ماہی SDK ریلیز سائیکل سے آزاد۔
فرسودگی کی گھڑی اس ریلیز کے ساتھ شروع ہو گئی ہے۔ نومبر 2026 ہے جب پرانی درآمدات کو سرکاری طور پر فرسودہ کر دیا جائے گا۔ تمام ٹیموں کے لیے منتقلی مکمل کرنے کے لیے یہ ایک آرام دہ رن وے ہے، لیکن یہ انتظار کرنے کی کوئی وجہ نہیں ہے۔ ہر ہفتے آپ کی تاخیر ہفتہ وار مواد کی اپ ڈیٹس کا ایک ہفتہ ہے جو آپ کو موصول نہیں ہوتی ہے۔
تین عملی اقدامات جو آپ کو ابھی اٹھانے کی ضرورت ہے: کارروائی کریں۔ flutter upgrade فلٹر 3.47 حاصل کرنے کے لیے، چلائیں: dart fix --apply --code=migrate_design_widgets منتقلی اور درآمد کو چلانے کے لیے flutter analyze نتائج چیک کرنے کے لیے۔ زیادہ تر پروجیکٹس کے لیے، یہ تینوں کمانڈز ایک مکمل منتقلی ہیں۔ مطابقت کے پل شامل کریں اگر آپ کے انحصار کو ان کی ضرورت ہے، اور منتقلی کے وقت انہیں ہٹا دیں۔
فلٹر 3.47 ایک اہم ورژن ہے۔ ڈیکپلنگ، تیز تر تکرار، آسان کنٹریبیوشن، اسٹائل نیوٹرل کور، اور آزاد ڈیزائن سسٹم ورژننگ کے ذریعے کھلا ہوا ایک ماحولیاتی نظام فلٹر کو ڈیزائن کے لحاظ سے واقعی ماڈیولر بناتا ہے۔ یہ اب ہجرت کے قابل ہے۔
حوالہ جات
-
فلٹر 3.47 میں نیا کیا ہے: آفیشل فلٹر بلاگ پوسٹ اسٹینڈ ایلون UI پیکیج، ڈیسک ٹاپ امپیلر، مستحکم ویجیٹ پیش نظارہ، اور اس ریلیز میں دیگر تمام تبدیلیاں متعارف کراتی ہے۔
-
فلٹر بریکنگ تبدیلیوں کا صفحہ: ہر فلٹر ریلیز میں بریکنگ تبدیلیوں کی مستند فہرست، بشمول ڈیکپلنگ ہجرت کی تفصیلات۔
-
Material_ui by pub.dev: Flutter.dev کے ذریعے شائع کردہ Flutter کے لیے باضابطہ اسٹینڈ اسٹون میٹریل ڈیزائن ویجیٹ لائبریری۔
package:flutter/material.dart. -
cupertino_ui pub.dev سے: فلٹر کے لیے آفیشل اسٹینڈ اسٹون کپرٹینو ویجیٹ لائبریری۔
package:flutter/cupertino.dart. -
Material_ui GitHub ریپوزٹری: ماخذ کوڈ، ایشو ٹریکنگ، اور اسٹینڈ اسٹون میٹریل پیکج کے لیے کنٹریبیوشن گائیڈز۔
-
Flutter سے مواد اور Cupertino کو الگ کرنا: Flutter 3.47 مکمل ہونے سے پہلے علیحدگی کے اقدام کی حوصلہ افزائی، ڈیزائن کے فیصلوں اور پیش نظارہ کی حیثیت کی وضاحت کرنے والا ایک پچھلا freeCodeCamp مضمون۔
-
Decoupling GitHub پروجیکٹ: ایک عوامی GitHub پروجیکٹ بورڈ جو ڈیکپلنگ کے کام کو ٹریک کرتا ہے، یہ دکھاتا ہے کہ کیا مکمل ہو چکا ہے اور کیا ابھی تک جاری ہے۔
-
پلگ ان مصنفین کے لیے Swift Package Manager Migration Guide: پلگ ان مصنفین کے لیے جنہیں Xcode 27 ٹرانزیشن کے حصے کے طور پر Swift Package Manager میں منتقل ہونے کی ضرورت ہے۔
-
Impeller Rendering Engine Documentation: Impeller کے بارے میں مکمل دستاویزات، اب تمام پلیٹ فارمز پر ڈیفالٹ پیش کنندہ، بشمول عارضی طور پر آپٹ آؤٹ کرنے کا طریقہ اور رینڈرنگ بگز کی اطلاع کیسے دی جائے۔