Structuring a Single-Activity Android App Without Losing Your Mind

Most Android tutorials still teach multi-Activity navigation, but for an app with 11 learning modules like Englo, that pattern falls apart fast — every screen transition pays an Activity re-creation cost, and shared state between screens becomes a bundle-passing nightmare.

We moved to a Single Activity architecture early: one host Activity, fragment-based navigation for every module, and a custom bottom navigation bar built on a plain LinearLayout instead of BottomNavigationView, which gave us room for a bounce animation and pill indicator that the stock component doesn't support.

The rule that kept this maintainable: fragments own their view logic, but nothing else. Networking goes through a shared Volley request queue, theme state lives in MyApplication backed by SharedPreferences, and no fragment ever reaches into another fragment's state directly. When two screens need to agree on something — like quiz progress — it goes through a single source of truth, not a chain of listener callbacks.

The payoff showed up months later, not on day one: adding the Admin Panel companion app took a fraction of the time it would have if each module had grown its own bespoke networking and state pattern.