NSNotificationCenterایک مفید API ہے جو ایپل کے فریم ورک میں وسیع ہے ، اور اکثر ہمارے اپنے کوڈ میں بہت زیادہ استعمال دیکھتا ہے۔ میں نے پہلےNSNotificationCenter مقصد C میں عمارت کی کھوج کی ۔ آج ، میں اسے سوئفٹ میں بنانا چاہتا ہوں ، لیکن اسی خیال کی صرف ایک اور تطبیق نہیں۔ اس کے بجائے ، میں API لینے جا رہا ہوں اور اسے تیز ، بہتر ، مضبوط بنانے جا رہا ہوں ، اور سوئفٹ کی پیش کردہ تمام اچھی چیزوں سے فائدہ اٹھانے جا رہا ہوں۔
NSNotifications
این ایس نوٹیفیکیشن دونوں سادہ اور طاقتور ہیں ، یہی وجہ ہے کہ وہ اکثر فریم ورک میں دکھائی دیتے ہیں۔ خاص طور پر ، ان کے چند مخصوص فوائد ہیں:
- نوٹیفکیشن بھیجنے والوں اور وصول کرنے والوں کے درمیان ڈھیلے جوڑے۔
- ایک نوٹیفکیشن کے لیے ایک سے زیادہ وصول کنندگان کے لیے معاونت۔
userInfoپراپرٹی کا استعمال کرتے ہوئے نوٹیفکیشن پر کسٹم ڈیٹا کے لیے سپورٹ ۔
کچھ نقصانات بھی ہیں:
- اطلاعات کے لیے بھیجنا اور رجسٹر کرنا آپ کی کلاسوں کے ساتھ واضح تعلق کے بغیر سنگلٹن مثال کے ساتھ بات چیت کرنا شامل ہے۔
- یہ ہمیشہ واضح نہیں ہوتا کہ کسی خاص طبقے کے لیے کیا اطلاعات دستیاب ہیں۔
- استعمال ہونے والی اطلاعات کے لیے
userInfo، یہ ہمیشہ واضح نہیں ہوتا کہ لغت میں کونسی چابیاں دستیاب ہیں۔ userInfoچابیاں متحرک طور پر ٹائپ کی جاتی ہیں اور بھیجنے والے اور وصول کرنے والے کے مابین تعاون کی ضرورت ہوتی ہے جسے زبان میں بیان نہیں کیا جاسکتا ، اور غیر چیزوں کی قسموں کے لیے گندا باکسنگ/ان باکسنگ۔- نوٹیفکیشن رجسٹریشن کو ہٹانے کے لیے ایک واضح ہٹانے کی کال درکار ہے۔
- کسی بھی نوٹیفکیشن کے لیے کون سی اشیاء رجسٹرڈ ہیں اس کا معائنہ کرنا مشکل ہے ، جو ڈیبگ کرنا مشکل بنا سکتا ہے۔
سوئفٹ میں نوٹیفیکیشنز کا دوبارہ تصور کرنے میں میرا مقصد ان مسائل کا حل ہے۔
API کا خاکہ API
کا عوامی چہرہ ایک کلاس کہلاتا ہے ObserverSet۔ ایک ObserverSetمثال مبصرین کا ایک مجموعہ رکھتی ہے جو کسی خاص چیز کی طرف سے بھیجی گئی ایک خاص اطلاع میں دلچسپی رکھتی ہے۔ سٹرنگ کنسٹینٹس کا اعلان کرنے اور سنگلٹن کے ذریعے ثالثی کرنے کے بجائے ، نوٹیفکیشن کا وجود صرف کلاس کی عوامی ملکیت ہے:
class ExampleNotificationSender {
public let exampleObservers = ObserverSet < Void > ()
یہ Voidنوٹیفیکیشن کے ساتھ بھیجے گئے ڈیٹا کی قسم ہے۔ Voidبغیر کسی اضافی ڈیٹا کے خالص اطلاع کی نشاندہی کرتا ہے۔ ڈیٹا بھیجنا اتنا ہی آسان ہے جتنا کہ قسم فراہم کرنا:
public let newURLObservers = ObserverSet < NSURL > ()
یہ ایک نوٹیفکیشن ہے جو NSURLہر مبصر کو ہر بار بھیجنے پر فراہم کرتا ہے ۔
ڈیٹا کے ایک سے زیادہ ٹکڑے ٹکڑوں کے جادو سے کوئی مسئلہ نہیں ہیں:
public let newItemObservers = ObserverSet < ( String ، Int ) > ()
یہ ہر مبصر کو ایک نئی شے کا نام اور انڈیکس فراہم کرتا ہے۔ اگر آپ اسے مزید واضح کرنا چاہتے ہیں تو آپ پیرامیٹرز کے نام بھی دے سکتے ہیں۔
public let newItemObservers = ObserverSet < ( name : String ، index : Int ) > ()
ایک مبصر کو رجسٹر کرنے کے لیے ، مبصر سیٹ میں ایک کال بیک شامل کریں:
اعتراض . exampleObservers . شامل { println ( "ایک مثال نوٹیفکیشن مل گیا" ) }
اعتراض . newURLObservers . شامل کریں { println ( "ایک نیا URL ملا: \ ($ 0)" ) }
یہ addطریقہ ایک ٹوکن لوٹاتا ہے جو مبصر کو ہٹانے کے لیے استعمال کیا جا سکتا ہے۔
let token = object . newItemObservers . شامل کریں { println ( "انڈیکس \ ($ 1) پر \ ($ 0) نامی ایک نئی چیز ملی ہے" ) }
...
آبجیکٹ ۔ newItemObservers . ہٹا دیں ( ٹوکن )
نوٹیفیکیشن کے لیے ایک عام معاملہ یہ ہے کہ انھیں ایک طریقہ کے ساتھ وصول کیا جائے ، اور جب نوٹیفکیشن کو منسوخ کیا جائے تو نوٹیفکیشن کو رجسٹرڈ کریں۔ مختلف addطریقوں سے اس کو پورا کرنا آسان ہے :
اعتراض . newItemObservers . add ( self ، self . dynamicType . gotNewItem )
func gotNewItem ( name : String ، index : Int ) {
println ( "Got a new item: \ (name) \ (index)" )
}}
self.dynamicTypeنحو تھوڑا سا شبدبہل اور بے کار ہے، لیکن قابل برداشت ہے. مبصر سیٹ ایک کمزور حوالہ رکھے گا selfاور خود بخود مبصر کو ہٹا دے گا جب مثال کو منسوخ کر دیا جائے گا ، اور اس دوران gotNewItemجب بھی وہ کوئی نوٹیفیکیشن بھیجے گا تو اس کی درخواست ہوگی۔
نوٹیفکیشن بھیجنا notifyمناسب پیرامیٹرز کو کال کرنا اور پاس کرنا شامل ہے :
exampleObservers . مطلع کریں ()
newURLObservers . ( newURL ) newItemObservers کو مطلع کریں ۔ مطلع کریں ( نام : newItemName ، index : newItemIndex )
یہ واقعی ایک اچھا API بناتا ہے۔ اوپر درج نقصانات سے گزرنا:
- اس میں کوئی سنگلٹن شامل نہیں ہے۔ ہر
(object, notification)جوڑے کی نمائندگی ایک الگ مبصر سیٹ مثال کے ساتھ کی جاتی ہے۔ - کلاس کے لیے دستیاب تمام اطلاعات اس کلاس کی عوامی خصوصیات ہیں۔
- مبصرین کو ڈیٹا منتقل کرنے کے لیے واضح پیرامیٹرز استعمال کیے جاتے ہیں۔ انہیں کوڈ میں نام دیا جا سکتا ہے تاکہ یہ واضح ہو جائے کہ وہ کیا ہیں۔
- نوٹیفکیشن پیرامیٹرز مستحکم ٹائپ ہیں۔ اقسام مبصر سیٹ پراپرٹی میں بیان کی جاتی ہیں اور نوٹیفکیشن بھیجنے والوں اور وصول کرنے والوں کو کمپائلر کے ذریعے چیک کیا جاتا ہے۔ ہر قسم کی حمایت کی جاتی ہے ، باکسنگ کی کوئی ضرورت نہیں۔
- عام معاملے کے لیے جہاں ایک مبصر کو ہٹا دیا جاتا ہے جب ہٹا دیا جاتا ہے ، ہٹانا خودکار ہو سکتا ہے۔
- ہر مبصر سیٹ اندراجات کی ایک فہرست رکھتا ہے جس کا معائنہ ڈیبگر میں کیا جاسکتا ہے۔
اچھا لگ رہا ہے! پھر ، ہم اسے کیسے بناتے ہیں؟
مبصر فنکشن کی اقسام
مان لیتے ہیں کہ ایک مبصر فنکشن کے پیرامیٹرز کہلاتے ہیں Parameters، یہ وہ نام ہے جو میں کوڈ میں عام قسم کے لیے استعمال کروں گا۔ بنیادی طور پر ، ایک مبصر فنکشن کی قسم ہے Parameters -> Void۔ تاہم ، عام معاملے کے لیے جہاں مبصر کا کام ایک طریقہ ہے ، اس سے مبصر آبجیکٹ کا کمزور حوالہ رکھنا مشکل ہوجاتا ہے اور جب آبجیکٹ تباہ ہوجاتا ہے تو اندراج صاف کردیتا ہے۔ جب آپ کلاس سے کوئی طریقہ حاصل کرتے ہیں ، جیسے self.dynamicType.gotNewItem، نتیجے میں آنے والے فنکشن کی قسم دراصل ہے TheClass -> Parameters -> Void۔ آپ فنکشن کو کال کرتے ہیں اور اسے کلاس کی مثال دیتے ہیں ، اور پھر اس طریقہ کار کے لئے ایک نیا فنکشن لوٹاتا ہے جو اس مثال پر لاگو ہوتا ہے۔
ہر چیز کو منظم رکھنے کے لیے ، ہم مبصر آبجیکٹ کا ایک کمزور حوالہ ذخیرہ کریں گے ، اور ہم مبصر فنکشن کو اس طویل شکل میں محفوظ کریں گے۔ addطریقہ کار کی آسان شکل کے لیے ، فنکشن کو کسی اور فنکشن میں لپیٹا جا سکتا ہے جو اس کے پیرامیٹر کو پھینک دیتا ہے اور اصل فنکشن لوٹاتا ہے۔ چونکہ مبصر اشیاء مختلف اقسام کی ہو سکتی ہیں ، ہم ان کو بطور ذخیرہ کریں گے AnyObjectاور مبصر کام کرتا ہے AnyObject -> Parameters -> Void۔
کوڈ
پر عملدرآمد دیکھنے کا وقت آگیا ہے۔ ہمیشہ کی طرح ، کوڈ GitHub پر دستیاب ہے:
اندراجات
ایک مبصر سیٹ میں ہر اندراج ایک کمزور طور پر منعقد مبصر آبجیکٹ اور ایک فنکشن ہے۔ یہ چھوٹی عام کلاس دونوں کو ایک ساتھ بنڈل کرتی ہے ، جس سے صوابدیدی پیرامیٹر کی اقسام کی اجازت ملتی ہے۔
پبلک کلاس ObserverSetEntry < Parameters > {
private weak var object : AnyObject ؟
private let f : AnyObject -> Parameters -> Void
private init ( object : AnyObject ، f : AnyObject -> Parameters -> Void ) {
خود ۔ اعتراض = اعتراض
خود . f = f
}
}
مبصر سیٹ آبجیکٹ اور فنکشن کو مبصرین کو کال کرنے کے لیے استعمال کر سکتا ہے ، اور nilڈیلیکیٹڈ اشیاء کے اندراجات کو ہٹانے کے لیے آبجیکٹ کو چیک کر سکتا ہے۔ اس کلاس کو نشان زد کیا گیا ہے publicکیونکہ یہ کال کرنے والوں کو بھی واپس کر دیا جائے گا تاکہ اس removeطریقہ کار کے پیرامیٹر کے طور پر استعمال کیا جا سکے ۔
مثالی طور پر ، اس کلاس کے اندر گھونسلے ہوں گے ObserverSet۔ تاہم ، سوئفٹ عام اقسام کے گھوںسلا کرنے کی اجازت نہیں دیتا ہے ، لہذا یہ ایک علیحدہ ٹاپ لیول قسم ہونا چاہیے۔
آبزرور سیٹ کلاس بھی کلی ہے :ObserverSetParameters
پبلک کلاس آبزرور سیٹ < پیرامیٹرز > {
NSNotificationCenterتھریڈ محفوظ ہے ، اور یہ کلاس بھی ہونی چاہیے۔ میں نے اسے پورا کرنے کے لیے سیریل ڈسپیچ قطار استعمال کرنے کا انتخاب کیا:
نجی var queue = dispatch_queue_create ( "com.mikeash.ObserverSet" ، nil )
میں نے اس کے لیے ایک فوری مددگار فنکشن بھی لکھا:
نجی فنک مطابقت پذیر ( f : Void -> Void ) {
dispatch_sync ( قطار ، f )
}
اس کے ساتھ ، یہ اتنا ہی آسان ہے جتنا synchronized{ ...code... }کوڈ پر لکھنا جو مشترکہ ڈیٹا استعمال کرتا ہے۔
اندراجات کو ایک صف میں رکھا گیا ہے:
نجی var اندراجات : [ ObserverSetEntry < Parameters > ] = []
مناسب طریقے سے ، یہ ایک صف کی بجائے ایک سیٹ ہونا چاہئے۔ تاہم ، ابھی تک سوئفٹ میں استعمال کرنے کے لیے سیٹ اتنے اچھے نہیں ہیں ، کیوں کہ کوئی بلٹ ان سیٹ قسم نہیں ہے۔ اس کے بجائے ، آپ کو یا تو استعمال کرنا ہوگا NSSet، یا قدر کی قسم کے Dictionaryساتھ استعمال کرنا Voidہوگا۔ چونکہ مبصرین کے سیٹ عام طور پر زیادہ سے زیادہ چند اندراجات پر مشتمل ہوں گے ، میں نے اس کے بجائے وضاحت کے لیے جانے کا فیصلہ کیا۔
سوئفٹ ایک واضح عوامی ابتداء کرنے پر بھی اصرار کرتا ہے ، حالانکہ یہ خالی ہے ، کیونکہ بطور ڈیفالٹ بظاہر عام نہیں کیا جاتا ہے:
عوامی init () {}
یہ سیٹ اپ کا خیال رکھتا ہے۔ آئیے مرکزی addطریقہ پر نظر ڈالیں ، جو ایک مبصر آبجیکٹ اور فنکشن لیتا ہے۔
پبلک Func کی ایڈ < T : AnyObject > ( اعتراض : T ، _ F : T -> پیرامیٹر -> باطل ) -> ObserverSetEntry < پیرامیٹر > {
اگلا ، ایک اندراج بنائیں۔ اس قسم کی توقعات سے fبالکل مماثل نہیں ObserverSetEntryہے ، کیونکہ یہ کسی فنکشن کی تلاش میں ہے جو لیتا ہے AnyObject، جبکہ یہ لیتا ہے T۔ ایک چھوٹا اڈاپٹر ٹائپ کاسٹ کے ساتھ مماثلت کا خیال رکھتا ہے۔
let entry = ObserverSetEntry < Parameters > ( object : object ، f : { f ( $ 0 as T ) })
اس طرح سوئفٹ کے ٹائپ سسٹم کو نظرانداز کرنا بدقسمتی ہے ، لیکن اس سے کام ہو جاتا ہے۔
بنائی گئی اندراج کے ساتھ ، اسے صف میں شامل کریں:
مطابقت پذیر {
خود . اندراجات . شامل کریں ( اندراج )
}
آخر میں ، اندراج کال کرنے والے کو واپس کردیا جاتا ہے:
واپسی اندراج
}
دوسرا addطریقہ ایک چھوٹا اڈاپٹر ہے۔
public func add ( f : Parameters -> Void ) -> ObserverSetEntry < Parameters > {
return self . شامل کریں ( خود ، { f میں نظر انداز کیا گیا ) }}
یہ selfصرف اس وجہ سے گزرتا ہے کہ یہ ایک آسان اشارہ ہے جو زندہ رہنے کی ضمانت دیتا ہے۔ چونکہ nilاشیاء کے ساتھ اندراجات کو ہٹا دیا جاتا ہے ، یہ اندراج کو اس وقت تک برقرار رکھتا ہے جب تک کہ مبصر خود سیٹ کرتا ہے۔ دوسرے پیرامیٹر میں داخل ہونے والا فنکشن صرف اس کے پیرامیٹر کو نظر انداز کرتا ہے اور لوٹتا ہے f۔
removeطریقہ کار کے ملاپ کے اندراج کو دور کرنے کے صف کی فلٹرنگ کی طرف سے لاگو کیا جاتا ہے. سوئفٹ کی Arrayقسم کا کوئی removeطریقہ نہیں ہے ، لیکن filterطریقہ وہی کام انجام دیتا ہے:
پبلک فنک ہٹائیں ( اندراج : ObserverSetEntry < پیرامیٹرز > ) {
ہم وقت ساز {
خود ۔ اندراجات = خود . اندراجات . فلٹر { $ 0 ! == entry }
}
}
یہ notifyطریقہ اصولی طور پر آسان ہے: ہر اندراج کے لیے ، مبصر فنکشن کو کال کریں ، اور کسی بھی اندراج کو کسی nilمبصر آبجیکٹ سے ہٹا دیں ۔ تاہم ، یہ اس حقیقت سے قدرے پیچیدہ بنا دیا گیا ہے کہ اس کے entriesاندر سے رسائی حاصل کرنے کی ضرورت ہے synchronized، لیکن مبصر کے افعال کو وہاں سے بلانا برا خیال ہے ، کیونکہ یہ آسانی سے تعطل کا باعث بن سکتا ہے۔ اس مسئلے سے بچنے کے لیے ، حکمت عملی یہ ہے کہ تمام مبصرین کے افعال کو مقامی صف میں جمع کریں ، پھر دوبارہ کریں اور انہیں synchronizedبلاک سے باہر کال کریں ۔ یہاں فنکشن ہے:
عوامی فنک اطلاع ( پیرامیٹرز : پیرامیٹرز ) {
کال کرنے کے افعال ایک صف میں جمع ہوتے ہیں:
var toCall : [ Parameters -> Void ] = []
نوٹ کریں کہ افعال کی قسم میں ابتدائی شامل نہیں ہے AnyObject ->۔ چیزوں کو آسان رکھنے کے لیے ، ہم synchronizedبلاک کے اندر وہ پہلی کال کریں گے ، تاکہ صف میں جمع کیے گئے افعال حتمی مبصر کے افعال ہوں جو پہلے سے لگائے گئے مبصر آبجیکٹ کے ساتھ ہوں۔
اندراجات پر تکرار ایک synchronizedبلاک میں ہونا ضروری ہے :
مطابقت پذیری {
نفس میں داخلے کے لیے ۔ اندراجات {
کسی nilشے کے ساتھ اندراجات کو چھوڑیں :
if let object : AnyObject = entry . اعتراض {
کالنگ entry.fاعتراض کے ساتھ کال کا مبصر تقریب کی پیداوار:
کال کریں . ضمیمہ ( اندراج ۔ ایف ( آبجیکٹ ))
}
}
اس سے پہلے کہ ہم synchronizedبلاک چھوڑیں ، انٹریوں کو فلٹر کرکے صاف کریں جو اب موجود ہیں nil:
خود . اندراجات = خود . اندراجات . فلٹر { $ 0. آبجیکٹ ! = nil }
}
اب چونکہ افعال اکٹھے ہو چکے ہیں اور synchronizedبلاک ختم ہو چکا ہے ، ہم مبصر افعال کو کہتے ہیں:
کے ایف میں toCall {
F ( پیرامیٹرز )
}
}
ObserverSetکلاس کے لیے یہی ہے ۔ آئیے اختتامی تسمہ کو مت بھولیں:
}
ٹپلز پر ایک نوٹ
آپ نوٹ کریں گے کہ ObserverSetپیش کردہ کوڈ میں سے کوئی بھی اس کیس کو ایڈریس نہیں کرتا جہاں متعدد ہیں Parameters، مثال کے طور پر:
public let newItemObservers = ObserverSet < ( String ، Int ) > ()
تاہم ، یہ اوپر والے کوڈ کا استعمال کرتے ہوئے بھی کام کرتا ہے۔ کیا ہو رہا ہے؟
یہ پتہ چلتا ہے کہ سوئفٹ ایک فنکشن کے درمیان کوئی فرق نہیں کرتا جو ایک سے زیادہ پیرامیٹرز لیتا ہے اور ایک فنکشن جو ایک پیرامیٹر لیتا ہے جس کی قسم ایک ٹپل ہے۔ مثال کے طور پر ، یہ کوڈ ایک فنکشن کو دونوں طریقوں سے استعمال کرتا ہے:
func f ( x : Int ، y : Int ) {}
f ( 0 ، 0 )
let params = ( 0 ، 0 )
f ( params )
اس کا مطلب یہ ہے کہ ObserverSetکوڈ کو ایک پیرامیٹر کے ساتھ افعال کے لیے لکھا جا سکتا ہے ، اور اسے کئی پیرامیٹرز کے لیے مفت سپورٹ ملتی ہے۔ ان معاملات میں آپ کیا کر سکتے ہیں اس کی کچھ مضبوط حدیں ہیں (مثال کے طور پر ، کسی بھی پیرامیٹر میں ترمیم کرنا بنیادی طور پر ناممکن ہے) لیکن یہ اس معاملے میں بہت اچھا کام کرتا ہے۔
نتیجہNSNotificationCenter آسان ہے ، لیکن سوئفٹ زبان کی خصوصیات بہت بہتر ورژن کی اجازت دیتی ہیں۔ Generics ایک سادہ API کی اجازت دیتا ہے جو اب بھی استعمال کی تمام صورتوں کی اجازت دیتا ہے جبکہ دونوں اطراف میں جامد اقسام اور ٹائپ چیکنگ فراہم کرتا ہے۔
آج کے لیے یہی ہے! مزید خوفناک تجربات کے لیے اگلی بار واپس آئیں۔ اس دوران ، جمعہ کا سوال و جواب قارئین کے خیالات سے چلتا ہے ، لہذا اگر آپ کے پاس کوئی ایسی چیز ہے جسے آپ یہاں احاطہ کرتے ہوئے دیکھنا چاہتے ہیں تو اسے بھیجیں !کیا آپ کو یہ مضمون پسند آیا؟ میں ان سے بھری پوری کتابیں بیچ رہا ہوں! جلد II اور III اب باہر ہیں! وہ بطور ای پب ، پی ڈی ایف ، پرنٹ ، اور آئی بوکس اور کنڈل پر دستیاب ہیں۔ مزید معلومات کے لیے یہاں کلک کریں ۔
تبصرے:جیکب Gorban میں 2015-01-23 17:34:16 :میں نے اپنے کوڈ کے لئے کچھ ایسا ہی تیار کیا (اسے چینلز کہا جاتا ہے)۔ اس میں کسی حد تک آسان عمل درآمد ہے (صفوں میں براہ راست افعال کو ذخیرہ کرنا اور نہ کہ طریقہ کار کے افعال جو آپ تخلیق کرتے ہیں۔
یقینا ، اس معاملے میں میں چینلز کو سبسکرائب نہیں کرسکتا لیکن اب تک یہ میرے استعمال کے معاملات میں کام کرتا ہے۔
آپ کے تصور کے بارے میں اس NSNotificationCenterنوٹیفیکیشن کو تبدیل کرنے کے لیے ، ایک اہم استعمال کا معاملہ ہے جو اس نقطہ نظر میں شامل نہیں ہے ، اور واقعتا possible ممکن نہیں لگتا ہے ، کسی بھی شے پر ایک نوٹیفکیشن کا مشاہدہ کر رہا ہے جو اسے بھیجتا ہے (addObserver میں آبجیکٹ کے لیے صفر)۔ اس طرح کے ڈھیلے جوڑے کو کیا اجازت دیتا ہے NSNotifications۔
ایک سوال جو میرے پاس ہے ، وہ یہ ہے کہ آپ کو dynamicTypeجائیداد سے کیوں گزرنا پڑتا ہے ؟
mikeash میں 2015-01-23 17:41:33 :مجھے یقین نہیں ہے کہ میں نے کبھی کسی صفر شے کا جائز استعمال دیکھا ہے۔ این ایس نوٹیفیکیشن سینٹر کی تمام سہولیات دلچسپ ہیں ، لیکن اس عمل کے عالمی ڈھانچے کے بارے میں خطرناک مفروضے کیے بغیر استعمال کرنا مشکل ہے جس میں آپ رہ رہے ہیں۔
جیسا کہ ڈائنامیک ٹائپ کی بات ہے ، آپ اس کے بجائے کلاس کا نام ضرور استعمال کر سکتے ہیں۔ میں نے صرف اس لیے نہ کرنے کا فیصلہ کیا کہ اس کی تکرار ختم ہو جاتی ہے اور اگر آپ کلاس کا نام تبدیل کرتے ہیں تو اضافی جگہوں کے ایک گروپ کا نام تبدیل کرنے کی ضرورت ہوتی ہے۔ خاص طور پر بڑی بات نہیں ، ذاتی ترجیح کا زیادہ معاملہ۔جان میں 2015-01-23 20:22:36 :یہ واقعی NSNotifications/Center استعمال کرنے جیسا نہیں ہے۔ این ایس نوٹیفیکیشن گمنام ہوسکتے ہیں اور یہ نہیں ہیں ، لہذا آپ اطلاعات اور مبصرین کے درمیان سب سے بڑا فرق یاد کر رہے ہیں۔ یہ سوئفٹ میں مبصرین کا ایک دلچسپ عمل ہے لیکن یہ واضح طور پر NSNotificationCenter کا متبادل نہیں ہے۔جان میں 2015-01-23 20:25:11 :در حقیقت ، میں ایسی مثال کے بارے میں نہیں سوچ سکتا جہاں میں نے این ایس نوٹیفیکیشن سینٹر کو گمنام نوٹیفکیشن نشر اور استقبال کے علاوہ کسی اور چیز کے لیے دیکھا یا استعمال کیا ہو۔ اگر میں اس چیز کو جانتا ہوں جسے میں دیکھنا چاہتا ہوں تو میں صرف ایک مبصر کا استعمال کروں گا۔mikeash میں 2015-01-23 21:08:57 :آپ اپنی درخواست کے ان حصوں کو مؤثر طریقے سے سنگلٹن میں تبدیل کیے بغیر صفر ھدف شدہ اطلاعات کو کیسے استعمال کرتے ہیں؟جان میں 2015-01-23 21:25:25 :یہ انہیں مؤثر طریقے سے سنگلٹن کیوں بنائے گا؟ آبجیکٹ رجسٹر اور مختلف نوٹیفیکیشنز کے لیے رجسٹرڈ ہوتے ہیں جیسے وہ آتے جاتے ہیں۔ کم از کم NSNotificationCenter کا استعمال کرتے ہوئے ، ایسے ایونٹس کے لیے اندراج کرنا جو کبھی نشر نہیں ہوتے صرف ٹھیک ہے۔ غیر سنگلٹن اشیاء کے لیے میں زیادہ تر سسٹم ایونٹس کے لیے NSNotificationCenter استعمال کرتا ہوں۔ لیکن چونکہ میں سنگلٹن کو فطری طور پر بری چیز نہیں سمجھتا ، اس لیے میں ان کو چند سنگلٹن اشیاء کے لیے مواصلاتی طریقہ کار کے طور پر بھی استعمال کرتا ہوں جو عام طور پر میرے پاس ہوتے ہیں۔ لاگ آؤٹ اور لاگ ان ایونٹس جیسی چیزیں مختلف سنگلٹنز کو کچھ کرنے کے لیے بتائیں (یعنی کیش صاف کریں ، نیٹ ورکنگ کو دوبارہ ترتیب دیں ، ڈسک پر لکھیں ، فائلیں ڈیلیٹ کریں)۔ NSNotificationCenter اطلاعات کے لیے ایک مرکزی قسم کی سروس کے طور پر بھی کام کرتا ہے ، لہذا مجھے بالکل یہ جاننے کی ضرورت نہیں ہے کہ میں کس چیز کو پہلی جگہ دیکھنا چاہتا ہوں۔
نیز ، اگر آپ ویسے بھی مبصر/نوٹیفکیشن میکانزم کو دوبارہ کر رہے ہیں تو ، کیوں نہ ان کو استعمال کرنے کے انتہائی پریشان کن پہلو سے نمٹیں ، انہیں دستی طور پر غیر رجسٹرڈ کریں۔ میں نے اس کا حل آبجیکٹ-سی میں دیکھا ہے لیکن اگر ممکن ہو تو سوئفٹ کا نفاذ دلچسپ ہوگا۔برائن بی میں 2015-01-23 21:25:58 :کیچ آل کے لیے کوئی جائز استعمال نہیں؟
میں اسے ہر وقت استعمال کرتا ہوں۔ مثال کے طور پر کچھ اشیاء کے مجموعہ کا انتظام کرتے وقت جو تمام اطلاعات آپ کو دلچسپی دیتی ہیں اور وہ مجموعہ وقت کے ساتھ تبدیل ہوتا رہتا ہے۔
کیچ سب کے ساتھ آپ [init] میں کسی بھی شے کی پوسٹس دیکھنے کے لیے ایک ہی نوٹیفکیشن رجسٹر کرتے ہیں ، پھر اپنے ہینڈلر طریقہ کار میں:
اگر ([مجموعہ پر مشتمل ہے Object: note.object]) {
ہینڈل نوٹیفکیشن …
}
اور [dealloc] میں آپ deregister
یہ گندا اور ممکنہ طور پر زیادہ مسئلے کا شکار ہوگا-یہاں تک کہ سوئفٹ ورژن کے ساتھ بھی۔mikeash میں 2015-01-23 21:55:18 :جون: اگر آپ تمام اشیاء کی طرف سے بھیجے گئے کسی خاص نوٹیفکیشن کے لیے رجسٹر ہوتے ہیں ، تو اب آپ کے کوڈ کو آپ کی ایپ میں موجود تمام اشیاء سے آگاہ ہونا پڑتا ہے جو کہ نوٹیفکیشن بھیجتے ہیں ، چاہے ان کا انتظام بالکل مختلف مثال سے کیا جا رہا ہو۔ اپنے لاگ آؤٹ ایونٹ کی مثال کے لیے ، اگر آپ کسی دوسرے مثال کے سیشن سے لاگ آؤٹ ہو گئے ہیں تو آپ کیش کو صاف کرنا یا فائلوں کو حذف نہیں کرنا چاہیں گے ، لہذا آپ اپنے آپ کو مؤثر طریقے سے ایک وقت میں ایک سیشن تک محدود کر رہے ہیں۔ میرے خیال میں یہ صرف آپ کے اس بیان پر آتا ہے کہ “میں سنگلٹن کو فطری طور پر بری چیز نہیں سمجھتا۔” اگر آپ چیزوں کو ایک مثال تک محدود کرنے میں راحت محسوس کرتے ہیں یہاں تک کہ جب اس کی سخت ضرورت نہ ہو تب بھی یہ تشویش دور ہو جاتی ہے ، لیکن میں خود نہیں ہوں۔
میں آپ کے “دستی طور پر غیر رجسٹرڈ” تبصرے کے بارے میں تھوڑا سا پریشان ہوں ، چونکہ مذکورہ کوڈ بالکل ہینڈل کرتا ہے بغیر کسی ہنگامے کے۔
برائن بی:ہر شے میں نوٹیفکیشن مشاہدہ شامل کرتے ہوئے جیسے آپ اسے صف میں شامل کرتے ہیں ، اور جب آپ صف سے ہٹاتے ہیں تو اسے ہٹانا اتنا ہی آسان لگتا ہے اور مزید بگ کا شکار نہیں ہوتا ہے۔ جب تک کہ آپ بہت سی مختلف جگہوں کو شامل اور ہٹا نہ دیں ، جو آپ کو ویسے بھی نہیں کرنا چاہیے۔باب اوپر 23/01/2015 22:06:10 :اگرچہ منقطع مبصرین کو اب نہیں بلایا جاتا ، لیکن کیا اب بھی مبصر سیٹ میں مبصر سیٹ اینٹری آبجیکٹ (نیل آبجیکٹ کے ساتھ) کو ہمیشہ کے لیے چھوڑنے کا مسئلہ نہیں ہے؟ لہذا اگر آپ باقاعدگی سے مبصرین کو رجسٹر کرتے ہیں ، اور وہ ڈیلوکیٹ کرتے ہیں ، تو صف صفائی کے ساتھ مستحکم ہوگی۔mikeash میں 2015-01-23 22:22:22 :اگر آپ کبھی بھی اطلاعات نہیں بھیجیں گے تو چیزیں بڑھ جائیں گی ، کیونکہ مردہ اندراجات صرف مطلع کرتے وقت صاف کیے جاتے ہیں۔ اگر ضرورت پڑی تو اسے چیک کے ساتھ آسانی سے دور کیا جائے گا۔جان میں 2015-01-23 23:01:13 :مجھے یقین نہیں ہے کہ آپ کیوں کہہ رہے ہیں کہ مجھے ان تمام اشیاء سے آگاہ رہنا ہے جو نوٹیفکیشن بھیجتے ہیں (اگر آپ کا مطلب ہے کہ مجھے ریفرنس کی ضرورت ہے) ، چونکہ بالکل وہی منظر ہے جس سے میں گمنام اطلاعات استعمال کرتے وقت گریز کرتا ہوں۔ کچھ آبجیکٹ ایک “لاگ آؤٹ” نوٹیفکیشن پوسٹ کرتا ہے ، مجھے واقعی پرواہ نہیں ہے کہ یہ کیا ہے۔ کچھ دوسری چیزیں یا اشیاء اس اطلاع کو وصول کرتی ہیں اور کچھ کارروائی کرتی ہیں۔ یا شاید ابھی تک کوئی ایسی چیز نہیں بنائی گئی جو اس نوٹیفکیشن کو سن سکے۔ زیادہ سے زیادہ مجھے اس بات سے آگاہ رہنا ہوگا کہ اگر میں پرواہ کرتا ہوں تو کلاس سے کیا اطلاعات بھیجی جاسکتی ہیں ، اور یہ صرف ایک دستاویزی مسئلہ ہے۔ مجھے ان اطلاعات سے نہیں کاٹا جا سکتا جن کے بارے میں میں نہیں جانتا۔
یا آپ کا مطلب یہ تھا کہ متعدد کلاسز مختلف وجوہات کی بنا پر ایک ہی نوٹیفکیشن بھیج سکتی ہیں اور شاید میں اس کے بارے میں نہیں جانتا ہوں؟ یعنی کچھ بے ترتیب شے ایک نوٹیفکیشن نشر کر سکتی ہے جسے میں سنتا ہوں جس کی مجھے توقع نہیں تھی۔ ایسا لگتا ہے کہ ناگوار چیز کے ذریعہ نوٹیفکیشن کا برا استعمال۔ ایپل کی کلاسیں ایسا نہیں کرتی ہیں (اطلاعات عام طور پر کسی کلاس یا فریم ورک کے لیے منفرد ہوتی ہیں)۔ اگر کسی تیسری پارٹی کی لائبریری کسی وجہ سے UIKeyboard نوٹیفکیشن جاری کر رہی ہوتی تو میں شاید اس فریم ورک کو استعمال کرنے پر دوبارہ غور کروں ، اگر میں کر سکتا۔
اگر واقعی ایسے اوقات ہوتے ہیں کہ میں کسی نوٹیفکیشن کی بنیاد پر کارروائی نہیں کرنا چاہتا ، تو میں انفارمیشن لغت پر انحصار کرتا ہوں کہ کیا کارروائی کی جائے۔ میرے تجربے میں ، ایسے حالات نایاب ہوتے ہیں ، خاص طور پر ان اطلاعات کے لیے جن کا مقصد عالمی ہونا ہے۔ اگر نوٹیفکیشن میں کوئی مفید معلومات شامل نہیں ہے تو ، یہ ایک خراب نوٹیفکیشن ڈیزائن کی طرح لگتا ہے ، عام طور پر گمنام نوٹیفکیشن پیٹرن کے ساتھ کوئی مسئلہ نہیں ہے۔
میرا واحد نکتہ یہ ہے کہ آپ کا حل ، دلچسپ ہوتے ہوئے ، اطلاعات کے لیے اس درست اور مفید منظر کو مکمل طور پر نظر انداز کرتا ہے۔ڈیوڈ اوپر 24/01/2015 02:19:17 :میں جون سے متفق ہوں۔ NSNotificationCenter مفید ہے ، جزوی طور پر ، کیونکہ یہ گمنام اطلاعات کی اجازت دیتا ہے۔ مجھے یقین ہے کہ یہ جو کچھ ایجاد کیا گیا تھا اس کا ایک بڑا حصہ ہے!
یہ خیال کہ آپ کسی نہ کسی طرح متعدد مثالوں کے ساتھ اختتام پذیر ہوسکتے ہیں جو تمام لاگ آؤٹ ایونٹ پر کارروائی کریں گے ، اور ایک دوسرے کی کوششوں کو جکڑ لیں گے۔ وہ لوگ جو گمنام اطلاعات استعمال کرنا چاہتے ہیں وہ اپنے کاموں کو ذہن میں رکھتے ہیں ، اور یہ تجویز کرنا غلط ہے کہ انہیں صحیح کوکو فیچرز کو صحیح طریقے سے استعمال کرنے کے لیے غیر محفوظ محسوس کرنا چاہیے۔
این ایس بلاگ نامی بلاگ سے ، میں ایک زیادہ شائستہ اور حوصلہ افزا انداز کی توقع کروں گا۔ اپنے آپ کو کوکو کے تخلیق کاروں سے برتر قرار دینے کی کوشش اسینین ہے۔mikeash میں 2015-01-24 02:43:58 :جون: میں جو کہہ رہا ہوں وہ یہ ہے کہ ممکنہ طور پر آپ کے پروگرام میں بہت سی مثالیں ہیں جو کہ نوٹیفکیشن بھیج رہی ہیں ، اور ایک مبصر کے لیے مناسب کارروائی کا انحصار اس بات پر ہے کہ یہ کس مثال پر ہے۔ اپنے لاگ آؤٹ نوٹیفکیشن کی مثال کے لیے ، ایک بار پھر ، آپ اسناد کو حذف کرنا چاہیں گے ، لیکن * صرف * جب اسے لاگ ان کنٹرولر نے بھیجا ہو جس کی آپ کو اصل میں پرواہ ہو۔ ایک اور لاگ ان کنٹرولر جو پروگرام کے مختلف حصے کے ذریعہ استعمال ہوتا ہے اس کی وجہ نہیں بننا چاہیے۔ مجھے ایسا لگتا ہے جیسے آپ بہت زیادہ انحصار کر رہے ہیں وہاں کسی بھی کلاس کی صرف ایک مثال ہے۔
ڈیوڈ:اگر آپ نے یہاں ایک عاجزانہ انداز کی توقع کی تھی تو میرے خیال میں آپ الجھن میں پڑ سکتے ہیں۔ آپ کو یہ تجویز دے کر میرے ساتھ صفر کرشن مل جائے گا کہ میں کوکو ڈیزائن کی غلطیوں کے طور پر جو کچھ دیکھتا ہوں اس پر تنقید نہیں کرنی چاہیے۔ کوکو اپنی طویل زندگی کے دوران کچھ غلطیوں کا شکار ہوا ہے ، اور میں ان کی نشاندہی کرنے میں شرمندہ نہیں ہوں گا۔ اس سے زیادہ ، بہت سارے کوکو پروگرامر اچھے ڈیزائن پر مہارت کی قدر کرتے ہیں۔ مثال کے طور پر ، میں ایک ٹن کوکو ایپس دیکھ رہا ہوں جو سنگلٹن اشیاء سے بھری ہوئی ہیں جو وہاں نہیں ہونی چاہئیں ، اور صرف اس وجہ سے استعمال ہوتی ہیں کہ سنگلٹن تک رسائی حاصل کرنا قدرے آسان ہے۔ گمنام اطلاعات میرے لیے ایک ہی قسم کی پریشانی لگتی ہیں۔ یقینا آپ کو اختلاف کرنے کا ہر حق ہے ، لیکن اگر آپ اس پر بحث کرنا چاہتے ہیں تو آپ کو کسی قسم کی دلیل لانے کی ضرورت ہے ، صرف مجھے غلط قرار نہ دیں کیونکہ میں ایپل سے اختلاف کر سکتا ہوں۔ڈیوڈ اوپر 2015-01-24 03:34:24 :لکھتے رہیں ، اگرچہ! معذرت ، میرا مطلب یہ نہیں تھا کہ میں اپنی حوصلہ شکنی کروں۔ بڑا پرستار ، صرف رویے سے مایوس۔اردن میں 2015-01-24 04:48:14 :خوب کیا۔ تجویز: “نظر انداز” کے بجائے “_” استعمال کریں۔
جون: میں مائیک سے اتفاق کرتا ہوں ، اور ایپل کی کلاسیں یقینی طور پر ایسا کرتی ہیں۔ یہ ایپ میں <em> تمام UITableViews </em> پر UITableViewSelectionDidChangeNotification سننے کی طرح ہے۔ آپ یہ کر سکتے ہیں ، لیکن یہ تب ہی سمجھ میں آتا ہے جب آپ جانتے ہو کہ آپ کے ایپ میں موجود تمام UITableViews کو اسی طرح برتاؤ کرنا چاہیے۔ کسی بھی نوٹیفیکیشن کے لیے بھی یہی ہے جو آپ خود بناتے ہیں: اگر ایپ میں موجود ہر چیز اسی جواب کی مستحق ہے تو یہ بہت اچھا ہے …پیول پر 24/01/2015 07:43:42 :آپ تفصیل () میں self.entries کا حوالہ کیوں لیتے ہیں اور پھر self.entries کا استعمال جاری رکھتے ہیں؟ اگر یہ کوئی ٹائپو نہیں ہے تو کیا آپ اس کے پیچھے دلیل کی وضاحت کر سکتے ہیں؟Deniska میں 2015-01-24 09:24:39 :نیل آبجیکٹ کے جائز استعمال میں سے ایک NSManagedObjectContextDidSaveNotification کو سننا بھی ہو سکتا ہے۔
ایپ میں داخلی ضروریات کے لیے متعدد سیاق و سباق ہو سکتے ہیں اور مرکزی موضوع ڈیٹا کی تبدیلیوں کو مرکزی سیاق و سباق میں ضم کر سکتا ہے۔ اور اہم سیاق و سباق کو تمام ممکنہ پس منظر کے سیاق و سباق سے آگاہ نہیں ہونا چاہیے۔ لہذا ، ہم تمام اطلاعات سنتے ہیں اور ان تبدیلیوں کو ضم کرتے ہیں۔جیسن میں 2015-01-24 18:02:15 :زبردست پوسٹ! آپ کے لیے ایک سوال:
آپ نے ذکر کیا کہ سوئفٹس ٹائپ سیفٹی کو نظرانداز کرنا کتنی بدقسمتی ہے جب آپ کسی اندراج کو شامل کرتے وقت AnyObject سے T پر جاتے ہیں۔ آپ کو ایک جگہ پر AnyObject اور T: AnyObject دوسری جگہ کیوں استعمال کرنا چاہیے؟ کیا آپ اس کے پیچھے دلیل کی وضاحت کر سکتے ہیں؟ (اگر یہ واضح ہے تو معذرت ، میں ایک تیز شروعات کرنے والا ہوں)۔
اس کے علاوہ ، گمنام اطلاعات سے بچنے کی ایک اور وجہ: جانچ ایک بہت بڑی تکلیف بن جاتی ہے کیونکہ ان اشیاء کی کئی مثالیں ہو سکتی ہیں جن کے بارے میں آپ سوچتے تھے کہ وہ سنگلٹن تھے جبکہ یہ تمام ٹیسٹ چل رہے ہیں۔ میرے خیال میں یہ سنگلٹن سے بچنے کی ایک وجہ بھی ہے۔جین ڈینیل اوپر 2015-01-24 21:55:12 :گمنام اطلاعات کے لیے ایک مفید استعمال کیس NSBundleDidLoadNotification کے لیے اندراج کرکے بنڈل کو متحرک طور پر بھری ہوئی ہے۔مائیکش 2015-01-25 02:31:41 پر :ڈیوڈ: کوئی فکر نہیں ، میں اسے سنبھال سکتا ہوں۔ کبھی کبھی میرے پختہ عقائد ہوتے ہیں اور میں لوگوں کو بتانے میں شرمندہ نہیں ہوں۔ مجھے امید نہیں ہے کہ ہر کوئی اتفاق کرے گا۔
اردن: نظر انداز کرنے کے بجائے _ استعمال کرنے کے بارے میں اچھی تجویز۔ مجھے لگتا ہے کہ میں ابھی “نظر انداز” کے ساتھ رہوں گا کیونکہ یہ مجھے زیادہ واضح لگتا ہے۔ یہ صرف زبان کی نئی ہونے کی وجہ سے ہوسکتا ہے ، اگرچہ۔ ایک بار جب لوگوں نے تھوڑی دیر کے لیے سوئفٹ استعمال کر لیا تو میں تصور کرتا ہوں کہ _ وہاں زیادہ قدرتی نظر آئے گا۔
پاول: عارضی دماغی خرابی۔ میں نے ایک فوری ٹھیک کیا۔ اس کی نشاندہی کرنے کے لیے شکریہ!
ڈینسکا: کیا یہ فرض نہیں کرتا کہ آپ کی ایپ صرف ایک کور ڈیٹا سٹور میں ہیرا پھیری کر رہی ہے؟ ایسا لگتا ہے کہ یہ ایک غلط مفروضہ ہے۔
جیسن:بہترین سوال۔ عام لوگوں کے ساتھ متفاوت مجموعہ رکھنے کا ایک اچھا طریقہ معلوم نہ کرنے کی وجہ سے یہ آتا ہے۔ تنہائی میں ، یہ سمجھ میں ObserverSetEntryآئے گا کہ اس کے طور پر لکھا جائے ObserverSetEntry<T, Parameters>۔ اس طرح ، ہر چیز مستقل طور پر عام ہوگی اور زندگی اچھی ہوگی۔ لیکن میں ObserverSetمعقول طور پر ObserverSetEntryمختلف Tاقسام والی اشیاء کے ایک گروپ سے بات چیت کرنے کا کوئی طریقہ نہیں جان سکا ۔ ان سب کو استعمال کرنے سے AnyObjectیہ مسئلہ ٹل جاتا ہے۔
جین ڈینیل: میں اتفاق کرتا ہوں ، یہ صفر کے لیے ایک اچھا کیس لگتا ہے ۔ اس خاص معاملے میں ، چونکہ آپ کبھی بھی اس نوٹیفکیشن کو کسی چیز کے لیے نہیں سننا چاہیں گے ، لیکنnil ایک ہی فعالیت ObserverSetتمام لوگوں کے لیے عالمی مثال کے ساتھ فراہم کی جا سکتی ہےNSBundle. یقینا Lo لوڈ شدہ کوڈ فطری طور پر عالمی ہے ، اور اس کے ساتھ چلنے کے لیے واضح طور پر عالمی نوٹیفکیشن سسٹم رکھنا معقول ہوگا۔R. جارج اوپر 2015-01-26 22:05:47 :میں وہی کور ڈیٹا پیٹرن استعمال کرتا ہوں جسے ڈینسکا نے بہت اچھے اثر کے لیے بیان کیا ہے۔
NSManagedObjectContextDidSaveNotification ہینڈلر طریقہ میں پہلی چیز پوسٹنگ سیاق و سباق کا ایک امتحان ہے تاکہ یہ دیکھا جا سکے کہ کیا اس کی مجھے پرواہ ہے: “کیا یہ بچت میرے اسٹور کو متاثر کر رہی ہے؟”
پورے ایپ کے ذریعے سکریچ سیاق و سباق کی وسیع تخلیق کو دیکھتے ہوئے ، ہر سیاق و سباق کے لیے سننے والے کو رجسٹر کرنے سے زیادہ آسان ہے جیسا کہ میں اسے تخلیق کرتا ہوں ، اور جب میں اسے خارج کرتا ہوں تو اسے غیر رجسٹر کرنا۔پیول پر 2015-01-27 07:45:54 :مائیکش مجھے ابھی تک سمجھ نہیں آیا کہ آپ کو سیلف انڈسٹری کا مقامی حوالہ کیوں ملتا ہے ، کیا یہ ایک ریفرنس کے بجائے ایک کاپی بنانا چاہیے؟بل میں 2015-01-27 13:28:44 :یہ واقعی ایک اچھا API ہے!
کیا آپ وضاحت کر سکتے ہیں کہ “(مثال کے طور پر ، کسی بھی پیرامیٹرز میں ترمیم کرنا بنیادی طور پر ناممکن ہے” “سیکشن میں نامی ٹیپلز کو ایک پیرامیٹر فنکشن کی دلیل کے طور پر استعمال کرنے کے بارے میں؟mikeash میں 2015-01-28 01:30:01 :پاول: یہ ایک کاپی بناتا ہے۔ سوئفٹ اریوں میں ویلیو سیمنٹکس ہیں ، لہذا صرف کرنے a = bسے آپ کو ایک نیا مل جاتا ہے۔
بل: ایک عام پاس تھرو فنکشن پر غور کریں: یہ متعدد پیرامیٹرز کے لیے کام کرتا ہے۔ اب ذرا تصور کریں کہ کیا آپ کوئی ایسا نسخہ لکھنا چاہتے ہیں جو کہے کہ اصل فنکشن کو کال کرنے سے پہلے 1 کوئی بھی انٹیجر پیرامیٹرز شامل کریں۔ اس کو پورا کرنے کا کوئی معقول طریقہ نہیں ہے۔
func call<T>(function: T -> Void, parameters: T) {
function(parameters)
}
روپرٹ میں 2015-01-29 10:56:52 :ہیلو مائیک – ایک اور معلوماتی مضمون کے لیے شکریہ! میں نے ہمیشہ آپ کے مضامین کو بہت سبق آموز پایا ہے ، خاص طور پر سوئفٹ کی نچلی سطح کی کارکردگی پر۔
میں آپ کے ساتھ سنگلیٹن کی برائیوں سے مکمل طور پر اتفاق کرتا ہوں ، جن میں سے صفر کا استعمال NSNotificationCenterیقینی طور پر ایک ہے۔ یہ بحث ممکن ہو سکتی ہے کہ اگر ہم نوٹیفکیشن سینٹر کی ایک غیر مشترکہ مثال استعمال کر رہے ہیں (یعنی جسے ہم نے فوری طور پر انجکشن دیا اور ہر جگہ اسے سبسکرائب / شائع کرنے کے لیے استعمال کیا جاتا ہے) تو یہ اب سنگلٹن نہیں بلکہ محض ایک ریاستی چیز ہے متحرک خصوصیات تاہم ، لگتا ہے کہ اس کے تقریبا all تمام استعمال مشترکہ مثال سے گزرتے ہیں۔
بدقسمتی سے کئی منظرنامے ہیں جہاں ایسا لگتا ہے کہ ہمارے پاس اس سنگلٹن رویے کو استعمال کرنے کے سوا کوئی چارہ نہیں ہے ، جیسے کی بورڈ نوٹیفیکیشن سنتے وقت (آئی او ایس میں) کیونکہ جو چیزیں ہم سننا چاہتے ہیں وہ ہمارے لیے دستیاب نہیں ہیں (اگر کوئی جانتا ہے کہ اس کے ارد گرد میں اسے سننے میں دلچسپی لوں گا)۔
میں نے سب singletons کے (انجیکشن کی لمبائی کے اپنے کوڈ میں سے چھٹکارا حاصل کرنے کے لئے عظیم درد لے کر دیا گیا ہے NSBundleاور UIScreenاس کی بجائے بلا کا ہے، ان تک رسائی کی ضرورت ہے جس میں اشیاء میں mainBundleاور mainScreen). کیا میں کوکو میں سنگلیٹن سے بچنے کے بہترین طریقوں پر ایک مضمون تجویز کر سکتا ہوں؟
دلچسپی رکھنے والوں کے لیے ، سنگلٹن کے خلاف سب سے زیادہ حوصلہ افزا دلیل جو میں نے دیکھی وہ یہ پرانا مضمون ہے- http://www.object-oriented-security.org/lets-argue/singletons
ایسا لگتا ہے کہ اگر مکمل انحصار انجکشن نافذ کیا جاتا ہے تو بہت سارے کوڈ/ایپلیکیشن سیکیورٹی مسائل موجود نہیں ہوں گے۔
ایک بار پھر شکریہ.Guillaume Lessard at 2015-02-02 20:06:09 :بہت دلچسپ مضمون ، شکریہ۔
ڈسپیچ_سینک کے سیریل قطار میں استعمال کے حوالے سے ، اگر آپ نے کبھی اس خاص تعمیر کو بینچ مارک کیا ہے تو آپ جان لیں گے کہ یہ خوفناک حد تک سست ہے۔ آپ اس کے بجائے OSSpinLock استعمال کر سکتے ہیں ، جو کہ آپ جس خاص ایپلی کیشن کو استعمال کر رہے ہیں اس کے لیے ٹھیک ہو گا: وقت میں تاخیر اس طرح ڈسپیچ_سینک استعمال کرنے کے مقابلے میں اس سے کم شدت کے آرڈر ہو سکتی ہے۔
private var lock = OS_SPINLOCK_INIT
private func synchronized(f: Void -> Void) {
OSSpinLockLock(&lock)
f()
OSSpinLockUnlock(&lock)
}
Deniska میں 2015-02-06 16:09:03 :مائیک ،
دراصل ، یہ نقطہ نظر متعدد بنیادی ڈیٹا اسٹورز کنفیگریشن کے ساتھ ٹھیک کام کرتا ہے۔
نوٹیفیکیشن میں مرسل ہے جو ایک سیاق و سباق کو محفوظ کیا جا رہا ہے۔ میں چیک کرتا ہوں کہ میرا سیاق و سباق بھیجنے والا ایک جیسا ہے۔
اگر نہیں – مجھے تبدیلیوں کو ضم کرنے کی ضرورت نہیں ہے۔
کچھ ایسا ہی۔
اور اس کے علاوہ ، یہ کئی گھریلو سیاق و سباق کے مقابلے میں تیزی سے کام کرتا ہے (میرے معاملے میں)۔mikeash میں 2015-02-06 16:32:20 :Guillaume Lessard: اتفاق سے میں اپنے تازہ ترین مضمون میں اس کے فوائد اور نقصانات پر بحث کرتا ہوں۔ آپ ٹھیک کہہ رہے ہیں کہ اسپن لاک یہاں بہت اچھا کام کرے گا ، لیکن میں ترجیح دیتا ہوں کہ بغیر کسی شناخت شدہ رفتار کے مسئلہ کے انہیں استعمال نہ کریں۔
ڈینسکا: میں کہوں گا کہ یہ کور ڈیٹا API میں ڈیزائن کے مسئلے کی نشاندہی کرتا ہے۔ اگر محفوظ اطلاعات ایک مخصوص مستقل سٹور کوآرڈینیٹر سے متعلقہ ہر چیز کو متاثر کرتی ہیں ، تو وہ اطلاعات کو پوسٹ کرنے والی چیز ہونی چاہیے ، انفرادی سیاق و سباق نہیں۔ (اگر ایسے معاملات ہیں جہاں آپ صرف مخصوص سیاق و سباق کی پرواہ کرتے ہیں تو میں کہوں گا کہ دونوں کو نوٹیفکیشن بھیجنا چاہئے۔)گورو اگروال میں 2015-02-13 02:46:34 :کیا آپ اس نحو پر کچھ روشنی ڈال سکتے ہیں:
private let f: AnyObject -> Parameters -> Voidmikeash میں 2015-02-15 02:34:48 :یہ قسم ایک فنکشن ہے جو ایک لیتا ہے AnyObjectاور دوسرا فنکشن لوٹاتا ہے۔ واپسی کی قسم Parametersباطل کو لیتی ہے اور لوٹاتی ہے۔Mobiledic میں 2015-03-04 14:42:50 :اگرچہ میں سوئفٹ سے زیادہ واقف نہیں ہوں (میں اب بھی او سی میں کوڈ لکھتا ہوں) ، مضمون میں وضاحت واقعی پوری ہے۔ شاید اب سوئفٹ پر جانے کا وقت آگیا ہے۔ڈیوڈ Baraff میں 2016-01-24 19:23:07 :ہر چیز کی ترسیل قطار؟ کیا یہ ایک مسئلہ ہے؟
میں نے اس کے بارے میں یہاں پوچھا:
Original Page Here By Michael Ash