AppSearch, डिवाइस पर खोज करने की सुविधा देता है. हालांकि, यह बेहतर परफ़ॉर्मेंस की सुविधा है, ताकि इसे स्थानीय तौर पर मैनेज किया जा सके स्ट्रक्चर्ड डेटा का इस्तेमाल किया जाता है. इसमें डेटा को इंडेक्स करने और डेटा वापस पाने के लिए एपीआई शामिल हैं पूरा टेक्स्ट खोज का इस्तेमाल करके. ऐप्लिकेशन, AppSearch का इस्तेमाल करके, पसंद के मुताबिक इन-ऐप्लिकेशन खरीदारी की सुविधा दे सकते हैं इससे उपयोगकर्ता, ऑफ़लाइन रहते हुए भी कॉन्टेंट खोज सकते हैं.
AppSearch में ये सुविधाएं मिलती हैं:
- कम I/O इस्तेमाल के साथ तेज़ी से मोबाइल-फ़र्स्ट स्टोरेज लागू करने की सुविधा
- बड़े डेटा सेट को इंडेक्स करना और उनके लिए क्वेरी करना, बेहद असरदार तरीके से काम करता है
- कई भाषाओं में सुविधा, जैसे कि अंग्रेज़ी और स्पैनिश
- प्रासंगिकता की रैंकिंग और इस्तेमाल का स्कोर
I/O के कम इस्तेमाल की वजह से, AppSearch के लिए इंडेक्स करने और खोजने में लगने वाला समय कम होता है SQLite की तुलना में, बड़े डेटासेट वाले होते हैं. AppSearch, क्रॉस-टाइप क्वेरी को आसान बनाता है यह सिंगल क्वेरी के साथ काम करता है, जबकि SQLite, कई टेबल के नतीजों को मर्ज करता है.
AppSearch की सुविधाओं के बारे में बताने के लिए, आइए संगीत का एक उदाहरण लेते हैं ऐसा ऐप्लिकेशन जो लोगों के पसंदीदा गानों को मैनेज करता है. साथ ही, इसकी मदद से लोग गाने खोजने की सुविधा उनके लिए. लोग अलग-अलग तरह के गानों के साथ, दुनिया भर के संगीत का आनंद लेते हैं जिसमें AppSearch, इंडेक्स करने और क्वेरी करने की सुविधा देता है. जब जब लोग किसी गाने को टाइटल या कलाकार के नाम से खोजते हैं, तो ऐप्लिकेशन बस इसमें AppSearch से, मिलते-जुलते गानों को तुरंत और बेहतर तरीके से वापस पाने का अनुरोध किया जाता है. कॉन्टेंट बनाने ऐप्लिकेशन, खोज के नतीजों को दिखाता है. इससे उपयोगकर्ता तुरंत गेम खेलना शुरू कर सकते हैं अपने पसंदीदा गाने भी सुनें.
सेटअप
अपने ऐप्लिकेशन में AppSearch का इस्तेमाल करने के लिए, अपने
ऐप्लिकेशन की build.gradle
फ़ाइल:
ग्रूवी
dependencies { def appsearch_version = "1.1.0-alpha05" implementation "androidx.appsearch:appsearch:$appsearch_version" // Use kapt instead of annotationProcessor if writing Kotlin classes annotationProcessor "androidx.appsearch:appsearch-compiler:$appsearch_version" implementation "androidx.appsearch:appsearch-local-storage:$appsearch_version" // PlatformStorage is compatible with Android 12+ devices, and offers additional features // to LocalStorage. implementation "androidx.appsearch:appsearch-platform-storage:$appsearch_version" }
Kotlin
dependencies { val appsearch_version = "1.1.0-alpha05" implementation("androidx.appsearch:appsearch:$appsearch_version") // Use annotationProcessor instead of kapt if writing Java classes kapt("androidx.appsearch:appsearch-compiler:$appsearch_version") implementation("androidx.appsearch:appsearch-local-storage:$appsearch_version") // PlatformStorage is compatible with Android 12+ devices, and offers additional features // to LocalStorage. implementation("androidx.appsearch:appsearch-platform-storage:$appsearch_version") }
AppSearch के सिद्धांत
इस डायग्राम में, AppSearch के कॉन्सेप्ट और उनके इंटरैक्शन को दिखाया गया है.
डेटाबेस और सेशन
AppSearch का डेटाबेस, दस्तावेज़ों का एक कलेक्शन होता है जो डेटाबेस के मुताबिक होता है स्कीमा चुनें. क्लाइंट ऐप्लिकेशन अपना ऐप्लिकेशन उपलब्ध कराकर डेटाबेस बनाते हैं कॉन्टेक्स्ट और डेटाबेस का नाम. डेटाबेस को सिर्फ़ ऐप्लिकेशन खोला जा सकता है जिन्होंने उन्हें बनाया. जब किसी डेटाबेस को खोला जाता है, तो इंटरैक्ट करने के लिए एक सेशन वापस लाया जाता है डेटाबेस के साथ होता है. AppSearch API को कॉल करने के लिए, सेशन सबसे पहले इस्तेमाल किया जाता है और क्लाइंट ऐप्लिकेशन के बंद होने तक यह खुला रहता है.
स्कीमा और स्कीमा के टाइप
स्कीमा, किसी AppSearch में डेटा की संगठनात्मक संरचना को दिखाता है डेटाबेस.
स्कीमा में अलग-अलग तरह के स्कीमा होते हैं. ये अलग-अलग तरह के डेटा के बारे में बताते हैं. स्कीमा टाइप में ऐसी प्रॉपर्टी होती हैं जिनका नाम, डेटा टाइप, और एलिमेंट की संख्या. डेटाबेस स्कीमा में स्कीमा टाइप जोड़ने के बाद, उस स्कीमा टाइप को बनाया और डेटाबेस में जोड़ा जा सकता है.
दस्तावेज़
AppSearch में, डेटा की यूनिट को दस्तावेज़ के तौर पर दिखाया जाता है. इसमें मौजूद हर दस्तावेज़ को AppSearch के डेटाबेस की पहचान, इसके नेमस्पेस और आईडी से की जाती है. नाम स्थान जब सिर्फ़ एक सोर्स की ज़रूरत हो, तब उसका इस्तेमाल अलग-अलग सोर्स से डेटा को अलग करने के लिए किया जाता है क्वेरी के लिए इस्तेमाल किया जा सकता है, जैसे कि उपयोगकर्ता खाते.
दस्तावेज़ों में, बनाए जाने का टाइमस्टैंप, टाइम-टू-लाइव (टीटीएल), और का इस्तेमाल, डेटा को वापस पाने के दौरान रैंकिंग के लिए किया जा सकता है. दस्तावेज़ को एक स्कीमा भी असाइन किया गया है टाइप, जो दस्तावेज़ में मौजूद अतिरिक्त डेटा प्रॉपर्टी के बारे में बताता है.
दस्तावेज़ की क्लास, किसी दस्तावेज़ का एक छोटा रूप होता है. इसमें ऐसे फ़ील्ड शामिल हैं जिनके बारे में जानकारी दी गई है जो किसी दस्तावेज़ का कॉन्टेंट दिखाते हैं. डिफ़ॉल्ट रूप से, दस्तावेज़ का नाम क्लास स्कीमा टाइप का नाम सेट करती है.
खोजें
दस्तावेज़ों को इंडेक्स किया जाता है और क्वेरी देकर उन्हें खोजा जा सकता है. यह एक दस्तावेज़ है खोज परिणामों में मेल खाता है और शामिल किया जाता है, अगर इसमें क्वेरी के शब्द हैं या किसी अन्य खोज स्पेसिफ़िकेशन से मेल खाता हो. नतीजों को उनके क्रम के आधार पर क्रम में लगाया गया है स्कोर और रैंकिंग की रणनीति तय करें. खोज परिणाम उन पृष्ठों द्वारा प्रदर्शित किए जाते हैं जिन्हें आप क्रम से वापस पाएं.
AppSearch आपको पसंद के मुताबिक बनाने की सुविधा देता है का इस्तेमाल करें, जैसे कि फ़िल्टर, पेज साइज़ कॉन्फ़िगरेशन, और स्निपेट.
प्लैटफ़ॉर्म स्टोरेज बनाम लोकल स्टोरेज
AppSearch दो स्टोरेज समाधान उपलब्ध कराता है: LocalStorage और PlatformStorage. LocalStorage से, आपका ऐप्लिकेशन एक खास ऐप्लिकेशन के इंडेक्स को मैनेज करता है, जो आपकी ऐप्लिकेशन डेटा डायरेक्ट्री. PlatformStorage के साथ, आपका ऐप्लिकेशन एक सिस्टम-वाइड सेंट्रल इंडेक्स में योगदान देता है. सेंट्रल इंडेक्स में डेटा का ऐक्सेस आपके ऐप्लिकेशन के योगदान और उस डेटा तक सीमित है जिसे आपके साथ किसी अन्य ऐप्लिकेशन के ज़रिए शेयर किया गया है. LocalStorage और दोनों PlatformStorage, एक ही एपीआई शेयर करता है. साथ ही, इसे डिवाइस के डेटा के आधार पर बदला जा सकता है वर्शन:
Kotlin
if (BuildCompat.isAtLeastS()) { appSearchSessionFuture.setFuture( PlatformStorage.createSearchSession( PlatformStorage.SearchContext.Builder(mContext, DATABASE_NAME) .build() ) ) } else { appSearchSessionFuture.setFuture( LocalStorage.createSearchSession( LocalStorage.SearchContext.Builder(mContext, DATABASE_NAME) .build() ) ) }
Java
if (BuildCompat.isAtLeastS()) { mAppSearchSessionFuture.setFuture(PlatformStorage.createSearchSession( new PlatformStorage.SearchContext.Builder(mContext, DATABASE_NAME) .build())); } else { mAppSearchSessionFuture.setFuture(LocalStorage.createSearchSession( new LocalStorage.SearchContext.Builder(mContext, DATABASE_NAME) .build())); }
PlatformStorage का इस्तेमाल करके, आपका ऐप्लिकेशन सुरक्षित तरीके से डेटा शेयर कर सकता है ताकि वे आपके ऐप्लिकेशन के डेटा को खोज सकें. सिर्फ़ पढ़ने के लिए ऐप्लिकेशन के डेटा को सर्टिफ़िकेट हैंडशेक के ज़रिए शेयर किया जाता है, ताकि यह पक्का किया जा सके कि दूसरे ऐप्लिकेशन को डेटा पढ़ने की अनुमति है. इस एपीआई के बारे में ज़्यादा जानें setSchemaType visibilityForPackage() के दस्तावेज़ में भी.
इसके अलावा, इंडेक्स किया गया डेटा, सिस्टम के यूज़र इंटरफ़ेस (यूआई) प्लैटफ़ॉर्म पर दिखाया जा सकता है. ऐप्लिकेशन, सिस्टम पर दिखाए जाने वाले अपने कुछ या सभी डेटा से ऑप्ट आउट कर सकते हैं यूज़र इंटरफ़ेस (यूआई) के प्लैटफ़ॉर्म. इस एपीआई के बारे में ज़्यादा जानने के लिए, setschemaTypeDisplayedBySystem() के दस्तावेज़ पढ़ें.
सुविधाएं | LocalStorage (compatible with Android 4.0+) |
PlatformStorage (compatible with Android 12+) |
---|---|---|
Efficient full-text search |
||
Multi-language support |
||
Reduced binary size |
||
Application-to-application data sharing |
||
Capability to display data on System UI surfaces |
||
Unlimited document size and count can be indexed |
||
Faster operations without additional binder latency |
LocalStorage में से चुनने पर, आपको कुछ और फ़ायदे भी मिलेंगे और PlatformStorage. क्योंकि PlatformStorage, Jetpack API को पूरी तरह से रैप करता है AppSearch सिस्टम सेवा, APK के साइज़ का असर कम से कम होता है. इसकी तुलना में, नीचे दिए गए फ़ंक्शन का इस्तेमाल किया जाता है LocalStorage. इसका मतलब यह भी है कि AppSearch की कार्रवाइयों से जुड़ी लागत, AppSearch सिस्टम सेवा को कॉल करते समय इंतज़ार का समय तय करता है. PlatformStorage के साथ, AppSearch, ऐप्लिकेशन में दस्तावेज़ों की संख्या और साइज़ तय करता है एक अच्छे सेंट्रल इंडेक्स को पक्का करने के लिए इंडेक्स कर सकते हैं.
AppSearch का इस्तेमाल शुरू करना
इस सेक्शन में दिए गए उदाहरण में, इंटिग्रेशन के लिए AppSearch API का इस्तेमाल करने का तरीका बताया गया है एक काल्पनिक नोट रखने की ऐप्लिकेशन होगी.
दस्तावेज़ की क्लास में लिखना
AppSearch के साथ इंटिग्रेट करने का पहला चरण है, दस्तावेज़ की क्लास तैयार करना
डेटाबेस में डाले जाने वाले डेटा के बारे में बताती हैं. किसी क्लास को दस्तावेज़ क्लास के तौर पर मार्क करना
@Document
का इस्तेमाल करके
एनोटेशन.दस्तावेज़ क्लास के इंस्टेंस का इस्तेमाल करके, दस्तावेज़ों को
डेटाबेस से दस्तावेज़ पाएं.
यह कोड, नोट दस्तावेज़ की क्लास के बारे में
@Document.StringProperty
व्याख्या की गई
किसी नोट ऑब्जेक्ट के टेक्स्ट को इंडेक्स करने के लिए फ़ील्ड.
Kotlin
@Document public data class Note( // Required field for a document class. All documents MUST have a namespace. @Document.Namespace val namespace: String, // Required field for a document class. All documents MUST have an Id. @Document.Id val id: String, // Optional field for a document class, used to set the score of the // document. If this is not included in a document class, the score is set // to a default of 0. @Document.Score val score: Int, // Optional field for a document class, used to index a note's text for this // document class. @Document.StringProperty(indexingType = AppSearchSchema.StringPropertyConfig.INDEXING_TYPE_PREFIXES) val text: String )
Java
@Document public class Note { // Required field for a document class. All documents MUST have a namespace. @Document.Namespace private final String namespace; // Required field for a document class. All documents MUST have an Id. @Document.Id private final String id; // Optional field for a document class, used to set the score of the // document. If this is not included in a document class, the score is set // to a default of 0. @Document.Score private final int score; // Optional field for a document class, used to index a note's text for this // document class. @Document.StringProperty(indexingType = StringPropertyConfig.INDEXING_TYPE_PREFIXES) private final String text; Note(@NonNull String id, @NonNull String namespace, int score, @NonNull String text) { this.id = Objects.requireNonNull(id); this.namespace = Objects.requireNonNull(namespace); this.score = score; this.text = Objects.requireNonNull(text); } @NonNull public String getNamespace() { return namespace; } @NonNull public String getId() { return id; } public int getScore() { return score; } @NonNull public String getText() { return text; } }
डेटाबेस खोलना
दस्तावेज़ों पर काम करने से पहले, आपको एक डेटाबेस बनाना होगा. यह कोड
notes_app
नाम से एक नया डेटाबेस बनाता है और ListenableFuture
AppSearchSession
के लिए,
जो डेटाबेस से कनेक्शन दिखाता है और
डेटाबेस ऑपरेशन.
Kotlin
val context: Context = getApplicationContext() val sessionFuture = LocalStorage.createSearchSession( LocalStorage.SearchContext.Builder(context, /*databaseName=*/"notes_app") .build() )
Java
Context context = getApplicationContext(); ListenableFuture<AppSearchSession> sessionFuture = LocalStorage.createSearchSession( new LocalStorage.SearchContext.Builder(context, /*databaseName=*/ "notes_app") .build() );
स्कीमा सेट करना
दस्तावेज़ों को इसमें रखने और वापस पाने से पहले, आपको स्कीमा सेट करना होगा दस्तावेज़ों को इकट्ठा या एक्सपोर्ट किया जाता है. डेटाबेस स्कीमा में अलग-अलग टाइप के होते हैं जिसे "स्कीमा टाइप" कहा जाता है. यह कोड, स्कीमा टाइप के तौर पर दस्तावेज़ की क्लास देकर स्कीमा का इस्तेमाल करें.
Kotlin
val setSchemaRequest = SetSchemaRequest.Builder().addDocumentClasses(Note::class.java) .build() val setSchemaFuture = Futures.transformAsync( sessionFuture, { session -> session?.setSchema(setSchemaRequest) }, mExecutor )
Java
SetSchemaRequest setSchemaRequest = new SetSchemaRequest.Builder().addDocumentClasses(Note.class) .build(); ListenableFuture<SetSchemaResponse> setSchemaFuture = Futures.transformAsync(sessionFuture, session -> session.setSchema(setSchemaRequest), mExecutor);
दस्तावेज़ को डेटाबेस में रखना
स्कीमा टाइप जोड़ने के बाद, डेटाबेस में उस टाइप के दस्तावेज़ों को जोड़ा जा सकता है.
यह कोड, Note
का इस्तेमाल करके Note
स्कीमा टाइप का दस्तावेज़ बनाता है
दस्तावेज़ क्लास बिल्डर. यह दस्तावेज़ के नेमस्पेस user1
को सेट करता है, ताकि
इस सैंपल का आर्बिट्रेरी उपयोगकर्ता. इसके बाद, दस्तावेज़ को डेटाबेस में डाला जाता है
और पुट ऑपरेशन के नतीजे को प्रोसेस करने के लिए लिसनर जोड़ा जाता है.
Kotlin
val note = Note( namespace="user1", id="noteId", score=10, text="Buy fresh fruit" ) val putRequest = PutDocumentsRequest.Builder().addDocuments(note).build() val putFuture = Futures.transformAsync( sessionFuture, { session -> session?.put(putRequest) }, mExecutor ) Futures.addCallback( putFuture, object : FutureCallback<AppSearchBatchResult<String, Void>?> { override fun onSuccess(result: AppSearchBatchResult<String, Void>?) { // Gets map of successful results from Id to Void val successfulResults = result?.successes // Gets map of failed results from Id to AppSearchResult val failedResults = result?.failures } override fun onFailure(t: Throwable) { Log.e(TAG, "Failed to put documents.", t) } }, mExecutor )
Java
Note note = new Note(/*namespace=*/"user1", /*id=*/ "noteId", /*score=*/ 10, /*text=*/ "Buy fresh fruit!"); PutDocumentsRequest putRequest = new PutDocumentsRequest.Builder().addDocuments(note) .build(); ListenableFuture<AppSearchBatchResult<String, Void>> putFuture = Futures.transformAsync(sessionFuture, session -> session.put(putRequest), mExecutor); Futures.addCallback(putFuture, new FutureCallback<AppSearchBatchResult<String, Void>>() { @Override public void onSuccess(@Nullable AppSearchBatchResult<String, Void> result) { // Gets map of successful results from Id to Void Map<String, Void> successfulResults = result.getSuccesses(); // Gets map of failed results from Id to AppSearchResult Map<String, AppSearchResult<Void>> failedResults = result.getFailures(); } @Override public void onFailure(@NonNull Throwable t) { Log.e(TAG, "Failed to put documents.", t); } }, mExecutor);
खोजें
इसमें शामिल खोज कार्रवाइयों का इस्तेमाल करके, इंडेक्स किए गए दस्तावेज़ों को खोजा जा सकता है
इस सेक्शन में बताया गया है. यह कोड "फल" शब्द के लिए क्वेरी करता है के ऊपर
user1
नेमस्पेस से जुड़े दस्तावेज़ों का डेटाबेस.
Kotlin
val searchSpec = SearchSpec.Builder() .addFilterNamespaces("user1") .build(); val searchFuture = Futures.transform( sessionFuture, { session -> session?.search("fruit", searchSpec) }, mExecutor ) Futures.addCallback( searchFuture, object : FutureCallback<SearchResults> { override fun onSuccess(searchResults: SearchResults?) { iterateSearchResults(searchResults) } override fun onFailure(t: Throwable?) { Log.e("TAG", "Failed to search notes in AppSearch.", t) } }, mExecutor )
Java
SearchSpec searchSpec = new SearchSpec.Builder() .addFilterNamespaces("user1") .build(); ListenableFuture<SearchResults> searchFuture = Futures.transform(sessionFuture, session -> session.search("fruit", searchSpec), mExecutor); Futures.addCallback(searchFuture, new FutureCallback<SearchResults>() { @Override public void onSuccess(@Nullable SearchResults searchResults) { iterateSearchResults(searchResults); } @Override public void onFailure(@NonNull Throwable t) { Log.e(TAG, "Failed to search notes in AppSearch.", t); } }, mExecutor);
Searchनतीजे के ज़रिए दोहराना
खोज करने पर, SearchResults
दिखता है
इंस्टेंस, जो SearchResult
ऑब्जेक्ट के पेजों का ऐक्सेस देता है. हर SearchResult
जो GenericDocument
से मेल खाता है. यह
वह दस्तावेज़ जिसमें सभी दस्तावेज़ों को बदला जाता है. सबसे पहले नीचे दिए गए कोड को
खोज के नतीजों वाले पेज को सेव करके, नतीजे को वापस Note
दस्तावेज़ में बदल देता है.
Kotlin
Futures.transform( searchResults?.nextPage, { page: List<SearchResult>? -> // Gets GenericDocument from SearchResult. val genericDocument: GenericDocument = page!![0].genericDocument val schemaType = genericDocument.schemaType val note: Note? = try { if (schemaType == "Note") { // Converts GenericDocument object to Note object. genericDocument.toDocumentClass(Note::class.java) } else null } catch (e: AppSearchException) { Log.e( TAG, "Failed to convert GenericDocument to Note", e ) null } note }, mExecutor )
Java
Futures.transform(searchResults.getNextPage(), page -> { // Gets GenericDocument from SearchResult. GenericDocument genericDocument = page.get(0).getGenericDocument(); String schemaType = genericDocument.getSchemaType(); Note note = null; if (schemaType.equals("Note")) { try { // Converts GenericDocument object to Note object. note = genericDocument.toDocumentClass(Note.class); } catch (AppSearchException e) { Log.e(TAG, "Failed to convert GenericDocument to Note", e); } } return note; }, mExecutor);
दस्तावेज़ हटाना
जब कोई उपयोगकर्ता किसी नोट को मिटाता है, तो ऐप्लिकेशन उससे जुड़े Note
को मिटा देता है
डेटाबेस से दस्तावेज़. इससे यह पक्का हो जाता है कि नोट
क्वेरी. यह कोड, Note
को हटाने का साफ़ तौर पर अनुरोध करता है
आईडी के हिसाब से डेटाबेस से दस्तावेज़.
Kotlin
val removeRequest = RemoveByDocumentIdRequest.Builder("user1") .addIds("noteId") .build() val removeFuture = Futures.transformAsync( sessionFuture, { session -> session?.remove(removeRequest) }, mExecutor )
Java
RemoveByDocumentIdRequest removeRequest = new RemoveByDocumentIdRequest.Builder("user1") .addIds("noteId") .build(); ListenableFuture<AppSearchBatchResult<String, Void>> removeFuture = Futures.transformAsync(sessionFuture, session -> session.remove(removeRequest), mExecutor);
डिस्क पर बने रहें
डेटाबेस में किए जाने वाले अपडेट, डिस्क में समय-समय पर सेव किए जाने चाहिए. इसके लिए,
requestFlush()
. कॉन्टेंट बनाने
नीचे दिया गया कोड, requestFlush()
को लिसनर को कॉल करता है, ताकि यह पता लगाया जा सके कि कॉल
सफल रहा.
Kotlin
val requestFlushFuture = Futures.transformAsync( sessionFuture, { session -> session?.requestFlush() }, mExecutor ) Futures.addCallback(requestFlushFuture, object : FutureCallback<Void?> { override fun onSuccess(result: Void?) { // Success! Database updates have been persisted to disk. } override fun onFailure(t: Throwable) { Log.e(TAG, "Failed to flush database updates.", t) } }, mExecutor)
Java
ListenableFuture<Void> requestFlushFuture = Futures.transformAsync(sessionFuture, session -> session.requestFlush(), mExecutor); Futures.addCallback(requestFlushFuture, new FutureCallback<Void>() { @Override public void onSuccess(@Nullable Void result) { // Success! Database updates have been persisted to disk. } @Override public void onFailure(@NonNull Throwable t) { Log.e(TAG, "Failed to flush database updates.", t); } }, mExecutor);
सेशन बंद करना
AppSearchSession
बंद हो जाना चाहिए जब कोई ऐप्लिकेशन किसी डेटाबेस को कॉल नहीं करेगा
कार्रवाइयां. यह कोड, खोले गए AppSearch सेशन को बंद करता है
डिस्क के सभी अपडेट पहले जैसे और बने रहते हैं.
Kotlin
val closeFuture = Futures.transform<AppSearchSession, Unit>(sessionFuture, { session -> session?.close() Unit }, mExecutor )
Java
ListenableFuture<Void> closeFuture = Futures.transform(sessionFuture, session -> { session.close(); return null; }, mExecutor);
अन्य संसाधन
AppSearch के बारे में ज़्यादा जानने के लिए, इन अन्य संसाधनों को देखें:
सैंपल
- Android AppSearch का सैंपल (Kotlin), नोट लेने वाला ऐसा ऐप्लिकेशन जो लोगों के नोट को इंडेक्स करने के लिए AppSearch का इस्तेमाल करता है और ताकि वे नोट में खोज सकें.
सुझाव या राय दें
इन संसाधनों की मदद से, हमारे साथ अपने सुझाव, शिकायत या राय शेयर करें:
गड़बड़ियों की शिकायत करें, ताकि हम उन्हें ठीक कर सकें.