موزوں iOS آرکیٹیکچر کا انتخاب کیسے کریں (حصہ 2)

ایم وی سی ، ایم وی پی ، ایم وی وی ایم ، وائپر یا وی آئی پی

آپ یہاں ایک حصہ اول سے مشورہ کرسکتے ہیں۔

IOS کے سب سے اہم فن تعمیرات

ایک مختصر جائزہ

ایم وی سی

ایم وی سی پرتیں مندرجہ ذیل ہیں۔

ایم: کاروباری منطق ، نیٹ ورک پرت اور ڈیٹا تکمیل پرت

V: UI سطح (UIKit آبجیکٹ ، اسٹوری بورڈز ، Xibs)

ج: ماڈل اور نظریہ کے مابین ثالثی کا سمنوی ہے۔

ایم وی سی کو سمجھنے کے لئے ہمیں اس سیاق و سباق کو سمجھنے کی ضرورت ہے جس میں ایجاد ہوئی تھی۔ ایم وی سی کی ایجاد پرانے ویب ترقیاتی دنوں میں کی گئی تھی جب مناظر کی کوئی حیثیت نہیں تھی۔ پرانے دنوں میں ، جب بھی ہمیں ویب سائٹ میں کسی بصری تبدیلی کی ضرورت ہوتی ہے تو براؤزر ہر وقت HTML کو دوبارہ لوڈ کرتا ہے۔ اس وقت ، اس بارے میں کوئی خیال نہیں تھا کہ نقطہ نظر کی حالت برقرار ہے اور اسے محفوظ کیا جارہا ہے۔

مثال کے طور پر ، کچھ ڈویلپرز بھی تھے جنہوں نے ایک ہی HTML فائلوں ، پی ایچ پی اور ڈیٹا بیس تک رسائی کا استعمال کیا۔ لہذا ایم وی سی کا بنیادی حوصلہ افزائی کی سطح کو ماڈل کی سطح سے الگ کرنا تھا۔ اس سے ماڈل کی سطح کی آزمائش میں اضافہ ہوا۔ مبینہ طور پر ایم وی سی میں نظریہ اور ماڈل کی تہوں کو ایک دوسرے کے بارے میں نہیں جاننا چاہئے۔ اس کو ممکن بنانے کے لئے ، ایک انٹرمیڈیٹ پرت ایجاد کی گئی تھی جسے کنٹرولر کہا جاتا ہے۔ یہ ایس آر پی تھی جسے لاگو کیا گیا تھا۔

ایم وی سی سائیکل کی ایک مثال:

  1. صارف کی کاروائی / منظر کی سطح میں استعمال کنندہ کے ایونٹ (جیسے "اپ ڈیٹ ایکشن") کو متحرک کیا جاتا ہے اور اس عمل کو کنٹرولر کو بتایا جاتا ہے۔
  2. کنٹرولر جو ماڈل کی سطح پر ڈیٹا بھیجتا ہے
  3. واپس آئے ڈیٹا کو کنٹرولر کو ماڈل کریں
  4. کنٹرولر کا کہنا ہے کہ یہ منظر نئے اعداد و شمار کے ساتھ اپنی حیثیت کو اپ ڈیٹ کرے گا
  5. اس کی حالت کی تازہ کاری دیکھیں

ایپل ایم وی سی

آئی او ایس میں ، ویو کنٹرولر کو یو آئی کیٹ اور لائف سائکل ویو کے ساتھ جوڑ دیا گیا ہے ، لہذا یہ خالص ایم وی سی نہیں ہے۔ تاہم ، ایم وی سی تعریف میں یہ کہنے کے لئے کچھ بھی نہیں ہے کہ کنٹرولر نقطہ نظر یا ماڈل کے مخصوص نفاذ کو نہیں جان سکتا ہے۔ اس کا بنیادی مقصد ماڈل کی سطح کی ذمہ داریوں کو نقطہ نظر کی سطح سے الگ کرنا ہے تاکہ ہم ان کا دوبارہ استعمال کرسکیں اور تنہائی میں ماڈل کی سطح کو جانچ سکیں۔

ویو کنٹولر میں ماڈل کا نظارہ ہوتا ہے اور اس کا مالک ہوتا ہے۔ مسئلہ یہ ہے کہ ہم کنٹرولر کوڈ اور ویو کوڈ دونوں ہی ویو کنٹرولٹر کو لکھ رہے ہیں۔

ایم وی سی اکثر اس کی وجہ بنتا ہے جس کو بڑے پیمانے پر ویو کنٹرولر مسئلہ کہا جاتا ہے ، لیکن یہ صرف ایسی ایپس میں ہوتا ہے جس میں کافی پیچیدگی ہوتی ہے اور سنگین کاروبار بن جاتا ہے۔

یہاں کچھ طریقے ہیں جن کا استعمال ڈویلپر ویو کنٹرولر کو واضح کرنے کے لئے کرسکتا ہے۔ کچھ مثالیں:

  • دیگر طبقات جیسے ٹیبل ویو کے طریقوں کا ڈیٹا ماخذ اور مندوب ڈیزائن ڈیزائن کا نمونہ استعمال کرتے ہوئے دیگر فائلوں کے لئے ڈیلیگیٹ کے لئے وی سی منطق نکالیں۔
  • ساخت کی ذمہ داریوں کی ایک واضح خرابی پیدا کریں (مثال کے طور پر ، VC کو بچوں کے نظارے کے کنٹرول میں تقسیم کرنا)۔
  • ورچوئل کنٹرولر میں نیویگیشن منطق کو لاگو کرنے کی ذمہ داری دور کرنے کے لئے کوآرڈینیٹر ڈیزائن پیٹرن کا استعمال کریں
  • ڈیٹا پریسنٹر ریپر کلاس استعمال کریں جو منطق کو سمیٹتا ہے اور ڈیٹا ماڈل کو ڈیٹا آؤٹ پٹ میں تبدیل کرتا ہے جو آخری صارف کے سامنے پیش کردہ ڈیٹا کی نمائندگی کرتا ہے۔

ایم وی سی بمقابلہ ایم وی پی

جیسا کہ آپ ایم وی پی سے ڈایاگرام دیکھ سکتے ہیں ، ایم وی سی بہت مماثلت ہے

ایم وی سی ایک قدم آگے تھا ، لیکن پھر بھی اس میں غیر موجودگی یا کچھ چیزوں کے بارے میں خاموشی کا نشان تھا۔

اس دوران میں ، ورلڈ وائڈ ویب بڑھتا جارہا تھا اور ڈویلپر کمیونٹی میں بہت ساری چیزیں تیار ہورہی ہیں۔ مثال کے طور پر ، پروگرامرز نے ایجیکس کا استعمال شروع کیا اور ایک ہی بار میں پورے HTML صفحے کی بجائے صفحات کے کچھ حصوں کو ہی لوڈ کیا۔

ایم وی سی میں ، میری رائے میں ، اس بات کا کوئی اشارہ نہیں ہے کہ کنٹرولر کو ویو (غیر موجودگی) کے مخصوص نفاذ کے بارے میں معلوم نہیں ہونا چاہئے۔

ایچ ٹی ایم ایل ویو لیئر کا ایک حصہ تھا ، اور بہت سارے معاملات وہ احمق تھے۔ کچھ معاملات میں ، یہ صارف سے واقعات وصول کرتا ہے اور GUI کا بصری مواد دکھاتا ہے۔

چونکہ ویب صفحات کے کچھ حصوں میں بھری ہوئی چیزیں ، اس تقسیم کی وجہ سے نقطہ نظر کی حالت کا تحفظ اور پیش کش کی منطق کے لئے ذمہ داریوں سے علیحدگی کی زیادہ ضرورت ہوگئ۔

پیش کش کی منطق وہ منطق ہے جو کنٹرول کرتی ہے کہ صارف انٹرفیس کو کس طرح ظاہر کیا جاتا ہے اور صارف انٹرفیس عناصر کیسے ایک دوسرے کے ساتھ تعامل کرتے ہیں۔ ایک مثال اس بات کی کنٹرول منطق ہے کہ لوڈنگ انڈیکیٹر کب دکھانا / متحرک کرنا شروع کردے اور کب اس کو دکھانا / متحرک کرنا چھوڑ دے۔

ایم وی پی اور ایم وی وی ایم میں ، نظریہ کی پرت اتنی مورھ ہونی چاہئے کہ اس میں کوئی منطق یا ذہانت موجود نہ ہو ، اور آئی او ایس میں ویو کنٹرولر منظر نگاری کی پرت کا حصہ ہونا چاہئے۔ حقیقت یہ ہے کہ دیکھیں گونگا ہے اس کا مطلب یہ ہے کہ یہاں تک کہ پیش کش کی منطق ویو ہوائی جہاز سے باہر ہی رہتی ہے۔

ایم وی سی کے ساتھ ایک مسئلہ یہ ہے کہ یہ واضح نہیں ہے کہ پریزنٹیشن کی منطق کو کہاں جانا چاہئے۔ اس کے بارے میں وہ صرف خاموش ہے۔ کیا پریزنٹیشن منطق کو دیکھنے کی سطح میں ہونا چاہئے یا ماڈل کی سطح میں؟

اگر ماڈل کا کردار صرف "خام ڈیٹا" مہیا کرنا ہے تو ، اس کا مطلب یہ ہے کہ اس نقطہ نظر میں کوڈ اس طرح ہے:

مندرجہ ذیل مثال پر غور کریں: ہمارے پاس پہلا اور آخری نام والا صارف ہے۔ اس نظریہ میں ہمیں صارف کا نام "آخری نام ، پہلا نام" (جیسے "فلورز ، ٹیاگو") ظاہر کرنا ہے۔

اگر ماڈل کا کردار "خام ڈیٹا" مہیا کرنا ہے تو ، اس کا مطلب یہ ہے کہ نقطہ نظر میں کوڈ اس طرح ہے:

پہلے نام = صارف_موڈیل.جیٹ فرسٹنیئم () آخری نام = صارف_موڈیل.بیٹ لسٹ نام () کا نام لیبل ڈاٹ ٹیکسٹ = آخری نام + "،" + پہلا نام بتائیں

اس کا مطلب یہ ہے کہ صارف انٹرفیس منطق کو سنبھالنا View کی ذمہ داری ہے۔ تاہم ، اس سے صارف کے انٹرفیس منطق کی جانچ کرنا ناممکن ہوجاتا ہے۔

دوسرا نقطہ نظر یہ ہے کہ ماڈل کو صرف وہی ڈیٹا دکھائیں جو دکھائے جانے کی ضرورت ہو اور کاروباری منطق کو دیکھنے سے چھپائے۔ لیکن پھر ہمارے پاس ایسے ماڈل موجود ہیں جو کاروباری منطق اور صارف انٹرفیس منطق دونوں کو سنبھالتے ہیں۔ یہ ایک قابل آزمائش ہستی ہوگی ، لیکن پھر ماڈل پر منحصر ہوتا ہے۔

نام = صارفموڈل.بیٹ ڈس پلے نام () کا نام لیبل ڈاٹ ٹیکسٹ = نام دیں

یہ ایم وی پی پر واضح ہے اور پیش کش کی منطق پیش کش سطح پر باقی ہے۔ اس سے پریزینٹر لیول کی آزمائش میں اضافہ ہوتا ہے۔ اب ماڈل اور پریزینٹر پرت کو بغیر کسی دشواری کے جانچ کیا جاسکتا ہے۔

عام طور پر ایم وی پی کے نفاذ میں نظارہ انٹرفیس / پروٹوکول کے پیچھے پوشیدہ ہوتا ہے اور پیش کش میں UIKit کا کوئی حوالہ نہیں ہونا چاہئے۔

نوٹ کرنے کے لئے ایک اور چیز عبوری انحصار ہے۔

اگر کنٹرولر کے پاس بطور انحصار بزنس پرت ہوتا ہے اور بزنس لیئر میں انحصار کے بطور ڈیٹا رس پرت ہوتا ہے تو ، کنٹرولر کو ڈیٹا تکمیل پرت کے لئے ایک عبوری انحصار ہوتا ہے۔ چونکہ ایم وی پی کے نفاذ عام طور پر تمام سطحوں کے درمیان معاہدہ (پروٹوکول) استعمال کرتے ہیں ، لہذا وہاں کوئی عارضی انحصار نہیں ہوتا ہے۔

مختلف پرتیں بھی مختلف وجوہات کی بناء پر اور مختلف نرخوں پر تبدیل ہوتی ہیں۔ لہذا اگر آپ ایک سطح پر سوئچ کرتے ہیں تو ، اس سے دوسرے درجوں میں ثانوی اثرات / پریشانی پیدا نہیں ہونی چاہئے۔

پروٹوکول کلاسوں سے زیادہ مستحکم ہیں۔ نوشتہ جات میں نفاذ کی کوئی تفصیلات شامل نہیں ہیں اور معاہدوں سے منسلک نہیں ہیں۔ لہذا ، یہ ممکن ہے کہ دوسرے سطحوں کو متاثر کیے بغیر ایک سطح کے نفاذ کی تفصیلات میں تبدیلی کی جاسکے۔

معاہدے (پروٹوکول) تہوں کے مابین ایک ڈیسپلنگ پیدا کرتے ہیں۔

ایم وی پی بمقابلہ ایم وی وی ایم

ایم وی وی ایم آریھ

ایم وی پی اور ایم وی وی ایم کے مابین اہم اختلافات میں سے ایک یہ ہے کہ ایم وی پی میں نظریہ کے ساتھ پیش کنندہ انٹرفیس ہوتا ہے اور ایم وی وی ایم میں نقطہ نظر ڈیٹا اور واقعہ کی تبدیلیوں پر مرکوز ہوتا ہے۔

ایم وی پی میں ہم پیش کنندہ اور انٹرفیس / پروٹوکول کا استعمال کرتے ہوئے دیکھنے کے مابین ایک دستی لنک بناتے ہیں۔ ایم وی وی ایم میں ہم RxSwift ، KVO یا عام طریقہ کار اور بندش کے ساتھ میکانزم کے ساتھ خود کار طریقے سے ڈیٹا کا پابند کرتے ہیں۔

ایم وی وی ایم میں ہمیں ویو موڈل اور ویو کے مابین کسی معاہدے (جیسے جاوا انٹرفیس / iOS پروٹوکول) کی بھی ضرورت نہیں ہے ، کیونکہ ہم عام طور پر آبزرور ڈیزائن پیٹرن کے ذریعے بات چیت کرتے ہیں۔

ایم وی پی مندوبین کا نمونہ استعمال کرتا ہے کیونکہ پیش کش پرت کو نمائندگی کرنے والی پرت کو ویو پرت پر کمانڈ کرتا ہے۔ لہذا ، اسے قول کے بارے میں کچھ جاننے کی ضرورت ہے ، چاہے یہ صرف انٹرفیس / پروٹوکول پر دستخط ہے۔ اطلاعاتی مرکز اور ٹیبل ویو کے نمائندوں کے مابین فرق کے بارے میں سوچئے۔ مواصلاتی چینل بنانے کیلئے اطلاعاتی مرکز کو کسی بھی انٹرفیس کی ضرورت نہیں ہے۔ تاہم ، ٹیبل ویو ڈیلیگیٹس ایک پروٹوکول استعمال کرتا ہے جسے کلاسوں کو لاگو کرنا چاہئے۔

چارج اشارے کی پیش کش کی منطق کے بارے میں سوچئے۔ ایم وی پی میں ، پریزینٹر ویو پروٹوکول.شو شو لوڈنگ انڈیکیٹر چلاتا ہے۔ ایم وی وی ایم میں ، ویو موڈل میں آئس لوڈنگ پراپرٹی ہوسکتی ہے۔ جب یہ پراپرٹی خود تبدیل ہوجاتی ہے اور خود کو اپ ڈیٹ کرتی ہے تو شناخت کرنے کے لئے ویو لیئر خود کار طریقے سے ڈیٹا بائنڈنگ کا استعمال کرتی ہے۔ ایم وی پی ایم وی وی ایم سے زیادہ مجبور ہوتا ہے کیونکہ پیشکنندہ حکم دیتا ہے۔

ایم وی وی ایم براہ راست آرڈرز کے مقابلے میں ڈیٹا کی تبدیلیوں کے بارے میں زیادہ ہے ، اور ہم اپ ڈیٹس کو دیکھنے کے ل data ڈیٹا کی تبدیلیوں کو جوڑتے ہیں۔ جب ہم MVVM کے ساتھ ساتھ RxSwift اور ایک عملی فعالی پروگرامنگ نمونہ استعمال کرتے ہیں تو ہم نے اس کوڈ کو اور بھی کم مجبور اور زیادہ اعلانیہ بنا دیا ہے۔

ایم وی وی ایم کی جانچ کرنا ایم وی پی سے زیادہ آسان ہے ، کیوں کہ ایم وی وی ایم آبزرور ڈیزائن پیٹرن کا استعمال کرتا ہے ، جو اعداد و شمار کو اعادہ کردہ انداز میں اجزاء کے درمیان منتقل کرتا ہے۔ لہذا ہم صرف دو چیزوں کا موازنہ کرکے اعداد و شمار میں ہونے والی تبدیلیوں کو دیکھ کر جانچ سکتے ہیں ، بجائے یہ کہ نقطہ نظر اور پیش کنندہ کے مابین مواصلات کی جانچ کے ل. طریقہ کی کال کا مذاق اڑایا جائے۔

PS: میں نے اس آئٹم میں کچھ تازہ کاری کی جس کی وجہ سے اس میں بہت اضافہ ہوا۔ لہذا اس کو تین حصوں میں تقسیم کرنا ضروری تھا۔ آپ یہاں تیسرا حصہ پڑھ سکتے ہیں۔

حصہ دو یہاں ختم ہوتا ہے۔ تمام آراء خوش آئند ہیں۔ حصہ تین وی آئی پی ای آر ، وی آئی پی ، ری ایکٹیٹو پروگرامنگ ، تجارتی آفس ، رکاوٹیں اور سیاق و سباق سے متعلق ہے۔

پڑھنے کے لئے آپ کا شکریہ! اگر آپ کو اس مضمون سے لطف اندوز ہوا ہے تو ، براہ کرم تالیاں بجائیں تاکہ دوسرے بھی اسے پڑھ سکیں :)