How ahmedsamy98/scribblr works
1. Repository shape
- This is a Flutter mobile app called *scribblr*, focused on articles/blogging.
- The repo is organized around a single Flutter codebase with Android and iOS native shells plus a large Dart UI layer.
2. Primary runtime boundary
- The app’s main logic lives in lib/, while android/ and ios/ contain platform bootstrap code only.
- There is no visible backend service code in the repo, so the architecture appears to be client-first UI with data/models/stores in-app, likely backed by mocked or externally supplied content.
3. Entry point and app composition
- lib/main.dart is the top-level entry point.
- It likely wires together global theme, app routes, and the central store before handing control to the first screen.
- lib/utils/app_theme.dart, colors.dart, constant.dart, and images.dart suggest shared configuration is centralized early in startup.
4. Screen-level architecture
- lib/screens/ is the main navigation layer and contains the app’s user journeys:
- onboarding and walkthrough,
- authentication (sign_in, sign_up, forgot_password),
- profile setup flow,
- dashboard and search/notification/settings,
- article exploration, creation, detail, comments, and profile views.
- The screen tree indicates a multi-stage consumer app with clear funnel boundaries: entry/onboarding → auth/profile setup → main dashboard → content and account management.
5. Dashboard as the hub
- lib/screens/dashboard/ and lib/screens/fragments/ show the main shell is probably tabbed or section-based.
- Fragments such as home_fragment, discover_fragment, my_articles_fragment, and profile_fragment suggest the dashboard is the central container that swaps between major content areas.
6. Reusable UI component layer
- lib/components/ contains most of the reusable presentation pieces: article cards, chips, comment widgets, settings controls, notifications, social login UI, top writers, invite user, FAQ, and progress indicators.
- This indicates a composition-heavy UI architecture: screens are assembled from smaller feature components rather than embedding all widget logic directly in each screen.
7. Domain/data models
- lib/models/ holds app-specific data shapes for articles, comments, notifications, invites, and walkthrough content.
- These models represent the app’s primary domain objects and likely act as the boundary between UI widgets and whatever content source the app uses.
8. Application state
- lib/store/app_store.dart suggests a shared state store for app-wide data such as authentication/session, current user/profile, content lists, or UI state.
- This is the main coordination point between screens and model data, and likely reduces direct coupling between fragments/screens.
9. Assets and generated resources
- assets/ contains content and media organized by domain: articles, authors, icons, and a Lottie animation loader.
- lib/generated/assets.dart indicates generated asset references are used to avoid raw string paths in the UI.
- The presence of article/author assets strongly suggests some screens may render curated or sample content directly from bundled assets.
10. Platform-specific scaffolding
- android/ and ios/ are standard Flutter host projects with launch screens, app icons, manifests, and runner classes.
- The Android entry point is MainActivity.kt; iOS uses AppDelegate.swift.
- These layers are mostly infrastructure and do not appear to contain app-specific business logic.
11. Feature boundary summary
- The app cleanly separates:
- navigation/screens for user journeys,
- components for reusable UI,
- models for domain data,
- store for shared state,
- utils for theme/constants/assets,
- assets for bundled content and visuals.
- That separation is the key structure to capture in an architecture diagram.
12. Likely data flow
- User enters through splash/onboarding/walkthrough, then auth/profile setup, then dashboard.
- Dashboard fragments and article-related screens consume shared state and models, render reusable components, and navigate to detail/edit/settings subflows.
- Notifications, comments, search, and settings appear as secondary flows branching from the dashboard rather than separate top-level apps.
Main entry points: dashboard.dart Dashboard · article_model.dart Models · article_component.dart Components · home_fragment.dart Home
Components 23
Platform Shells
Flutter host projects and native bootstrap code.
App Core
Entry point, shared state, theme, and domain models.
- Main · Top-level app entry that wires startup composition.
lib/main.dart - Theme · Centralized app styling, colors, constants, and image references.
lib/utils/app_theme.dart - App Store · Shared application state and coordination point.
lib/store/app_store.dart - Models · Core data shapes for articles, comments, notifications, walkthroughs, and invites.
lib/models/article_model.dart - Assets Ref · Typed asset references used by the UI layer.
lib/generated/assets.dart
Navigation & Journeys
Primary screens and user flows.
- Splash · Initial app launch screen before onboarding or auth.
lib/screens/splash_screen.dart - Onboarding · Introductory walkthrough and app explanation screens.
lib/screens/on_boarding.dart - Auth · Sign-in, sign-up, and password recovery journey.
lib/screens/auth/sign_in.dart - Profile Setup · Profile completion, country, topics, and discovery steps.
lib/screens/profile_setup/profile_completion.dart - Dashboard · Main app container and navigation hub for content sections.
lib/screens/dashboard/dashboard.dart - Home · Primary content feed and landing fragment.
lib/screens/fragments/home_fragment.dart - Discover · Content discovery fragment inside the dashboard shell.
lib/screens/fragments/discover_fragment.dart - My Articles · User-authored content fragment and article management entry.
lib/screens/fragments/my_articles_fragment.dart - Profile · Account/profile fragment within the dashboard.
lib/screens/fragments/profile_fragment.dart - Article Detail · Detailed article reading and engagement screen.
lib/screens/article_detail.dart - Create Article · Article creation flow and publishing UI.
lib/screens/create_article.dart - Comments · Comment thread and interaction screen.
lib/screens/comments.dart - Search · Search experience available from the main shell.
lib/screens/dashboard/search_screen.dart - Notifications · Notification center for system and generated alerts.
lib/screens/dashboard/notification_screen.dart - Settings · Settings and account management surface.
lib/screens/dashboard/settings_screen.dart
Reusable UI
Shared presentation components used across screens.
- Components · Reusable widgets for articles, comments, chips, settings, social login, and related UI.
lib/components/article_component.dart
Connections 27
- Main → Theme: configure · Startup assembles shared theme and constants.
- Main → App Store: init state · Startup connects global application state.
- Main → Splash: launches · The app starts on the splash screen.
- Splash → Onboarding: next · Initial launch can route into onboarding.
- Onboarding → Auth: continues · Walkthrough leads into authentication.
- Auth → Profile Setup: after login · New users move into profile setup.
- Profile Setup → Dashboard: enters · Completed setup reaches the main app shell.
- Dashboard → Home: tab · Dashboard swaps into the home fragment.
- Dashboard → Discover: tab · Dashboard swaps into discovery.
- Dashboard → My Articles: tab · Dashboard exposes authored content.
- Dashboard → Profile: tab · Dashboard exposes profile/account state.
- Dashboard → Search: tool · Search is opened as a secondary dashboard surface.
- Dashboard → Notifications: tool · Notifications are surfaced from the shell.
- Dashboard → Settings: tool · Settings branches from the main shell.
- Home → Article Detail: open · Feed items navigate into article detail.
- Home → Create Article: compose · Home can lead into article creation.
- Article Detail → Comments: discuss · Detail view opens the comments thread.
- Components → Home: render · Shared widgets compose the home experience.
- Components → Article Detail: render · Article UI is built from reusable components.
- Components → Comments: render · Comment widgets are shared across discussion views.
- Components → Settings: render · Settings screens reuse common controls.
- Assets Ref → Components: binds · Generated asset references feed the shared UI layer.
- Models → App Store: populate · Domain models are coordinated through app state.
- Models → Home: data · Feed content is rendered from app models.
- Models → Article Detail: data · Article detail consumes article domain data.
- Models → Comments: data · Comments screen consumes comment models.
- Models → Notifications: data · Notification screens consume notification models.