Builder

Builder

Builder(schemaType: String)

Creates a new AppSearchSchema.Builder.

addParentType

fun addParentType(parentSchemaType: String): AppSearchSchema.Builder

Adds a parent type to the given type for polymorphism, so that the given type will be considered as a subtype of parentSchemaType.

Subtype relations are automatically considered transitive, so callers are only required to provide direct parents. Specifically, if T1 <: T2 and T2 <: T3 are known, then T1 <: T3 will be inferred automatically, where <: is the subtype symbol.

Polymorphism is currently supported in the following ways:

• Search filters on a parent type will automatically be extended to the child types as well. For example, if Artist <: Person, then a search with a filter on type Person (by calling android.app.appsearch.SearchSpec.Builder#addFilterSchemas) will also include documents of type Artist in the search result.
• In the projection API, the property paths to project specified for a parent type will automatically be extended to the child types as well. If both a parent type and one of its child type are specified in the projection API, the parent type's paths will be merged into the child's. For more details on projection, see android.app.appsearch.SearchSpec.Builder#addProjection.
• A document property defined as type U is allowed to be set with a document of type T, as long as T <: U, but note that index will only be based on the defined type, which is U. For example, consider a document of type "Company" with a repeated "employees" field of type "Person". We can add employees of either type "Person" or type "Artist" or both to this property, as long as "Artist" is a subtype of "Person". However, the index of the "employees" property will be based on what's defined in "Person", even for an added document of type "Artist".

Subtypes must meet the following requirements. A violation of the requirements will cause AppSearchSession.setSchema to throw an AppSearchException with the result code of AppSearchResult.RESULT_INVALID_ARGUMENT. Consider a type Artist and a type Person, and Artist claims to be a subtype of Person, then:

• Every property in Person must have a corresponding property in Artist with the same name.
• Every non-document property in Person must have the same type as the type of the corresponding property in Artist. For example, if "age" is an integer property in Person, then "age" must also be an integer property in Artist, instead of a string.
• The schema type of every document property in Artist must be a subtype of the schema type of the corresponding document property in Person, if such a property exists in Person. For example, if "awards" is a document property of type Award in Person, then the type of the "awards" property in Artist must be a subtype of Award, say ArtAward. Note that every type is a subtype of itself.
• Every property in Artist must have a cardinality stricter than or equal to the cardinality of the corresponding property in Person, if such a property exists in Person. For example, if "awards" is a property in Person of cardinality OPTIONAL, then the cardinality of the "awards" property in Artist can only be REQUIRED or OPTIONAL. Rule: REQUIRED < OPTIONAL < REPEATED.
• There are no other enforcements on the corresponding properties in Artist, such as index type, tokenizer type, etc. These settings can be safely overridden.

A type can be defined to have multiple parents, but it must be compatible with each of its parents based on the above rules. For example, if LocalBusiness is defined as a subtype of both Place and Organization, then the compatibility of LocalBusiness with Place and the compatibility of LocalBusiness with Organization will both be checked.

addProperty

fun addProperty(propertyConfig: AppSearchSchema.PropertyConfig): AppSearchSchema.Builder

Adds a property to the given type.

build

fun build(): AppSearchSchema

Constructs a new AppSearchSchema from the contents of this builder.