class MohamedAbdelRahem extends FlutterDeveloper {

  final String currentFocus  = "Offline-First Architecture & Real-Time Sync";
  final String philosophy    = "Learning to build scalable systems, not just apps.";
  final bool   obsessedWith  = Clean Code && Architectural Patterns && SOLID;

  List<String> get coreBeliefs => [
    "Every layer in a system must have a deliberate reason to exist.",
    "The UI is the least important part of an application.",
    "Complexity that serves no domain purpose is disguised technical debt.",
  ];

  String get status => "Junior by title. Senior in discipline.";
}

I am a self-taught Flutter engineer who built my expertise through deep, deliberate study of world-class resources — not tutorials, but real system design. My goal is not to build apps that work. My goal is to build apps that scale, maintain, and survive.

This is what separates me from a typical beginner.

Not what I have built — but how I build.

[ Remote Sources ]         [ Local Persistence ]      [ UI Layer ]
  Firebase Firestore   ──►                        ──►
  Supabase PostgreSQL  ──►   Repository Layer     ──►  ViewModel / Provider
  REST Endpoints       ──►   (Unified Contract)   ──►
                             SQLite Cache         ──►

• Firebase Firestore handles real-time document synchronization through persistent stream listeners — the UI reacts to emissions, never polls.
• Supabase serves structured relational data needs (row-level security, PostgreSQL queries) via typed repository interfaces that the domain layer is never aware of directly.
• SQLite acts as the ground truth for offline-capable features. On reconnection, a reconciliation strategy compares local state against the remote source — conflict resolution is handled at the data layer, invisible to the UI.
• Caching discipline: TTL-based invalidation and stale-while-revalidate patterns ensure the user always sees data — even during network failure.

• All media assets (images, documents, thumbnails) are routed through Cloudinary's delivery pipeline rather than stored as raw blobs in the database.
• Transformation parameters (resize, format conversion, quality compression) are applied at the URL level — no client-side processing, no bloated storage.
• Lazy-loading and progressive rendering are coordinated with Flutter's CachedNetworkImage to ensure fast perceived performance on slow connections.
• This approach decouples media concerns from application logic — a dedicated MediaRepository handles all Cloudinary interactions, exposing clean typed methods to the domain.

• Riverpod manages the application-wide dependency graph and all asynchronous data streams. Code generation (@riverpod) eliminates runtime provider mismatches and produces compile-safe provider references.
• BLoC is reserved for flows that benefit from strict event/state separation — where auditability and testability of every transition matters.
• Provider handles lightweight, widget-scoped state where Riverpod's full power would introduce unnecessary overhead.
• Every consumable state is modeled as a sealed class — the UI is forced to handle every possible outcome at compile time. No silent failures.

  

┌─────────────────────────────────────────────────────────┐
│                    MY THREE LAWS                        │
│                                                         │
│  1. ISOLATE  →  Business logic never touches the UI.   │
│  2. REACT    →  State is a stream, not a snapshot.     │
│  3. SURVIVE  →  Offline is the baseline, not the edge. │
└─────────────────────────────────────────────────────────┘