A demo app project made with Flutter for personal favorites GitHub repos

  Flutter App

Flutter App – My Starred Repos

A demo app project made with Flutter

This app shows your favorites GitHub repositories. You can search for other repos, preview them, and star or un-star them.


Features

Platform-specific features

AndroidiOSWebLinuxWindowsMacOS
Native flavors✔️✔️
Different app icon per flavor✔️✔️🔍🔍🔍🔍
Different app splash per flavor✔️📌🔍🔍🔍🔍
Different app splash per dark/light theme✔️🔍🔍🔍🔍🔍
App signing pre-configuration✔️🔍🔍🔍🔍🔍
Internationalization✔️📌🔍🔍🔍🔍
TagDescription
✔️Implemented
📌Not implemented (yet)
Not applicable
🔍Under investigation

Project-wide features

  • Mono-repo structure and management using the melos tool with the available actions (with variants for CI workflows):
    • Clean package.
    • Install package dependencies.
    • Format package source code.
    • Analyze package source code.
    • Test package and generate coverage data.
    • Merge all packages coverage data with coverde.
    • Run entire workflow.
  • Flutter-level flavors by using different entry points per flavor.
  • Conditional features implementation based on the selected build flavor and a given config file.
  • Modular and composable logger with the lumberdash package, which can be easily integrated with Firebase Analytics or Sentry.
  • CI/CD:
    • GitHub Actions:
      • Code formatting
      • Code analysis (considering info and warning level issues as fatal)
      • Unit testing (randomizing tests execution)
      • 100% coverage check (ignoring generated files)
      • Automatic coverage info upload to codecov.io
  • GitHub issue templates.
  • GitHub pull request template.
  • Strong lint rules with the lint package.
  • IDE launch setup:
    • Visual Studio Code
  • Secure app configuration based on a bundled config file (looking for a safer method 🔍).
  • Directional dependency injection independent of the widgets tree with riverpod.
  • Raw OAuth flow implementation with GitHub specifications.
  • ETag-based data caching for basic offline mode support.
  • REST API server integration.
  • GraphQL server integration.

Prerequisites

Required

  • Flutter 2 to build and test the project.You could follow the official docs about installation.
  • GitHub OAuth App to provide auth functionality.You could check the official docs about GitHub OAuth apps creation considering the following parameters:
    • Homepage URL: http://localhost:8080
    • Authorization callback URL: http://localhost:3000/callbackNOTE: The client ID and a client secret are necessary.
  • The melos tool to manage this mono-repo project.You could install it with the flutter pub global activate melos command.NOTE: It is recommended to add the Dart system cache directory to the your PATH environment variable so you can run any dart command globally.
  • The coverde tool to merge coverage tracefiles from each sub-package and other coverage related functionality.You could install it with the flutter pub global activate --source git https://github.com/mrverdant13/coverde.git command.NOTE: It is recommended to add the Dart system cache directory to the your PATH environment variable so you can run any dart command globally.

Working with the project

As described in the Features section, this projects is a monorepo and uses melos to provide easy management of it. Thus, this tool should be previously activated.

The available melos scrips are defined in the melos.yaml file.

In short, the scripts with lowercase names are selective (they get executed for a selected package) and the ones with uppercase names are global (they get executed for all packages in the project). Besides, those scripts named with the :ci ending are the variations used for CI workflows.

To review all available scrips, run melos run in the project root folder and they will be listed with a short description of their functionality.


App configuration

This project uses a YAML file as config data provider and it should be placed inside the assets/config/ folder.

Its name should be app_config.<env_tag>.yaml, where <env_tag> should be replaced by devstg or prod according to your desired flavor.

The schema of this config file should be as described below:

# GitHub auth config data.
githubAuthConfig:
  # GitHub app client identifier.
  clientId: client_id
  # GitHub app client secret.
  clientSecret: client_secret

For easy setup, you can take the assets/config/app_config.sample.yaml sample file.


App flavors

This project supports 3 flavors/environments that provide different properties for the resultant app as described in the Features section.

These flavors can be used directly with the launch configuration in Visual Studio Code or by executing one of the following commands in the project root folder:

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

# Staging
$ flutter run --flavor stg --target lib/main_stg.dart

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

Note 1: The --flavor option only applies for Android and iOS. For other platforms, this options is ignored.

Note 2: The target path separator (\ or /) might change according to the OS.

Note 3: Each flavor use a config file to setup some elements. You should make sure that this file exists.


IDE debugging

Visual Studio Code

Follow these steps on Visual Studio Code:

  1. Open the Run and Debug view.
  2. Select the flavor you want to use and then click the Play icon or press the F5 key to start debugging.

Internationalization (app languages)

This project relies on flutter_localizations and follows the official internationalization guide for Flutter.

Adding localized values

  1. To add a new localizable string, open the app_<locale ID>.arb file at the lib/l10n/arb/ folder.{ "@@locale": "<locale ID>", ··· "<valueKey>": "<value>", "@<valueKey>": { "description": "<description>" }, ··· }
  2. Then add a new key, value and description{ "@@locale": "<locale ID>", ··· "<valueKey>": "<value>", "@<valueKey>": { "description": "<description>" }, ··· "<newValueKey>": "<new value>", "@<newValueKey>": { "description": "<new value description>" } }
  3. Generate the localization implementation by running the flutter gen-l10n command in the project root folder.
  4. Use the new stringimport ‘package:<app_package_name>/l10n/l10n.dart’; ··· @override Widget build(BuildContext context) { final l10n = context.l10n; return Text(l10n.<newValueKey>); } ···

Adding translations

  1. For each supported locale, add a new ARB file in lib/l10n/arb.├── lib │ ├── l10n │ │ ├── arb │ │ │ ├── app_<locale ID>.arb │ │ │ └── app_<new locale ID>.arb
  2. Add the translated strings to each .arb file:app_<locale ID>.arb{ "@@locale": "<locale ID>", ··· "<valueKey>": "<value for locale ID>", "@<valueKey>": { "description": "<description for locale ID>", }, ··· } app_<new locale ID>.arb{ "@@locale": "<new locale ID>", ··· "<valueKey>": "<value for new locale ID>", "@<valueKey>": { "description": "<description for new locale ID>" }, ··· }

Complex use cases

For more complex needs, you could check the following resources:


Testing

  1. To run all unit and widget tests, run the following melos script:$ melos run TNote: This scrip will exclude tests tagged as ci-only, which indicates that they should be run on CI/CD envs only.
  2. To unify the generated coverage data, run the following melos script:$ melos run MNote: This script will discard coverage data related to Dart source code generated with build_runner-based packages (for this project: ~.freezed.dart~.g.dart~.gr.dart).
  3. To generate simple coverage HTML report within the coverage folder, run the following coverde command:$ coverde –input-tracefile coverage/merged.lcov.info –output-report-dir coverage/html/
  4. To open the generated coverage report follow your preferred method:
    • 4.a. Run one of the following commands according to your OS:# Linux $ xdg-open coverage/html/index.html # MacOS $ open coverage/html/index.html # Windows $ start coverage/html/index.htmlNow, within the launched browser window, the test coverage per folder, file and even file content can be reviewed.
    • 4.b. Follow these steps on Visual Studio Code:
      1. Download the Coverage Gutters VSC extension.
      2. Start watching the coverage info with the Coverage Gutters: Watch VSC command.
      3. Navigate throw your files. You will see visual indicators highlighting covered parts with green and uncovered parts with red (as long as you use the default extension configuration but this behavior can be changed).

Issues

Submit a new issue report if you find any bug or have any suggestion.

Download source code on GitHub

https://github.com/mrverdant13/flutter_my_starred_repos/?ref=flutterappworld