Trinea/android-common: an Android cache, list and utility toolkit for Java apps

What Trinea/android-common actually covers

The README describes the project as a collection of cache components, UI widgets and utility helpers. That is a broad scope, and the module list shows how broad: an in-memory and disk image cache, an HTTP cache, a preload data cache with FIFO, LIFO and LRU policies plus persistence helpers; reusable views including a pull-to-refresh and infinite-scroll ListView, a paged Gallery and a responsive ScrollView; and utility classes for downloads, shell commands, packages, resources, files, JSON, strings, collections, silent install, time and random values.

The target reader is a small team shipping a Java Android app. The README says the project exists so that small teams can ship stable products quickly, and the components are the kind of thing every app writes once and then maintains badly. A pull-to-refresh ListView with pagination is a day of work per app if you write it yourself. A disk image cache with an eviction policy is a week if you want it correct. This library packages those answers.

One caveat sits in the README itself. The maintenance section says the codebase has been quiet recently while the components remain in use, and that modernization work is being prepared. The repository is not archived, and the last push was on 2026-03-25. The only release listed is 1.0, dated 2014-03-26 and labelled Android2.3, while the dependency coordinate in Getting Started points at version 4.2.15. Those two version numbers do not line up in the README, so treat the release list as incomplete rather than as a statement about what is current.

How the cache suite and list views fit together

The architecture visible in the README is a library of independent components rather than a framework. There is no single entry point, no application class to initialize and no plugin system. You pull in the classes you need.

The cache suite is the part with the most stated structure. Three cache types are named: image caches that live in memory and on disk, an HTTP cache, and a preload data cache. The preload cache is the interesting one, because the README says it supports FIFO, LIFO, LRU and other policies and provides persistence helpers. That means the eviction strategy is a choice you make at construction time rather than a fixed behaviour, which matters when your access pattern is a feed you scroll forward through rather than a set of items you revisit.

The view components sit on top of that. A pull-to-refresh and infinite-scroll ListView is the pairing most apps need: the refresh gesture triggers a network call, the infinite scroll triggers the next page, and the image cache absorbs the thumbnails. The README does not describe how the list view talks to the cache, so the wiring is presumably left to the caller. That is a design choice with a cost. You get components that do not fight each other, and you also get no opinion about how they should be combined.

The utility layer is the least structured part. DownloadManagerPro wraps the platform download manager, and the shell, package, resource, file, JSON, string and collection helpers are exactly what their names suggest. Silent install helpers are listed, which on modern Android depends on permissions the README does not discuss.

Installing Trinea/android-common and making a first call

The README gives one dependency line for Gradle. Add it to the module that needs the library:

implementation 'cn.trinea.android.common:trinea-android-common:4.2.15'

If you build with Proguard or R8, the README also supplies keep rules. Without them, obfuscation can strip or rename the classes the library expects to find by name:

-keep class cn.trinea.android.** { *; }
-keepclassmembers class cn.trinea.android.** { *; }
-dontwarn cn.trinea.android.**

The README offers a second integration path for older projects: import the library module and add TrineaAndroidCommon under Project Properties, then Android, then Library. That path is for the Eclipse-era build system and does not apply to a Gradle-only project.

For usage patterns, the README points at two places rather than documenting an API inline: the API Guide at trinea.github.io/doc/trinea_android_common and a sample app at github.com/Trinea/AndroidDemo. The README does not show a code example for constructing a cache or attaching the pull-to-refresh ListView, so the first real use starts by reading the API Guide or the sample. Expect to spend the first hour there rather than in the README.

The README also mentions a Dev Tools app on Google Play that browses open source projects, inspects activities, decompiles APKs, picks colors, dumps manifest info and toggles developer options. That is a separate tool for developers, not part of the library dependency.

Where the documentation stops short

The README is a module inventory, not a manual. It lists what exists and where to find more, and it does not describe how any component behaves at its edges.

Several gaps matter for adoption. The README does not document cache size defaults, eviction thresholds or what happens when a disk cache write fails. It does not describe threading: whether cache reads block, whether the list view's pagination callback runs on the main thread, or what the download manager wrapper returns when a download is cancelled. It does not state a minimum or maximum supported Android API level, which is the first thing you check before adding a dependency. It does not mention AndroidX or the support library split at all, and the roadmap section implies the migration to AndroidX has not happened.

There is also a maintenance question the README answers only partly. The last push was on 2026-03-25, and the README says the codebase has been quiet recently. The components are described as remaining in use across the community, but the README does not cite anything that would let a reader verify that, and the release list shows only a 2014 entry. The modernization work it describes, AndroidX migration, a refreshed sample app and expanded tests, is stated as being prepared, not as done. Anyone adopting this should plan on reading source when the documentation is silent.

The license section says Apache License 2.0 and points at a LICENSE file. The repository metadata supplied here lists the license as unknown, so if the terms matter to your organization, read the LICENSE file in the repository rather than relying on either summary.

Comparing it with assembling single-purpose libraries

The realistic alternative is not one competitor but the combination most Java Android projects already use: a networking and image library such as OkHttp with an image loader, a separate pull-to-refresh widget, and hand-written helpers for files, strings and collections.

The difference in approach is scope versus depth. A single-purpose image loader does one thing and typically documents its memory and disk cache behaviour, its threading model and its API level support in detail. Trinea/android-common gives you an image cache, an HTTP cache, a preload cache, list views, a download wrapper and utility classes under one dependency, and documents them as a list of names. You trade documentation depth and a narrow, well-understood surface for breadth and fewer dependencies to track.

That trade favours this library in one situation: a small team on an existing Java codebase that wants pagination, caching and download helpers without introducing several libraries and reconciling their versions. It favours the alternative in another: a new project where the image loader's documented cache behaviour is something you will debug in production, and where an undocumented eviction policy is a liability rather than a convenience.

The utility classes are the part least served by the alternative. File, string, collection, JSON, time and random helpers are the kind of code nobody wants to write, and having them in the same artifact as the caches is convenient. It is also the part most likely to overlap with Kotlin standard library extensions if you are migrating, which reduces the value of the bundle over time.

Maintenance, upgrades and what the version numbers imply

The README gives two version signals that do not agree. Getting Started uses cn.trinea.android.common:trinea-android-common:4.2.15. The release list contains a single entry, 1.0, dated 2014-03-26 and labelled Android2.3. Either the release list is incomplete or the artifact coordinate has moved ahead of what is recorded. A team pinning a version should resolve the coordinate in their own build and confirm what they get, rather than assuming the release list reflects the current artifact.

Upgrade cost is hard to estimate from the README because it does not describe a changelog, a deprecation policy or a compatibility statement between versions. The roadmap mentions AndroidX migration as future work, which is the upgrade that will matter most: if your project has already moved to AndroidX, a support-library-era dependency can force jetifier or manual intervention. The README does not say which side of that split 4.2.15 sits on.

The Proguard rules are a small but real maintenance item. The keep rules cover the whole cn.trinea.android package, which means none of the library's code is obfuscated or shrunk. That is safe, and it also means the rules will keep working only as long as the package name stays the same.

On licensing, the README states Apache License 2.0 and links a LICENSE file. Apache 2.0 is a permissive license with an explicit patent grant, and it requires you to preserve notices. This is not legal advice; if your organization has a policy about third-party dependencies, have it reviewed against the actual LICENSE file in the repository.

Editorial conclusion

Adopt Trinea/android-common if you maintain a small Java Android app that needs paginated lists, image caching and download helpers without assembling several libraries, and if you can accept the 4.2.15 artifact as it stands. Do not adopt it if you are starting a Kotlin or AndroidX-first project, since the README lists the AndroidX migration as future work. Before committing, verify that the Maven coordinate resolves, that your Gradle and Android plugin versions match what the README assumes, and that the Proguard keep rules are in place, because the README does not document an obfuscation-free fallback.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. Trinea/android-common on GitHub