A Flutter project template built with BLoC pattern and Clean Architecture principles. This project is configured with three environments (development, staging, production) for both mobile and web platforms.

This project follows Clean Architecture principles:

• Presentation Layer: UI components, BLoC files
• Domain Layer: Use cases, entities, repository interfaces
• Data Layer: Repository implementations, data sources, models

The project uses .env files for configuring different environments:

• .env.development - Development settings
• .env.staging - Staging settings
• .env.production - Production settings

The application's environment is determined by the entry point file used when running or building the app:

• lib/main_dev.dart - Development environment
• lib/main_stag.dart - Staging environment
• lib/main_prod.dart - Production environment

The Android flavors are configured in android/app/build.gradle with three product flavors:

flavorDimensions "environment"
productFlavors {
    dev {
        dimension "environment"
        applicationIdSuffix ".dev"
        resValue "string", "app_name", "Base Project Dev"
    }
    stag {
        dimension "environment"
        applicationIdSuffix ".stag"
        resValue "string", "app_name", "Base Project Stag"
    }
    prod {
        dimension "environment"
        resValue "string", "app_name", "Base Project"
    }
}

For iOS, you need to set up Xcode schemes manually:

1. Open the Runner.xcworkspace in Xcode:

   open ios/Runner.xcworkspace

2. Create three new schemes for each environment:

   • Xcode → Product → Scheme → New Scheme...
   • Create schemes named: Runner-dev, Runner-stag, Runner-prod

3. Configure each scheme:

   • In Xcode, select a scheme → Edit Scheme...
   • Under 'Build Configuration', select 'Debug' for development and staging, 'Release' for production
   • Under 'Arguments', add environment variables:
     • For Runner-dev: FLAVOR=dev
     • For Runner-stag: FLAVOR=stag
     • For Runner-prod: FLAVOR=prod

4. Update Info.plist by adding custom display names for each flavor:

   • Add the key CFBundleDisplayName with value: $(PRODUCT_NAME)-$(FLAVOR)

# Development
flutter run --flavor dev -t lib/main_dev.dart

# Staging
flutter run --flavor stag -t lib/main_stag.dart

# Production
flutter run --flavor prod -t lib/main_prod.dart

# Development
flutter run -d chrome -t lib/main_dev.dart

# Staging
flutter run -d chrome -t lib/main_stag.dart

# Production
flutter run -d chrome -t lib/main_prod.dart

# Development APK
flutter build apk --flavor dev -t lib/main_dev.dart

# Staging APK
flutter build apk --flavor stag -t lib/main_stag.dart

# Production APK
flutter build apk --flavor prod -t lib/main_prod.dart

# Development AAB
flutter build appbundle --flavor dev -t lib/main_dev.dart

# Staging AAB
flutter build appbundle --flavor stag -t lib/main_stag.dart

# Production AAB
flutter build appbundle --flavor prod -t lib/main_prod.dart

# Development build
flutter build web -t lib/main_dev.dart

# Staging build
flutter build web -t lib/main_stag.dart

# Production build
flutter build web --release -t lib/main_prod.dart

When deploying web builds, each environment should have its own deployment:

1. Deploy development build to development server/URL
2. Deploy staging build to staging server/URL
3. Deploy production build to production server/URL

1. Generate code with build_runner:

flutter pub run build_runner build --delete-conflicting-outputs

2. Before committing code, run the analyzer:

flutter analyze

This project uses the following major dependencies:

• flutter_bloc: State management
• get_it: Dependency injection
• dio: HTTP client
• shared_preferences: Local storage
• flutter_dotenv: Environment configuration
• intl: Internationalization support
• intl_utils: Internationalization utilities

This project uses the intl package for internationalization support. The following guide explains how to generate and use locales in the project.

The localization files are organized as follows:

lib/
  core/
    locale/
      l10n/              # ARB files for each language
        intl_en.arb     # English translations
        intl_vi.arb     # Vietnamese translations
      generated/        # Generated localization files

1. Add new translation keys to lib/core/locale/l10n/intl_en.arb:

{
  "newKey": "English text",
  "@newKey": {
    "description": "Description of the translation"
  }
}

2. Add corresponding translations to lib/core/locale/l10n/intl_vi.arb:

{
  "newKey": "Vietnamese text",
  "@newKey": {
    "description": "Description of the translation"
  }
}

3. For translations with parameters, use the following format:

{
  "welcomeMessage": "Welcome to {appName}!",
  "@welcomeMessage": {
    "description": "Welcome message with app name",
    "placeholders": {
      "appName": {
        "type": "String"
      }
    }
  }
}

Run the following command to generate the localization files:

flutter pub run intl_utils:generate

This will generate the necessary files in the lib/core/locale/generated directory.

// Using the generated S class
Text(S.of(context).appTitle)

// Using with parameters
Text(S.of(context).welcomeMessage('My App'))

// Using error messages
Text(S.of(context).errorMessage('Connection failed'))

// Get current translations
final translations = S.current;

// Use translations with parameters
final welcomeMessage = translations.welcomeMessage('My App');
final errorMessage = translations.errorMessage('Connection failed');

class MyCubit extends Cubit<MyState> {
  void showError(String error) {
    // Using translations in cubit
    final message = S.current.errorMessage(error);
    // Use the message...
  }
}

class ApiService {
  void handleError(dynamic error) {
    // Using translations in service
    final message = S.current.serverError;
    // Use the message...
  }
}

1. Create a new ARB file in lib/core/locale/l10n/ (e.g., intl_es.arb for Spanish)
2. Copy all translation keys from intl_en.arb
3. Translate all values to the new language
4. Run flutter pub run intl_utils:generate
5. Add the new locale to LocaleCubit.supportedLocales

1. Always use the generated S class for translations
2. Keep translation keys descriptive and organized
3. Use parameters for dynamic content
4. Add descriptions for all translation keys
5. Maintain consistent naming conventions
6. Test translations in all supported languages
7. Keep translations up to date with UI changes