jydv402/memno

1. Project type and runtime

- Memno is a Flutter/Dart client application with a shared codebase targeting Android and Windows as the primary platforms.

- The repository also contains standard Flutter scaffolding for iOS, macOS, Linux, and Web, but the product focus is clearly on mobile + desktop.

2. Top-level architecture

- The app is organized into three main layers:

- UI layer in lib/mobile and lib/desktop

- Logic/data layer in lib/logic

- Platform shells in android/, ios/, macos/, linux/, windows/, and web/

- This is a local-first offline app, not a backend-driven system.

3. Application entry and platform split

- lib/main.dart is the entry point and likely decides which experience to launch based on platform.

- The app has two distinct UI shells:

- Mobile flow centered around home.dart and lib/mobile/...

- Desktop flow centered around lib/desktop/desktop_shell.dart and desktop pages/components

4. Mobile UI subsystem

- lib/mobile/components contains reusable mobile surfaces such as:

- inner page navigation

- settings page

- share-target handling

- toast feedback

- subtile/list item widgets

- lib/mobile/home.dart is the main mobile landing experience.

- The mobile side is optimized for compact navigation and sharing/importing content into the app.

5. Desktop UI subsystem

- lib/desktop provides a dedicated widescreen experience with:

- a dock/sidebar

- a search overlay

- desktop note pages

- settings pages

- specialized cards/tiles/notifications

- This side is explicitly tailored for keyboard-driven navigation and productivity workflows.

6. Data model and persistence

- lib/logic/database contains Hive-backed persisted models:

- code_data

- preview_data

- toggles_data

- The presence of generated .g.dart files indicates Hive type adapters and strongly suggests local on-device storage as the system of record.

- The app stores notes, links, preview metadata, and user toggles/settings locally for offline access.

7. Core functional services

- lib/logic/functionality holds the non-UI application services:

- code_gen.dart for generating the unique 6-digit access codes

- preview_map.dart and related utilities for metadata/preview extraction and mapping

- link_utils.dart for URL handling

- import_export.dart for moving data in and out of the app

- check_update.dart for release/update checks

- These services form the main business logic boundary between UI and persistence.

8. Primary data flow

- The main user flow is:

1. User saves a link and adds a note

2. Link utilities normalize/inspect the URL

3. Metadata/preview logic fetches or maps title/description/image

4. A 6-digit code is generated

5. The record is stored in Hive

6. Mobile or desktop UI reads from the same local store to render cards, search results, or detail pages

- Because the app is offline-first, read and write paths stay local after the initial metadata fetch.

9. Cross-cutting UI concerns

- lib/logic/theme/app_colors.dart centralizes color/theme definitions.

- The README also calls out dark mode support, so theme selection is part of the shared app shell rather than isolated to one screen.

- Settings/toggles are persisted separately so UI preferences survive restarts.

10. Share/import and external entry points

- The mobile folder includes a share-target page, which suggests the app can receive links from the OS share sheet and convert them into saved entries.

- import_export.dart provides another integration boundary for transferring library data without a server.

11. Platform integration

- Each native folder is the standard Flutter embedder layer for its platform:

- Android uses Kotlin MainActivity

- iOS/macOS use Swift app delegates and Xcode projects

- Windows uses the C++ runner/installer stack

- Linux uses a C++/CMake runner

- These folders mostly wrap the shared Flutter runtime; the app’s actual product logic remains in lib/.

12. Packaging and distribution

- The repository includes Fastlane metadata for Android store/release packaging and a Windows installer script under windows/installer.iss.

- Assets such as icons, branding images, screenshots, and fonts are bundled for app presentation and distribution, not core behavior.

13. Testing and CI

- test/widget_test.dart provides Flutter test coverage.

- .github/workflows/main.yml indicates CI automation for build/test validation.

- This is a relatively lightweight test surface compared with the app itself, so runtime architecture remains centered on the shared Flutter client.

14. Diagram takeaway

- If you are drawing the architecture, the key boxes are:

- Flutter app shell

- Mobile UI

- Desktop UI

- Local Hive storage

- Link/preview/code-generation services

- Platform wrappers and packaging

- The main arrows are:

- user interaction → UI → logic services → local database

- share/import/update-related flows feeding into the same logic layer

- shared data store powering both mobile and desktop experiences