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

इस दस्तावेज़ में, 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 Admin SDK का इस्तेमाल करके, रिमोट कॉन्फ़िगरेशन में बदलाव करना

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

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

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

जब आप Admin SDK को बिना किसी पैरामीटर के शुरू करते हैं, तो SDK टूल Google Application Default Credentials का इस्तेमाल करता है. साथ ही, 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 के 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));

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

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

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

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

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

ज़रूरत पड़ने पर, 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());
  }
}

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

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

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

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

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

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

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

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

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

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

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

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

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

Linux या macOS

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

Windows

PowerShell के साथ:

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

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

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

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

इस उदाहरण में, 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

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

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

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

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

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 पेलोड एक फ़ाइल में और हेडर (ईटैग शामिल है) एक अलग फ़ाइल में आउटपुट होता है.

Raw HTTP request

Host: firebaseremoteconfig.googleapis.com

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

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

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

आपके पास, अपडेट को पब्लिश करने से पहले उनकी पुष्टि करने का विकल्प होता है. टेंप्लेट के अपडेट की पुष्टि करने के लिए, अपने पब्लिश करने के अनुरोध में यूआरएल पैरामीटर ?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 कमांड के लिए, कॉन्टेंट तय करने के लिए, "@" वर्ण के बाद फ़ाइल का नाम दिया जा सकता है.

Raw HTTP request

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

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

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

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

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

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

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

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

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

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

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