इस दस्तावेज़ में, प्रोग्राम के हिसाब से JSON फ़ॉर्मैट में मौजूद पैरामीटर और शर्तों के सेट को पढ़ने और उनमें बदलाव करने का तरीका बताया गया है. इन पैरामीटर और शर्तों को Remote Config टेंप्लेट कहा जाता है. इससे, बैकएंड में टेंप्लेट में बदलाव किए जा सकते हैं. क्लाइंट ऐप्लिकेशन, क्लाइंट लाइब्रेरी का इस्तेमाल करके ये बदलाव फ़ेच कर सकता है.
इस गाइड में बताए गए Remote Config REST API या Admin SDKs का इस्तेमाल करके, Firebase कंसोल में टेंप्लेट को मैनेज करने की प्रोसेस को बायपास किया जा सकता है. इससे, Remote Config में किए गए बदलावों को सीधे अपनी प्रोसेस में इंटिग्रेट किया जा सकता है. उदाहरण के लिए, Remote Config बैकएंड एपीआई की मदद से, ये काम किए जा सकते हैं:
- Remote Config अपडेट शेड्यूल करना. cron job के साथ एपीआई कॉल का इस्तेमाल करके, 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 के साथ इंटरैक्ट किया जा सकता है. Remote Config में अपडेट करने के अलावा, Admin SDK की मदद से Firebase के पुष्टि करने वाले टोकन जनरेट और पुष्टि किए जा सकते हैं. साथ ही, Realtime Database से पढ़ने और उसमें लिखने जैसे काम भी किए जा सकते हैं. Admin SDK सेटअप करने से पहले की ज़रूरी शर्तों और सेटअप के बारे में ज़्यादा जानने के लिए, अपने सर्वर में Firebase Admin 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 पैरामीटर में बदलाव करना
प्रोग्राम के हिसाब से, 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 की शर्तों में बदलाव करना
प्रोग्राम के हिसाब से, 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 बैकएंड एपीआई कई शर्तें और तुलना करने वाले ऑपरेटर उपलब्ध कराते हैं. इनका इस्तेमाल करके, अपने ऐप्लिकेशन के व्यवहार और दिखावट को बदला जा सकता है. शर्तों और इन शर्तों के लिए काम करने वाले ऑपरेटर के बारे में ज़्यादा जानने के लिए, शर्त के साथ इस्तेमाल होने वाली एक्सप्रेशन का रेफ़रंस देखें.
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()); } }
REST API का इस्तेमाल करके, रिमोट कॉन्फ़िगरेशन में बदलाव करना
इस सेक्शन में, https://firebaseremoteconfig.googleapis.com
पर Remote Config REST API की मुख्य सुविधाओं के बारे में बताया गया है.
पूरी जानकारी के लिए, एपीआई का रेफ़रंस देखें.
एपीआई अनुरोधों की पुष्टि करने और उन्हें अनुमति देने के लिए ऐक्सेस टोकन पाना
Firebase प्रोजेक्ट में Google के सेवा खाते काम करते हैं. इनका इस्तेमाल, अपने ऐप्लिकेशन सर्वर या भरोसेमंद एनवायरमेंट से Firebase सर्वर एपीआई को कॉल करने के लिए किया जा सकता है. अगर स्थानीय तौर पर कोड डेवलप किया जा रहा है या अपने ऐप्लिकेशन को ऑन-प्राइमिस डिप्लॉय किया जा रहा है, तो सर्वर के अनुरोधों को अनुमति देने के लिए, इस सेवा खाते से मिले क्रेडेंशियल का इस्तेमाल किया जा सकता है.
किसी सेवा खाते की पुष्टि करने और उसे Firebase की सेवाओं को ऐक्सेस करने की अनुमति देने के लिए, आपको JSON फ़ॉर्मैट में निजी कुंजी फ़ाइल जनरेट करनी होगी.
अपने सेवा खाते के लिए निजी पासकोड फ़ाइल जनरेट करने के लिए:
Firebase कंसोल में, सेटिंग > सेवा खाते खोलें.
नई निजी कुंजी जनरेट करें पर क्लिक करें. इसके बाद, कुंजी जनरेट करें पर क्लिक करके पुष्टि करें.
कुंजी वाली JSON फ़ाइल को सुरक्षित तरीके से सेव करें.
सेवा खाते से अनुमति देते समय, आपके पास अपने ऐप्लिकेशन को क्रेडेंशियल देने के लिए दो विकल्प होते हैं. 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);
});
}
इस उदाहरण में, 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 टेंप्लेट में बदलाव करना
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
यह एपीआई कॉल, यहां दिया गया JSON और एक अलग हेडर दिखाता है. इस हेडर में एक ETag शामिल होता है, जिसका इस्तेमाल अगले अनुरोध के लिए किया जाता है.
Remote Config टेंप्लेट की पुष्टि करना
इसके अलावा, अपडेट पब्लिश करने से पहले उनकी पुष्टि की जा सकती है.
पब्लिश करने के अनुरोध में यूआरएल पैरामीटर ?validate_only=true
जोड़कर, टेंप्लेट के अपडेट की पुष्टि करें.
जवाब में, स्टेटस कोड 200 और -0
के सफ़िक्स वाला अपडेट किया गया ईटैग मिलने का मतलब है कि आपके अपडेट की पुष्टि हो गई है. 200 के अलावा कोई भी रिस्पॉन्स, यह दिखाता है कि JSON डेटा में गड़बड़ियां हैं. इन्हें पब्लिश करने से पहले ठीक करना ज़रूरी है.
Remote Config टेंप्लेट अपडेट करना
टेंप्लेट को वापस पाने और अपने मनमुताबिक अपडेट के साथ 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 भी दिया जाता है.
Remote Config बैकएंड एपीआई कई शर्तें और तुलना करने वाले ऑपरेटर उपलब्ध कराते हैं. इनका इस्तेमाल करके, अपने ऐप्लिकेशन के व्यवहार और दिखावट को बदला जा सकता है. शर्तों और इन शर्तों के लिए काम करने वाले ऑपरेटर के बारे में ज़्यादा जानने के लिए, शर्त के साथ इस्तेमाल होने वाली एक्सप्रेशन का रेफ़रंस देखें.
एचटीटीपी गड़बड़ी कोड
स्थिति कोड | मतलब |
---|---|
200 | अपडेट हो गया |
400 | पुष्टि करने में कोई गड़बड़ी हुई. उदाहरण के लिए, अगर अनुरोध में अनुमति के मुताबिक 2,000 से ज़्यादा कुंजियां शामिल हैं, तो आपको गड़बड़ी का मैसेज Param count too large के साथ 400 (अनुरोध अमान्य है) कोड दिखेगा.
साथ ही, यह एचटीटीपीएस स्टेटस कोड इन दो स्थितियों में दिख सकता है:
|
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
कमांड के साथ किया जा सकता है.
Remote Config टेंप्लेट को इस तरह अपडेट करके, ETag और इससे मिलने वाली सुरक्षा को गच्चा दिया जा सकता है: If-Match: *
हालांकि, हमारा सुझाव है कि आप ऐसा न करें. ऐसा करने पर, अगर एक से ज़्यादा क्लाइंट Remote Config टेंप्लेट को अपडेट कर रहे हैं, तो आपके Remote Config टेंप्लेट के अपडेट मिटने का खतरा होता है. इस तरह का विरोध, एपीआई का इस्तेमाल करने वाले कई क्लाइंट के साथ हो सकता है. इसके अलावा, एपीआई क्लाइंट और Firebase कंसोल के उपयोगकर्ताओं के अपडेट के बीच विरोध भी हो सकता है.
Remote Config टेंप्लेट के वर्शन मैनेज करने के बारे में दिशा-निर्देश पाने के लिए, रिमोट कॉन्फ़िगरेशन टेंप्लेट और वर्शन लेख पढ़ें.