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
Android | iOS | Web | Linux | Windows | MacOS | |
---|---|---|---|---|---|---|
Native flavors | ✔️ | ✔️ | ➖ | ➖ | ➖ | ➖ |
Different app icon per flavor | ✔️ | ✔️ | 🔍 | 🔍 | 🔍 | 🔍 |
Different app splash per flavor | ✔️ | 📌 | 🔍 | 🔍 | 🔍 | 🔍 |
Different app splash per dark/light theme | ✔️ | 🔍 | 🔍 | 🔍 | 🔍 | 🔍 |
App signing pre-configuration | ✔️ | 🔍 | 🔍 | 🔍 | 🔍 | 🔍 |
Internationalization | ✔️ | 📌 | 🔍 | 🔍 | 🔍 | 🔍 |
Tag | Description |
---|---|
✔️ | 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 Actions:
- 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.
- A 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/callback
NOTE: The client ID and a client secret are necessary.
- Homepage URL:
- 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 dev
, stg
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:
- Open the
Run and Debug
view. - Select the flavor you want to use and then click the
Play
icon or press theF5
key to start debugging.
Internationalization (app languages)
This project relies on flutter_localizations and follows the official internationalization guide for Flutter.
Adding localized values
- To add a new localizable string, open the
app_<locale ID>.arb
file at thelib/l10n/arb/
folder.{ "@@locale": "<locale ID>", ··· "<valueKey>": "<value>", "@<valueKey>": { "description": "<description>" }, ··· }
- Then add a new key, value and description
{ "@@locale": "<locale ID>", ··· "<valueKey>": "<value>", "@<valueKey>": { "description": "<description>" }, ··· "<newValueKey>": "<new value>", "@<newValueKey>": { "description": "<new value description>" } }
- Generate the localization implementation by running the
flutter gen-l10n
command in the project root folder. - 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
- 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
- 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
- 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. - 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
). - 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/ - 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:
- Download the Coverage Gutters VSC extension.
- Start watching the coverage info with the
Coverage Gutters: Watch
VSC command. - 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
Provides the list of the opensource Flutter apps collection with GitHub repository.