byfedin.
← Back to selected workCLICKMONEY / ANDROID CASE STUDY

A complete Android
product, delivered.

Offer discovery and reward flows, with the architecture, analytics and APK update lifecycle behind them.

MY ROLE
Full Android development
CONTEXT
Galaksion · Mobile product
DELIVERY
APK distribution
CORE STACK
Kotlin · Jetpack Compose
01 / PRODUCT & OWNERSHIP

The interface is one part.
The delivery is the whole job.

ClickMoney is a native Android offerwall application. Users browse offers, inspect completion goals and point rewards, track progress, and explore gift-card rewards.

I owned the Android implementation: app architecture, Compose screens, API integrations, session handling, analytics, and APK delivery. The Android app works with backend services for offers, account data, and reward operations.

The screenshots and walkthrough below were captured from the app on a Pixel 9 Pro XL using a demo account.

02 / THE APPLICATION

Actual product.
Actual device.

Offer discovery, goal details, and reward browsing. Open any capture to view it at a larger size.

ClickMoney home screen showing point balance, categories and offer cards
Offer discoveryCategory filters, sorting, and a paginated catalog.
Offer details bottom sheet showing the description, point reward and individual goals
Goals & offer detailsA focused bottom sheet before leaving the app.
Gift-card catalog with location selection and point requirements
Rewards catalogLocation-aware options and visible point requirements.
03 / DEVICE WALKTHROUGH

See the flow.

A 21-second walkthrough of the offer catalog, goal details, and rewards — recorded directly from the Android app.

Recorded on Pixel 9 Pro XL · No audio.

  1. Browse the home offer catalog.
  2. Open an offer’s description and goals.
  3. Close the sheet and visit Rewards.
  4. Return to the catalog.
04 / ENGINEERING DECISIONS

Beyond the screens.

The implementation includes the infrastructure needed to operate an Android app distributed as an APK.

01 / STATE & DATA

Keep the catalog consistent.

Category and sort changes can overlap with pagination and refresh requests. The home screen uses a ViewModel, StateFlow, cancellable jobs, and request-generation tracking to manage loading and stale results.

Compose · Coroutines · StateFlow · Retrofit

See the same approach in open-source code
02 / APK UPDATES

Own the update lifecycle.

APK distribution needs its own update flow. The app supports optional and mandatory updates, resumable HTTPS downloads, size and SHA-256 verification, package/version checks, and installation through Android’s system confirmation.

OkHttp · DataStore · PackageInstaller

03 / PRODUCT ANALYTICS

Track what actually happened.

Analytics distinguish opening an offer’s details, requesting its link, handing that link to another app, and returning. A visible balance increase is tracked separately from completion of a specific offer.

AppMetrica · Event abstraction · Activation tracking

04 / RELIABILITY

Model failure paths explicitly.

The code separates presentation, domain, and data responsibilities, with shared result/error types. Automated tests cover APK downloads, update decisions, installer statuses, offer-return tracking, and notification permission handling.

Hilt · Domain use cases · Unit tests

05 / WHAT THIS PROJECT DEMONSTRATES

Responsibility across
the Android lifecycle.

This project brings together native UI, asynchronous state, backend integration, product analytics, and the operational details of shipping and updating an APK. My scope covered the complete Android implementation.

KotlinJetpack ComposeCoroutines & FlowHiltRetrofit / OkHttpDataStoreAppMetrica
LET’S TALK ANDROID

Have a product
to build↗

Evgenii Fedin · Android Engineer

More work ↗Résumé PDF ↓LinkedIn ↗