इस पेज का अनुवाद Cloud Translation API से किया गया है.

खोज से जुड़े कस्टम सुझाव जोड़ें

Android के लिए, Jetpack Compose को यूज़र इंटरफ़ेस (यूआई) टूलकिट के तौर पर इस्तेमाल करने का सुझाव दिया जाता है. Compose में खोज की सुविधा जोड़ने का तरीका जानें.

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

पसंद के मुताबिक सुझाव देने के बाद, उन्हें सिस्टम-वाइड क्विक सर्च बॉक्स के लिए भी उपलब्ध कराया जा सकता है. इससे आपके ऐप्लिकेशन के बाहर से भी आपके कॉन्टेंट को ऐक्सेस किया जा सकेगा.

कस्टम सुझाव जोड़ने से पहले, अपने ऐप्लिकेशन में खोज के लिए Android सर्च डायलॉग या सर्च विजेट लागू करें. सर्च इंटरफ़ेस बनाना और कॉन्टेंट प्रोवाइडर लेख पढ़ें.

बुनियादी बातें

पहली इमेज. कस्टम खोज के सुझावों के साथ खोज डायलॉग का स्क्रीनशॉट.

जब उपयोगकर्ता, कस्टम सुझाव चुनता है, तो सिस्टम आपकी खोजे जा सकने वाली गतिविधि को Intent भेजता है. सामान्य खोज क्वेरी में, ACTION_SEARCH ऐक्शन के साथ इंटेंट भेजा जाता है. हालांकि, इसके बजाय कस्टम सुझावों को ACTION_VIEW या किसी अन्य इंटेंट ऐक्शन का इस्तेमाल करने के लिए तय किया जा सकता है. साथ ही, चुने गए सुझाव से जुड़ा डेटा भी शामिल किया जा सकता है. डिक्शनरी के उदाहरण में, जब उपयोगकर्ता कोई सुझाव चुनता है, तो ऐप्लिकेशन उस शब्द की परिभाषा तुरंत खोल सकता है. इसके लिए, उसे डिक्शनरी में मिलते-जुलते शब्दों को खोजने की ज़रूरत नहीं होती.

अपनी पसंद के मुताबिक सुझाव पाने के लिए, यह तरीका अपनाएं:

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

Android सिस्टम, खोज डायलॉग बॉक्स के साथ-साथ खोज के सुझाव भी दिखाता है. आपको कॉन्टेंट उपलब्ध कराने वाली ऐसी कंपनी की ज़रूरत होगी जिससे सिस्टम आपके सुझावों को वापस पा सके. कॉन्टेंट उपलब्ध कराने वाली कंपनी बनाने का तरीका जानने के लिए, कॉन्टेंट उपलब्ध कराने वाली कंपनियां पढ़ें.

जब सिस्टम को पता चलता है कि आपकी गतिविधि को खोजा जा सकता है और वह खोज के सुझाव देता है, तो उपयोगकर्ता के क्वेरी डालने पर यह प्रोसेस होती है:

सिस्टम, खोज क्वेरी के टेक्स्ट को लेता है. इसका मतलब है कि अब तक जो भी जानकारी डाली गई है उसे लेता है. इसके बाद, यह आपके कॉन्टेंट उपलब्ध कराने वाले उस पार्टनर को क्वेरी भेजता है जो सुझावों को मैनेज करता है.
कॉन्टेंट उपलब्ध कराने वाली कंपनी, Cursor दिखाती है. यह खोज क्वेरी के टेक्स्ट से जुड़े सभी सुझावों की ओर इशारा करता है.
सिस्टम, Cursor से मिले सुझावों की सूची दिखाता है.

कस्टम सुझाव दिखने के बाद, ऐसा हो सकता है:

अगर उपयोगकर्ता कोई दूसरा अक्षर डालता है या क्वेरी में किसी भी तरह का बदलाव करता है, तो ऊपर दिए गए चरण दोहराए जाते हैं. साथ ही, सुझावों की सूची को उसके हिसाब से अपडेट किया जाता है.
अगर उपयोगकर्ता खोज करता है, तो सुझावों को अनदेखा कर दिया जाता है. साथ ही, सामान्य ACTION_SEARCH इंटेंट का इस्तेमाल करके, खोज को आपकी खोजे जा सकने वाली गतिविधि तक पहुंचाया जाता है.
अगर उपयोगकर्ता किसी सुझाव को चुनता है, तो खोजे जा सकने वाले आपके ऐप्लिकेशन को एक इंटेंट भेजा जाता है. इसमें कस्टम ऐक्शन और कस्टम डेटा होता है, ताकि आपका ऐप्लिकेशन सुझाया गया कॉन्टेंट खोल सके.

खोजे जा सकने वाले कॉन्फ़िगरेशन में बदलाव करना

कस्टम सुझावों की सुविधा जोड़ने के लिए, अपनी खोजे जा सकने वाले कॉन्फ़िगरेशन फ़ाइल में <searchable> एलिमेंट में android:searchSuggestAuthority एट्रिब्यूट जोड़ें. इसे यहां दिए गए उदाहरण में दिखाया गया है:

<?xml version="1.0" encoding="utf-8"?>
<searchable xmlns:android="http://schemas.android.com/apk/res/android"
    android:label="@string/app_label"
    android:hint="@string/search_hint"
    android:searchSuggestAuthority="com.example.MyCustomSuggestionProvider">
</searchable>

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

कॉन्टेंट देने वाली कंपनी बनाना

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

जब उपयोगकर्ता खोज डायलॉग या खोज विजेट में टेक्स्ट डालता है, तो सिस्टम आपके कॉन्टेंट उपलब्ध कराने वाले को सुझावों के लिए क्वेरी करता है. इसके लिए, वह हर बार अक्षर डाले जाने पर query() को कॉल करता है. query() को लागू करने के दौरान, कॉन्टेंट उपलब्ध कराने वाली कंपनी को आपके सुझाव वाले डेटा को खोजना होगा. साथ ही, उसे एक Cursor दिखाना होगा, जो उन लाइनों की ओर ले जाता हो जिन्हें वह अच्छे सुझाव मानता है.

कस्टम सुझावों के लिए कॉन्टेंट प्रोवाइडर बनाने के बारे में जानकारी, यहां दिए गए दो सेक्शन में दी गई है:

सुझाव वाली क्वेरी को हैंडल करना: सिस्टम, कॉन्टेंट उपलब्ध कराने वाली कंपनी को अनुरोध कैसे भेजता है और उन्हें कैसे मैनेज किया जाता है.
सुझाव वाली टेबल बनाना: उन कॉलम को कैसे तय करें जो सिस्टम को हर क्वेरी के साथ Cursor में चाहिए.

सुझाव वाली क्वेरी को मैनेज करना

जब सिस्टम, कॉन्टेंट उपलब्ध कराने वाली कंपनी से सुझावों का अनुरोध करता है, तो वह कॉन्टेंट उपलब्ध कराने वाली कंपनी के query() तरीके को कॉल करता है. इस तरीके को लागू करके, सुझावों से जुड़े डेटा को खोजें. इसके बाद, Cursor को वापस लाएं. यह Cursor, उन सुझावों की ओर इशारा करता है जो आपको काम के लगते हैं.

यहां उन पैरामीटर की खास जानकारी दी गई है जिन्हें सिस्टम, आपके query() तरीके में पास करता है. इन्हें क्रम से दिया गया है:

uri: हमेशा एक कॉन्टेंट Uri होता है, जिसे इस तरह फ़ॉर्मैट किया जाता है:
content://your.authority/optional.suggest.path/SUGGEST_URI_PATH_QUERY

डिफ़ॉल्ट रूप से, सिस्टम इस यूआरआई को पास करता है और इसमें क्वेरी टेक्स्ट जोड़ता है:

content://your.authority/optional.suggest.path/SUGGEST_URI_PATH_QUERY/puppies

आखिर में मौजूद क्वेरी टेक्स्ट को यूआरआई एन्कोडिंग के नियमों का इस्तेमाल करके एन्कोड किया जाता है. इसलिए, आपको खोज करने से पहले इसे डिकोड करना पड़ सकता है.

optional.suggest.path हिस्सा, यूआरआई में सिर्फ़ तब शामिल होता है, जब आपने android:searchSuggestPath एट्रिब्यूट के साथ, खोजे जा सकने वाले कॉन्फ़िगरेशन फ़ाइल में ऐसा पाथ सेट किया हो. इसकी ज़रूरत सिर्फ़ तब होती है, जब खोजे जा सकने वाले कई कामों के लिए, एक ही कॉन्टेंट देने वाली कंपनी का इस्तेमाल किया जाता हो. अगर ऐसा है, तो सुझाव वाली क्वेरी के सोर्स के बारे में ज़्यादा जानकारी दें.

ध्यान दें: SUGGEST_URI_PATH_QUERY, यूआरआई में दी गई स्ट्रिंग नहीं है. यह एक कॉन्स्टेंट है. अगर आपको इस पाथ का रेफ़रंस देना है, तो इसका इस्तेमाल करें.
projection: हमेशा शून्य होता है.
selection: खोजे जा सकने वाले कॉन्फ़िगरेशन फ़ाइल के android:searchSuggestSelection एट्रिब्यूट में दी गई वैल्यू. अगर आपने android:searchSuggestSelection एट्रिब्यूट की वैल्यू नहीं दी है, तो यह वैल्यू 'शून्य' होगी. इस बारे में ज़्यादा जानकारी यहां दी गई है.
selectionArgs: अगर आपने खोजे जा सकने वाले कॉन्फ़िगरेशन में android:searchSuggestSelection एट्रिब्यूट के बारे में बताया है, तो इसमें खोज क्वेरी को कलेक्शन के पहले और एकमात्र एलिमेंट के तौर पर शामिल किया जाता है. अगर आपने android:searchSuggestSelection का एलान नहीं किया है, तो इस पैरामीटर की वैल्यू शून्य होगी. इस बारे में यहां दिए गए सेक्शन में ज़्यादा जानकारी दी गई है.
sortOrder: हमेशा शून्य होता है.

सिस्टम, खोज क्वेरी का टेक्स्ट आपको दो तरीकों से भेज सकता है. क्वेरी टेक्स्ट को शामिल करने का डिफ़ॉल्ट तरीका यह है कि इसे uri पैरामीटर में पास किए गए कॉन्टेंट यूआरआई के आखिरी पाथ के तौर पर शामिल किया जाए. हालांकि, अगर आपने खोजे जा सकने वाले कॉन्फ़िगरेशन के android:searchSuggestSelection एट्रिब्यूट में कोई सिलेक्शन वैल्यू शामिल की है, तो क्वेरी टेक्स्ट, selectionArgs स्ट्रिंग ऐरे के पहले एलिमेंट के तौर पर पास होता है. इन दोनों विकल्पों के बारे में यहां बताया गया है.

यूआरआई में क्वेरी पाना

डिफ़ॉल्ट रूप से, क्वेरी को uri पैरामीटर के आखिरी सेगमेंट के तौर पर जोड़ा जाता है. यह एक Uri ऑब्जेक्ट होता है. इस मामले में क्वेरी टेक्स्ट को वापस पाने के लिए, getLastPathSegment() का इस्तेमाल करें. जैसा कि इस उदाहरण में दिखाया गया है:

Kotlin

val query: String = uri.lastPathSegment.toLowerCase()

Java

String query = uri.getLastPathSegment().toLowerCase();

इससे Uri का आखिरी सेगमेंट दिखता है. यह वह क्वेरी टेक्स्ट होता है जिसे उपयोगकर्ता डालता है.

चुने गए आर्ग्युमेंट में क्वेरी पाना

यूआरआई का इस्तेमाल करने के बजाय, आपकी query() विधि को लुक-अप करने के लिए ज़रूरी सभी चीज़ें मिल सकती हैं. साथ ही, आपको selection और selectionArgs पैरामीटर में सही वैल्यू मिल सकती हैं. इस मामले में, अपने खोजे जा सकने वाले कॉन्फ़िगरेशन में android:searchSuggestSelection एट्रिब्यूट जोड़ें. इसके लिए, SQLite की अपनी चुनी गई स्ट्रिंग का इस्तेमाल करें. चुने गए टेक्स्ट में, सवाल का निशान (?) शामिल करें. यह असली खोज क्वेरी के लिए प्लेसहोल्डर के तौर पर काम करेगा. सिस्टम, query() को कॉल करता है. इसमें selection पैरामीटर के तौर पर चुनी गई स्ट्रिंग और selectionArgs ऐरे में पहले एलिमेंट के तौर पर खोज क्वेरी शामिल होती है.

उदाहरण के लिए, फ़ुल-टेक्स्ट सर्च स्टेटमेंट बनाने के लिए, android:searchSuggestSelection एट्रिब्यूट को इस तरह बनाया जा सकता है:

<?xml version="1.0" encoding="utf-8"?>
<searchable xmlns:android="http://schemas.android.com/apk/res/android"
    android:label="@string/app_label"
    android:hint="@string/search_hint"
    android:searchSuggestAuthority="com.example.MyCustomSuggestionProvider"
    android:searchSuggestIntentAction="android.intent.action.VIEW"
    android:searchSuggestSelection="word MATCH ?">
</searchable>

इस कॉन्फ़िगरेशन की मदद से, query() तरीके से selection पैरामीटर को "word MATCH ?" के तौर पर और selectionArgs पैरामीटर को खोज क्वेरी के तौर पर डिलीवर किया जाता है. जब इन्हें SQLite query() के किसी तरीके को उनके संबंधित आर्ग्युमेंट के तौर पर पास किया जाता है, तो इन्हें एक साथ सिंथेसाइज़ किया जाता है. इसका मतलब है कि प्रश्न चिह्न को क्वेरी टेक्स्ट से बदल दिया जाता है. अगर आपको इस तरह से सुझाव वाली क्वेरी मिलती हैं और आपको क्वेरी टेक्स्ट में वाइल्डकार्ड जोड़ने हैं, तो उन्हें selectionArgs पैरामीटर में जोड़ें या पहले लगाएं. ऐसा इसलिए, क्योंकि यह वैल्यू कोटेशन में रैप की जाती है और प्रश्न चिह्न की जगह पर डाली जाती है.

पिछले उदाहरण में मौजूद एक अन्य एट्रिब्यूट android:searchSuggestIntentAction है. यह इंटेंट ऐक्शन को तय करता है. जब उपयोगकर्ता कोई सुझाव चुनता है, तब हर इंटेंट के साथ यह इंटेंट ऐक्शन भेजा जाता है. इस बारे में ज़्यादा जानकारी, सुझावों के लिए इंटेंट का एलान करना सेक्शन में दी गई है.

अहम जानकारी: अगर आपको android:searchSuggestSelection एट्रिब्यूट में कोई सिलेक्शन क्लॉज़ तय नहीं करना है, लेकिन आपको अब भी selectionArgs पैरामीटर में क्वेरी टेक्स्ट चाहिए, तो android:searchSuggestSelection एट्रिब्यूट के लिए कोई ऐसी वैल्यू दें जो शून्य न हो. इससे क्वेरी, selectionArgs में पास हो जाती है. साथ ही, selection पैरामीटर को अनदेखा किया जा सकता है. इस तरह, निचले लेवल पर असली सिलेक्शन क्लॉज़ तय किया जा सकता है, ताकि कॉन्टेंट उपलब्ध कराने वाली कंपनी को इसे मैनेज न करना पड़े.

सुझावों की टेबल बनाना

जब सिस्टम को Cursor के साथ सुझाव वापस भेजे जाते हैं, तो सिस्टम को हर लाइन में कुछ कॉलम की ज़रूरत होती है. सुझाव देने वाले डेटा को डिवाइस पर SQLite डेटाबेस में सेव किया जाता है या वेब सर्वर पर मौजूद डेटाबेस में. इसके अलावा, इसे डिवाइस या वेब पर किसी दूसरे फ़ॉर्मैट में भी सेव किया जा सकता है. सुझावों को टेबल में पंक्तियों के तौर पर फ़ॉर्मैट करें और उन्हें Cursor के साथ दिखाएं.

ध्यान दें: अगर आपकी खोज के सुझाव, टेबल फ़ॉर्मैट में सेव नहीं किए गए हैं, तो सिस्टम के लिए ज़रूरी कॉलम का इस्तेमाल करके, उन्हें SQLite टेबल जैसे फ़ॉर्मैट में सेव करें. इसके बाद, सुझाव वाले डेटा में मिलते-जुलते सुझाव खोजें और हर अनुरोध पर उन्हें ज़रूरी टेबल में फ़ॉर्मैट करें. इसके लिए, ज़रूरी कॉलम के नामों का इस्तेमाल करके MatrixCursor बनाएं. इसके बाद, addRow(Object[]) का इस्तेमाल करके, हर सुझाव के लिए एक लाइन जोड़ें. कॉन्टेंट उपलब्ध कराने वाली कंपनी के query() तरीके से, फ़ाइनल प्रॉडक्ट वापस पाएं.

सिस्टम कई कॉलम को समझता है, लेकिन इनमें से सिर्फ़ दो कॉलम ज़रूरी हैं:

_ID: हर सुझाव के लिए, यूनीक पूर्णांक पंक्ति आईडी. सिस्टम को इसकी ज़रूरत इसलिए होती है, ताकि वह ListView में सुझाव दिखा सके.
SUGGEST_COLUMN_TEXT_1: यह वह स्ट्रिंग है जिसे सुझाव के तौर पर दिखाया जाता है.

नीचे दिए गए सभी कॉलम में जानकारी देना ज़रूरी नहीं है. इनमें से ज़्यादातर के बारे में यहां दिए गए सेक्शन में ज़्यादा जानकारी दी गई है.

SUGGEST_COLUMN_TEXT_2: एक स्ट्रिंग. अगर आपके Cursor में यह कॉलम शामिल है, तो सभी सुझाव दो लाइन वाले फ़ॉर्मैट में दिए जाते हैं. इस कॉलम में मौजूद स्ट्रिंग, मुख्य सुझाव वाले टेक्स्ट के नीचे, टेक्स्ट की दूसरी और छोटी लाइन के तौर पर दिखती है. अगर कोई दूसरा टेक्स्ट नहीं है, तो इसे शून्य या खाली किया जा सकता है.
SUGGEST_COLUMN_ICON_1: ड्रॉ किए जा सकने वाले संसाधन, कॉन्टेंट या फ़ाइल यूआरआई स्ट्रिंग. अगर आपकी Cursor में यह कॉलम शामिल है, तो सभी सुझाव, आइकॉन-प्लस-टेक्स्ट फ़ॉर्मैट में दिए जाते हैं. इसमें आइकॉन बाईं ओर होता है. इसकी वैल्यू शून्य या null हो सकती है. इससे पता चलता है कि इस लाइन में कोई आइकॉन नहीं है.
SUGGEST_COLUMN_ICON_2: ड्रॉ किए जा सकने वाले संसाधन, कॉन्टेंट या फ़ाइल यूआरआई स्ट्रिंग. अगर आपके Cursor में यह कॉलम शामिल है, तो सभी सुझाव, आइकॉन-प्लस-टेक्स्ट फ़ॉर्मैट में दिए जाते हैं. इसमें आइकॉन दाईं ओर होता है. इसकी वैल्यू null या शून्य हो सकती है. इससे पता चलता है कि इस लाइन में कोई आइकॉन नहीं है.
SUGGEST_COLUMN_INTENT_ACTION: इंटेंट ऐक्शन स्ट्रिंग. अगर यह कॉलम मौजूद है और दी गई लाइन में इसकी कोई वैल्यू है, तो सुझाव के इंटेंट को तय करते समय, यहां तय की गई कार्रवाई का इस्तेमाल किया जाता है. अगर एलिमेंट नहीं दिया गया है, तो कार्रवाई, खोजे जा सकने वाले कॉन्फ़िगरेशन में मौजूद android:searchSuggestIntentAction फ़ील्ड से की जाती है. अगर सभी सुझावों के लिए आपकी कार्रवाई एक जैसी है, तो android:searchSuggestIntentAction का इस्तेमाल करके कार्रवाई तय करना ज़्यादा असरदार होता है. साथ ही, इस कॉलम को शामिल न करें.
SUGGEST_COLUMN_INTENT_DATA: यह एक डेटा यूआरआई स्ट्रिंग है. अगर यह कॉलम मौजूद है और इसमें दी गई लाइन में कोई वैल्यू है, तो सुझाव के इंटेंट को तय करते समय इस डेटा का इस्तेमाल किया जाता है. अगर एलिमेंट नहीं दिया गया है, तो डेटा को खोजे जा सकने वाले कॉन्फ़िगरेशन में मौजूद android:searchSuggestIntentData फ़ील्ड से लिया जाता है. अगर दोनों में से कोई भी सोर्स नहीं दिया गया है, तो इंटेंट का डेटा फ़ील्ड null होता है. अगर सभी सुझावों के लिए आपका डेटा एक जैसा है या उसे किसी स्थिर हिस्से और खास आईडी का इस्तेमाल करके बताया जा सकता है, तो उसे android:searchSuggestIntentData का इस्तेमाल करके बताना ज़्यादा असरदार होता है. साथ ही, इस कॉलम को शामिल न करें.
SUGGEST_COLUMN_INTENT_DATA_ID: यूआरआई पाथ स्ट्रिंग. अगर यह कॉलम मौजूद है और दी गई लाइन में इसकी कोई वैल्यू है, तो "/" और इस वैल्यू को इंटेंट के डेटा फ़ील्ड में जोड़ दिया जाता है. इस विकल्प का इस्तेमाल सिर्फ़ तब करें, जब खोजे जा सकने वाले कॉन्फ़िगरेशन में android:searchSuggestIntentData एट्रिब्यूट से तय किया गया डेटा फ़ील्ड, पहले से ही सही बेस स्ट्रिंग पर सेट हो.
SUGGEST_COLUMN_INTENT_EXTRA_DATA: आर्बिट्रेरी डेटा. अगर यह कॉलम मौजूद है और इसमें किसी लाइन के लिए कोई वैल्यू है, तो यह अतिरिक्त डेटा है. इसका इस्तेमाल सुझाव के इंटेंट को तय करने के लिए किया जाता है. अगर यह वैल्यू नहीं दी जाती है, तो इंटेंट के एक्स्ट्रा डेटा फ़ील्ड की वैल्यू शून्य होती है. इस कॉलम की मदद से, सुझावों में अतिरिक्त डेटा शामिल किया जा सकता है. यह डेटा, इंटेंट के EXTRA_DATA_KEY में अतिरिक्त तौर पर शामिल किया जाता है.
SUGGEST_COLUMN_QUERY: अगर यह कॉलम मौजूद है और यह एलिमेंट दी गई लाइन में मौजूद है, तो सुझाव की क्वेरी बनाते समय इस डेटा का इस्तेमाल किया जाता है. इसे इंटेंट की QUERY कुंजी में अतिरिक्त तौर पर शामिल किया जाता है. अगर सुझाव में दी गई कार्रवाई ACTION_SEARCH है, तो यह फ़ील्ड ज़रूरी है. हालांकि, अन्य मामलों में यह वैकल्पिक है.
SUGGEST_COLUMN_SHORTCUT_ID: इस कुकी का इस्तेमाल सिर्फ़ तब किया जाता है, जब क्विक सर्च बॉक्स के लिए सुझाव दिए जाते हैं. इस कॉलम से यह पता चलता है कि खोज के सुझाव को शॉर्टकट के तौर पर सेव किया जाना चाहिए या नहीं. साथ ही, यह भी पता चलता है कि इसकी पुष्टि की जानी चाहिए या नहीं. आम तौर पर, शॉर्टकट तब बनते हैं, जब उपयोगकर्ता क्विक सर्च बॉक्स में मौजूद किसी सुझाव पर टैप करता है. अगर यह मौजूद नहीं है, तो नतीजे को शॉर्टकट के तौर पर सेव किया जाता है और कभी रीफ़्रेश नहीं किया जाता. अगर इसे SUGGEST_NEVER_MAKE_SHORTCUT पर सेट किया जाता है, तो नतीजे को शॉर्टकट के तौर पर सेव नहीं किया जाता. ऐसा न होने पर, शॉर्टकट आईडी का इस्तेमाल किया जाता है. इससे SUGGEST_URI_PATH_SHORTCUT का इस्तेमाल करके, अपडेट किए गए सुझाव को फिर से देखा जा सकता है.
SUGGEST_COLUMN_SPINNER_WHILE_REFRESHING: इस कुकी का इस्तेमाल सिर्फ़ तब किया जाता है, जब क्विक सर्च बॉक्स के लिए सुझाव दिए जाते हैं. इस कॉलम से यह पता चलता है कि SUGGEST_COLUMN_ICON_2 से आइकॉन दिखाने के बजाय, स्पिनर दिखाना ज़रूरी है. ऐसा तब होता है, जब क्विक सर्च बॉक्स में इस सुझाव का शॉर्टकट रीफ़्रेश हो रहा हो.

इनमें से ज़्यादातर कॉलम के बारे में, यहां दिए गए सेक्शन में ज़्यादा जानकारी दी गई है.

सुझावों के लिए इंटेंट का एलान करना

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

इंटेंट ऐक्शन का एलान करना

कस्टम सुझाव के लिए, सबसे आम इंटेंट ऐक्शन ACTION_VIEW होता है. यह तब सही होता है, जब आपको कोई चीज़ खोलनी हो. जैसे, किसी शब्द की परिभाषा, किसी व्यक्ति की संपर्क जानकारी या कोई वेब पेज. हालांकि, इंटेंट ऐक्शन कोई दूसरा ऐक्शन भी हो सकता है और हर सुझाव के लिए अलग-अलग हो सकता है.

अगर आपको सभी सुझावों के लिए एक ही इंटेंट ऐक्शन का इस्तेमाल करना है, तो ऐक्शन को दो तरीकों से तय किया जा सकता है:

खोजे जा सकने वाले कॉन्फ़िगरेशन फ़ाइल के android:searchSuggestIntentAction एट्रिब्यूट का इस्तेमाल करके, सभी सुझावों के लिए कार्रवाई तय करें. ऐसा करने का तरीका इस उदाहरण में दिखाया गया है:
```
<?xml version="1.0" encoding="utf-8"?>
<searchable xmlns:android="http://schemas.android.com/apk/res/android"
    android:label="@string/app_label"
    android:hint="@string/search_hint"
    android:searchSuggestAuthority="com.example.MyCustomSuggestionProvider"
    android:searchSuggestIntentAction="android.intent.action.VIEW" >
</searchable>
```
SUGGEST_COLUMN_INTENT_ACTION कॉलम का इस्तेमाल करके, हर सुझाव के लिए कार्रवाई तय करें. इसके लिए, सुझावों की टेबल में SUGGEST_COLUMN_INTENT_ACTION कॉलम जोड़ें. इसके बाद, हर सुझाव के लिए, इस्तेमाल की जाने वाली कार्रवाई को इसमें रखें. जैसे, "android.intent.action.VIEW".

इन दोनों तकनीकों को एक साथ भी इस्तेमाल किया जा सकता है. उदाहरण के लिए, android:searchSuggestIntentAction एट्रिब्यूट को किसी ऐसी कार्रवाई के साथ शामिल किया जा सकता है जिसे डिफ़ॉल्ट रूप से सभी सुझावों के साथ इस्तेमाल किया जाना है. इसके बाद, SUGGEST_COLUMN_INTENT_ACTION कॉलम में कोई दूसरी कार्रवाई तय करके, कुछ सुझावों के लिए इस कार्रवाई को बदला जा सकता है. अगर आपने SUGGEST_COLUMN_INTENT_ACTION कॉलम में कोई वैल्यू शामिल नहीं की है, तो android:searchSuggestIntentAction एट्रिब्यूट में दी गई वैल्यू का इस्तेमाल किया जाता है.

ध्यान दें: अगर आपने खोजे जा सकने वाले कॉन्फ़िगरेशन में android:searchSuggestIntentAction एट्रिब्यूट शामिल नहीं किया है, तो आपको हर सुझाव के लिए SUGGEST_COLUMN_INTENT_ACTION कॉलम में वैल्यू शामिल करनी होगी. ऐसा न करने पर, इंटेंट पूरा नहीं होगा.

इंटेंट डेटा का एलान करना

जब उपयोगकर्ता कोई सुझाव चुनता है, तो आपकी खोजे जा सकने वाली गतिविधि को वह इंटेंट मिलता है जिसमें आपकी तय की गई कार्रवाई शामिल होती है. इसके बारे में पिछले सेक्शन में बताया गया है. हालांकि, इंटेंट में आपकी गतिविधि का डेटा भी होना चाहिए, ताकि यह पता चल सके कि कौन-सा सुझाव चुना गया है. खास तौर पर, हर सुझाव के लिए डेटा यूनीक होना चाहिए. जैसे, आपकी SQLite टेबल में सुझाव के लिए लाइन का आईडी. इंटेंट मिलने पर, अटैच किए गए डेटा को getData() या getDataString() की मदद से वापस पाया जा सकता है.

इरादे के साथ शामिल किए गए डेटा को दो तरीकों से तय किया जा सकता है:

सुझावों की टेबल के SUGGEST_COLUMN_INTENT_DATA कॉलम में, हर सुझाव के लिए डेटा तय करें.
सुझावों वाली टेबल में, हर इंटेंट के लिए ज़रूरी डेटा की जानकारी दें. इसके लिए, SUGGEST_COLUMN_INTENT_DATA कॉलम को शामिल करें. इसके बाद, हर पंक्ति के लिए यूनीक डेटा डालें. इस कॉलम में मौजूद डेटा को इंटेंट से ठीक उसी तरह जोड़ा जाता है जिस तरह आपने इस कॉलम में तय किया है. इसके बाद, getData() या getDataString() की मदद से इसे वापस लाया जा सकता है.

अहम जानकारी: आम तौर पर, टेबल के लाइन आईडी को इंटेंट डेटा के तौर पर इस्तेमाल करना आसान होता है, क्योंकि यह हमेशा यूनीक होता है. ऐसा करने का सबसे आसान तरीका यह है कि SUGGEST_COLUMN_INTENT_DATA कॉलम के नाम का इस्तेमाल, लाइन आईडी कॉलम के लिए उपनाम के तौर पर किया जाए.
डेटा यूआरआई को दो हिस्सों में बांटें: पहला हिस्सा, सभी सुझावों में एक जैसा हो और दूसरा हिस्सा, हर सुझाव के लिए अलग-अलग हो. इन हिस्सों को, खोजे जा सकने वाले कॉन्फ़िगरेशन के android:searchSuggestintentData एट्रिब्यूट और सुझावों की टेबल के SUGGEST_COLUMN_INTENT_DATA_ID कॉलम में रखें.
यहां दिए गए उदाहरण में बताया गया है कि यूआरआई के उस हिस्से को कैसे एलान किया जाता है जो खोजे जा सकने वाले कॉन्फ़िगरेशन के android:searchSuggestIntentData एट्रिब्यूट में मौजूद सभी सुझावों के लिए एक जैसा होता है:
```
  <?xml version="1.0" encoding="utf-8"?>
  <searchable xmlns:android="http://schemas.android.com/apk/res/android"
      android:label="@string/app_label"
      android:hint="@string/search_hint"
      android:searchSuggestAuthority="com.example.MyCustomSuggestionProvider"
      android:searchSuggestIntentAction="android.intent.action.VIEW"
      android:searchSuggestIntentData="content://com.example/datatable" >
  </searchable>
  
```
सुझावों की टेबल के SUGGEST_COLUMN_INTENT_DATA_ID कॉलम में, हर सुझाव के लिए फ़ाइनल पाथ शामिल करें. यह यूनीक हिस्सा होता है. जब उपयोगकर्ता किसी सुझाव को चुनता है, तो सिस्टम android:searchSuggestIntentData से स्ट्रिंग लेता है, उसमें स्लैश (/) जोड़ता है, और फिर SUGGEST_COLUMN_INTENT_DATA_ID कॉलम से संबंधित वैल्यू जोड़कर, कॉन्टेंट का पूरा यूआरआई बनाता है. इसके बाद, getData() का इस्तेमाल करके Uri को वापस पाया जा सकता है.

ज़्यादा डेटा जोड़ना

अगर आपको अपने इंटेंट के बारे में ज़्यादा जानकारी देनी है, तो टेबल में एक और कॉलम जोड़ा जा सकता है. जैसे, SUGGEST_COLUMN_INTENT_EXTRA_DATA. इसमें सुझाव के बारे में ज़्यादा जानकारी सेव की जा सकती है. इस कॉलम में सेव किया गया डेटा, इंटेंट के अतिरिक्त बंडल के EXTRA_DATA_KEY में रखा जाता है.

इंटेंट को मैनेज करना

कस्टम इंटेंट के साथ कस्टम खोज के सुझाव देने के बाद, आपको अपनी खोजे जा सकने वाली गतिविधि की ज़रूरत होगी, ताकि जब उपयोगकर्ता कोई सुझाव चुने, तो इन इंटेंट को मैनेज किया जा सके. यह ACTION_SEARCH इरादे को समझने के साथ-साथ, खोजे जा सकने वाले डेटा को भी मैनेज करता है. यहाँ एक उदाहरण दिया गया है कि गतिविधि के दौरान इंटेंट को कैसे हैंडल किया जा सकता है. साथ ही, onCreate() कॉलबैक के बारे में भी बताया गया है:

Kotlin

when(intent.action) {
    Intent.ACTION_SEARCH -> {
        // Handle the normal search query case.
        intent.getStringExtra(SearchManager.QUERY)?.also { query ->
            doSearch(query)
        }
    }
    Intent.ACTION_VIEW -> {
        // Handle a suggestions click, because the suggestions all use ACTION_VIEW.
        showResult(intent.data)
    }
}

Java

Intent intent = getIntent();
if (Intent.ACTION_SEARCH.equals(intent.getAction())) {
    // Handle the normal search query case.
    String query = intent.getStringExtra(SearchManager.QUERY);
    doSearch(query);
} else if (Intent.ACTION_VIEW.equals(intent.getAction())) {
    // Handle a suggestions click, because the suggestions all use ACTION_VIEW.
    Uri data = intent.getData();
    showResult(data);
}

इस उदाहरण में, इंटेंट ऐक्शन ACTION_VIEW है. साथ ही, डेटा में सुझाए गए आइटम की ओर ले जाने वाला पूरा यूआरआई शामिल है. इसे android:searchSuggestIntentData स्ट्रिंग और SUGGEST_COLUMN_INTENT_DATA_ID कॉलम से बनाया गया है. इसके बाद, यूआरआई को लोकल showResult() तरीके से पास किया जाता है. यह तरीका, कॉन्टेंट देने वाली कंपनी से यूआरआई में बताए गए आइटम के बारे में क्वेरी करता है.

ध्यान दें: android:searchSuggestIntentAction एट्रिब्यूट या SUGGEST_COLUMN_INTENT_ACTION कॉलम की मदद से तय की गई इंटेंट कार्रवाई के लिए, आपको Android मेनिफ़ेस्ट फ़ाइल में इंटेंट फ़िल्टर जोड़ने की ज़रूरत नहीं है. सिस्टम, सुझाव देने के मकसद को पूरा करने के लिए, नाम के हिसाब से खोजे जा सकने वाले आपके खाते की गतिविधि को खोलता है. इसलिए, गतिविधि को स्वीकार की गई कार्रवाई के बारे में बताने की ज़रूरत नहीं होती.

क्वेरी के टेक्स्ट को फिर से लिखना

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

क्वेरी के टेक्स्ट को इन तरीकों से फिर से लिखा जा सकता है:

"queryRewriteFromText" वैल्यू के साथ, android:searchMode एट्रिब्यूट को खोजे जा सकने वाले कॉन्फ़िगरेशन में जोड़ें. इस मामले में, सुझाव वाले SUGGEST_COLUMN_TEXT_1 कॉलम में मौजूद कॉन्टेंट का इस्तेमाल, क्वेरी के टेक्स्ट को फिर से लिखने के लिए किया जाता है.
"queryRewriteFromData" वैल्यू के साथ, android:searchMode एट्रिब्यूट को अपने खोजे जा सकने वाले कॉन्फ़िगरेशन में जोड़ें. इस मामले में, सुझाव के SUGGEST_COLUMN_INTENT_DATA कॉलम में मौजूद कॉन्टेंट का इस्तेमाल, क्वेरी के टेक्स्ट को फिर से लिखने के लिए किया जाता है. इसका इस्तेमाल सिर्फ़ उन यूआरआई या डेटा फ़ॉर्मैट के साथ करें जिन्हें उपयोगकर्ता देख सकते हैं. जैसे, एचटीटीपी यूआरएल. क्वेरी को इस तरह से फिर से लिखने के लिए, इंटरनल यूआरआई स्कीम का इस्तेमाल न करें.
सुझावों वाली टेबल के SUGGEST_COLUMN_QUERY कॉलम में, यूनीक क्वेरी टेक्स्ट स्ट्रिंग दें. अगर यह कॉलम मौजूद है और इसमें मौजूदा सुझाव के लिए कोई वैल्यू शामिल है, तो इसका इस्तेमाल क्वेरी के टेक्स्ट को फिर से लिखने के लिए किया जाता है. साथ ही, यह पिछले किसी भी सुझाव को बदल देता है.

होम स्क्रीन पर मौजूद खोज बॉक्स में खोज से जुड़े सुझाव दिखाना

अपने ऐप्लिकेशन को खोज के लिए मनमुताबिक सुझाव देने की सुविधा के लिए कॉन्फ़िगर करने के बाद, उन्हें दुनिया भर में उपलब्ध Quick Search Box में उपलब्ध कराना उतना ही आसान है जितना कि खोजे जा सकने वाले कॉन्फ़िगरेशन में बदलाव करना. इसके लिए, android:includeInGlobalSearch को "true" वैल्यू के साथ शामिल करें.

सिर्फ़ इस स्थिति में आपको अतिरिक्त काम करना होगा, जब कॉन्टेंट उपलब्ध कराने वाली कंपनी, पढ़ने की अनुमति मांगे. ऐसे में, आपको सेवा देने वाली कंपनी के लिए <path-permission> एलिमेंट जोड़ना होगा, ताकि वह कॉन्टेंट उपलब्ध कराने वाली कंपनी को Quick Search Box के लिए, कॉन्टेंट को पढ़ने का ऐक्सेस दे सके. इसका उदाहरण यहां दिया गया है:

<provider android:name="MySuggestionProvider"
          android:authorities="com.example.MyCustomSuggestionProvider"
          android:readPermission="com.example.provider.READ_MY_DATA"
          android:writePermission="com.example.provider.WRITE_MY_DATA">
  <path-permission android:pathPrefix="/search_suggest_query"
                   android:readPermission="android.permission.GLOBAL_SEARCH" />
</provider>

इस उदाहरण में, सेवा देने वाली कंपनी ने कॉन्टेंट को पढ़ने और लिखने के ऐक्सेस को सीमित कर दिया है. <path-permission> एलिमेंट, "android.permission.GLOBAL_SEARCH" अनुमति मौजूद होने पर, "/search_suggest_query" पाथ प्रीफ़िक्स के अंदर मौजूद कॉन्टेंट को पढ़ने का ऐक्सेस देकर, पाबंदी में बदलाव करता है. इससे Quick Search Box को ऐक्सेस मिलता है, ताकि वह सुझावों के लिए आपके कॉन्टेंट प्रोवाइडर से क्वेरी कर सके.

अगर कॉन्टेंट देने वाला व्यक्ति या कंपनी, पढ़ने की अनुमतियां लागू नहीं करती है, तो क्विक सर्च बॉक्स इसे डिफ़ॉल्ट रूप से पढ़ता है.

किसी डिवाइस पर सुझाव पाने की सुविधा चालू करना

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

क्विक सर्च बॉक्स में उपलब्ध हर ऐप्लिकेशन की एंट्री, खोजे जा सकने वाले आइटम सेटिंग पेज पर होती है. इस एंट्री में ऐप्लिकेशन का नाम शामिल होता है. साथ ही, इसमें यह भी बताया जाता है कि ऐप्लिकेशन में मौजूद किस कॉन्टेंट को खोजा जा सकता है. इसके अलावा, यह भी बताया जाता है कि क्विक सर्च बॉक्स में सुझाव देने के लिए, कौनसे कॉन्टेंट को उपलब्ध कराया गया है. खोजे जा सकने वाले ऐप्लिकेशन के लिए, जानकारी के टेक्स्ट को तय करने के लिए, खोजे जा सकने वाले कॉन्फ़िगरेशन में android:searchSettingsDescription एट्रिब्यूट जोड़ें. इसे नीचे दिए गए उदाहरण में दिखाया गया है:

<?xml version="1.0" encoding="utf-8"?>
<searchable xmlns:android="http://schemas.android.com/apk/res/android"
    android:label="@string/app_label"
    android:hint="@string/search_hint"
    android:searchSuggestAuthority="com.example.MyCustomSuggestionProvider"
    android:searchSuggestIntentAction="android.intent.action.VIEW"
    android:includeInGlobalSearch="true"
    android:searchSettingsDescription="@string/search_description" >
</searchable>

android:searchSettingsDescription के लिए स्ट्रिंग को जितना हो सके उतना छोटा बनाएं और बताएं कि किस कॉन्टेंट को खोजा जा सकता है. उदाहरण के लिए, संगीत ऐप्लिकेशन के लिए "कलाकार, एल्बम, और ट्रैक" या नोटपैड ऐप्लिकेशन के लिए "सेव किए गए नोट". यह ब्यौरा देना ज़रूरी है, ताकि उपयोगकर्ता को पता चल सके कि किस तरह के सुझाव दिए गए हैं. android:includeInGlobalSearch की वैल्यू 'सही' होने पर, इस एट्रिब्यूट को हमेशा शामिल करें.

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

क्विक सर्च बॉक्स में सुझाव देने वाले शॉर्टकट मैनेज करना

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

डिफ़ॉल्ट रूप से, यह सुविधा Quick Search Box से मिले सभी सुझावों के लिए चालू होती है. हालांकि, अगर समय के साथ आपके सुझाव के डेटा में बदलाव होता है, तो शॉर्टकट को रीफ़्रेश करने का अनुरोध किया जा सकता है. उदाहरण के लिए, अगर आपके सुझावों में डाइनैमिक डेटा शामिल है, जैसे कि किसी संपर्क की उपलब्धता की स्थिति, तो अनुरोध करें कि उपयोगकर्ता को दिखाए जाने पर सुझाव वाले शॉर्टकट रीफ़्रेश किए जाएं. इसके लिए, सुझावों की टेबल में SUGGEST_COLUMN_SHORTCUT_ID शामिल करें. इस कॉलम का इस्तेमाल करके, यहां दिए गए किसी एक तरीके से हर सुझाव के लिए शॉर्टकट के व्यवहार को कॉन्फ़िगर किया जा सकता है:

Quick Search Box को, सुझाव के शॉर्टकट के नए वर्शन के लिए, कॉन्टेंट प्रोवाइडर से फिर से क्वेरी करने के लिए कहें.

SUGGEST_COLUMN_SHORTCUT_ID कॉलम में कोई वैल्यू डालें, ताकि सुझाव के नए वर्शन के लिए हर बार फिर से क्वेरी की जा सके. ऐसा तब होगा, जब शॉर्टकट दिखेगा. शॉर्टकट में, सबसे हाल ही में उपलब्ध डेटा तुरंत दिखता है. यह तब तक दिखता है, जब तक रीफ़्रेश क्वेरी का जवाब नहीं मिल जाता. इसके बाद, सुझाव को नई जानकारी के साथ रीफ़्रेश किया जाता है. रीफ़्रेश क्वेरी, आपके कॉन्टेंट प्रोवाइडर को SUGGEST_URI_PATH_QUERY के बजाय SUGGEST_URI_PATH_SHORTCUT यूआरआई पाथ के साथ भेजी जाती है.

वापस भेजे गए Cursor में, मूल सुझाव वाले कॉलम का इस्तेमाल करके एक सुझाव दें या उसे खाली छोड़ दें. इससे पता चलेगा कि शॉर्टकट अब मान्य नहीं है. ऐसा होने पर, सुझाव गायब हो जाएगा और शॉर्टकट हटा दिया जाएगा.

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

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

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

अगर आपके किसी भी सुझाव में कभी बदलाव नहीं होता है, तो आपको SUGGEST_COLUMN_SHORTCUT_ID कॉलम की ज़रूरत नहीं है.

होम स्क्रीन पर मौजूद खोज बॉक्स में सुझावों की रैंकिंग के बारे में जानकारी

अपने ऐप्लिकेशन के खोज सुझावों को Quick Search Box के लिए उपलब्ध कराने के बाद, Quick Search Box की रैंकिंग तय करती है कि किसी क्वेरी के लिए, उपयोगकर्ता को सुझाव कैसे दिखाए जाएंगे. यह इस बात पर निर्भर करता है कि उस क्वेरी के लिए, कितने अन्य ऐप्लिकेशन के नतीजे उपलब्ध हैं. साथ ही, यह भी देखा जाता है कि उपयोगकर्ता, अन्य ऐप्लिकेशन के नतीजों की तुलना में आपके नतीजों को कितनी बार चुनता है. इस बात की कोई गारंटी नहीं है कि आपके सुझावों को किस तरह रैंक किया जाएगा या किसी क्वेरी के लिए आपके ऐप्लिकेशन के सुझाव दिखेंगे या नहीं. आम तौर पर, अच्छी क्वालिटी के नतीजे देने से, आपके ऐप्लिकेशन के सुझावों के प्रमुख जगह पर दिखने की संभावना बढ़ जाती है. वहीं, खराब क्वालिटी के सुझाव देने वाले ऐप्लिकेशन के रैंक कम होने या न दिखने की संभावना ज़्यादा होती है.