Modularize Cahier codebase following Now in Android architecture

[hmzgtl16]

Migrate the current single-module monolith into a structured multi-module architecture adhering to Now in Android (NiA) guidelines. By introducing distinct App, Feature, and Core layers driven by centralized Gradle convention plugins, we will isolate complex low-latency inking APIs, improve build performance, and establish clear separation of concerns across the project.

[muhmmadnabil]

Hi, I would like to work on this issue.

I spent some time checking the current Cahier codebase and comparing it with the latest Now in Android modularization approach. Before starting the implementation, I wanted to share the direction I am thinking about and confirm that it matches what the maintainers expect.

At the moment, Cahier has only two Gradle modules: :app and :ink-proto. The packages are already grouped into core, feature, and developer areas, but the boundaries are not enforced by Gradle yet. There are also a few dependency directions that need to be cleaned up before moving files:

• core:data currently imports UI classes, drawing code, and brush-designer database types.
• NoteDatabase depends on CustomBrushDao and CustomBrushEntity from the brush-designer package.
• The current core:navigation package imports and creates all feature screens, so it is really app-level composition.
• Drawing accesses CustomBrushDao and other brush-designer implementation details directly.
• Home imports DrawingDetailThumbnail from drawing, while text imports preview code from home.
• MainActivity knows about BrushGraphRepository.
• The current Converters class mixes Room conversion and Ink stroke serialization.
• All Compose, Room, Hilt, Ink, protobuf, Coil, navigation, and testing dependencies are configured in :app.

Because of this, I do not think moving the existing packages directly into modules would work cleanly. It would create circular dependencies. I would first correct the dependency boundaries, then extract the modules incrementally.

Proposed module structure

App

• :app

This module would contain only application-level code: CahierApplication, MainActivity, external intent handling, root app scaffolding, and the root navigation graph.

Core

• :core:common — coroutine dispatchers/scopes, qualifiers, and small shared utilities
• :core:model — public models such as Note and NoteType
• :core:database — Room database, entities, DAOs, migrations, and Room converters
• :core:data — repository contracts and implementations, model mappings, image storage, and custom-brush persistence
• :core:ink — AndroidX Ink integration, stroke codecs, texture storage, built-in brushes, rendering primitives, and the shared drawing surface
• :core:ink:proto — the existing :ink-proto Java/protobuf module
• :core:designsystem — Cahier theme, typography, colors, generic dialogs, and reusable visual components
• :core:ui — shared note previews, drawing thumbnails, drag/drop UI, and higher-level shared Compose components
• :core:navigation — common navigation contracts only; it should not know about feature implementations
• :core:testing — fake repositories, coroutine rules, shared fixtures, and the Hilt test runner

Features

I propose following the current NiA api / impl feature structure:

• :feature:home:api / :feature:home:impl
• :feature:text:api / :feature:text:impl
• :feature:drawing:api / :feature:drawing:impl
• :feature:brushdesigner:api / :feature:brushdesigner:impl
• :feature:brushgraph:api / :feature:brushgraph:impl

The API modules would contain only route/navigation contracts. The implementation modules would contain screens, ViewModels, UI state, resources, and feature-internal logic.

I would keep Settings inside the home feature for now because it is not an independent destination. I also would not add an empty domain module yet. If shared or complex use cases appear while doing the refactor, we can introduce :core:domain when there is a real need for it.

Dependency rules

The dependency direction I would enforce is:

1. :app can depend on feature and core modules.
2. A feature implementation can depend on its own API and the core modules it needs.
3. A feature implementation may depend on another feature API only when necessary, but never on another feature implementation.
4. Core modules must never depend on app or feature modules.
5. Features use repositories, not DAOs or Room entities.
6. Navigation passes IDs or small route arguments, not database entities or graph objects.
7. Shared code moves to core only when it is really used by multiple features.
8. Dependencies use implementation unless a type intentionally belongs to the public API.
9. Most declarations inside a module should become internal.

Boundary cleanup

Some concrete changes I think are needed:

• Split the current Room-annotated Note into a public Note model and an internal NoteEntity, with explicit mapping functions.
• Move CustomBrushEntity, CustomBrushDao, and AUTOSAVE_KEY into :core:database.
• Add a CustomBrushRepository so drawing, brush designer, and brush graph no longer access the DAO directly.
• Split Converters into a Room-only converter and an Ink StrokeCodec.
• Move CustomBrushes, CahierTextureBitmapStore, Ink resources, stroke serialization, and DrawingSurface into :core:ink.
• Replace the shared CahierUiState with feature-owned states such as HomeUiState, TextEditorUiState, and DrawingUiState.
• Move CahierApp and CahierNavHost into :app.
• Give every feature its own route contract, such as TextNoteRoute(noteId) and DrawingRoute(noteId).
• Move DrawingDetailThumbnail to shared UI so home does not depend on drawing implementation.
• Move generic brush editor widgets used by both brush designer and brush graph into shared UI/design system.
• Replace the MainActivity -> BrushGraphRepository dependency with a small brush import contract/use case.

For this issue, I would prefer to keep the existing Navigation Compose version while modularizing it. The latest NiA uses Navigation 3, but changing the navigation library and the whole module structure in the same change would make regressions much harder to isolate. Navigation 3 can be handled in a separate follow-up.

Convention plugins

I would add an included build-logic build, similar to NiA, but only with the plugins Cahier actually needs:

• cahier.android.application
• cahier.android.application.compose
• cahier.android.library
• cahier.android.library.compose
• cahier.android.feature.api
• cahier.android.feature.impl
• cahier.jvm.library
• cahier.hilt
• cahier.room
• cahier.roborazzi

These plugins would centralize SDK versions, Java/Kotlin 17, Compose, Hilt/KSP, Room schema configuration, test dependencies, resource prefixes, packaging rules, and Roborazzi setup.

I would also move plugin versions into the version catalog, remove the old root room_version value, and enable type-safe project accessors.

Implementation sequence

I would do the work incrementally, keeping the project buildable after each step:

1. Add the architecture document and convention plugins without moving production source.
2. Extract :core:model and :core:database, preserving the existing Room schema and migrations.
3. Extract :core:ink and move :ink-proto under the core Ink area.
4. Extract :core:data and replace feature DAO access with repository contracts.
5. Extract the design system and shared UI/resources.
6. Move app scaffolding/navigation into :app and introduce feature navigation APIs.
7. Extract home and text.
8. Extract drawing.
9. Extract brush designer.
10. Extract brush graph last, because it is the largest and most connected area.
11. Consolidate shared testing code, update CI/documentation, and measure build performance.

I would keep every step behavior-preserving and avoid mixing unrelated UI changes with the modularization.

Validation

The current unit-test baseline is green with:

./gradlew projects testDebugUnitTest --continue

During the migration I would run, at minimum:

• testDebugUnitTest
• :app:assembleDebug
• lintDebug
• the relevant module tests after every extraction
• instrumented and Roborazzi tests at the major milestones

I would also add/keep specific coverage for Room migrations, Ink encode/decode, custom brush import/autosave, navigation arguments, external CREATE_NOTE and brush-import intents, multi-window behavior, drawing save/load/export, and the brush graph conversion/validation flow.

The main completion criteria would be that :app is only the composition root, Room and Ink have explicit core boundaries, no core module depends on a feature, no feature implementation depends on another implementation, all existing behavior remains unchanged, and the final module graph is documented.

If this direction looks good, could you please assign this issue to me? I would be happy to start with the build-logic/convention-plugin foundation and then send the migration as small, reviewable PRs. I am also happy to adjust the proposed module granularity if you prefer fewer feature API modules.