Stetho
Stetho is a debug bridge for Android, created by Facebook. It helps you use your Chrome inspector to inspect your app’s Network, DB, View Hierarchy, etc. These are Stetho’s specifications.
This post is about integrating with Android libraries related to Networking (OkHttp — Retrofit, Glide).
TL;DR
Integrating with Stetho
- Add dependencies & proguard
- Initialize Stetho and make Stetho injected OkHttpClient & Retrofit
- Make a Stetho injected glide module to replace a default glide module
- Using GlideApp
- Debugging on Chrome inspector
Extra part
- Separate build variants (Build type)
Integrating with Stetho
Add dependencies & proguard
Add dependencies for network debugging. — Stetho, Glide, Retrofit.
C.F) DebugImplementation is for separating build variants which will be explained in the extra part.
If you are using Proguard, Add some required rules for Glide & OkHttp & Retrofit on your proguard-rules.
Initialize Stetho and make Stetho injected OkHttpClient & Retrofit
Initialize Stetho with an Application context.
C.F) Usually, Stetho is initialized at an Application class.
Make OkHttpClient which is injected Stetho.
Make a Stetho injected glide module to replace a default glide module
Replace a default Glide module with a Stetho-injected Glide module for debugging a glide network. To replace the default glide module, Create an AppGlideModule for connecting Glide and the Stetho-injected OkHttp.
After finishing making GlideModule, Register meta-data at android manifest in the application tags.
C.F) This is for avoiding conflict between your glide module and the default glide module. If you want to know the detail about this, You can explore here.
Using GlideApp
Using GlideApp instead of normal Glide class.
This is because limiting the generated API to applications allows us to have a single implementation of the API in Glide. For more details about this, please visit here.
Debugging on Chrome inspector
Open Chrome and Browse chrome://inspect/#devices for enjoying easy debugging :)
Extra part
It should be a disaster if your application can be debugged on a release build. So We usually use it this way.
if (BuildConfig.DEBUG) {
// initialize
}But this way can make your codes complex and easy to make confused. So For clear and mistake-proof code, Separating builds variants (Build type) will be introduced in this extra part.
Separate build variants (Build type)
It’s already separated by Debug/Release when you make a project. So Only the separating folder is necessary for separating build variants. This is my sample project structure for separating build variants.
Make two directories debug/release like above and Make classes of the same name in each directory as follows.
Your manifest even can be separated by the debug variant as follows. It will be merged automatically with your manifest in the main directory.
C.F) You can change your build variant in the menu in Android Studio as follows.
Your code is completely separated by debugging and release build variables, And It makes you safe from mistakenly leaking your network information.
References
If you’d like to see the full codes for this post
Please feel free to visit here.
