Integration Libraries

Róbert Papp edited this page Apr 28, 2016 · 9 revisions

Introduction

What are integration libraries?

Glide includes a number of small and optional integration libraries that allow Glide to interface with external libraries. Currently Glide includes integration libraries for performing all http/https operations with Volley and OkHttp.

Why include integration libraries?

We strongly believe that your choice of a client side media library should neither dictate the networking library you use in your app, nor require you to include an additional networking library used only to load images. The integration libraries and Glide's ModelLoader system allow developers to use a consistent platform for all networking operations across their app.

Why isn't xxx library implemented?

Because you haven't written the integration library for it yet! OkHttp and Volley are popular libraries that many developers will find useful, but we certainly don't mean to exclude any other library. If you've written a ModelLoader for another library for your app and want to open source it, we'd love to see pull requests to support additional libraries.

How do I depend on an integration library?

There are two parts to depending on any integration library:

  1. Include the corresponding Maven, Gradle, or jar dependency, because the optional integration libraries are not included in the glide jar dependency.
  2. Make sure the app includes the integration library's GlideModule. For more information on GlideModules, see the Configuration wiki page. For specific instructions for each of Glide's current integration libraries, see below.

Which version should I pick?

The integration libraries are versioned together with the Glide releases, but follow different numbering. Make sure you pick the version that corresponds to your Glide dependency version. Check the Downloads on releases page for versions.

The networking libraries have yet another versioning and the integration libraries depend on those versions via transitive Maven/Gradle dependencies when used through Maven Central/JCenter, you can override the version by explicitly including the networking library dependency.

Volley

Volley is an HTTP library that makes networking for Android apps easier and most importantly, faster.

Volley with Gradle

dependencies {
    compile 'com.github.bumptech.glide:volley-integration:1.4.0@aar'
    //compile 'com.mcxiaoke.volley:library:1.0.8'
}

When you use the @aar qualifier the integration library's GlideModule will be merged into your application's manifest automatically. When using @jar or omitting the qualifier you need include the library module yourself or use the classes in your own GlideModule.

Volley with Maven

<dependency>
    <groupId>com.github.bumptech.glide</groupId>
    <artifactId>volley-integration</artifactId>
    <version>1.4.0</version>
    <type>aar</type>
</dependency>
<dependency>
    <groupId>com.mcxiaoke.volley</groupId>
    <artifactId>library</artifactId>
    <version>1.0.8</version>
    <type>aar</type>
</dependency>

See the corresponding manifest section to include the integration library's GlideModule.

Volley Manually

Download the glide-volley-integration-<version>.jar from the releases page and add it to your Android app's compile classpath.

See the corresponding manifest section to include the integration library's GlideModule.

Volley Manifest

If you build with Maven, Ant, or any build system that does not support manifest merging, you must manually add the GlideModule metadata tag in your AndroidManifest.xml:

<meta-data
    android:name="com.bumptech.glide.integration.volley.VolleyGlideModule"
    android:value="GlideModule" />

Volley Proguard

Regardless of the build system you use, you need to make sure proguard doesn't obfuscate or strip the VolleyGlideModule class so it can be instantiated using reflection. Add the following to your proguard.cfg file (or see the generic section):

-keep class com.bumptech.glide.integration.volley.VolleyGlideModule

OkHttp

OkHttp is an HTTP client that’s efficient by default, perseveres when the network is troublesome and is easy to use.

OkHttp with Gradle

dependencies {
    compile 'com.github.bumptech.glide:okhttp-integration:1.4.0@aar'
    //compile 'com.squareup.okhttp:okhttp:2.2.0'
}

When you use the @aar qualifier the integration library's GlideModule will be merged into your application's manifest automatically. When using @jar or omitting the qualifier you need include the library module yourself or use the classes in your own GlideModule.

OkHttp with Maven

<dependency>
    <groupId>com.github.bumptech.glide</groupId>
    <artifactId>okhttp-integration</artifactId>
    <version>1.4.0</version>
    <type>aar</type>
</dependency>
<!--
<dependency>
    <groupId>com.squareup.okhttp</groupId>
    <artifactId>okhttp</artifactId>
    <version>2.2.0</version>
    <type>jar</type>
</dependency>
-->

See the corresponding manifest section to include the integration library's GlideModule.

OkHttp Manually

Download the glide-okhttp-integration-<version>.jar from the releases page and add it to your Android app's compile classpath.

See the corresponding manifest section to include the integration library's GlideModule.

OkHttp Manifest

If you build with Maven, Ant, or any build system that does not support manifest merging, you must manually add the GlideModule metadata tag in your AndroidManifest.xml:

<meta-data
    android:name="com.bumptech.glide.integration.okhttp.OkHttpGlideModule"
    android:value="GlideModule" />

OkHttp Proguard

Regardless of the build system you use, you need to make sure proguard doesn't obfuscate or strip the VolleyGlideModule class so it can be instantiated using reflection. Add the following to your proguard.cfg file (or see the generic section):

-keep class com.bumptech.glide.integration.okhttp.OkHttpGlideModule

OkHttp 3

OkHttp is an HTTP client that’s efficient by default, perseveres when the network is troublesome and is easy to use.

OkHttp 3 with Gradle

dependencies {
    compile 'com.github.bumptech.glide:okhttp3-integration:1.4.0@aar'
    //compile 'com.squareup.okhttp3:okhttp:3.2.0'
}

When you use the @aar qualifier the integration library's GlideModule will be merged into your application's manifest automatically. When using @jar or omitting the qualifier you need include the library module yourself or use the classes in your own GlideModule.

OkHttp 3 with Maven

<dependency>
    <groupId>com.github.bumptech.glide</groupId>
    <artifactId>okhttp3-integration</artifactId>
    <version>1.4.0</version>
    <type>aar</type>
</dependency>
<!--
<dependency>
    <groupId>com.squareup.okhttp3</groupId>
    <artifactId>okhttp</artifactId>
    <version>3.2.0</version>
    <type>jar</type>
</dependency>
-->

See the corresponding manifest section to include the integration library's GlideModule.

OkHttp 3 Manually

Download the glide-okhttp3-integration-<version>.jar from the releases page and add it to your Android app's compile classpath.

See the corresponding manifest section to include the integration library's GlideModule.

OkHttp 3 Manifest

If you build with Maven, Ant, or any build system that does not support manifest merging, you must manually add the GlideModule metadata tag in your AndroidManifest.xml:

<meta-data
    android:name="com.bumptech.glide.integration.okhttp3.OkHttpGlideModule"
    android:value="GlideModule" />

OkHttp 3 Proguard

Regardless of the build system you use, you need to make sure proguard doesn't obfuscate or strip the VolleyGlideModule class so it can be instantiated using reflection. Add the following to your proguard.cfg file (or see the generic section):

-keep class com.bumptech.glide.integration.okhttp3.OkHttpGlideModule

More Options

Generic Proguard

You have an alternative to keep all possible GlideModule modules:

-keep public class * implements com.bumptech.glide.module.GlideModule

This has the added benefit that it doesn't need to change if/when you change integration libraries, or customize the integration library's behavior. It also includes any additional modules which you may add later and portable between projects.

Overriding default behaviour

All integration libraries have additional options if you're not satisfied with the defaults. For example adding retry-behaviour. See the source code of the integration libraries' GlideModules at /integration/<lib>/src/main/java/<package> for how the default registration is done. You can then modify the behavior by changing the arguments for the UrlLoader.Factory class in your own custom GlideModule.

When overriding default behaviour make sure your custom GlideModule is registered in the manifest and the default one is excluded. Exclusion may mean removing the corresponding metadata from the manifest or using the jar dependency instead of the aar one. For more info on GlideModules see the Configuration wiki page.