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

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

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

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

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

  

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

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

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

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

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

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

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

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

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

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 एक्सपेरिमेंट में वैरिएंट के तौर पर बनाए गए पैरामीटर और पैरामीटर वैल्यू शामिल नहीं होती हैं.

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

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);
      });
}

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

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

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

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

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

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

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

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

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

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

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

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

रिमोट कॉन्फ़िगरेशन टेंप्लेट की पुष्टि करना

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

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);
      });
}

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 दिखेगा.

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

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

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

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

• उपयोगकर्ता की दिलचस्पी के मुताबिक सेटिंग को एक प्रोजेक्ट से दूसरे प्रोजेक्ट में इंपोर्ट नहीं किया जा सकता.

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

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

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

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

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);
      });
}

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());
  }
}

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

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

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

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

अपने Firebase प्रोजेक्ट के सभी सेवा खाते देखने के लिए, सेटिंग settings सेटिंग > सेवा खाते टैब पर जाएं.

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

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

1. Firebase कंसोल में, सेटिंग settings सेटिंग > सेवा खाते टैब पर जाएं.

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

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

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

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

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

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

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

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

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

 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

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

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 टेम्प्लेट के साथ काम करते समय, ध्यान रखें कि इनके वर्शन होते हैं. साथ ही, हर वर्शन की समय-सीमा सीमित होती है. यह समय-सीमा, टेम्प्लेट के बनने से लेकर अपडेट के ज़रिए उसे बदलने तक 90 दिनों की होती है. इसके अलावा, ज़्यादा से ज़्यादा 300 वर्शन सेव किए जा सकते हैं. ज़्यादा जानकारी के लिए, टेंप्लेट और वर्शनिंग देखें.

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

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

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

ये कमांड इस्तेमाल करें:

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

Host: firebaseremoteconfig.googleapis.com

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

रिमोट कॉन्फ़िगरेशन टेंप्लेट की पुष्टि करना

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

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

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

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

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

• उपयोगकर्ता की दिलचस्पी के मुताबिक सेटिंग को एक प्रोजेक्ट से दूसरे प्रोजेक्ट में इंपोर्ट नहीं किया जा सकता.

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

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

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

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

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

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

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

शर्तों और शर्तों के आधार पर तय की गई वैल्यू में प्रोग्राम के ज़रिए बदलाव किया जा सकता है.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."
    }
  }
}

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

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

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

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

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

ईटैग का इस्तेमाल और ज़बरदस्ती अपडेट करना

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

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

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

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