Firebase Remote Config: یہ کیا ہے، پیرامیٹرز اور دور سے کیسے منظم کریں

Firebase Remote Config کیا ہے اور یہ کیسے کام کرتا ہے

Firebase Remote Config ایک سروس ہے جو Firebase سرور سائڈ پر کلید-قدر کے جوڑے محفوظ کرتی ہے اور انہیں طلب پر یا شیڈول کے مطابق کلائنٹ ڈیوائسز تک پہنچاتی ہے۔ ہر پیرامیٹر کا ایک نام (سٹرنگ)، ایک قدر (سٹرنگ، نمبر، بولین یا JSON) ہوتا ہے اور اسے شرائط سے منسلک کیا جا سکتا ہے — قواعد جو یہ طے کرتے ہیں کہ کسی خاص صارف کو کون سی قدر ملتی ہے۔ شرائط ایپ ورژن، ڈیوائس زبان، علاقہ، بے ترتیب فیصد اور بہت سی دیگر خصوصیات کو چیک کر سکتی ہیں۔

Remote Config کا فن تعمیر پش-پل ماڈل پر مبنی ہے جس میں پل کو ترجیح دی جاتی ہے۔ کلائنٹ وقتاً فوقتاً سرور سے موجودہ قدریں طلب کرتا ہے (ڈیفالٹ طور پر ہر 12 گھنٹے بعد)۔ تاہم ڈویلپر کوڈ میں یا Firebase کنسول (“Publish changes” بٹن) کے ذریعے فوری مطابقت پذیری شروع کر سکتا ہے۔ تبدیلیاں شائع کرنے کے بعد، سرور Firebase Cloud Messaging کے ذریعے پش نوٹیفکیشن بھیجتا ہے، اور ایپ اسے وصول کر کے پیرامیٹرز دوبارہ طلب کر سکتی ہے۔

مفت درجہ Firebase Remote Config میں پیرامیٹرز یا درخواستوں کی تعداد کی کوئی حد نہیں ہے، جو اسے دیگر Firebase خدمات سے ممتاز کرتا ہے۔ واحد حد یہ ہے کہ جواب کا سائز 800 KB سے زیادہ نہیں ہونا چاہیے (تمام پیرامیٹرز کے لیے کل)۔ یہ عام منظر نامے کے لیے کافی سے زیادہ ہے: زیادہ تر پروجیکٹس 10–50 پیرامیٹرز استعمال کرتے ہیں، اور ان کا کل حجم شاذ و نادر ہی 100 KB سے زیادہ ہوتا ہے۔

Remote Config کیسے طے کرتا ہے کہ صارف کو کون سی قدر دی جائے

قدر کے انتخاب کا طریقہ کار شرائط کی ترجیح پر مبنی ہے۔ ہر شرط ایک اصول کی نمائندگی کرتی ہے (مثال کے طور پر، “iOS ورژن > 15.0”)۔ Remote Config شرائط کو ان کی ترجیح کے مطابق چیک کرتا ہے اور پہلی مماثل شرط کی قدر لوٹاتا ہے۔ اگر کوئی شرط مماثل نہیں ہوتی، تو ڈیفالٹ قدر استعمال ہوتی ہے۔ یہ طریقہ کار قواعد کا ایک درجہ بندی بنانے کی اجازت دیتا ہے: سب سے مخصوص سے سب سے عام تک۔

اہم: Firebase کنسول میں شرائط کی ترتیب اہم ہے۔ اگر دو شرائط ایک ہی وقت میں ایک صارف سے مماثل ہو سکتی ہیں، تو فہرست میں اوپر والی جیتتی ہے۔ زیادہ مخصوص شرائط (مثال کے طور پر کسی مخصوص ایپ ورژن کے لیے) کو عام شرائط (مثال کے طور پر “تمام iOS صارفین”) سے اوپر رکھنے کی سفارش کی جاتی ہے۔ غلط ترتیب کی وجہ سے کوئی ہدف والی تبدیلی کبھی لاگو نہیں ہو سکتی۔

کیشنگ اور پیرامیٹر کی زندگی کا دورانیہ

ڈیفالٹ طور پر، Remote Config سرور سے موصول ہونے والی قدروں کو 12 گھنٹے تک کیش کرتا ہے۔ اس کا مطلب ہے کہ کنسول میں تبدیلیاں شائع کرنے کے بعد، ایپ انہیں 12 گھنٹے سے پہلے نہیں دیکھے گی (یا اگلی واضح fetch کال کے بعد)۔ کم سے کم کیشنگ وقت FirebaseRemoteConfigSettings(minimumFetchIntervalInSeconds: 3600) کے ذریعے سیٹ کیا جا سکتا ہے — پروڈکشن کے لیے سرور سے ضرورت سے زیادہ درخواستوں اور صارف ڈیٹا ٹریفک سے بچنے کے لیے کم از کم 1 گھنٹہ تجویز کیا جاتا ہے۔

ترقی کے دوران تبدیلیوں کی جانچ کے لیے، 0 سیکنڈ کا کم سے کم وقفہ استعمال کریں: FirebaseRemoteConfigSettings(minimumFetchIntervalInSeconds: 0)۔ اس موڈ میں، ہر fetch کال سرور سے موجودہ قدریں لوڈ کرے گی۔ ریلیز سے پہلے پروڈکشن وقفے پر واپس جانا نہ بھولیں، ورنہ ایپ کے ہر آغاز پر سرور سے رابطہ ہوگا، جس سے اخراجات اور بیٹری کی کھپت بڑھ جائے گی۔

پیرامیٹرز، شرائط اور صارف گروپس

Remote Config پیرامیٹر ایک نامزد متغیر ہے جو شرائط کے لحاظ سے کئی قدروں میں سے ایک لے سکتا ہے۔ قدروں کی اقسام: سٹرنگ، نمبر (double)، بولین، JSON آبجیکٹ (سیریلائزڈ سٹرنگ)۔ JSON پیرامیٹرز متعدد علیحدہ پیرامیٹرز بنائے بغیر ساختی ڈیٹا منتقل کرنے کے لیے آسان ہیں: مثال کے طور پر، ایپ تھیم سیٹنگز والا آبجیکٹ (primaryColor، backgroundColor، fontSize)۔

شرائط منطقی قواعد ہیں جو صارف یا ڈیوائس کی خصوصیات کو چیک کرتی ہیں: OS ورژن (iOS، Android)، ایپ ورژن، ملک، زبان، صارف کے سامعین (کوڈ میں بیان کردہ خاصیت)، بے ترتیب فیصد (A/B ٹیسٹ کے لیے)۔ شرائط کو منطقی AND کے ذریعے جوڑا جا سکتا ہے: مثال کے طور پر، “ایپ ورژن >= 5.0” AND “ملک = روس”۔ ہر پیرامیٹر میں لامحدود شرائط ہو سکتی ہیں، لیکن عملی طور پر 2–5 استعمال ہوتی ہیں۔

پرسنلائزیشن کے لیے، صارف کی خصوصیات (user properties) استعمال کریں — Firebase Analytics کے ذریعے ایپلیکیشن کوڈ میں سیٹ کردہ صفات۔ مثال کے طور پر: analytics.setUserProperty(“subscription_tier”, “premium”)۔ Remote Config اس خاصیت کو چیک کر سکتا ہے اور پریمیم صارفین کے لیے مخصوص قدریں فراہم کر سکتا ہے۔ Remote Config کے ذریعے پرسنلائزیشن کے لیے کلائنٹ سائڈ پر شرائط بنانے کی ضرورت نہیں ہے — تمام منطق کلاؤڈ کنسول میں مرکوز ہے۔

صارف گروپس اور تقسیم

Remote Config دو تقسیم ماڈلز کو سپورٹ کرتا ہے: خصوصیات پر مبنی (شرائط) اور Firebase Analytics خصوصیات پر مبنی (صارف کی خصوصیات)۔ پہلا ماڈل جامد ہے: ایک شرط ایک مقررہ خصوصیت کو چیک کرتی ہے جو سیشن یا ایپ ورژن کے اندر تبدیل نہیں ہوتی۔ دوسرا ماڈل متحرک ہے: ایک خاصیت ایپ کے آپریشن کے دوران کسی بھی وقت سیٹ کی جا سکتی ہے، جو رن ٹائم پر لچکدار صارف تقسیم کی اجازت دیتی ہے۔

اہم: Remote Config میں صارف کی خصوصیات استعمال کرنے کے لیے، Firebase Analytics کو ضم کرنا ضروری ہے۔ یہ ضرورت اس وجہ سے ہے کہ Remote Config Analytics SDK سے صارف کا ڈیٹا وصول کرتا ہے۔ Analytics کے بغیر، Remote Config صرف ڈیوائس کی خصوصیات (OS ورژن، ایپ ورژن، IP سے ملک) کے ساتھ کام کرتا ہے۔ صارف کے رویے پر مبنی پرسنلائزیشن (مثال کے طور پر “5 خریداریاں کیں”) صرف Analytics کے ذریعے دستیاب ہے۔

سانچہ ورژننگ

Remote Config سانچہ تمام پیرامیٹرز، شرائط اور ان کی قدروں کا مکمل سیٹ ہے۔ Firebase سانچے کی تبدیلی کی تاریخ محفوظ کرتا ہے اور 90 دنوں کے اندر کسی بھی پچھلے ورژن پر واپس جانے کی اجازت دیتا ہے۔ ورژننگ انتہائی اہم ہے: اگر تبدیلیاں شائع کرنے کے بعد کوئی خرابی دریافت ہوتی ہے (مثلاً غلط پیرامیٹر ویلیو UI کو توڑ دیتی ہے)، تو آپ Firebase کنسول کے ذریعے فوری طور پر سانچے کو پچھلے کام کرنے والے ورژن پر واپس لا سکتے ہیں۔

سانچے کی ہر تبدیلی (اشاعت) ایک منفرد نمبر کے ساتھ ایک نیا ورژن بناتی ہے۔ Firebase کنسول وقت، صارف اور تفصیل (اگر پُر کی گئی ہو) کے ساتھ تبدیلی لاگ فراہم کرتا ہے۔ اشاعتوں میں ہمیشہ تفصیل شامل کرنے کی سفارش کی جاتی ہے: “iOS 10% ٹیسٹ گروپ کے لیے نئی فیڈ فعال کی”۔ تفصیل کے بغیر، ایک مہینے بعد یاد رکھنا ناممکن ہوگا کہ ورژن 42 میں بالکل کیا تبدیل کیا گیا تھا۔

ایپلیکیشن میں Remote Config کیسے لاگو کریں

Remote Config کا نفاذ تین مراحل پر مشتمل ہے: SDK کو ترتیبات (کیشنگ وقت) کے ساتھ شروع کرنا، ڈیفالٹ پیرامیٹرز کی وضاحت کرنا (سرور دستیاب نہ ہونے پر قدریں) اور حاصل کردہ قدروں کو لاگو کرنے کی منطق۔ ڈیفالٹ پیرامیٹرز اس صورت میں ایک حفاظتی جال ہیں جب ڈیوائس Firebase سے منسلک نہ ہو سکے (کوئی انٹرنیٹ نہیں، سرور دستیاب نہیں)۔ ڈیفالٹ ویلیوز کے بغیر، ایپ null استعمال کرے گی، جو کریش کا سبب بن سکتا ہے۔

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

غیر مطابقت پذیری Remote Config SDK کی ایک اہم خصوصیت ہے۔ fetchAndActivate() طریقہ UI کو روکے بغیر بیک گراؤنڈ تھریڈ میں سرور کو درخواست بھیجتا ہے۔ لوڈنگ مکمل ہونے کے بعد، ایکٹیویشن ہوتی ہے — پیرامیٹر ویلیوز ایپ کی میموری میں اپ ڈیٹ ہو جاتی ہیں۔ تکمیل کو ٹریک کرنے کے لیے listeners یا coroutines (Android/Kotlin میں) استعمال کریں۔ پیرامیٹرز اپ ڈیٹ ہونے پر صارف کو UI میں “چھلانگ” نظر نہیں آنی چاہیے — تمام تبدیلیاں آسانی سے لاگو ہونی چاہئیں۔

onComplete اور listeners کے ساتھ ابتدا

پہلی بار لانچ ہونے پر، Remote Config SDK ایپ کی ابتدا کو مسدود نہیں کرتا۔ جب مطابقت پذیری ہو رہی ہوتی ہے، ایپ ڈیفالٹ ویلیوز استعمال کرتی ہے۔ اس کا مطلب ہے کہ صارف پہلی بار لانچ پر پرانا انٹرفیس ورژن دیکھ سکتا ہے، اور fetch مکمل ہونے کے بعد — نیا۔ اہم پیرامیٹرز (مثلاً serverUrl، جس پر آپریشنلٹی منحصر ہے) کے لیے، نتیجہ کے انتظار کے ساتھ ہم آہنگ ایکٹیویشن استعمال کریں۔

تجویز کردہ عمل: اگر ایپ کو پہلی اسکرین دکھانے سے پہلے موجودہ پیرامیٹرز حاصل کرنے کی ضرورت ہو تو کم سے کم تاخیر کے ساتھ لوڈنگ اسکرین دکھائیں۔ لوڈنگ اسکرین پر، 5 سیکنڈ ٹائم آؤٹ کے ساتھ fetchAndActivate چلائیں۔ اگر 5 سیکنڈ میں پیرامیٹرز لوڈ نہیں ہوتے، تو ایپ ڈیفالٹ ویلیوز کے ساتھ شروع ہوتی ہے۔ یہ انٹرنیٹ نہ ہونے پر لامحدود انتظار کو روکتا ہے۔

JSON پیرامیٹرز کے ساتھ کام کرنا

JSON پیرامیٹرز Remote Config میں ساختی ڈیٹا کو ایک قدر کے طور پر منتقل کرنے کی اجازت دیتے ہیں۔ مثال کے طور پر، تھیم اسٹائلز والا آبجیکٹ: {“primaryColor”: “#6200EE”, “borderRadius”: 8, “fontFamily”: “Roboto”}۔ کلائنٹ پر، JSON کو پارس کیا جاتا ہے اور UI پر لاگو کیا جاتا ہے۔ فوائد: تین کے بجائے ایک پیرامیٹر، ایٹمی اپ ڈیٹ (تینوں فیلڈز ایک ساتھ اپ ڈیٹ ہوتے ہیں)، صاف کنسول۔ نقصان: Firebase کنسول میں پڑھنے میں دشواری (JSON کو سٹرنگ کے طور پر دکھایا جاتا ہے)۔

سفارش: منطقی طور پر متعلقہ قدروں کے گروپس کے لیے JSON پیرامیٹرز استعمال کریں جو ایک ساتھ اپ ڈیٹ ہوتے ہیں (تھیمز، اسکرین کنفیگریشن، نیٹ ورک سیٹنگز)۔ آزاد پیرامیٹرز (feature toggle، serverUrl) کے لیے، علیحدہ سٹرنگ یا بولین پیرامیٹرز استعمال کریں — یہ کنسول میں پڑھنے میں آسان ہیں اور سانچہ ورژن ہسٹری میں تبدیلیوں کو ٹریک کرنا آسان ہے۔

Remote Config کے ساتھ A/B ٹیسٹنگ

A/B ٹیسٹنگ Firebase Remote Config کی ایک بلٹ ان خصوصیت ہے جو صارفین کو گروپس میں تقسیم کرنے، ہر گروپ کے لیے مختلف پیرامیٹر ویلیوز سیٹ کرنے اور منتخب میٹرکس پر تبدیلیوں کے اثرات کی پیمائش کرنے کی اجازت دیتی ہے۔ random_percent کے ساتھ شرائط کے ذریعے دستی تقسیم کے برعکس، Firebase Analytics کے ساتھ انضمام خود بخود ہر تجرباتی گروپ کے لیے اعدادوشمار جمع کرتا ہے اور فرق کی شماریاتی اہمیت دکھاتا ہے۔

A/B ٹیسٹ کا عمل: ڈویلپر Firebase کنسول (A/B Testing سیکشن) میں ایک تجربہ بناتا ہے، ایک Remote Config پیرامیٹر منتخب کرتا ہے، کنٹرول اور ٹیسٹ گروپس کے لیے ویلیوز سیٹ کرتا ہے اور ہدف میٹرک (مثلاً تبادلوں کی شرح یا آمدنی) کی وضاحت کرتا ہے۔ Firebase خود بخود صارفین کو گروپس میں تقسیم کرتا ہے، ڈیٹا جمع کرتا ہے اور 2–4 ہفتوں بعد p-ویلیو کے ساتھ نتیجہ دکھاتا ہے۔ اگر نتیجہ حتمی ہو تو تجربہ جلد روکا جا سکتا ہے۔

شماریاتی اہمیت تجربہ روکنے کا کلیدی معیار ہے۔ Firebase A/B Testing فریکوئنٹسٹ طریقہ استعمال کرتا ہے اور ہر میٹرک کے لیے p-ویلیو دکھاتا ہے۔ اہمیت کی معیاری حد 0.05 ہے (95% اعتماد کا امکان)۔ جب یہ حد کسی ایک گروپ کے حق میں پہنچ جاتی ہے، Firebase تجربہ روکنے اور تمام صارفین پر تبدیلیاں لاگو کرنے کی سفارش کرتا ہے۔ اگر 4 ہفتوں کے بعد اہمیت حاصل نہیں ہوتی، تو تجربہ غیر حتمی سمجھا جاتا ہے۔

تجربات کی اقسام

Firebase A/B Testing دو قسم کے تجربات کو سپورٹ کرتا ہے: کلاسک A/B (ایک پیرامیٹر کی دو قدروں کا موازنہ) اور ملٹی ویریٹ A/B/n (تین یا زیادہ قدروں کا موازنہ)۔ ملٹی ویریٹ ٹیسٹوں کو شماریاتی اہمیت حاصل کرنے کے لیے زیادہ صارفین کی ضرورت ہوتی ہے۔ A/B/n کو صرف 3–5 ویریئنٹس والے پیرامیٹرز کے لیے استعمال کرنے کی سفارش کی جاتی ہے، جہاں ہر ویریئنٹ دوسروں سے بنیادی طور پر مختلف ہو۔

تجربے کی مدت ٹریفک کے حجم پر منحصر ہے: 1000 روزانہ فعال صارفین والی ایپ کے لیے کم از کم مدت 2 ہفتے ہے؛ 100,000 صارفین والی ایپ کے لیے 3–5 دن۔ Firebase خود بخود ضروری وقت کا حساب لگاتا ہے اور خبردار کرتا ہے اگر موجودہ ٹریفک اہم فرق کا پتہ لگانے کے لیے ناکافی ہو۔ اہم: متوقع وقت سے پہلے تجربہ نہ روکیں، چاہے نتیجہ واضح لگے — یہ کلاسک “peeking” غلطی ہے۔

A/B ٹیسٹنگ کے لیے میٹرکس

ہدف میٹرکس Firebase A/B Testing میں Firebase Analytics واقعات کی بنیاد پر سیٹ کی جاتی ہیں۔ معیاری میٹرکس دستیاب ہیں: روزانہ فعال صارفین، آمدنی، تبادلوں کی شرح، برقرار رکھنا، صارف کی مصروفیت۔ اضافی پیرامیٹرز کے ساتھ کسی بھی Analytics واقعہ کی بنیاد پر ایک حسب ضرورت میٹرک بھی بنایا جا سکتا ہے۔ مثال کے طور پر، میٹرک “ادائیگی کی اسکرین تک پہنچنے والے صارفین کا فیصد” پیرامیٹر screen_name = “payment” کے ساتھ screen_view واقعہ سے بنایا جاتا ہے۔

تجربے کی کامیابی کے فیصلے کی بنیاد کے لیے ایک بنیادی میٹرک اور اضافی تجزیہ کے لیے 2–3 ثانوی میٹرک منتخب کرنے کی سفارش کی جاتی ہے۔ متعدد بنیادی میٹرکس کا انتخاب غلط مثبت نتیجہ کے خطرے کو بڑھاتا ہے (متعدد موازنہ کا مسئلہ)۔ اگر منتخب کردہ بنیادی میٹرک شماریاتی طور پر اہم بہتری نہیں دکھاتا، تو تجربہ ناکام سمجھا جاتا ہے، چاہے ثانوی میٹرکس میں بہتری آئی ہو۔

Kotlin میں Remote Config کے لیے کوڈ مثالیں

آئیے Android ایپلیکیشن میں Kotlin میں Remote Config انضمام کو دیکھتے ہیں۔ مثالوں میں کسٹم کیشنگ وقت کے ساتھ SDK کی ابتدا، مختلف اقسام کے پیرامیٹرز حاصل کرنا، کلائنٹ سائڈ پر A/B شرط کو لاگو کرنا اور سرور دستیاب نہ ہونے پر غلطی کا انتظام شامل ہے۔ تمام کوڈ مرکزی سرگرمی یا Application کلاس میں چلتا ہے تاکہ پیرامیٹرز ایپ کے شروع ہونے سے ہی دستیاب ہوں۔

استعمال کرنے سے پہلے، Firebase BOM کے ذریعے انحصار شامل کریں: implementation(“com.google.firebase:firebase-config”)۔ یقینی بنائیں کہ Firebase Analytics بھی منسلک ہے، کیونکہ Remote Config صارف کی خصوصیات منتقل کرنے کے لیے Analytics استعمال کرتا ہے۔

ابتدا اور پیرامیٹرز حاصل کرنا

پہلی مثال پروڈکشن کے لیے 1 گھنٹے کے کم سے کم fetch وقفہ کے ساتھ بنیادی Remote Config سیٹ اپ ہے۔ SDK کو Application کلاس کے onCreate طریقہ میں شروع کیا جاتا ہے۔ fetchAndActivate کے بعد، welcome_message پیرامیٹر کی قدر چیک کی جاتی ہے، جسے استقبالیہ اسکرین کے لیے دور سے تبدیل کیا جا سکتا ہے۔

class MainApp : Application() {

    override fun onCreate() {
        super.onCreate()
        val remoteConfig = Firebase.remoteConfig
        val settings = FirebaseRemoteConfigSettings.Builder()
            .setMinimumFetchIntervalInSeconds(3600)
            .build()

        remoteConfig.setConfigSettingsAsync(settings)
        remoteConfig.setDefaultsAsync(
            R.xml.remote_config_defaults
        )

        remoteConfig.fetchAndActivate()
            .addOnCompleteListener { task ->
                if (task.isSuccessful) {
                    val welcomeMsg = remoteConfig
                        .getString("welcome_message")
                    Log.d("RemoteConfig", welcomeMsg)
                }
            }
    }
}

مثال میں، setDefaultsAsync XML فائل res/xml/remote_config_defaults.xml سے ڈیفالٹ ویلیوز لوڈ کرتا ہے۔ اگر fetch ناکام ہوتا ہے (نیٹ ورک نہیں، سرور دستیاب نہیں)، تو ایپ یہ ویلیوز استعمال کرے گی۔ XML فائل میں Firebase کنسول جیسے ہی پیرامیٹر کے نام ہوتے ہیں: <entry key=“welcome_message”>خوش آمدید!</entry>۔ تمام Remote Config پیرامیٹرز کے لیے ہمیشہ ڈیفالٹ ویلیوز رکھنے کی سفارش کی جاتی ہے۔

Remote Config کے ساتھ فیچر ٹوگل

دوسری مثال ایک فیچر ٹوگل (feature toggle) ہے۔ پیرامیٹر new_checkout_enabled بولین قسم کا ہے۔ اگر true ہے تو ایپ نیا چیک آؤٹ اسکرین دکھاتی ہے، اگر false ہے تو پرانا۔ فیچر ٹوگل سب سے مشہور Remote Config منظر نامہ ہے: تبدیلی صرف ایک پیرامیٹر کو متاثر کرتی ہے، منطق میں ترمیم کی ضرورت نہیں ہوتی اور فوری طور پر واپس لیا جا سکتا ہے۔

fun isFeatureEnabled(paramName: String): Boolean {
    return Firebase.remoteConfig
        .getBoolean(paramName)
}

// activity میں استعمال
if (isFeatureEnabled("new_checkout_enabled")) {
    navigateToNewCheckout()
} else {
    navigateToLegacyCheckout()
}

isFeatureEnabled فنکشن Remote Config تک رسائی کو انکیپسلیٹ کرتا ہے اور mock کے ذریعے آسانی سے جانچا جا سکتا ہے۔ فیچر ٹوگلز کے لیے نام رکھنے کا اصول استعمال کرنے کی سفارش کی جاتی ہے: سابقہ feature_، ff_ یا flag_ تاکہ Firebase کنسول میں پیرامیٹر کا مقصد فوری طور پر واضح ہو۔ مثال: feature_new_onboarding، ff_dark_mode، flag_v3_api۔ 3 ماہ سے زیادہ فعال/غیر فعال کرنے کے لیے پرچم پیرامیٹرز استعمال نہ کریں — مردہ پرچموں کا جمع ہونا دیکھ بھال کو پیچیدہ بناتا ہے۔

JSON تھیم کنفیگریشن حاصل کرنا

تیسری مثال ایپ تھیم سیٹنگز کے ساتھ JSON پیرامیٹر حاصل کرنا ہے۔ app_theme پیرامیٹر میں primaryColor، borderRadius اور fontFamily کے ساتھ ایک JSON آبجیکٹ ہوتا ہے۔ کلائنٹ پر، JSON کو Gson یا kotlinx.serialization کے ساتھ پارس کیا جاتا ہے اور ویلیوز کو UI پر لاگو کیا جاتا ہے۔ یہ طریقہ ڈیزائنرز کو ڈویلپر کی شمولیت اور ریلیز کے بغیر ایپ تھیم تبدیل کرنے کی اجازت دیتا ہے۔

data class AppTheme(
    val primaryColor: String = "#6200EE",
    val borderRadius: Int = 8,
    val fontFamily: String = "Roboto"
)

fun getAppTheme(): AppTheme {
    val json = Firebase.remoteConfig
        .getString("app_theme")
    return Gson().fromJson(json, AppTheme::class.java)
}

JSON کے ساتھ کام کرنا احتیاط کی ضرورت ہے: اگر Firebase کنسول میں JSON غلط ہے (مثلاً کوما غائب ہے)، تو پارسنگ ناکام ہو جائے گی اور ایپ موجودہ تھیم کے بجائے ڈیفالٹ ویلیوز حاصل کرے گی۔ JSON توثیق کنندہ کے ذریعے اشاعت سے پہلے JSON سٹرنگز کی تصدیق کرنے کی سفارش کی جاتی ہے۔ پروڈکشن کے لیے، پارسنگ کے دوران try-catch شامل کریں اور Firebase Crashlytics کے ذریعے غلطیاں لاگ کریں۔

بہترین طریقے اور حدود

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

حساس ڈیٹا سے بچیں — Remote Config راز (API چابیاں، ٹوکن، پاس ورڈ) محفوظ کرنے کے لیے ڈیزائن نہیں کیا گیا ہے۔ تمام پیرامیٹر ویلیوز کلائنٹ کوڈ کے لیے قابل رسائی ہیں اور ایپ کی میموری سے نکالی جا سکتی ہیں۔ خفیہ ڈیٹا کے لیے، سرور سائڈ تصدیق کے ساتھ Cloud Functions یا Secret Manager استعمال کریں۔ Remote Config میں صرف عوامی پیرامیٹرز محفوظ کریں: متن، پرچم، UI ترتیبات، عوامی اختتامی نکات کے URLs۔

ہر تبدیلی کو جانچیں پورے سامعین پر شائع کرنے سے پہلے۔ اس بات کی تصدیق کرنے کے لیے A/B ٹیسٹ یا چھوٹے فیصد (1–5% صارفین) پر اشاعت استعمال کریں کہ نئی قدر کریش کا سبب نہیں بنتی یا ڈسپلے کو نہیں توڑتی۔ Remote Config کا کوئی اسٹیجنگ ماحول نہیں ہے — تمام تبدیلیاں فوری طور پر پروڈکشن میں شائع ہو جاتی ہیں۔ محفوظ طریقے سے شائع کرنے کا واحد طریقہ بتدریج رول آؤٹ ہے۔

پلیٹ فارم کی حدود: زیادہ سے زیادہ پیرامیٹرز کی تعداد — 2000 (تمام اقسام کے لیے)، ایک قدر کا زیادہ سے زیادہ سائز — 256 KB، کل سرور جوابی سائز — 800 KB۔ Remote Config میں استعمال ہونے والی صارف کی خصوصیات کی تعداد 25 تک محدود ہے۔ کم سے کم fetch وقفہ 0 سیکنڈ ہے (ڈیبگنگ کے لیے)، لیکن ضرورت سے زیادہ استعمال Cloud Functions کوٹہ (فی منٹ 30,000 درخواستیں فی پروجیکٹ) سے تجاوز کر سکتا ہے۔