Skip to content
Mai Trinh
ENVI
Completed

CIPPO

Android developer on CIPPO, a Japanese local-community app (business listings, coupons, membership passes, bookings, and city services) — three and a half years of feature work across the app's main navigation, commerce, and communication areas.

Role
Android Developer
Platform
Android
Period
2022–2026
Client
Confidential client

Project overview

Domain
Local community & commerce — business listings, coupons, membership passes, and municipal services (e.g. garbage-collection schedules), for the Japanese market, as part of a wider platform of Android apps.
Product
CIPPO is an Android app connecting local businesses and residents in Japanese cities: browsing and posting business ads/listings, redeeming coupons and time-limited offers, a paid membership/benefits pass, in-app chat, QR-code scanning, maps, and city-specific information such as garbage-collection schedules. The same codebase is also cloned and rebranded for individual city/company deployments (see architecture notes) — CIPPO itself is the base app within a larger 60+-app platform.
Audience
Residents and local businesses in the Japanese cities CIPPO and its city-specific clones serve — residents browse listings, redeem coupons, use the membership pass, and look up municipal information; businesses post and manage their own listings/offers.
Why it exists
CIPPO gives local businesses a lightweight way to reach residents (listings, coupons, a paid membership pass) while also serving as a municipal information channel for the city it's deployed in — combining commerce and civic information in one app that can be relabeled and redeployed per city.
Problem
Across more than three years, the problems I worked on spanned much of the app's day-to-day surface: keeping the main navigation/hub reliable as new sections were added, building and maintaining business-listing and coupon features, a membership/benefits (welfare) area, in-app purchases, push notifications, in-app chat, and city information like garbage-collection schedules.

My role & contributions

Over my time on CIPPO, I worked across many parts of the Android app: the main navigation hub, business/ad listings and their detail pages, the membership/benefits ('welfare') area, coupon and magazine features, Google Play Billing for in-app purchases, push notifications, in-app chat, maps, and the garbage-collection information feature, plus ongoing work in the app's data layer and its manual dependency-injection setup.

Challenges & solutions

  1. Technical challenges

    Two areas stood out. First, CIPPO's dependency injection is hand-rolled (no Hilt/Dagger/Koin) — a single factory class wires up 196 ViewModels, and extending it safely as new features were added meant understanding and preserving that pattern rather than working around it. Second, the app combines a REST API (Retrofit) with several Firebase services (Realtime Database, Firestore, Auth, Storage, Messaging) across a large, actively-evolving feature set, and keeping data consistent across that hybrid backend while building new features was a recurring concern.

    How I approached it

    For dependency injection, new features were wired into the existing manual factory pattern consistently, rather than introducing a second, incompatible DI approach into an already-large app. For the hybrid backend, features were built to go through the app's existing data-source abstractions (REST vs. Firebase per feature) so the rest of the app didn't need to know which backend a given feature used underneath.

Architecture & technologies

CIPPO is a Kotlin Android app using classic View/XML UI (data binding + view binding, no Compose), an MVVM pattern with a hand-rolled dependency-injection factory (no DI framework), RxJava2 for asynchronous work, and a hybrid backend of a REST API (Retrofit/Gson) plus several Firebase services. The product is also redeployed as separately-branded clones for individual cities/companies (a real, source-verified pattern — this codebase's own git history shows dedicated clone branches for other city deployments), the same clone-per-deployment business model later also used for Biske, though implemented here at the branch level rather than as Gradle product flavors.

Technologies

  • Kotlin
  • RxJava2
  • Retrofit
  • Firebase Realtime Database
  • Firebase Firestore
  • Firebase Crashlytics
  • Firebase Cloud Messaging
  • Glide
  • Google Maps
  • Google Play Billing
  • Branch
  • ZXing

This project demonstrates

This project demonstrates sustained, long-term ownership of a real, actively-evolving production Android app — feature work across navigation, commerce (listings, coupons, billing), communication (chat, push), and civic information, all within a legacy-but-actively-maintained architecture (manual DI, RxJava2, hybrid REST+Firebase backend) over more than three years.

  • Android Development
  • Third-Party Integration
  • Maps & Location
  • Existing System Maintenance
  • Production Debugging

Have a similar project in mind?

Tell me about your product or challenge, and we can discuss how I can help.

Work With Me