Files
Krow-workspace/apps/mobile
Achintha Isuru b31a615092 feat: Migrate staff profile features from Data Connect to V2 REST API
- Removed data_connect package from mobile pubspec.yaml.
- Added documentation for V2 profile migration status and QA findings.
- Implemented new session management with ClientSessionStore and StaffSessionStore.
- Created V2SessionService for handling user sessions via the V2 API.
- Developed use cases for cancelling late worker assignments and submitting worker reviews.
- Added arguments and use cases for payment chart retrieval and profile completion checks.
- Implemented repository interfaces and their implementations for staff main and profile features.
- Ensured proper error handling and validation in use cases.
2026-03-16 22:45:06 -04:00
..
2026-02-26 11:17:01 -05:00

KROW Workforce Mobile 📱

This folder holds the mobile app code for the KROW Workforce apps. This project uses Melos to manage multiple Flutter packages and applications.

📂 Project Structure

The project is organized into modular packages to ensure separation of concerns and maintainability.

  • apps/: Main application entry points.
    • client: The application for businesses/clients.
    • staff: The application for workforce/staff.
    • design_system_viewer: A gallery of our design system components.
  • packages/: Shared logic and feature modules.
    • features/: UI and business logic for specific features (e.g., Auth, Home, Hubs).
      • features/client: Client specific features.
      • features/staff: Staff specific features.
    • design_system/: Shared UI components, tokens (colors, spacing), and core widgets.
    • domain/: Shared business entities and repository interfaces.
    • data_connect/: Data access layer (Mocks and Firebase Data Connect SDK).
    • core_localization/: Internationalization using Slang.
    • core/: Base utilities and common logic.

🚀 Getting Started

1. Prerequisites

Ensure you have the Flutter SDK installed and configured.

2. Android Keystore Setup (Required for Release Builds)

To build release APKs/AABs for Android, you need the signing keystores. The keystore configuration (key.properties) is committed to the repository, but the actual keystore files are not for security reasons.

For Local Development (First-time Setup)

Contact your team lead to obtain the keystore files:

  • krow_with_us_client_dev.jks - Client app signing keystore
  • krow_with_us_staff_dev.jks - Staff app signing keystore

Once you have the keystores, copy them to the respective app directories:

# Copy keystores to their locations
cp krow_with_us_client_dev.jks apps/mobile/apps/client/android/app/
cp krow_with_us_staff_dev.jks apps/mobile/apps/staff/android/app/

The key.properties configuration files are already in the repository:

  • apps/mobile/apps/client/android/key.properties
  • apps/mobile/apps/staff/android/key.properties

No manual property file creation is needed — just place the .jks files in the correct locations.

For CI/CD (CodeMagic)

CodeMagic uses a native keystore management system. Follow these steps:

Step 1: Upload Keystores to CodeMagic

  1. Go to CodeMagic Team SettingsCode signing identitiesAndroid keystores
  2. Upload the keystore files with these Reference names (important!):
    • krow_client_dev (for dev builds)
    • krow_client_staging (for staging builds)
    • krow_client_prod (for production builds)
    • krow_staff_dev (for dev builds)
    • krow_staff_staging (for staging builds)
    • krow_staff_prod (for production builds)
  3. When uploading, enter the keystore password, key alias, and key password for each keystore

Step 2: Automatic Environment Variables CodeMagic automatically injects the following environment variables based on the keystore reference:

  • CM_KEYSTORE_PATH_CLIENT / CM_KEYSTORE_PATH_STAFF - Path to the keystore file
  • CM_KEYSTORE_PASSWORD_CLIENT / CM_KEYSTORE_PASSWORD_STAFF - Keystore password
  • CM_KEY_ALIAS_CLIENT / CM_KEY_ALIAS_STAFF - Key alias
  • CM_KEY_PASSWORD_CLIENT / CM_KEY_PASSWORD_STAFF - Key password

Step 3: Build Configuration The build.gradle.kts files are already configured to:

  • Use CodeMagic environment variables when running in CI (CI=true)
  • Fall back to key.properties for local development

Reference: CodeMagic Android Signing Documentation

3. Initial Setup

Run the following command from the project root to install Melos, bootstrap all packages, generate localization files, and generate the Firebase Data Connect SDK:

# Using Makefile (Recommended)
make mobile-install

This command will:

  • Install Melos if not already installed
  • Generate the Firebase Data Connect SDK from schema files
  • Bootstrap all packages (install dependencies)
  • Generate localization files

Note: The Firebase Data Connect SDK files (dataconnect_generated/) are auto-generated and not committed to the repository. They will be regenerated automatically when you run make mobile-install or any mobile development commands.

4. Running the Apps

You can run the applications using Melos scripts or through the Makefile:

First, find your device ID:

flutter devices

Client App

# Using Melos
melos run start:client -- -d <device_id>
# Using Makefile (DEVICE defaults to 'android' if not specified)
make mobile-client-dev-android DEVICE=<device_id>

Staff App

# Using Melos
melos run start:staff -- -d <device_id>
# Using Makefile (DEVICE defaults to 'android' if not specified)
make mobile-staff-dev-android DEVICE=<device_id>

🛠 Useful Commands

  • Bootstrap: melos bootstrap (Installs all dependencies)
  • Generate All: melos run gen:all (Localization + Code Generation)
  • Analyze: melos run analyze:all
  • Test: melos run test:all
  • Help: melos run info (Shows all available custom scripts)

🏗 Coding Principles

  • Clean Architecture: We strictly follow Domain-Driven Design and Clean Architecture.
  • Modularity: Every feature should be its own package in packages/features/. Client and staff specific features should be in their respective packages.
  • Consistency: Use the design_system package for all UI elements to ensure a premium, unified look.