getActivity/EasyHttp setup, lifecycle control, and request design

EasyHttp's request-object approach for Android APIs

EasyHttp addresses Android HTTP integration where common behaviors such as global parameters, multiple domains, dynamic hosts, logging, caching, timeout retries, and lifecycle cancellation may otherwise require separate application setup. It is intended for Android developers who prefer Java request classes and setters over an annotation-defined API style. OkHttp supplies the underlying HTTP implementation, while EasyHttp adds an object model and built-in request handling around it.

Each endpoint is represented by a request object. The README shows an `XxxApi` class implementing `IRequestApi`. Its `getApi()` method returns the endpoint path, a private field holds a request value, and a setter accepts that value and returns the same API object. A nested `Bean` class can contain the response model with a getter for each field. Locating the request path, parameters, and response type in one class gives the endpoint a visible definition.

This approach differs from passing parameter names and values at every call site. EasyHttp fields can carry comments and annotations at their definition site, so a parameter's purpose is documented once rather than repeated with every invocation. The README also says an individual API class can configure its own `OkHttpClient`, parameter submission, and response handling. Those choices do not have to be repeated throughout the application.

That flexibility creates a real ownership cost. An API class is part of the application's source and may hold mutable request state. Services need conventions for constructing it, setting fields, executing it, and avoiding accidental reuse across different values. The README presents the pattern as simpler, but adopting it means accepting the Java object model rather than merely adding a collection of helper methods.

EasyHttp request cancellation through AndroidX Lifecycle

EasyHttp binds network requests to a `LifecycleOwner` and cancels matching requests when that owner is destroyed. The documented `HttpLifecycleManager` registers a `LifecycleEventObserver`, removes the observer after `ON_DESTROY`, and calls `EasyHttp.cancelByTag(source)`.

This mechanism reduces cancellation boilerplate. The lifecycle owner becomes the request tag, allowing requests associated with that owner to be selected when destruction occurs. The README says this removes the need to distinguish manually between an `Activity`, a `Fragment`, or another supported lifecycle-bearing object. Callers still have to bind requests appropriately, but destruction does not require each request site to retain a separate field solely for cancellation.

The behavior has a specific boundary. The implementation reacts only to `ON_DESTROY`. It does not cancel when a lifecycle owner is merely stopped or backgrounded, and the README does not claim that work continues while an owner is stopped. Code that depends on cancellation during another lifecycle event should not infer that behavior from this observer.

AndroidX is mandatory for this documented integration. EasyHttp uses the AndroidX `Lifecycle` feature, so a project based on the older support-library architecture cannot adopt the framework as documented without resolving that incompatibility. The repository also uses `HttpLifecycleManager.register(LifecycleOwner lifecycleOwner)` rather than a project-independent request controller. This is convenient for conventional Android components, but less natural for workers, services, or other code that does not have an AndroidX lifecycle owner.

Installing EasyHttp 13.8 with Gradle and JitPack

The README integrates EasyHttp through JitPack. It provides different repository instructions for Gradle configurations, so the correct block depends on where the consuming project declares repositories.

For projects using Gradle below 7.0, the README places JitPack inside `allprojects` in `build.gradle`. This makes the remote repository available to project dependency resolution.

allprojects {
    repositories {
        // JitPack 远程仓库：https://jitpack.io
        maven { url 'https://jitpack.io' }
    }
}

For Gradle 7.0 and above, the documented location is `settings.gradle`. This version uses `dependencyResolutionManagement` rather than the project-level repository block shown above.

dependencyResolutionManagement {
    repositories {
        // JitPack 远程仓库：https://jitpack.io
        maven { url 'https://jitpack.io' }
    }
}

After adding the repository, configure the app module's `build.gradle` for Java 8 compatibility and add the EasyHttp and OkHttp dependencies. The OkHttp dependency is explicit in the documented setup even though EasyHttp uses OkHttp internally.

android {
    // 支持 JDK 1.8
    compileOptions {
        targetCompatibility JavaVersion.VERSION_1_8
        sourceCompatibility JavaVersion.VERSION_1_8
    }
}

dependencies {
    // 网络请求框架：https://github.com/getActivity/EasyHttp
    implementation 'com.github.getActivity:EasyHttp:13.8'
    // OkHttp 框架：https://github.com/square/okhttp
    // noinspection GradleDependency
    implementation 'com.squareup.okhttp3:okhttp:5.4.0'
}

A real first request begins with the patterns in `HelpDoc.md`, which the README links as the detailed usage guide. The README excerpt does not provide a complete request execution example, so it would be misleading to invent a builder method or lifecycle registration sequence here. Before adding an API class, confirm that the app uses AndroidX and that its Gradle file can consume both documented coordinates.

Keeping EasyHttp bean fields through ProGuard or R8

EasyHttp applications that shrink their code must preserve response bean fields. The README warns that bean fields may otherwise fail to map to fields returned by the backend. This failure can appear after a successful request: the server returns JSON, but the parsed object contains missing or incorrect values because its field metadata was removed or renamed during shrinking.

The documented solution is a keep rule for the package containing the bean classes. The repository example uses placeholder package segments, which the developer must replace with the corresponding application package.

# 必须要加上此规则，否则可能会导致 Bean 类的字段无法解析成后台返回的字段，xxx 请替换成对应包名
-keep class com.xxx.xxx.xxx.xxx.** {
    <fields>;
}

This rule belongs in the main module's `proguard-rules.pro` file. It preserves fields beneath the selected package so JSON parsing can inspect them during release builds.

The package-wide rule is simple but broad. Keeping every field under `com.xxx.xxx.xxx.xxx.**` can retain model members beyond the exact classes needed by one endpoint. The README does not document narrower per-model rules, supported field annotations, or exclusion patterns. Teams with many data classes therefore need an application-level convention for where bean classes live.

Bean placement also creates upgrade work. Moving or renaming packages without updating the keep rule can silently break release parsing. The first verification step for a new integration should exercise a response model in the build configuration that the application ships, rather than relying only on an unshrunk debug build.

EasyHttp caching, file checks, and accelerated downloads

EasyHttp's comparison table lists HTTP caching, download verification, accelerated downloads, and resumable transfers. These features target Android applications that retrieve files rather than only small JSON responses. The accelerated-download mechanism compares a backend-provided MD5 value with a local file. When the local file exists and its MD5 matches, EasyHttp skips the transfer and invokes the download-success listener.

This is cache reuse rather than accelerated network delivery. The application already has a local copy whose content matches the file identified by the backend, so there is no need to send the full file again. That can reduce waiting time and server traffic for repeated downloads.

The mechanism also depends on backend and storage consistency. A wrong or unavailable MD5 prevents the shortcut from identifying a valid local copy. The README does not explain whether a mismatched file is deleted before downloading, how hash calculation errors are reported, or how the framework handles a partially downloaded destination file. It also does not document cache retention limits or storage validation.

HTTP cache configuration and local-file identity are therefore separate adoption concerns. A team may need the first for ordinary responses and the second for large files, but they should not assume that a matching HTTP cache entry automatically exercises accelerated download. The backend contract for MD5 delivery and the application's storage policy need to be explicit before relying on the shortcut for correctness-sensitive files.

Retrofit, OkGo, and EasyHttp API design differences

Retrofit is the main alternative for teams that prefer an annotation-based service interface and typed method signatures. EasyHttp instead represents a request as a Java object implementing `IRequestApi`, with fields and setters for values. Retrofit's service abstraction is attractive when endpoints map cleanly to fixed method declarations, while EasyHttp gives each request class room to own its path, values, client configuration, submission method, and response handling.

The README compares EasyHttp 13.8 with Retrofit 2.9.0 and OkGo 3.0.4. It lists API 14 as EasyHttp's minimum SDK, compared with API 21 for Retrofit in that table. For OkGo, it lists multiple domains, global parameters, logging, retries, HTTP caching, resumable downloads, and upload progress. The practical difference highlighted for OkGo is where parameters live. OkGo calls use externally defined keys, whereas EasyHttp keeps values in fields belonging to the API object.

Those choices affect maintenance. Field-based definitions keep an endpoint's parameter model and response bean together in source, but teams must establish conventions for mutable request objects. OkGo's external keys require consistent definitions, while Retrofit annotations require integration code for concerns such as dynamic hosts or global headers. EasyHttp packages several of those concerns, trading application assembly for framework dependency.

The README's comparison also identifies features marked as unavailable in the listed Retrofit version, including dynamic hosts, HTTP caching, file verification, accelerated downloads, delayed requests, and automatic lifecycle management. These are comparison-table claims, not measured performance results. No benchmark or project-specific throughput figure is documented.

EasyHttp maintenance, licensing, and upgrade constraints

The repository is not archived. Its last push was on 2026-09-08, and release `13.8` is dated 2026-09-08. The earlier listed releases are `13.6` from 2026-07-11 and `13.5` from 2025-12-14. This provides dated evidence of repository activity, but it does not establish which Android Gradle Plugin, Kotlin, or Java toolchain combinations each release supports.

The repository uses the Apache-2.0 license. Consumers still need to read the repository's `LICENSE` and review the artifacts they actually receive. The documented dependency is hosted through JitPack, so a build may also need approval for that repository. The separate OkHttp dependency introduces another direct version decision that should be recorded and checked for conflicts with other app dependencies.

The README does not document a compatibility matrix, a deprecation schedule, or an automated migration path between EasyHttp releases. Upgrading can therefore require ordinary source review, release-build testing, and validation of request lifecycle behavior. Bean packages must also remain aligned with the keep rule after code moves.

For a first adoption, record the exact EasyHttp and OkHttp coordinates, the Gradle repository configuration, Java compatibility settings, and the `proguard-rules.pro` package rule. Release 13.8 can be pinned, but the repository's current activity does not replace application-level testing of authenticated requests, JSON parsing after shrinking, and cancellation when a lifecycle owner is destroyed.

Editorial conclusion

Adopt EasyHttp when an AndroidX application benefits from Java request objects and lifecycle-bound cancellation, but not when the project cannot use AndroidX or expects Retrofit's annotation-driven model. Verify the Gradle and Java configuration, test the documented request patterns, and confirm that bean fields remain correct after shrinking before updating the EasyHttp dependency.

Frequently asked questions

Official sources

1. getActivity/EasyHttp on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases