Suggest Migration to Declarative Plugin DSL in Android Gradle Build
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 35/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- android, flutter
- Domain
- build-system, mobile
Research direction
Read the linked Flutter migration documentation, then inspect android/settings.gradle and android/app/build.gradle to compare the current legacy plugin application with the proposed declarative structure. The work is done when plugin management and plugins blocks replace the legacy buildscript and apply plugin usage in those files.
Written by the indexing model from the issue text.
Description
Feature Suggestion
Feature Description
I would like to suggest an update for the Android Gradle build configuration within the Firebase Quickstart Flutter project to utilize Gradle's declarative Plugin DSL, moving away from the legacy imperative apply script method. This suggestion aligns with the best practices recommended by Flutter from version 3.16 onwards and aims to enhance build configuration maintainability and facilitate easier future enhancements.
Why Is This Change Important?
- Adherence to Best Practices: According to Flutter's official documentation, the recommended approach for applying Gradle plugins in Flutter projects is now through the declarative Plugin DSL. Adopting this method would ensure the project remains up-to-date with Flutter's best practices.
- Improved Maintainability: By utilizing the Plugin DSL, the project's Gradle plugin management becomes cleaner and more straightforward, improving the overall maintainability of the build configuration.
- Future-Proofing: Preparing the project for potential future updates that could leverage new Gradle features, possibly including the adoption of Kotlin for Gradle scripts.
Proposed Changes
The update would involve modifications to the android/settings.gradle and android/app/build.gradle files to define and apply plugins using the declarative syntax. The key adjustments include:
- Implementing the
pluginManagementandplugins {}blocks insettings.gradlefor managing plugin versions and applications. - Eliminating the legacy
buildscriptblocks and replacing imperativeapply plugin:commands with the declarativeplugins {}block inapp/build.gradle.
- Dominant language
- Dart
- Stars
- 199
- Forks
- 75
- PR merge metrics
- No merged PRs in 30d
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from firebase/quickstart-flutter
-
Difficulty 5/5 Over a week Newbie friendliness 10/100
firebase/quickstart-flutter#116 · 2 comments ·
-
Difficulty 5/5 Over a week Newbie friendliness 15/100
firebase/quickstart-flutter#115 ·
-
ExecutionException: java.lang.NullPointerException: Firebase Messaging component is not present, Open
Difficulty 4/5 3-5 days Newbie friendliness 20/100
firebase/quickstart-flutter#88 · 1 comment ·
-
firebase/quickstart-flutter#13 · 1 assignee ·
All issues in firebase/quickstart-flutter
Similar issues
-
status: needs-triage
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
a2ui-project/a2ui#2782 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
MaikuB/flutter_local_notifications#2832 · 1 comment ·
-
bug triage
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
fluttercommunity/plus_plugins#3979 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
flutter-webrtc/flutter-webrtc#2206 ·
-
from.page-issue
Difficulty 1/5 Under an hour Newbie friendliness 85/100