Android-ZBLibrary: an MVP framework built around copy-paste and Base classes

What ZBLibrary solves, and who it is written for

ZBLibrary targets a specific kind of Android project: a Java app with many list screens, network calls, image loading and a standard set of form and picker UIs, built by a team that would rather copy a working Activity than design an architecture. The README states the framework provides an MVP structure plus a development standard it calls View, Data, Event, together with templates and utility classes. The pitch is that the encapsulation layer is thin, so the framework stays compatible with ordinary Android code.

The author's stated programming philosophy is unusually explicit for a README. It includes lines such as "能复制就复制，节约时间避免出错" (copy wherever you can, to save time and avoid mistakes) and "保留原本结构，简单上手容易调试" (keep the original structure, easy to start with and easy to debug). That is not marketing language, it is a description of the intended workflow, and it tells you who the framework is for. If your team's instinct is to build a clean architecture from scratch, ZBLibrary will feel like it is fighting you. If your team ships screens by duplicating an existing Activity and editing it, the framework is shaped around exactly that habit.

The bundled demo app is part of the product, not an afterthought. The README lists two APKs for download, ZBLibraryDemoApp.apk and APIJSONApp.apk, so you can inspect the intended behaviour before reading a line of source. It also links a page of all demo screens and several GIFs covering caching, a place picker and a date picker.

How the MVP structure and the Base classes fit together

The framework's mechanism is inheritance. Rather than asking you to wire a presenter to a view through an interface, ZBLibrary supplies Base classes you extend, and those classes already own the network, list, refresh and caching behaviour. The README names several of them directly: BaseView for custom views, BaseHttpListActivity for HTTP list loading and caching, BaseHttpRecyclerActivity for the RecyclerView equivalent, and BaseTabActivity and BaseTabFragment, whose TopTabBar became customizable in release 21.0.

The data layer is deliberately thin. Entry<K, V> is a two-variable model class, offered so that small Model or JavaBean types do not have to be written at all. JSON is a wrapper around Alibaba FastJson, described in the README as existing to prevent parsing exceptions. HttpManager wraps OkHttp and, according to the README, supports self-signed HTTPS. Demo code named HttpRequest shows how the wrapper is meant to be used. SmartRefreshLayout is built into the Base HTTP activities, so pull-to-refresh and load-more arrive with the base class rather than as separate wiring.

UI conventions are handled through resources as much as through code. The README advertises more than 100 common Styles, so a single line of XML sets a View's attributes and a change to one Style propagates across the app. Immersive status bars come from SystemBarTint applied inside BaseActivity. QR scanning comes from QRCodeLibrary, which the README describes as a modified, trimmed version of the ZXing library. One dependency detail is called out sharply: okio.jar is part of OkHttp and must not be removed, because deleting it produces no compile error but does fail at runtime. That warning is worth taking literally, since it describes a failure that only appears when the app runs.

Installing ZBLibrary and getting a first screen running

The README does not give a Gradle dependency line, but the repository carries a JitPack badge, and the top-level layout is a standard multi-module Gradle project with settings.gradle, build.gradle and gradlew. JitPack publishes from the repository, so the coordinate follows the usual JitPack form with the group and artifact taken from the GitHub path. Confirm the exact version tag on the JitPack page before pinning it, since the README itself does not list one.

git clone https://github.com/TommyLemon/Android-ZBLibrary.git
cd Android-ZBLibrary
./gradlew :app:assembleDebug

Cloning and building the app module is the fastest way to see the framework in its intended state, because app/ contains the demo application. The README states the framework requires Android 4.0.3 or later and Gradle 2.10 or later.

Application-level setup is a single call. Either extend BaseApplication, or call its init method from your own Application subclass. The README gives both forms, and the second one looks like this.

public class DemoApplication extends Application {

    @Override
    public void onCreate() {
        super.onCreate();

        BaseApplication.init(this);
    }
}

After that, the README says to copy the uses-permission and activity entries from ZBLibrary's AndroidManifest.xml into your own manifest. That is the point where the copy-based workflow becomes concrete: the manifest, not a dependency declaration, is where the framework's Activities get registered. If you skip it, the base classes will be present in your build and their screens will not launch.

Where ZBLibrary is the wrong choice

The release history is the first limitation. The newest tagged release is 21.0, dated 2019-08-20, which added customizable TopTabBar support to BaseTabActivity and BaseTabFragment. Before that, 20.0 in June 2019 added a thread pool wrapper class and better full-screen adaptation, and 19.2 in December 2018 added the importantForAutofill attribute for input fields. There is a long gap between that release cadence and the last push on the default branch, which was 2026-03-29. The repository is not archived, and the branch still receives pushes, but anyone expecting frequent tagged releases should read the release list first.

A second constraint is the dependency generation. The README credits SystemBarTint for the immersive status bar, and SystemBarTint is a support-library-era project. The framework's own version badge starts at Android 4.0.3. Whether the current master has been migrated to AndroidX is not stated in the README, and that question matters more than any feature list, because it determines whether the library can coexist with modern AndroidX dependencies in the same build.

Third, the framework is Java-first and inheritance-first. If your codebase is Kotlin with Compose, extending BaseHttpListActivity is not a design you can adopt halfway. ZBLibrary wants to be the top of your Activity hierarchy; it is a poor fit as a small utility dropped into an app that already has its own base classes and its own MVP or MVVM convention. The README also does not document rollback or an upgrade path between versions, so pinning a version and reading its source is the only reliable way to know what changed.

ZBLibrary compared with assembling the same stack yourself

The honest alternative is not a competing framework. It is the same set of libraries without ZBLibrary on top: OkHttp for transport, Glide for images, FastJson for parsing, SmartRefreshLayout for refresh and load-more, and ZXing for scanning. The README names all of these as the components ZBLibrary wraps, which makes the comparison unusually direct. The difference is what the wrapper adds.

If you assemble the stack yourself, you write your own base Activity, your own list-loading and caching logic, your own JSON error handling and your own status bar handling. You get to choose the threading model, the caching key scheme and the parsing fallback behaviour, and you upgrade each library on its own schedule. The cost is that every screen starts from nothing, and consistency across a team depends on discipline rather than on a shared base class.

ZBLibrary inverts that. You inherit list loading, caching, refresh, immersive bars and QR scanning, and the Styles file gives you a single place to change View attributes across the app. The cost is that your upgrade schedule is now tied to the framework's, and the framework's tagged releases stop at 2019. That trade is the whole decision. A team that values a fixed internal convention and can read the source when something breaks gets real speed from the Base classes. A team that wants each dependency current and each abstraction its own will find the wrapper is the part that ages fastest.

Licence and the cost of staying on this version

ZBLibrary is Apache-2.0, and the LICENSE file sits at the top level of the repository. Apache-2.0 is a permissive licence that allows commercial use and modification, and it includes an explicit patent grant. It also requires that you keep the licence and notice files with any redistribution. What that means for a closed-source app shipped through an app store is a question for your own legal review, not something the README answers, and the README does not discuss attribution requirements for the bundled QRCodeLibrary or the other wrapped projects.

Upgrade cost is the practical concern. Because releases are tagged infrequently and the README documents no migration procedure, moving between versions means diffing source rather than following a changelog. The bundled dependencies raise the same issue from the other direction: if you need a newer OkHttp or Glide than the version ZBLibrary pins, you are resolving a conflict inside a wrapper you did not write. The README's warning about okio.jar is a small illustration of the general problem, since it describes a runtime failure that compile-time checks will not catch.

Editorial conclusion

Adopt ZBLibrary if you are starting a Java Android app and want a ready-made MVP convention with Base classes, Styles and demo activities you can copy from, and you accept that the newest tagged release is 21.0 from 2019 while the master branch still receives pushes. Do not adopt it if you are on Kotlin, Jetpack Compose or AndroidX-first architecture, or if you need a documented migration path: the README does not document rollback or version upgrades. Before committing, verify the JitPack artifact resolves for your Gradle version, confirm which AndroidX or support-library generation the current master depends on, and check that the Activities you plan to extend exist in the version you pin.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. TommyLemon/Android-ZBLibrary on GitHub