[EPIC] MMEX V2 Rewrite: Modernizing the Android App with Clean Architecture & Jetpack Compose

[wolfsolver]

🚀 The Vision: MMEX Android V2

The current Android codebase has served us well over the years, but it's built on older technologies (XML layouts, legacy patterns) that make adding new features, maintaining the app, and achieving high performance increasingly difficult.

It’s time for a major leap forward. I am proposing (and starting) a complete rewrite of the MMEX Android app from scratch, targeting a fully modern Android stack.

Video

---

🏗 Architectural Guidelines & Tech Stack

To ensure this rewrite is sustainable, highly testable, and ready for future integrations (like MMX Sync / PocketBase syncing), we are adopting strict architectural rules.

Core Stack:

• Language: 100% Kotlin (idiomatic, using sealed classes and scope functions).
• UI Toolkit: Jetpack Compose + Material Design 3. (No XML, Fragments, or RecyclerViews).
• Asynchronous Programming: Kotlin Coroutines & Flow (StateFlow / SharedFlow).
• Dependency Injection: Hilt.
• Database: Room (with KSP).

Clean Architecture Structure:
We are strictly separating concerns into three layers:

1. domain: The core of the app. Pure Kotlin models (DTOs) and Use Cases. No Android or database dependencies.
2. data: The only layer aware of Room and external sources. It maps our legacy database into clean domain models via Mappers.
3. presentation: Jetpack Compose UI and ViewModels (MVVM/MVI pattern). UI components must be stateless, and state is hoisted via StateFlow.

---

🛡 The Legacy Database Rule

The existing SQLite desktop database schema is strictly untouchable. To maintain 100% compatibility with the desktop version of Money Manager Ex, we cannot alter the tables.

• Room will be configured using createFromFile() to hook into the existing .db.
• We will use Room @Entity and @ColumnInfo to map the legacy naming conventions, but these entities must never leak into the presentation or domain layers. They will be immediately mapped to clean Domain Models.

---

🛤 Execution Strategy: The Strangler Fig Pattern

To avoid breaking the current app and to keep the repository stable, we are not refactoring "in place".

1. New Module: All new code will live in a completely isolated module called :app_v2.
2. Vertical Slices: We will not build horizontal layers (e.g., "all DAOs first"). We will develop feature by feature (Vertical Slices): Database -> Mapper -> UseCase -> ViewModel -> Compose UI.
3. Phase 1 (Read-Only MVP): The first milestone is building a read-only MVP (Homepage Dashboard, Accounts list, and Transactions) to validate the Room integration and the new Compose UI without risking data corruption.

---

🤝 Feedback & Contributions

This is a massive undertaking, but the result will be a lightning-fast, beautiful, and easily maintainable app.
I'd love to hear feedback from the community on this architectural approach. If anyone wants to jump in, let's coordinate in the comments below to assign specific vertical slices!

screen preview

[JoshuaLampert]

Sounds interesting. I can help a bit with testing. If the language is still debatable, one could also think about using flutter (dart). Together with AI, I recently built an app with it and it is a really powerful and at the same time easy -to-use and modern tool. With the same code, you can not only build Android apps, but also for basically every other platform you can think of (edit: I just learned Kotlin can also do multiplatform). But if you want to use Kotlin, that is of course also fine and understandable. It is only an idea :)

[velmuruganc]

Good to see the initiative for taking the app next level modern UI. I am not a development professional by role and I have limited development knowledge, so someone should set the foundation. Then I can take few task which can be completed by my self. Obeously I can do testing as well.

May be we should look for opportunities to use the AI here. Yesterday, i fixed 3-4 issues using AI and implemented show/hide balance and summary of asset report using AI. I didn't do any coding by my self. Just I spent time to prepare proper prompts.

[wolfsolver]

Hi! Thanks a lot for feedback. Having you on board for testing will be absolutely invaluable as soon as the first MVP slices are ready! 🚀

Regarding Flutter: I totally agree that it is a fantastic and powerful tool for cross-platform development (and AI loves Dart!). However, for this specific rewrite, I've decided to stick with native Kotlin and Jetpack Compose for a few critical architectural reasons:

• Legacy Database Mapping: The biggest challenge of this rewrite is handling the existing, strict desktop SQLite schema without breaking compatibility. Android's native Room library gives us compile-time query validation and incredibly robust mapping annotations that are hard to replicate safely in Dart with sqflite.

• Modern UI: Jetpack Compose uses the exact same declarative, state-driven paradigm as Flutter, so we still get all the modern UI benefits and fast development cycles.

• Future Proofing: If we ever want to go cross-platform in the future, we can leverage Kotlin Multiplatform (KMP), sharing our Clean Architecture layers while keeping native performance.

I really appreciate the idea though, it's exactly the kind of technical discussion I want to encourage here. I'll definitely ping you when the first :app_v2 module builds are ready for some stress testing! Let's keep in touch.

[JoshuaLampert]

Thanks for the explanation. I honestly don't have enough knowledge to judge this so I trust your decision. And yes using Kotlin Multiplatform at some point for cross-platform sounds promising (but Android should have priority). Did not know before that Kotlin can also do cross-platform :)
I'm really looking forward to the first prototype! At the same time, I am hoping the current AMMEX keeps maintained and supported for a while at least until the rewrite has reached feature parity.

[wolfsolver]

Yes, for sure. Right now I'm working on two major functions:

• new UI
• sync server

[fisgathub]

Hello! This might not be the right forum, but I’d like to offer some suggestions for features not currently in the app that I believe could be included in an updated version:

1. An option to display the installment number (e.g., "1 of 10") for payments or outstanding items in statements and reports. Currently, you can only see outstanding installments within the "future transactions" view; once they are processed or recorded, the specific installment number is no longer visible.

2. An option to toggle the display of cumulative monthly balances in statements and reports. For example, the ability to choose not to add the balance from Month X to the balance of Month Y (and so on). This could be controlled via a simple checkbox.

3. An option to record or process all scheduled/future transactions at once. Currently, you can only process, skip, or record these transactions—which are normally set for a specific due date—one by one.

4. An option to adjust category visibility in statements, reports, and charts so that either the main category or the subcategories are displayed, preventing the views from becoming cluttered. Currently, the display format is "Main Category: Subcategory X: Subcategory Y." I suggest simplifying this to show just the "Main Category," "Subcategory X," or "Subcategory Y," with easily selectable options.

[sbushell3-code]

Sounds like a fantastic project !
Unfortunately I'm not experienced in the app tech side of things to help much 😕
SQL I could, but seems from above that that's not changing.
Would definitely help with user testing when the time comes.

Would like to ask, if this would help GRM compatibility between desktop & mobile (android).
Currently it seems the dB & charting libraries have significant differences - would be great to have them working seamless as you hop between devices.

Thanks & good luck 🤞