DefaultApolloExtension
Types
Properties
Whether to generate kotlin constructors with @JvmOverloads for more graceful Java interop experience when default values are present. Note: when enabled in a multi-platform setup, the generated code can only be used in the common or JVM sourcesets.
When to add __typename. One of "always", "ifAbstract", "ifPolymorphic" or "ifFragments"
A list of Regex patterns matching schema coordinates for types and fields that should be generated whether they are used by queries/fragments in this module or not.
A list of Regex patterns for GraphQL enums that should be generated as Java classes.
What codegen to use. One of "operationBased", "responseBased" or "experimental_operationBasedWithInterfaces"
Whether to decapitalize fields (for instance FooBar ->fooBar). This is useful if your schema has fields starting with an uppercase as it may create name clashes with models that use PascalCase
Common apollo dependencies using the same version as the Apollo Gradle Plugin currently in the classpath
Fail the build if there are warnings. This is not named allWarningAsErrors to avoid nameclashes with the Kotlin options
Whether fields with different shape are disallowed to be merged in disjoint types.
Whether to flatten the models. File paths are limited on MacOSX to 256 chars and flattening can help keeping the path length manageable The drawback is that some classes may nameclash in which case they will be suffixed with a number
Whether to generate Apollo metadata. Apollo metadata is used for multimodule support. Set this to true if you want other modules to be able to re-use fragments and types from this module.
Whether to generate Kotlin models with internal visibility modifier.
Whether to generate the type safe Data builders. These are mainly used for tests but can also be used for other use cases too.
Class name to use when generating the Schema class.
Whether to generate the com.apollographql.apollo.api.Fragment as well as response and variables adapters.
Whether to generate builders in addition to constructors for operations and input types. Constructors are more concise but require passing an instance of Optional always, making them more verbose for the cases where there are a lot of optional input parameters.
Whether to generate Kotlin or Java models Default to true if the Kotlin plugin is found
Specifies which methods will be auto generated on operations, models, fragments and input objects.
Whether to generate builders for java models
Whether to generate the operationOutput.json
Whether to generate operation variables as com.apollographql.apollo.api.Optional
Whether to generate fields as primitive types (int, double, boolean) instead of their boxed types (Integer, Double, Boolean) when possible.
Whether to embed the query document in the com.apollographql.apollo.api.Operations. By default, this is true as it is needed to send the operations to the server. If performance/binary size is critical, and you are using persisted queries or a similar mechanism, disable this.
Whether to generate the Schema class.
Adds "generateApolloSources" as a dependency of "prepareKotlinIdeaImport" This makes IDEA aware of codegen and will run it during your Gradle Sync
Target language version for the generated code.
For Kotlin native projects, whether to link Sqlite (-lsqlite3). This is required by apollo-normalized-cache-sqlite but some projects might want to customize linker options
The style to use for fields that are nullable in the Java generated code.
By default, Apollo uses Sha256 hashing algorithm to generate an ID for the query. To provide a custom ID generation logic, pass an instance that implements the OperationIdGenerator. How the ID is generated is indifferent to the compiler. It can be a hashing algorithm or generated by a backend.
The file where to write the operation manifest. If you want a RegularFileProperty that carries the task dependency, use operationManifestConnection.
The format to output for the operation manifest. Valid values are:
The file where the operation output will be written. It's called operationOutputFile but this an "input" parameter for the compiler If you want a RegularFileProperty that carries the task dependency, use operationManifestConnection
A generator to generate the operation output from a list of operations. OperationOutputGenerator is similar to OperationIdGenerator but can work on lists. This is useful if you need to register/whitelist your operations on your server all at once.
The directory where the generated models will be written. It's called outputDir but this an "input" parameter for the compiler If you want a DirectoryProperty that carries the task dependency, use outputDirConnection
The package name for generated classes. Operations use the package name directly. Other classes like fragments and schema types use sub-packages to avoid name clashes:
Use packageNameGenerator to customize how to generate package names from file paths.
The annotation to use for @requiresOptIn fields/inputFields/enumValues
The location of the main schema file.
The schema files in either ".json" introspection schemas or ".sdl|.graphqls" SDL schemas.
A list of Regex patterns for GraphQL enums that should be generated as a Kotlin sealed interface.
Where to look for GraphQL sources. The plugin searches "src/main/graphql/$sourceFolder" for Android/JVM projects and "src/commonMain/graphql/$sourceFolder" for multiplatform projects.
Whether to use process isolation. By default, the Apollo tasks use classloader isolation, which may leak and increase memory usage over time. By using process isolation, the tasks are run in a separate process and the memory is reclaimed when the process stops. This comes at a price of more forking time.
When true, the operation class names are suffixed with their operation type like ('Query', 'Mutation' ot 'Subscription'). For an example, query getDroid { ... } GraphQL query generates the 'GetDroidQuery' class.
Warn if using a deprecated field
Functions
registers multiple services for an android project
registers multiple services for a Kotlin project
Adds a dependency for the codegen. Use this when some types/fragments are generated in upstream modules.
Same as dependsOn but allows for automatic detection of used types. This works by adding the current project to the upstream project dependencies using cross-project configuration.
Configures Introspection to download an introspection Json schema
Counterpoint of dependsOn. isADependencyOf allows a schema module to discover used types in downstream modules automatically without having to specify alwaysGenerateTypesMatching.
Map a GraphQL scalar type to the Java/Kotlin type. The adapter must be configured at runtime via com.apollographql.apollo.ApolloClient.Builder.addCustomScalarAdapter.
Map a GraphQL scalar type to the Java/Kotlin type and provided adapter expression. The adapter will be configured at compile time and you must not call com.apollographql.apollo.ApolloClient.Builder.addCustomScalarAdapter.
Map the given GraphQL scalar to java.lang.Boolean and use the builtin adapter
Map the given GraphQL scalar to java.lang.Double and use the builtin adapter
Map the given GraphQL scalar to java.lang.Float and use the builtin adapter
Map the given GraphQL scalar to java.lang.Integer and use the builtin adapter
Map the given GraphQL scalar to java.lang.Long and use the builtin adapter
Map the given GraphQL scalar to java.lang.Object and use the builtin adapter
Map the given GraphQL scalar to java.lang.String and use the builtin adapter
Map the given GraphQL scalar to kotlin.Any and use the builtin adapter
Map the given GraphQL scalar to kotlin.Boolean and use the builtin adapter
Map the given GraphQL scalar to kotlin.Double and use the builtin adapter
Map the given GraphQL scalar to kotlin.Float and use the builtin adapter
Map the given GraphQL scalar to kotlin.Int and use the builtin adapter
Map the given GraphQL scalar to kotlin.Long and use the builtin adapter
Map the given GraphQL scalar to kotlin.String and use the builtin adapter
Map the given GraphQL scalar to com.apollographql.apollo.api.Upload and use the builtin adapter
overrides the way the operation manifest is connected. Use this if you want to connect the generated operation manifest. For an example you can use this to send the modified queries to your backend for whitelisting
overrides the way operationOutput is connected. Use this if you want to connect the generated operationOutput. For an example you can use this to send the modified queries to your backend for whitelisting
Overrides the way the generated models are connected. Use this if you want to connect the generated models to another task than the default destination.
A helper method to configure a PackageNameGenerator that will use the file path relative to the source roots to generate the packageNames
Configures operation safelisting (requires an Apollo Studio account)