रिमोट कॉन्फ़िगरेशन को प्रोग्राम के हिसाब से बदलें

इस दस्तावेज़ में बताया गया है कि प्रोग्राम के हिसाब से, JSON फ़ॉर्मैट में मौजूद पैरामीटर और शर्तों के सेट को कैसे पढ़ा और उनमें बदलाव किया जा सकता है. इन पैरामीटर और शर्तों को Remote Config टेंप्लेट कहा जाता है. इससे, बैकएंड में टेंप्लेट में बदलाव किए जा सकते हैं. क्लाइंट ऐप्लिकेशन, क्लाइंट लाइब्रेरी का इस्तेमाल करके ये बदलाव फ़ेच कर सकता है.

इस गाइड में बताए गए Remote Config REST API या Admin SDK का इस्तेमाल करके, Firebase कंसोल में टेंप्लेट को मैनेज किए बिना, Remote Config बदलावों को अपनी प्रोसेस में सीधे तौर पर इंटिग्रेट किया जा सकता है. उदाहरण के लिए, Remote Config बैकएंड एपीआई की मदद से, ये काम किए जा सकते हैं:

• Remote Config अपडेट शेड्यूल करना. क्रॉन जॉब के साथ एपीआई कॉल का इस्तेमाल करके, Remote Config की वैल्यू को नियमित शेड्यूल के हिसाब से बदला जा सकता है.
• अपने मालिकाना सिस्टम से Firebase Remote Config पर बेहतर तरीके से ट्रांज़िशन करने के लिए, कॉन्फ़िगरेशन वैल्यू को एक साथ इंपोर्ट करें.

• Cloud Functions for Firebase के साथ Remote Config का इस्तेमाल करें. इससे सर्वर साइड पर होने वाले इवेंट के हिसाब से अपने ऐप्लिकेशन में वैल्यू बदली जा सकती हैं. उदाहरण के लिए, अपने ऐप्लिकेशन में किसी नई सुविधा का प्रमोशन करने के लिए, Remote Config का इस्तेमाल किया जा सकता है. इसके बाद, जब आपको पता चल जाएगा कि बहुत ज़्यादा लोगों ने नई सुविधा का इस्तेमाल किया है, तो इस प्रमोशन को अपने-आप बंद कर दिया जाएगा.

  

इस गाइड के नीचे दिए गए सेक्शन में Remote Config बैकएंड एपीआई की मदद से किए जा सकने वाले कामों के बारे में बताया गया है. REST API की मदद से ये काम करने वाले कोड की समीक्षा करने के लिए, इनमें से कोई एक सैंपल ऐप्लिकेशन देखें:

• Firebase रिमोट कॉन्फ़िगरेशन REST API Java Quickstart
• Firebase रिमोट कॉन्फ़िगरेशन REST API Node.js के लिए क्विकस्टार्ट
• Firebase रिमोट कॉन्फ़िगरेशन REST API Python के लिए क्विकस्टार्ट

Firebase एडमिन SDK का इस्तेमाल करके रिमोट कॉन्फ़िगरेशन में बदलाव करना

Admin SDK, सर्वर लाइब्रेरी का एक सेट है. इसकी मदद से, ऐक्सेस लेवल वाले एनवायरमेंट से Firebase के साथ इंटरैक्ट किया जा सकता है. Remote Config में अपडेट करने के अलावा, Admin SDK की मदद से Firebase के पुष्टि करने वाले टोकन जनरेट और पुष्टि किए जा सकते हैं. साथ ही, Realtime Database से पढ़ने और उसमें लिखने जैसे काम भी किए जा सकते हैं. Admin SDK की ज़रूरी शर्तों और सेटअप के बारे में ज़्यादा जानने के लिए, अपने सर्वर पर Firebase एडमिन SDK टूल जोड़ना देखें.

आम तौर पर, Remote Config फ़्लो में आपको मौजूदा टेंप्लेट मिल सकता है. साथ ही, कुछ पैरामीटर या पैरामीटर ग्रुप और शर्तों में बदलाव किया जा सकता है. इसके बाद, टेंप्लेट की पुष्टि करके उसे पब्लिश किया जा सकता है. ये एपीआई कॉल करने से पहले, आपको एसडीके से मिले अनुरोधों को अनुमति देनी होगी.

SDK टूल को शुरू करना और एपीआई अनुरोधों को अनुमति देना

बिना पैरामीटर के Admin SDK शुरू करने पर, SDK टूल Google ऐप्लिकेशन के डिफ़ॉल्ट क्रेडेंशियल का इस्तेमाल करता है. साथ ही, FIREBASE_CONFIG के एनवायरमेंट वैरिएबल में मौजूद विकल्पों को पढ़ता है. अगर FIREBASE_CONFIG वैरिएबल का कॉन्टेंट { से शुरू होता है, तो उसे JSON ऑब्जेक्ट के तौर पर पार्स किया जाएगा. ऐसा न होने पर, SDK यह मान लेता है कि स्ट्रिंग, विकल्पों वाली JSON फ़ाइल का नाम है.

उदाहरण के लिए:

Node.js

const admin = require('firebase-admin');
admin.initializeApp();

Java

FileInputStream serviceAccount = new FileInputStream("service-account.json");
FirebaseOptions options = FirebaseOptions.builder()
        .setCredentials(GoogleCredentials.fromStream(serviceAccount))
        .build();
FirebaseApp.initializeApp(options);

मौजूदा रिमोट कॉन्फ़िगरेशन टेंप्लेट पाना

Remote Config टेंप्लेट का इस्तेमाल करते समय, ध्यान रखें कि उनके वर्शन होते हैं. साथ ही, हर वर्शन का लाइफ़टाइम सीमित होता है. वर्शन बनाने के बाद, उसे अपडेट से बदलने तक का समय 90 दिन होता है. साथ ही, 300 वर्शन से ज़्यादा सेव नहीं किए जा सकते. ज़्यादा जानकारी के लिए, टेंप्लेट और वर्शन देखें.

Remote Config टेंप्लेट का मौजूदा चालू वर्शन, JSON फ़ॉर्मैट में पाने के लिए, बैकएंड एपीआई का इस्तेमाल किया जा सकता है.

A/B Testing एक्सपेरिमेंट में खास तौर पर वैरिएंट के तौर पर बनाए गए पैरामीटर और पैरामीटर वैल्यू, एक्सपोर्ट किए गए टेंप्लेट में शामिल नहीं की जाती हैं.

टेंप्लेट पाने के लिए:

Node.js

function getTemplate() {
  var config = admin.remoteConfig();
  config.getTemplate()
      .then(function (template) {
        console.log('ETag from server: ' + template.etag);
        var templateStr = JSON.stringify(template);
        fs.writeFileSync('config.json', templateStr);
      })
      .catch(function (err) {
        console.error('Unable to get template');
        console.error(err);
      });
}

Java

Template template = FirebaseRemoteConfig.getInstance().getTemplateAsync().get();
// See the ETag of the fetched template.
System.out.println("ETag from server: " + template.getETag());

सलाह: मौजूदा Remote Config टेंप्लेट को सीधे Firebase कंसोल से भी डाउनलोड किया जा सकता है. ज़्यादा जानने के लिए, रिमोट कॉन्फ़िगरेशन टेंप्लेट डाउनलोड और पब्लिश करें पर जाएं.

Remote Config पैरामीटर में बदलाव करना

प्रोग्राम के ज़रिए, Remote Config पैरामीटर और पैरामीटर ग्रुप में बदलाव किया जा सकता है और उन्हें जोड़ा जा सकता है. उदाहरण के लिए, "new_menu" नाम के किसी मौजूदा पैरामीटर ग्रुप में, सीज़न के हिसाब से जानकारी दिखाने की सुविधा को कंट्रोल करने के लिए पैरामीटर जोड़ा जा सकता है:

Node.js

function addParameterToGroup(template) {
  template.parameterGroups['new_menu'].parameters['spring_season'] = {
    defaultValue: {
      useInAppDefault: true
    },
    description: 'spring season menu visibility.',
  };
}

Java

template.getParameterGroups().get("new_menu").getParameters()
        .put("spring_season", new Parameter()
                .setDefaultValue(ParameterValue.inAppDefault())
                .setDescription("spring season menu visibility.")
        );

एपीआई की मदद से, नए पैरामीटर और पैरामीटर ग्रुप बनाए जा सकते हैं. इसके अलावा, डिफ़ॉल्ट वैल्यू, शर्तों के हिसाब से वैल्यू, और ब्यौरे में बदलाव भी किया जा सकता है. सभी मामलों में, बदलाव करने के बाद आपको टेंप्लेट को साफ़ तौर पर पब्लिश करना होगा.

रिमोट कॉन्फ़िगरेशन की शर्तें बदलें

प्रोग्राम के हिसाब से, Remote Config शर्तों और शर्तों के हिसाब से लागू होने वाली वैल्यू में बदलाव किया जा सकता है और उन्हें जोड़ा जा सकता है. उदाहरण के लिए, नई शर्त जोड़ने के लिए:

Node.js

function addNewCondition(template) {
  template.conditions.push({
    name: 'android_en',
    expression: 'device.os == \'android\' && device.country in [\'us\', \'uk\']',
    tagColor: 'BLUE',
  });
}

Java

template.getConditions().add(new Condition("android_en",
        "device.os == 'android' && device.country in ['us', 'uk']", TagColor.BLUE));

सभी मामलों में, बदलाव करने के बाद आपको टेंप्लेट को साफ़ तौर पर पब्लिश करना होगा.

ध्यान दें: Firebase Remote Config के लिए हर वैल्यू, असल में एक स्ट्रिंग होती है. इसलिए, बूलियन को "सही" और "गलत" के तौर पर इनपुट किया जाता है. getBoolean के तरीकों का इस्तेमाल करते समय, इन्हें सही तरीके से टाइप कास्ट करके बोलियन के तौर पर दिखाया जाता है. Firebase Remote Config के लिए, "सही" या "गलत" या "1" या "0", बूलियन वैल्यू के सही उदाहरण नहीं हैं.

Remote Config बैकएंड एपीआई में ऐसी कई शर्तें और तुलना करने वाले ऑपरेटर उपलब्ध हैं जिनका इस्तेमाल करके, ऐप्लिकेशन के काम करने के तरीके और लुक को बदला जा सकता है. इन शर्तों और उनके साथ काम करने वाले ऑपरेटर के बारे में ज़्यादा जानने के लिए, कंडिशनल एक्सप्रेशन का रेफ़रंस देखें.

Remote Config टेंप्लेट की पुष्टि करना

इसके अलावा, अपडेट पब्लिश करने से पहले उनकी पुष्टि की जा सकती है. इसके लिए, यह तरीका अपनाएं:

Node.js

function validateTemplate(template) {
  admin.remoteConfig().validateTemplate(template)
      .then(function (validatedTemplate) {
        // The template is valid and safe to use.
        console.log('Template was valid and safe to use');
      })
      .catch(function (err) {
        console.error('Template is invalid and cannot be published');
        console.error(err);
      });
}

Java

try {
  Template validatedTemplate = FirebaseRemoteConfig.getInstance()
          .validateTemplateAsync(template).get();
  System.out.println("Template was valid and safe to use");
} catch (ExecutionException e) {
  if (e.getCause() instanceof FirebaseRemoteConfigException) {
    FirebaseRemoteConfigException rcError = (FirebaseRemoteConfigException) e.getCause();
    System.out.println("Template is invalid and cannot be published");
    System.out.println(rcError.getMessage());
  }
}

पुष्टि करने की यह प्रोसेस, पैरामीटर और शर्तों के लिए डुप्लीकेट कुंजियों, अमान्य शर्तों के नामों या मौजूद न होने वाली शर्तों या गलत फ़ॉर्मैट वाले ईटैग जैसी गड़बड़ियों की जांच करती है. उदाहरण के लिए, अगर अनुरोध में अनुमति वाली संख्या—2,000—से ज़्यादा कुंजियां शामिल हैं, तो गड़बड़ी का मैसेज Param count too large दिखेगा.

Remote Config टेंप्लेट पब्लिश करना

टेंप्लेट को वापस लाने और उसमें अपनी पसंद के अपडेट करने के बाद, उसे पब्लिश किया जा सकता है. इस सेक्शन में बताए गए टेंप्लेट को पब्लिश करने के बाद, पूरा मौजूदा कॉन्फ़िगरेशन टेंप्लेट, अपडेट की गई फ़ाइल से बदल जाएगा. साथ ही, नए चालू टेंप्लेट को, बदले गए टेंप्लेट से बड़ा वर्शन नंबर एक असाइन किया जाता है.

अगर ज़रूरी हो, तो पिछले वर्शन पर वापस जाने के लिए, REST API का इस्तेमाल किया जा सकता है. किसी अपडेट में गड़बड़ियों के जोखिम को कम करने के लिए, पब्लिश करने से पहले पुष्टि की जा सकती है.

Remote Config डाउनलोड किए गए टेंप्लेट में, उपयोगकर्ताओं के हिसाब से कॉन्टेंट बनाने की सुविधा और शर्तें शामिल होती हैं. इसलिए, किसी दूसरे प्रोजेक्ट में पब्लिश करने के दौरान, इन सीमाओं का ध्यान रखना ज़रूरी है:

• मनमुताबिक बनाने की सुविधा, प्रोजेक्ट से प्रोजेक्ट में इंपोर्ट नहीं की जा सकती.

  उदाहरण के लिए, अगर आपने अपने प्रोजेक्ट में उपयोगकर्ता के हिसाब से कॉन्टेंट बनाने की सुविधा चालू की है और किसी टेंप्लेट को डाउनलोड करके उसमें बदलाव किया है, तो उसे उसी प्रोजेक्ट में पब्लिश किया जा सकता है. हालांकि, टेंप्लेट से उपयोगकर्ता के हिसाब से कॉन्टेंट बनाने की सुविधा मिटाए बिना, उसे किसी दूसरे प्रोजेक्ट में पब्लिश नहीं किया जा सकता.

• शर्तों को एक प्रोजेक्ट से दूसरे प्रोजेक्ट में इंपोर्ट किया जा सकता है. हालांकि, ध्यान रखें कि पब्लिश करने से पहले, टारगेट प्रोजेक्ट में शर्तों के हिसाब से कोई खास वैल्यू (जैसे, ऐप्लिकेशन आईडी या ऑडियंस) मौजूद होनी चाहिए.

  उदाहरण के लिए, अगर आपके पास कोई Remote Config पैरामीटर है, जिसमें ऐसी शर्त का इस्तेमाल किया गया है जो iOS की प्लैटफ़ॉर्म वैल्यू बताती है, तो टेंप्लेट को किसी दूसरे प्रोजेक्ट में पब्लिश किया जा सकता है. इसकी वजह यह है कि किसी भी प्रोजेक्ट के लिए प्लैटफ़ॉर्म वैल्यू एक जैसी होती हैं. हालांकि, अगर इसमें कोई ऐसी शर्त है जो किसी खास ऐप्लिकेशन आईडी या उपयोगकर्ता ऑडियंस पर निर्भर करती है और वह टारगेट प्रोजेक्ट में मौजूद नहीं है, तो पुष्टि नहीं हो पाएगी.

• अगर आपको जिस टेंप्लेट को पब्लिश करना है उसमें Google Analytics पर निर्भर शर्तें शामिल हैं, तो टारगेट प्रोजेक्ट में Analytics चालू होना चाहिए.

Node.js

function publishTemplate() {
  var config = admin.remoteConfig();
  var template = config.createTemplateFromJSON(
      fs.readFileSync('config.json', 'UTF8'));
  config.publishTemplate(template)
      .then(function (updatedTemplate) {
        console.log('Template has been published');
        console.log('ETag from server: ' + updatedTemplate.etag);
      })
      .catch(function (err) {
        console.error('Unable to publish template.');
        console.error(err);
      });
}

Java

try {
  Template publishedTemplate = FirebaseRemoteConfig.getInstance()
          .publishTemplateAsync(template).get();
  System.out.println("Template has been published");
  // See the ETag of the published template.
  System.out.println("ETag from server: " + publishedTemplate.getETag());
} catch (ExecutionException e) {
  if (e.getCause() instanceof FirebaseRemoteConfigException) {
    FirebaseRemoteConfigException rcError = (FirebaseRemoteConfigException) e.getCause();
    System.out.println("Unable to publish template.");
    System.out.println(rcError.getMessage());
  }
}

सलाह: Remote Config टेंप्लेट को सीधे Firebase कंसोल से भी पब्लिश किया जा सकता है. ज़्यादा जानने के लिए, रिमोट कॉन्फ़िगरेशन टेंप्लेट डाउनलोड और पब्लिश करें पर जाएं.

REST API का इस्तेमाल करके, रिमोट कॉन्फ़िगरेशन में बदलाव करना

इस सेक्शन में, https://firebaseremoteconfig.googleapis.com पर Remote Config REST API की मुख्य सुविधाओं के बारे में बताया गया है. पूरी जानकारी के लिए, एपीआई का रेफ़रंस देखें.

एपीआई अनुरोधों की पुष्टि करने और उन्हें अनुमति देने के लिए, ऐक्सेस टोकन पाएं

Firebase प्रोजेक्ट, Google सेवा खातों के साथ काम करते हैं. इनका इस्तेमाल करके, अपने ऐप्लिकेशन सर्वर या भरोसेमंद एनवायरमेंट से Firebase सर्वर एपीआई को कॉल किया जा सकता है. अगर स्थानीय तौर पर कोड डेवलप किया जा रहा है या अपने ऐप्लिकेशन को ऑन-प्राइमिस डिप्लॉय किया जा रहा है, तो सर्वर के अनुरोधों को अनुमति देने के लिए, इस सेवा खाते से मिले क्रेडेंशियल का इस्तेमाल किया जा सकता है.

सेवा खाते की पुष्टि करने और उसे Firebase की सेवाएं ऐक्सेस करने की अनुमति देने के लिए, आपको JSON फ़ॉर्मैट में एक निजी कुंजी फ़ाइल जनरेट करनी होगी.

अपने सेवा खाते के लिए निजी पासकोड फ़ाइल जनरेट करने के लिए:

1. Firebase कंसोल में, सेटिंग > सेवा खाते खोलें.

2. नई निजी कुंजी जनरेट करें पर क्लिक करें. इसके बाद, कुंजी जनरेट करें पर क्लिक करके पुष्टि करें.

3. कुंजी वाली JSON फ़ाइल को सुरक्षित तरीके से सेव करें.

ध्यान दें: क्रेडेंशियल जनरेट करने के लिए इस्तेमाल किए जाने वाले सेवा खाते के पास, Firebase रिमोट कॉन्फ़िगरेशन एडमिन की भूमिका में शामिल अनुमतियां होनी चाहिए. ऊपर दिया गया तरीका अपनाने और डिफ़ॉल्ट Firebase Admin SDK सेवा खाते का इस्तेमाल करने पर, ज़रूरी Remote Config अनुमतियां शामिल हो जाती हैं. अगर आपको REST API की मदद से ऑडियंस या उपयोगकर्ता प्रॉपर्टी की शर्तों को अपडेट करना है, तो आपको firebaseanalytics.resources.googleAnalyticsReadAndAnalyze की अनुमति को कस्टम रोल में जोड़ना होगा.

सेवा खाते से अनुमति देते समय, आपके पास अपने ऐप्लिकेशन को क्रेडेंशियल देने के दो विकल्प होते हैं. GOOGLE_APPLICATION_CREDENTIALS एनवायरमेंट वैरिएबल सेट किया जा सकता है या कोड में सेवा खाते की कुंजी का पाथ साफ़ तौर पर दिया जा सकता है. पहला विकल्प ज़्यादा सुरक्षित है और इसका सुझाव दिया जाता है.

एनवायरमेंट वैरिएबल सेट करने के लिए:

एनवायरमेंट वैरिएबल GOOGLE_APPLICATION_CREDENTIALS को उस JSON फ़ाइल के फ़ाइल पाथ पर सेट करें जिसमें आपकी सेवा खाता कुंजी है. यह वैरिएबल सिर्फ़ आपके मौजूदा शेल सेशन पर लागू होता है. इसलिए, नया सेशन खोलने पर, वैरिएबल को फिर से सेट करें.

Linux या macOS

export GOOGLE_APPLICATION_CREDENTIALS="/home/user/Downloads/service-account-file.json"

शीशा

PowerShell की मदद से:

$env:GOOGLE_APPLICATION_CREDENTIALS="C:\Users\username\Downloads\service-account-file.json"

ऊपर दिए गए चरणों को पूरा करने के बाद, ऐप्लिकेशन डिफ़ॉल्ट क्रेडेंशियल (एडीसी) आपके क्रेडेंशियल को सीधे तौर पर तय कर सकते हैं. इससे, Google से बाहर के प्लैटफ़ॉर्म में जांच करते समय या रन करते समय, सेवा खाते के क्रेडेंशियल का इस्तेमाल किया जा सकता है.

अपनी पसंदीदा भाषा के लिए, Google Auth Library के साथ अपने Firebase क्रेडेंशियल का इस्तेमाल करके, कुछ समय के लिए मान्य OAuth 2.0 ऐक्सेस टोकन पाएं:

node.js

 function getAccessToken() {
  return admin.credential.applicationDefault().getAccessToken()
      .then(accessToken => {
        return accessToken.access_token;
      })
      .catch(err => {
        console.error('Unable to get access token');
        console.error(err);
      });
}
index.js

इस उदाहरण में, Google API क्लाइंट लाइब्रेरी, अनुरोध की पुष्टि JSON वेब टोकन या JWT की मदद से करती है. ज़्यादा जानकारी के लिए, JSON वेब टोकन देखें.

Python

def _get_access_token():
  """Retrieve a valid access token that can be used to authorize requests.

  :return: Access token.
  """
  credentials = ServiceAccountCredentials.from_json_keyfile_name(
      'service-account.json', SCOPES)
  access_token_info = credentials.get_access_token()
  return access_token_info.access_token
configure.py

Java

public static String getAccessToken() throws IOException {
  GoogleCredentials googleCredentials = GoogleCredentials
          .fromStream(new FileInputStream("service-account.json"))
          .createScoped(Arrays.asList(SCOPES));
  googleCredentials.refreshAccessToken();
  return googleCredentials.getAccessToken().getTokenValue();
}
FirebaseRemoteConfigSnippets.java

ऐक्सेस टोकन की समयसीमा खत्म होने के बाद, अपडेट किया गया ऐक्सेस टोकन पाने के लिए, टोकन रीफ़्रेश करने का तरीका अपने-आप लागू हो जाता है.

Remote Config के ऐक्सेस की अनुमति देने के लिए, https://www.googleapis.com/auth/firebase.remoteconfig के स्कोप के लिए अनुरोध करें.

Remote Config टेंप्लेट में बदलाव करना

Remote Config टेंप्लेट का इस्तेमाल करते समय, ध्यान रखें कि उनके वर्शन होते हैं. साथ ही, हर वर्शन का लाइफ़टाइम सीमित होता है. इसे बनाने के बाद, अपडेट किए जाने तक हर वर्शन 90 दिनों तक सेव रहता है. साथ ही, एक साथ 300 वर्शन सेव किए जा सकते हैं. ज़्यादा जानकारी के लिए, टेंप्लेट और वर्शन देखें.

मौजूदा रिमोट कॉन्फ़िगरेशन टेंप्लेट पाना

Remote Config टेंप्लेट का मौजूदा चालू वर्शन, JSON फ़ॉर्मैट में पाने के लिए, बैकएंड एपीआई का इस्तेमाल किया जा सकता है.

A/B Testing एक्सपेरिमेंट में खास तौर पर वैरिएंट के तौर पर बनाए गए पैरामीटर और पैरामीटर वैल्यू, एक्सपोर्ट किए गए टेंप्लेट में शामिल नहीं की जाती हैं.

इन निर्देशों का इस्तेमाल करें:

cURL

curl --compressed -D headers -H "Authorization: Bearer token" -X GET https://firebaseremoteconfig.googleapis.com/v1/projects/my-project-id/remoteConfig -o filename

यह निर्देश JSON पेलोड को एक फ़ाइल में और हेडर (Etag के साथ) को एक अलग फ़ाइल में दिखाता है.

रॉ एचटीटीपी अनुरोध

Host: firebaseremoteconfig.googleapis.com

GET /v1/projects/my-project-id/remoteConfig HTTP/1.1
Authorization: Bearer token
Accept-Encoding: gzip

ध्यान दें: यह पढ़ने का अनुरोध है. इसलिए, इस निर्देश से ETag दिखता है, लेकिन उसमें कोई बदलाव नहीं किया जाता है.

यह एपीआई कॉल, यहां दिया गया JSON और एक अलग हेडर दिखाता है. इस हेडर में एक ETag शामिल होता है, जिसका इस्तेमाल अगले अनुरोध के लिए किया जाता है.

Remote Config टेंप्लेट की पुष्टि करना

इसके अलावा, अपडेट पब्लिश करने से पहले उनकी पुष्टि की जा सकती है. पब्लिश करने के अनुरोध में यूआरएल पैरामीटर ?validate_only=true जोड़कर, टेंप्लेट के अपडेट की पुष्टि करें. जवाब में, स्टेटस कोड 200 और -0 के सफ़िक्स वाला अपडेट किया गया ईटैग मिलने का मतलब है कि आपके अपडेट की पुष्टि हो गई है. 200 के अलावा कोई भी रिस्पॉन्स, यह दिखाता है कि JSON डेटा में गड़बड़ियां हैं. आपको पब्लिश करने से पहले, इन गड़बड़ियों को ठीक करना होगा.

रिमोट कॉन्फ़िगरेशन टेंप्लेट अपडेट करें

टेंप्लेट को वापस पाने और अपने मनमुताबिक अपडेट के साथ JSON कॉन्टेंट में बदलाव करने के बाद, उसे पब्लिश किया जा सकता है. इस सेक्शन में बताए गए तरीके से टेंप्लेट पब्लिश करने पर, पूरे मौजूदा कॉन्फ़िगरेशन टेंप्लेट को अपडेट की गई फ़ाइल से बदल दिया जाता है. साथ ही, नए ऐक्टिव टेंप्लेट को उस टेंप्लेट से एक नंबर ज़्यादा वर्शन नंबर असाइन किया जाता है जिसे बदला गया है.

अगर ज़रूरी हो, तो पिछले वर्शन पर वापस जाने के लिए, REST API का इस्तेमाल किया जा सकता है. किसी अपडेट में गड़बड़ियों के जोखिम को कम करने के लिए, पब्लिश करने से पहले पुष्टि की जा सकती है.

Remote Config डाउनलोड किए गए टेंप्लेट में, उपयोगकर्ताओं के हिसाब से कॉन्टेंट बनाने की सुविधा और शर्तें शामिल होती हैं. इसलिए, किसी दूसरे प्रोजेक्ट में पब्लिश करने के दौरान, इन सीमाओं का ध्यान रखना ज़रूरी है:

• मनमुताबिक बनाने की सुविधा, प्रोजेक्ट से प्रोजेक्ट में इंपोर्ट नहीं की जा सकती.

  उदाहरण के लिए, अगर आपने अपने प्रोजेक्ट में उपयोगकर्ता के हिसाब से कॉन्टेंट बनाने की सुविधा चालू की है और किसी टेंप्लेट को डाउनलोड करके उसमें बदलाव किया है, तो उसे उसी प्रोजेक्ट में पब्लिश किया जा सकता है. हालांकि, टेंप्लेट से उपयोगकर्ता के हिसाब से कॉन्टेंट बनाने की सुविधा मिटाए बिना, उसे किसी दूसरे प्रोजेक्ट में पब्लिश नहीं किया जा सकता.

• शर्तों को एक प्रोजेक्ट से दूसरे प्रोजेक्ट में इंपोर्ट किया जा सकता है. हालांकि, ध्यान रखें कि पब्लिश करने से पहले, टारगेट प्रोजेक्ट में शर्तों के हिसाब से कोई खास वैल्यू (जैसे, ऐप्लिकेशन आईडी या ऑडियंस) मौजूद होनी चाहिए.

  उदाहरण के लिए, अगर आपके पास कोई Remote Config पैरामीटर है, जिसमें ऐसी शर्त का इस्तेमाल किया गया है जो iOS की प्लैटफ़ॉर्म वैल्यू बताती है, तो टेंप्लेट को किसी दूसरे प्रोजेक्ट में पब्लिश किया जा सकता है. इसकी वजह यह है कि किसी भी प्रोजेक्ट के लिए प्लैटफ़ॉर्म वैल्यू एक जैसी होती हैं. हालांकि, अगर इसमें कोई ऐसी शर्त है जो किसी खास ऐप्लिकेशन आईडी या उपयोगकर्ता ऑडियंस पर निर्भर करती है और वह टारगेट प्रोजेक्ट में मौजूद नहीं है, तो पुष्टि नहीं हो पाएगी.

• अगर आपको जिस टेंप्लेट को पब्लिश करना है उसमें Google Analytics पर निर्भर शर्तें शामिल हैं, तो टारगेट प्रोजेक्ट में Analytics चालू होना चाहिए.

cURL

curl --compressed -H "Content-Type: application/json; UTF8" -H "If-Match: last-returned-etag" -H "Authorization: Bearer token" -X PUT https://firebaseremoteconfig.googleapis.com/v1/projects/my-project-id/remoteConfig -d @filename

इस curl कमांड के लिए, "@" वर्ण का इस्तेमाल करके कॉन्टेंट की जानकारी दी जा सकती है. इसके बाद, फ़ाइल का नाम लिखें.

रॉ एचटीटीपी अनुरोध

Host: firebaseremoteconfig.googleapis.com
PUT /v1/projects/my-project-id/remoteConfig HTTP/1.1
Content-Length: size
Content-Type: application/json; UTF8
Authorization: Bearer token
If-Match: expected ETag
Accept-Encoding: gzip
JSON_HERE

यह लिखने का अनुरोध है, इसलिए इस कमांड से ETag में बदलाव किया जाता है. साथ ही, अगले PUT कमांड के रिस्पॉन्स हेडर में अपडेट किया गया ETag दिया जाता है.

Remote Config की शर्तों में बदलाव करना

प्रोग्राम के हिसाब से, Remote Config शर्तों और शर्त के हिसाब से वैल्यू में बदलाव किया जा सकता है. REST API का इस्तेमाल करके, टेंप्लेट को पब्लिश करने से पहले, शर्तों में बदलाव करने के लिए, आपको टेंप्लेट में सीधे बदलाव करना होगा.

{
  "conditions": [{
    "name": "android_english",
    "expression": "device.os == 'android' && device.country in ['us', 'uk']",
    "tagColor": "BLUE"
  }, {
    "name": "tenPercent",
    "expression": "percent <= 10",
    "tagColor": "BROWN"
  }],
  "parameters": {
    "welcome_message": {
      "defaultValue": {
        "value": "Welcome to this sample app"
      },
      "conditionalValues": {
        "tenPercent": {
          "value": "Welcome to this new sample app"
        }
      },
      "description": "The sample app's welcome message"
    },
    "welcome_message_caps": {
      "defaultValue": {
        "value": "false"
      },
      "conditionalValues": {
        "android_english": {
          "value": "true"
        }
      },
      "description": "Whether the welcome message should be displayed in all capital letters."
    }
  }
}

ऊपर दिए गए बदलावों में, सबसे पहले शर्तों का एक सेट तय किया जाता है. इसके बाद, हर पैरामीटर के लिए डिफ़ॉल्ट वैल्यू और शर्त के आधार पर पैरामीटर (शर्त के हिसाब से वैल्यू) की वैल्यू तय की जाती है. यह हर एलिमेंट के लिए वैकल्पिक जानकारी भी जोड़ता है. जैसे, कोड की टिप्पणियां. ये डेवलपर के इस्तेमाल के लिए होती हैं और इन्हें ऐप्लिकेशन में नहीं दिखाया जाता. वर्शन कंट्रोल के लिए, ETag भी दिया जाता है.

ध्यान दें: हर वैल्यू, Firebase Remote Config के लिए मूल रूप से एक स्ट्रिंग होती है. इसलिए, बूलियन का इस्तेमाल "सही" और "गलत" के तौर पर किया जाता है. getBoolean तरीकों का इस्तेमाल करते समय, इन्हें सही तरीके से बूलियन के तौर पर कास्ट किया जाता है. "सही" या "गलत" या "1" या "0", Firebase Remote Config के लिए बूलियन को सही ढंग से नहीं दिखाते हैं.

Remote Config बैकएंड एपीआई कई शर्तें और तुलना करने वाले ऑपरेटर उपलब्ध कराते हैं. इनका इस्तेमाल करके, अपने ऐप्लिकेशन के व्यवहार और दिखावट को बदला जा सकता है. शर्तों और इन शर्तों के लिए काम करने वाले ऑपरेटर के बारे में ज़्यादा जानने के लिए, शर्त के साथ इस्तेमाल होने वाली एक्सप्रेशन का रेफ़रंस देखें.

एचटीटीपी गड़बड़ी कोड

स्थिति कोड	मतलब
200	अपडेट हो गया
400	पुष्टि करने में कोई गड़बड़ी हुई. उदाहरण के लिए, अगर अनुरोध में अनुमति के मुताबिक 2,000 से ज़्यादा कुंजियां शामिल हैं, तो आपको गड़बड़ी का मैसेज Param count too large के साथ 400 (अनुरोध अमान्य है) कोड दिखेगा. साथ ही, यह एचटीटीपीएस स्टेटस कोड इन दो स्थितियों में दिख सकता है: वर्शन मेल न खाने की गड़बड़ी हुई, क्योंकि आपने पिछली बार ETag वैल्यू हासिल करने के बाद, वैल्यू और शर्तों का सेट अपडेट कर दिया है. इसे ठीक करने के लिए, GET कमांड का इस्तेमाल करके नया टेंप्लेट और ETag वैल्यू पाएं और टेंप्लेट को अपडेट करें. इसके बाद, उस टेंप्लेट और नई ETag वैल्यू का इस्तेमाल करके सबमिट करें. If-Match हेडर के बारे में बताए बिना, PUT कमांड (Remote Config टेंप्लेट को अपडेट करने का अनुरोध) दिया गया था.
401	अनुमति से जुड़ी गड़बड़ी हुई (कोई ऐक्सेस टोकन नहीं दिया गया था या Firebase Remote Config REST API को Cloud Developer Console में आपके प्रोजेक्ट में नहीं जोड़ा गया है)
403	पुष्टि करने के दौरान कोई गड़बड़ी हुई (गलत ऐक्सेस टोकन दिया गया)
500	एक आंतरिक गड़बड़ी हुई. अगर यह गड़बड़ी होती है, तो Firebase की सहायता टीम को एक टिकट भेजें

स्टेटस कोड 200 का मतलब है कि Remote Config टेंप्लेट (पैरामीटर, वैल्यू, और प्रोजेक्ट के लिए शर्तें) अपडेट हो गया है और अब यह उन ऐप्लिकेशन के लिए उपलब्ध है जो इस प्रोजेक्ट का इस्तेमाल करते हैं. अन्य स्टेटस कोड से पता चलता है कि पहले से मौजूद Remote Config टेंप्लेट अब भी चालू है.

टेंप्लेट में अपडेट सबमिट करने के बाद, Firebase कंसोल पर जाकर पुष्टि करें कि आपके बदलाव सही तरीके से दिख रहे हैं या नहीं. यह ज़रूरी है, क्योंकि शर्तों के क्रम से उनके आकलन के तरीके पर असर पड़ता है. true का आकलन करने वाली पहली शर्त लागू होती है.

ETag का इस्तेमाल और अपडेट को जबरन लागू करना

Remote Config REST API, इकाई टैग (ETag) का इस्तेमाल करता है, ताकि 'एक ही समय पर कई अनुरोध' की स्थिति और संसाधनों के अपडेट ओवरलैप होने से रोका जा सके. ईटैग के बारे में ज़्यादा जानने के लिए, ईटैग - एचटीटीपी देखें.

Google का सुझाव है कि आप REST API के लिए, सबसे नए GET कमांड से मिले ETag को कैश मेमोरी में सेव करें. साथ ही, PUT कमांड जारी करते समय, If-Match अनुरोध हेडर में उस ETag वैल्यू का इस्तेमाल करें. अगर आपके PUT कमांड से एचटीटीपीएस स्टेटस कोड 409 मिलता है, तो आपको नया GET कमांड जारी करना चाहिए. इससे, आपको नया ईटैग और टेंप्लेट मिलेगा, जिसका इस्तेमाल अपने अगले PUT कमांड के साथ किया जा सकता है.

ध्यान दें: हमें एक ऐसी समस्या के बारे में पता है जिसमें ईटैग सही तरीके से नहीं लौटाया जाता. ऐसा उन मामलों में होता है जहां अनुरोध में कंप्रेशन के टाइप के बारे में नहीं बताया गया हो. फ़िलहाल, सभी अनुरोधों में Accept-Encoding: gzip हेडर या इसके बराबर का कोई हेडर शामिल करना ज़रूरी है.

ETag और उससे मिलने वाली सुरक्षा को गच्चा देने के लिए, Remote Config टेंप्लेट को इस तरह से अपडेट करना ज़रूरी है: If-Match: * हालांकि, आपको यह तरीका इस्तेमाल करने का सुझाव नहीं दिया जाता, क्योंकि अगर कई क्लाइंट Remote Config टेंप्लेट को अपडेट कर रहे हैं, तो इससे आपके Remote Config टेंप्लेट का अपडेट बंद हो सकता है. एपीआई का इस्तेमाल करने वाले एक से ज़्यादा क्लाइंट के साथ इस तरह का टकराव हो सकता है. इसके अलावा, एपीआई क्लाइंट और Firebase कंसोल उपयोगकर्ताओं के अपडेट होने से भी समस्या हो सकती है.

टेंप्लेट के Remote Config वर्शन को मैनेज करने के बारे में दिशा-निर्देश पाने के लिए, रिमोट कॉन्फ़िगरेशन टेंप्लेट और वर्शन देखें.